the-tcpdump-group / libpcap

the LIBpcap interface to various kernel packet capture mechanism
https://www.tcpdump.org/
Other
2.64k stars 840 forks source link

'any' device seems to have extra 16bits in ether_header #163

Closed guyharris closed 11 years ago

guyharris commented 11 years ago

Converted from SourceForge issue 3524040, submitted by javran

when i was attempting use an 'any' device, things went strange and i could not get the correct field of 'ether->ether_type'('0x0800' was expected while the output was '0x0000') after some attempts I tried to use another ethernel header like:

struct ether { u_int8_t ether_dhost[ETH_ALEN]; u_int8_t ether_shost[ETH_ALEN]; u_int8_t reserv[2]; u_int16_t ether_type; };

and this time everything was ok. I guess there were something like 'struct ether_header' has been failed to be packed to work properly.

the attactment is my source code.

compiling it with 'cc pcap.c -DSYS_ETH_HDR -o pcap -lpcap' and then running with './pcap any' will not receive correct ether_type as well as source ip while compiling it without '-DSYS_ETH_HDR' will work well.

guyharris commented 11 years ago

Submitted by guy_harris

Packets received on the "any" device don't have Ethernet headers!

If pcap_datalink() doesn't return DLT_EN10MB, the packets you read will not have Ethernet headers; programs using libpcap/WinPcap must not assume Ethernet headers - they should call pcap_datalink() and either

1) process the header type supplied by the device, as indicated by the return value of pcap_datalink - see

        http://www.tcpdump.org/linktypes.html

    for a description of the headers

or

2) fail if the header type isn't DLT_EN10MB.

The header for the "any" device is the one for a DLT_ value of DLT_LINUX_SLL, which is described here:

http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html