Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Improving logging of match failures
Improving logging of match failures [message #1852494] Wed, 18 May 2022 11:44 Go to next message
Pau Espin Pedrol is currently offline Pau Espin PedrolFriend
Messages: 14
Registered: November 2021
Junior Member
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 104 times)
Re: Improving logging of match failures [message #1852525 is a reply to message #1852494] Fri, 20 May 2022 10:11 Go to previous messageGo to next message
Adam Knapp is currently offline Adam KnappFriend
Messages: 54
Registered: November 2020
Member
Hi,

I added this request to our backlog (https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/606). We will investigate what/how can be improved.
Re: Improving logging of match failures [message #1852530 is a reply to message #1852525] Fri, 20 May 2022 16:09 Go to previous message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 127
Registered: November 2018
Senior Member
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
Previous Topic:Accessing members of super class
Next Topic:Ghost field in record to help RAW encoder choose union member
Goto Forum:
  


Current Time: Wed Oct 09 23:37:13 GMT 2024

Powered by FUDForum. Page generated in 0.04030 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top