http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2509
--- Comment #3 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2008-04-29 10:48:50 GMT ---
Hmmm, I'm not sure I agree that your patch makes sense.
The assoc data is supposed to span multiple messages (I guess it's named
"assoc" so that multiple messages are "assoc"iated together?). I think its
primary purpose is for Class-2 where the data messages don't have the SSN on
them: this structure lets us know what the SSN for the _connection_ is.
I'm not clear why it's used for connectionless, though.
It does appear to make the assumption (in get_sccp_assoc()) that any messages
between 2 PCs would be on the same SSN which explains your problem: the first
messages are SCCP-management (Called and Calling SSNs are 1) and subsequent
messages between the same PCs are not (probably Called SSN==X and Calling
SSN=Y).
Because the code in dissect_sccp_data_param() prefers to use the Called or
Calling SSN depending on which direction Wireshark thinks the message is going,
I'm guessing that you're seeing messages in one direction being dissected as
RANAP but the messages in the other direction are SCCP-management?
It may be that my change in rev 23564
http://anonsvn.wireshark.org/viewvc/index.py?view=rev&revision=23564 is
screwing up the design intent here? Unfortunately I'm not clear on the intent
of using this structure for connectionless messages.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.