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] Raw SS7 dissector (was fakelink)

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 23 Sep 2003 14:58:34 -0700

On Sep 23, 2003, at 2:50 PM, Jeff Morriss wrote:

Usually it would be capturing on different links--or at some higher-layer (maybe even at the application). Because MTP2 SS7 links are slow (48000, 56000, or 64000 baud) and for redundancy, no one ever has just one link. Plus, MTP3 allows its users to load-share among links, so monitoring just one link is usually useless (unless you're looking at a low-level problem).

But would those be captures at the same protocol level?


For now, the protocol type is necessary, but it's not really a LINKTYPE_ value - tcpdump.org can maintain other values as well, so perhaps they're better assigned as SS7TYPE_ values, in which case they could start at 0.

I agree it's not really a LINKTYPE_ value--though the argument has been that there was plenty of address space for LINKTYPE_'s (so why create another numbering scheme).

If, with libpcap TNG, we'd have, for example, something in the file header specifying that one interface is carrying MTP2 traffic and another is carrying MTP3 traffic (pcap-TNG would definitely have a list of interfaces in the file, giving names, link-layer types, etc.; packets would be tagged by the interface they arrived on or were sent on), and if we still used LINKTYPE_ values (as opposed to, for example, strings), then multiple LINKTYPE_ values would make sense.