> ---> BUT! If sniffing on the link payload..... i only get an indication that
> it is "Multi Protocol Link", which could be any kind of traffic capable of
> tunneling inside PPP or different link type (Ethernet (bridging ethernet),
> IPX, IP and some other stuff)).
If you don't get an indication of the type of traffic at the network
layer - i.e., if the only packet data you get is, for an IP datagram,
the IP header followed by the IP payload and, for an IPX datagram, the
IPX header followed by the IPX payload, and so on, with *NO* independent
indication as to whether the packet is an IP packet or an IPX packet
or... - then the *ONLY* way that *ANY* packet analyzer will be able to
dissect the data would be through heuristics that try to figure out what
kind of packet it is.
> If there was a type called PCAP_UNKOWN_LINK_PAYLOAD or something like this,
> then ethereal could try and guess the contents of these packets. But maybe
> there is not.
There isn't a libpcap DLT_ value for that, because libpcap and tcpdump
were not designed to work with annoying router packet capture software
that says "here's a packet, good luck trying to figure out what kind of
packet it is".
> Maybe it would be smarter if i made a mini analyzer, to
> determine the type before i save my stuff.
Yes. Have whatever software generates a libpcap trace from the horrible
mess you get from the router when sniffing on the link payload do all
the messy heuristics (look for 0xFFFF to see if it's an IPX packet, look
for the bits that would be the IP version number being 4 or 6 to see if
it's an IP packet, etc.), and put out, for example, a fake Ethernet
header, with source and destination addresses of 0, and an Ethernet type
corresponding to the packet type.
Then write it out as DLT_EN10MB, and you now have a capture file that
can be read by *any* program that reads libpcap files - Ethernet,
tcpdump, etc..