ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] GSM MAP: register for range of SSNs

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jeff Morriss <jeff.morriss@xxxxxxxxxxx>
Date: Thu, 17 Mar 2005 10:23:55 -0500

Hi,

I put that preference there as I received a trace where the ssn was outside of the range predefined in the
previous dissector, my reasoning for making it individual ones rather than a range was that I though
the ssn:s used could be "any" rather than a range, I haven't found any documentation giving certain applications
fixed ssn numbers. Is there sutch a document or any convention used? ( GSM-MAP, INAP, CCBS ....)
or is it totally up to the administration?

Hmmm, I don't know.

However, I do tend to get questions like: "Why isn't Ethereal decoding
my GSM MAP message as GSM MAP?  I thought it understood GSM MAP."  I
look and find they're using (in their testing) some unusual SSN (either
because that SSN is their favorite number or because they got forced off
the "usual" SSNs because someone else is testing on those).

Perhaps only two ssn number are realy needed for any particular trace?

Probably yes.

I suppose all dissectors based on ssn should be made the same in this respect?

I would think so (I was thinking of looking at doing that if this patch were accepted).

(Another reason for the patch is simply that I tend to prefer the look-n-feel of one preference with a range to N uint preferences...)

Regards,
-Jeff

-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Jeff Morriss
Sent: den 17 mars 2005 01:12
To: Ethereal Development List
Subject: [Ethereal-dev] GSM MAP: register for range of SSNs



I saw today that the GSM MAP dissector now has a preference for up to 5 TCAP SSNs. Rather than do that I think it would be better if it used the new range preference type.

The attached patch does that and (sorry, I know it makes the patch harder to read) cleaned up some indenting around the code I was changing (which results in the actual code being easier to read).

I didn't register the old prefs as obsolete since README.developer doesn't suggest doing that any more; should it (both my patch and the README)?