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.
