Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-2332242.1
Update Date:2017-11-26
Keywords:

Solution Type  Problem Resolution Sure

Solution  2332242.1 :   Event Id 8008 EvRxException,Connection ingress message processing exception.," GN_INFO/INF Diameter message received with an invalid format. events observed in system.  


Related Items
  • Oracle Communications Diameter Signaling Router (DSR)
  •  
Related Categories
  • PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec DSR
  •  




In this Document
Symptoms
Cause
Solution
 References :-


Created from <SR 3-16118421301>

Applies to:

Oracle Communications Diameter Signaling Router (DSR) - Version DSR 7.3.0 and later
Tekelec

Symptoms

Customer is observing following events in DSR:-

EvRxException,Connection ingress message processing exception.," GN_INFO/INF Diameter message received with an invalid format. Connection ID=26, Message Header=0x01 00 02 40 50 00 01 3e 01 00 00 23 80 0b 78 00 6f a2 36 aa ^^ [48771:DiameterLogs.C:831]",1510127363,291000,1510127363,440000,0

Cause

CSL 8008 EvRxException (Connection ingress message processing exception) Event DIAM

A Diameter message is invalid if decoding encounters an invalid header or an AVP which extends beyond the end of the message. As such, an EvRxException event shall be generated for the following reason:
• Diameter message received with an invalid format.

Trigger :- A Diameter message is invalid if decoding encounters an invalid header or an AVP which extends beyond the end of the message.

Solution

As per RFC 6733, the Answers can't have T bit set. Therefore the event reported by DSR is right behavior and as per design. 

RFC 6733, section 3, Diameter Header

>>>>>>>>>>>>>>>>>>

T(Potentially retransmitted message)  

This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possibleduplicate due to a link failure. This bit MUST be cleared whensending a request for the first time; otherwise, the senderMUST set this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request; retransmissions by other entities need not be tracked. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an error answer message (e.g., a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request, and the request has been sent again. 

This flag MUST NOT be set in answer messages.

>>>>>>>>>>>>>>>>>>

So, problem needs to be investigated with peer node as the Peer node is returning the Answer message with T bit set in response to Request message which is not in line with specifications.

References :-

https://tools.ietf.org/html/rfc6733
 


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback