Thomas Steffen wrote:
Of course. The other question is whether they care to define something
that is of no obvious use for them. AFAIK there is no SS7 in the Linux
kernel.
Intel have Linux drivers for their Septel cards (or whatever they're
called now), but that doesn't go through the regular Linux networking stack.
If it's a mix of raw MTP2 and presumably-IP-based SCTP and TCP, there's
no option for that, currently. With pcap-NG:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
Unless I misread the draft, it is not possible to generate this format
in real time (on a pipe).
It should be possible - that's certainly the intent; what do you see as
preventing it from being written to a pipe? (Note that many of the
block types are optional and don't need to be in a capture; tables
giving the offsets of packets, etc. are optional.)
So, no multi-interface analysis? I would have thought this to be a
rather common problem (relatively spoken).
It might have been common, but it requires a new file format, and
designing a file format shouldn't be done quickly (file formats can last
a long while, and if you keep changing them, you run the risk of
repeatedly breaking older applications; it's probably going to be
painful enough with pcap-NG, which is why it would have been nice had we
been able to get read-only support for it into libpcap 0.9, but, as is
often the case, time was the scarce resource...), and the people doing
the work on libpcap do it in their spare time.
But if linux cooked is the
closest there is, I will have another look at it. I could not figure
out how the dissector deals with the protocol types, but maybe I just
didn't look close enough.
See the code that handles the "protocol" variable in "dissect_sll()" -
if the protocol variable is < 1536, it's a "special" value (Linux has
only "802.3+802.2" and "802.3+IPX", those being the other two packet
types in real Ethernet, other than D/I/X Ethernet with a type field),
otherwise it's an Ethernet type and it treats it as an Ethernet type (by
calling "ethertype()", which uses the "ethertype" dissector table).
If you want to use DLT_LINUX_SLL, you'd probably want to use a "special"
value, as the IEEE controls the use of regular Ethernet types, and you
run the risk of any regular Ethernet type you choose being assigned for
some other protocol.
The special types that have already been assigned are in the
linux/if_ether.h file - look for "Non DIX types". As they say, "Won't
clash for 1500 types", so they might be willing to assign one (they've
assigned them to AX.25 and IRDA, for example - there might even be
people looking at SS7 stacks for Linux that might want a value such as
that, if they'll be implementing the SS7 stacks using the regular
networking code).
