Re: Understanding particular tcpdump log

[Guy Harris <guy () alum mit edu>]

On Sep 28, 2011, at 2:28 AM, Srikanth Raju wrote:

> In one of my tcpdump logs, I have the following two lines which is the same packet.
>
> 00:43:44.896482   P 00:00:ac:12:80:01 ethertype IPv4 (0x0800), length 76: 172.18.128.1.ssh > 155.xx.xx.xx.56365: S 
> 1308033114:1308033114(0) ack 1315850475 win 5792 <mss 1460,sackOK,timestamp 12196173 122040733,nop,wscale 8>
>
> 00:43:44.896482  In 00:00:ac:12:80:01 ethertype IPv4 (0x0800), length 76: 172.18.128.1.ssh > 155.yy.yy.yy.4242: S 
> 1308033114:1308033114(0) ack 1315850475 win 5792 <mss 1460,sackOK,timestamp 12196173 122040733,nop,wscale 8>
>
> I'm running with tcpdump -e -n -i any
>
> What I want to know is the meaning of the "P" and "In" in the second column? It seems to be involved in changing the 
> address of the packet.

The Linux "any" device uses the DLT_LINUX_SLL/LINKTYPE_LINUX_SLL link-layer header, which includes information you get 
from a "recvfrom()" call on a PF_PACKET socket, which includes the source address, but not the destination address, of 
the packet, so the only link-layer address you see is the source address.

It also includes some flags that indicate how the packet was received:

        "In" - the packet was unicast to the host;

        "B" - the packet was broadcast;

        "M" - the packet wasn't broadcast but was multicast;

        "P" - the packet was unicast to some *other* host and this host received it because the network adapter was in 
promiscuous mode;

        "Out" - the packet was sent by the host and "wrapped around" and delivered to the PF_PACKET socket.

The way the Linux networking stack determines the difference between "In", "B", "M", and "P" is, I think, by looking at 
the destination address of the packet and seeing whether it's a broadcast address (ff:ff:ff:ff:ff:ff on networks using 
IEEE MAC-48 addresses), a multicast address (has the "group" bit set, on networks using IEEE MAC-48 addresses), or the 
address of the adapter on which it's received.  It's a *bit* surprising that it detected a promiscuously-received 
packet on the "any" device, as the "any" device itself can't be put into promiscuous mode, but perhaps the particular 
interface from which that packet was received was in promiscuous mode for some other reason.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.