https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4050
David Dombek <david.dombek@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |david.dombek@xxxxxxxxx
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #3 from David Dombek <david.dombek@xxxxxxxxx> 2009-10-16 07:02:02 PDT ---
Sorry for the delay in responding. I was on vacation.
Yes this is an ISUP packet. Your analysis is correct. After the 'End of
optional parameters' there is an extra byte 00.
I am told by my vendor Squire Technologies
(http://www.squire-technologies.co.uk) that they are padding to the 32bit
boundary per the SPEC. I personally don't see this in the SPEC.
However, CISCO says that the packet is not in SPEC.
Here is the text from Comcast and Cisco complaining about the extra byte.
-------------------- snip of email from Comcast/Cisco BTS
Long story short, Coretel is sending an extra octet after the end of optional
parameter. This does not comply with the GR317 spec.
The right way of fixing this is to NOT send the extra octet in the ACM after
the end of optional parameters from the far end (Coretel). Our only option is
to escalate this with Coretel, or we have to wait for a CISCO patch to be in
place , for which I have no idea about ETA nor the patch on when they can fix
it.
As a note, I did open a CISCO case to see if they can patch this to ignore the
extra octet after the end of optional parameters and CISCO gracefully accepted
to implement a patch to do so (Attaching the e-mails from CISCO).
However, there is no ETA for the patch yet.
------------
Some more explanation below and another attempt
1) When we send this call over the 2001 TG, the ACM we receive back (Raw Hex
trace is below)
MSG_TYPE=ACM HEX: d5 13 06 10 14 01 29 01 01 00 00
Here if you see there are 2 octets 00 and 00 at the end. The first 00 octet to
the left indicates the end of optional parameters, and that should have been
it. But they are sending an additional octet 00 towards the right after the
end of the optional parameter, which is the issue here. Actually GR317 does not
clearly define this scenario, but the GR246 Core pasted below clearly explains
this
------------
GR-246-CORE Chapter T1.112.3 Issue 3, December 1998 SCCP Formats and Codes
1.7 End of optional parameters octet
After all optional parameters have been sent, an "end of optional parameters"
octet containing all zeros will be transmitted. This octet is only included if
optional parameters are present in the message.
GR-246-CORE Chapter T1.113.3 Issue 3, December 1998 Formats and Codes
1.8 End of Optional Parameters Octet
When optional parameters are present and after all optional parameters have
been sent an "end of optional parameters" octet containing all zeros will be
transmitted. If no optional parameter is present an "end of optional
parameters" octet is not transmitted.
------------
2) However, if we route the same call to the 85XX TG, the ACM we receive
is below
Good call ACM hex string;
HEX = 18 00 06 00 21 01 29 01 80 00
Here, there is only octet with 00 at the end , which indicates end of optional
parameter.
In the SS7 ISUP world (whether it is ANSI or ITU), the messages are comprised
of 2 parts, mandatory and optional parameters. First the mandatory fields are
transmitted and then the optional parameters if any. If there are any optional
parameters that need to be transmitted, the SG needs to send 00 octet to
indicate the end of optional parameters and that’s the end of it. Them
sending an extra octet 00 after the first 00 is causing the BTS to reject the
ACM
-------------------------------------------
So wireshark doesn't complain about the extra byte and doesn't flag it. Is the
packet formatted correctly or is it a special case that needs to be handled?
Thanks
David
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
