[Guy Harris <gharris@xxxxxxxxxxxx>]

> I have tried a X25 over ethernet capture and some strange things happened.
> When I captured some data with libpcap, the EthernetII.type was 0x6000
> and the ethereal does not recognize the encapsulation.
> When I captured some data with RedHat 6.1 modified libpcap, the
> EthernetII.type was 0x0805; (ETH_P_X25) and the ethereal recognizes
> it as X25 packet.

...except that the packets all seem to contain the same Ethernet
payload, namely 0x02 0x00 0x01 0x3f.  I'm not sure that's a valid X.25
packet - and it looks as if it's not a valid LAPB packet, either
("dissect_lapb()" rejects packets whose first octet is neither 0x01 nor
0x03).

0x6000 is ETH_P_DEC, and 0x0805 is ETH_P_X25; in
"drivers/net/lapbether.c" in the 2.2.13 kernel, both of those appear to
be used for different purposes.

Does anybody with a clue about X.25-over-Ethernet, and the Linux
implementation thereof, know what's going on there?  Perhaps the old
SOCK_PACKET mechanism (which is what the vanilla libpcap uses) and the
new PF_PACKET/SOCK_RAW mechanism (which is what the RH 6.1 libpcap uses)
get the Ethernet type, somehow, from a different location (the
RH 6.1 libpcap/tcpdump may use PF_PACKET/SOCK_DGRAM, which puts a header
on the packets to make them all look like Ethernet packets; perhaps it
gets the Ethernet type for that header from somewhere other than the
actual Ethernet header if the capture is being done on a real Ethernet,
so that it's picking up the ETH_P_X25 while the Ethernet packets have
ETH_P_DEC in their real headers).  Were these captures done with
Ethereal or tcpdump?

> Another strange thing is that the captured packet size is smaller than
> the minimum ethernet packet size.(which I think is 60 bytes).

I've seen that with some captures; perhaps, at least for packets
transmitted by the host on which the capture is being done, the actual
length of the packet, rather than the length to which it was padded, is
supplied as the actual and captured length.

> There are some more differences between the same traffic captured
> simultaneously with plain libpcap and the new RH 6.1 libpcap.
> For instance, in the RH6.1 libpcap :
> traffic on loopback interface (lo) is captured as ethernet not as
> NULL/LOOPBACK which is wrong.

Actually, recent discussions on the tcpdump-workers mailing list (see

	http://www.tcpdump.org/

) indicate that DLT_NULL is the *wrong* type for the loopback interface
- packets sent on the loopback interface in Linux actually have an
Ethernet header on them, but whoever did the Linux libpcap code decided
to try to pretend that they had a BSD-style DLT_NULL header, by removing
the source and destination Ethernet addresses and padding the 2-byte
Ethernet type with 2 extra bytes of 0.  Unfortunately, that does *not*
generated a BSD-style DLT_NULL header; a BSD-style DLT_NULL header has
a 4-byte AF_/PF_ address-family/protocol-family type value, in *host*
byte order, using the AF_/PF_ values for that *particular* flavor of
BSD.  Future libpcaps will just supply the Ethernet header for loopback
captures on Linux, and will mark the capture as DLT_EN10MB.

The RH 6.1 libpcap also appears to map the loopback interface
(ARPHRD_LOOPBACK) to DLT_EN10MB in that fashion.

>traffic on ppp interface (ppp0) is again captured as ethernet which
>is wrong.

Unfortunately, the Linux PPP code appears to have the irritating habit
of making it impossible for the packet-capture code to see the PPP
header, *even though it supports protocols other than just IP, so you
really want the PPP header to know what type of packet it is*; the RH
6.1 libpcap maps ARPHRD_PPP to DLT_RAW, which means "no link-level
header, just raw IP".

I'm not sure how that got turned into Ethernet, though.