On Wed, Jun 26, 2002 at 05:02:29AM -0500, Beatriz Silva wrote:
> Thanks again for the answer Guy !
>
> Could you though explain me better what do you mean with this sentece ...
>
> device that supports "raw-mode" (PF_PACKET/SOCK_RAW)
>
> What is this raw-mode ?
Different OSes have different packet capture mechanisms. The libpcap
library provides an OS-independent interface to those packet capture
mechanisms, so that programs like tcpdump, Ethereal, snort, Ksnuffle,
and so on don't have to have a bunch of OS-dependent code to do packet
capture.
The mechanism used on Linux is a "packet" socket, which is a socket
whose "domain" is PF_PACKET. There are two types of "packet" sockets:
a socket where something that is typically the raw packet,
complete with a link-layer header, is supplied to the program;
a socket where the link-layer header is removed.
A socket of the first type is created by the capture code requesting a
PF_PACKET socket of type SOCK_RAW; a capture on a socket of that type is
a "raw capture". A socket of the second type is created by the capture
code requestiing a PF_PACKET socket of type SOCK_DGRAM; a capture on a
socket of that type is a "cooked capture".
It is not always the case that a PF_PACKET/SOCK_RAW socket will supply
packets with a reasonable and valid link-layer header. If that is the
case, libpcap uses a PF_PACKET/SOCK_DGRAM socket instead, and constructs
a fake link-layer header. The information supplied by reading from the
socket with a "recvfrom()" system call includes the source address of
the packet, but *NOT* the destination address of the packet, so the
destination MAC address is unavailable with PF_PACKET/SOCK_DGRAM
sockets.
On the "any" device, the link-layer type of a packet depends on the
device that supplies the packet; there is no guarantee that all devices
on the system have the same link-layer type, and libpcap does not
support capturing from a device where not all packets have the same
link-layer type, and does not include any code to try to determine
whether all network interfaces have the same link-layer type, so libpcap
cannot use a PF_PACKET/SOCK_RAW socket to capture on the "any" device,
so it cannot provide the destination MAC address.
On some devices, the "link-layer header" has random junk in it; that
appears to happen when capturing on PPP-over-ISDN devices, for example.
For those devices, libpcap uses a PF_PACKET/SOCK_DGRAM socket, so that
programs using it can get a fake link-layer header that doesn't have
random amounts of random junk.
Libpcap doesn't necessarily know about all the link-layer types
supported by Linux; if a device has a type it doesn't support, it does a
cooked capture, so you can at least get packet data.
> I really want to be able to see the destination mac address of the
> packet: would you have some other suggestion ?
If you want the MAC destination address:
do *NOT* capture on the "any" device - if you want to capture on
more than one device, run separate instances of Ethereal, one
per device;
capture only on network interfaces that libpcap can do "raw
mode" captures on, such as Ethernet, Token Ring, FDDI, or 802.11
wireless LAN network interfaces.
