understanding tcpdump trace with ethernet headers

I have two packets in my tcpdump log and I have no idea what "P" and "In" in the second column mean. Could someone explain what they mean?

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开发者_如何学JAVA 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>

Note that the dest IP changes because of this "P" thing.

Got the following answer from the tcpdump-workers mailing list from Guy Harris.

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.