ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

Date: Mon, 15 Sep 2008 13:18:29 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2861


Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff.morriss.ws@xxxxxxxxx
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>  2008-09-15 13:18:28 PDT ---
(In reply to comment #0)
> 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.

Well "international" generally means ITU so that's the way I had coded it
originally (of course back then neither the Japan nor China variants were
decoded so this bug wasn't there).  The reality, though, is that I've never
seen a (real) ANSI message with National == 0 and I think many systems would
not handle it, well, not "correctly" but even in the same manner.

Anyway I checked in a different fix (add national==0 to the ITU case when
decoding the PCI) in rev 26210 to preserve the original intended functionality
(at least until someone comes along and tells me/us otherwise).


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