Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 2861] New: ANSI SCCP address decode problem?

Date: Tue, 9 Sep 2008 13:37:49 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2861

           Summary: ANSI SCCP address decode problem?
           Product: Wireshark
           Version: SVN
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: Neil@xxxxxxxxxxxxxxxxxx



Neil Piercy <Neil@xxxxxxxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2228|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=2228)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2228)
Possible patch to fix - please check!

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
There is a problem with called/calling party address dissection in
packet-sccp.c in the case of ANSI and the Address Indicator bit 8
(National/International Indicator) is zero, indicating International.

I say there is a problem, but I'm not exactly sure what the dissection should
be, so let me just layout the facts I do know.

In this case the "national" variable is zero, and the code goes into the if
clause along with the 3 ITU variants (line 1259), and not the ANSI else if
(line 1364) clause. Later in this if ITU clause it goes into there is an if
ITU, else if JAPAN, else /* Chinese */, and in the case of ANSI with
national=0, it drops into the final else /* Chinese */ clause - I'm pretty sure
that is wrong no matter what, hence this bug report.

I also have a trace with ANSI and national=0 which has the address layed out in
the ANSI way (SSN before PC) rather than the ITU way (SSN after PC) - but since
this is from a test environment, I'm not 100% convinced that the
equipment/trace is correct, but I _think_ it is. All other ANSI traces I've
seen have the nationl bit set to 1, and conform to the ANSI SSN before PC
order.

So what does the spec say? Well it (T1.112.3) says for bit 8 = 0 that "both the
address indicator and the address are coded according to international
standards", but nowhere I can find does it qualify this with exactly what this
means, and I think this may be the reason the national=0 case goes into the ITU
clause, but I'm not convinced it should.

Attached is a patch which just removes the national flag from causing entry to
the if ITU clause - which fixes the issue for the trace I have - but I could
really do with an ANSI SCCP expert to give a review (I'm an ITU man myself!).

Regards,
Neil


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.