Hi ! I think it would be easy-to-do, and very usable feature of describe specified field values. Currently I am working a lot on SS7 packets, where MTP3(SPC,DPC) and SCCP(GT) are subjects, where description on specified value would help a lot. So for example, when displaying it would be What do you think ? BR Alex asked 08 Aug '16, 03:26  ahmediukas edited 08 Aug '16, 17:07  Guy Harris ♦♦ |
2 Answers:
So generically, what you ask for is a name resolution for other than IP and MAC addresses, using a user-provided configuration file, right? For the point code at MTP level, it wouldn't be so complex; for the SCP's Calling and Called Party Addresses, this could be a nightmare due to their flexible structure - point code, SSN, global title may all be present or absent in the complete address, and the global title's address space (numbering plan identifier) may be E.212, E.164 or even other. And you might need translation of prefixes because the GT is sometimes a single subscriber's address, not GMSC's or VLR's. In any case, this site is not the right place for such requirement - you should file an Enhancement request (bug with severity Enhancement) on Wireshark Bugzilla. If it may help you as a quick workaround, try using the coloring rules - you can use any display filter as a trigger for assigning a color scheme to the frame in the packet list. But your color perception has to be good enough to distinguish between enough color combinations (background + foreground). Also, you may want to write a Lua post-dissector which would contain the translation table and generate additional filterable meta-fields with the names. answered 08 Aug '16, 05:19  sindy edited 08 Aug '16, 05:55 |
Sounds like you're looking for bug 7592. It requests translation from (SS7) PCs to names. (Now we just need someone with the time and inclination to implement that enhancement request...) answered 11 Aug '16, 06:53  JeffMorriss ♦ |
Whenever a user (Wireshark or otherwise) suggests a change is "very easy to do", I expect to see the patch attached. I'm usually disappointed.
Another possible "enhancement" approach to this would be to give the option within the MTP3 protocol preferences to enable/disable the code which pushes point codes into the "source" and "destination" columns to begin with.
If that was a configurable option, a user could pretty much accomplish this task by disabling that feature and writing IP host file entries for all the IPs which map to an MTP3 point code, using the already-written IP host resolver code of Wireshark to map point codes to named sources/destinations.
Of course, if it's an M2PA passthrough or you're doing PC translation rather than GT/SSN routing then you might have the same point code crossing two IP legs, but in that case you could at least define a given STP as a source/destination in the resolver. Not completely what you're asking for, but since it would just be a toggle to "disable" a feature which is already built into MTP3 (a feature which denies us the ability to resolve the IP-level source/destination info in the Source/Destination columns for MTP3-dissected frames), I think that would be easy. :)
Oh, and aside from the above reasons for why SCCP would be messy for something like this, consider that Sigtran implementations would normally concatenate many SCCP-level messages over a single IP packet, so a best-case result would probably have to be similar to column field values ("first", "last", or "all"), making it kind of useless for following a transaction even if the code gets it all right.
And that's to say nothing about the problem of inconsistent uses of GT translation for DPC's even within a single dialogue (eg: many GSN/VLR implementations will use E.212 GT for an initial address to HLR, then flip to E.164 GT of the HLR directly for the next TCAP transaction, mid-dialogue, based on MM/GMM state of the IMSI).
If wireshark can translate value of GT (or ANY other fields) in proper form, it means it knows the value, no matter what it is. So description table (protocol.field.value=description) can help a lot. Not just within SS7. For example, I have some own specific protocols, which could such table help me as well). Due various form of protocols use, I know it can't be bulletproof on results, but still can be usefull to lookup into table and add description near value if found. Such implementation I guess can't be such a pain, have such code in my own shark (limited to some other old protocols). Btw, SS7 was just an example, since I'm currently working lot on it.