Home » Eclipse Projects » Eclipse Titan » Improving logging of match failures
| Improving logging of match failures [message #1852494] |
Wed, 18 May 2022 07:44  |
Eclipse User |
|
|
|
Hi,
I'm currently trying to write some templates matching some long/complex Diameter messages with lots of AVPs, and I'm really struggling to find where it fails to match each time I run TTCN3.
Each time I have to run the test, then go to the merged log file, run ttcn3_logformat, find where the message was received to find out the line ("unmatched: First message in the queue does not match the template"), then split the rx message output and the expected message template (at the "with" keyword) into 2 different files, and finally use some diff tool like meld. Even then it's extremely hard to find out where the match failed (de to use of superset(), etc.)
See for instance this template:
template (present) PDU_DIAMETER
tr_DIA_Gy_CCR(template (present) DCC_NONE_CC_Request_Type req_type := INITIAL_REQUEST)
:= tr_DIAMETER(flags:='11000000'B, cmd_code:=Credit_Control,
avps := superset(
tr_AVP_SessionId,
tr_AVP_OriginHost,
tr_AVP_OriginRealm,
tr_AVP_DestinationRealm,
tr_AVP_AuthAppId(int2oct(c_DIAMETER_CREDIT_CONTROL_AID, 4)),
tr_AVP_ServiceContextId,
tr_AVP_CcReqType(req_type),
tr_AVP_CcReqNum(?),
tr_AVP_EventTimestamp(?),
tr_AVP_SubcrId({tr_AVP_SubcrIdType(END_USER_IMSI), tr_AVP_SubcrIdData(?)}),
tr_AVP_SubcrId({tr_AVP_SubcrIdType(END_USER_E164), tr_AVP_SubcrIdData(?)}),
tr_AVP_RequestedAction(DIRECT_DEBITING),
tr_AVP_3GPP_AoCRequestType,
tr_AVP_MultipleServicesIndicator,
tr_AVP_Multiple_Services_Credit_Control(content := superset(
tr_AVP_Requested_Service_Unit,
tr_AVP_Used_Service_Unit, /*TODO: Implement internals of this? */
tr_AVP_3GPP_QoS_Information,
tr_AVP_3GPP_RatType
)),
tr_AVP_3GPP_ServiceInformation(content := superset(
tr_AVP_3GPP_PSInformation(content := superset(
tr_AVP_3GPP_ChargingId,
tr_AVP_3GPP_PDPType,
tr_AVP_3GPP_PDPAddress,
tr_AVP_3GPP_SGSNAddress,
tr_AVP_3GPP_GGSNAddress,
tr_AVP_3GPP_CalledStationId,
tr_AVP_3GPP_SelectionMode,
tr_AVP_3GPP_ChargingCharacteristics,
tr_AVP_3GPP_SGSNMCCMNC,
tr_AVP_3GPP_NSAPI,
tr_AVP_3GPP_MS_TimeZone,
tr_AVP_3GPP_ULI,
tr_AVP_UserEquipmentInfo({
tr_AVP_UserEquipmentInfoType(IMEISV),
tr_AVP_UserEquipmentInfoValue
})
))
))
));
And this is something I get in the log when the message fails to match:
(attached due to being a long file).
Titan version: 8.1.0.r43.g6be5a7f23
So now the question is: Why isn't the log providing more detailed info on where the match failure occurred? For instance one time I used a ts_AVP template by error instead of tr_AVP, so it failed to match against length:=0, but still the logging just showed the entire message.
Having some logging stating "length:=34 vs exp length:=0" would be really helpful in here and save a lot of time. IIRC I saw this behavior already when using simpler templates? Maybe it's due to use of supserset() that I don't get those?
In any case, it would be great to at least have a more similar formatting between the received message and the expecteds template when ttcn3_logformat is used. If you check log.txt and split and use meld you'll see that "}, {" and similar stuff is not formatted using the same whitespace rules.
Attachment: log.txt
(Size: 60.30KB, Downloaded 121 times)
|
|
| |
| Re: Improving logging of match failures [message #1852530 is a reply to message #1852525] |
Fri, 20 May 2022 12:09  |
| Eclipse User |
|
|
|
Hi all, just to report my experience on this issue:
I am working with the MCX and IMS conformance test suites developped at ETSI TF160 and face similar problems when receiving complex messages like the SIP INVITE where the expected receive template is build from a hierarchy of templates of templates containing superset and alternatives like (templateA, templateB) within other generic templates.
- Firstly a mismatch when using superset seems to be difficult to properly log and sometimes additional TTCN code is needed to correctly find out what goes wrong
- For debugging, I rewrite the altstep with the receive statement passing a simple receive template and once the call setup is completed I verify the SIP INVITE that it exactly matches the expected template as follows:
If (not (match(v_ReceivedInviteHeader, v_ExpectedInviteHeader)) {
log(match(v_ReceivedInviteHeader, v_ExpectedInviteHeader)); // hopefully log out exactly what went wrong
f_IMS_SetVerdictFailOrInconc("Invalid SIP INVITE"); // Fail and stop exec
}
Regards,
Olaf
|
|
|
Goto Forum:
Current Time: Mon Mar 10 21:48:41 EDT 2025
Powered by FUDForum. Page generated in 0.03163 seconds |
Home