This problem is actually I met a few months ago, but it seems to be still in memory of what, the heart of Shanghai, has not fully adapted to the new environment, plus this problem is not too abstruse problem, feel too simple, put on hold. I came to the end of the day with nothing to do at the weekend. In addition, Shenzhen often rains, more and more like.
This article has no depth, only for the record, as well as a "look at the document learning principle-guessing and self-implementation---contrast standard implementation Confirmation" method.
The problem is this:
On Linux If you use Tcpdump to crawl the LO port packet, you can only catch it once, not two times, as a rule, the packet will be caught on the outgoing path and the incoming path, for Lo Port, two paths go through itself, Why can we only catch one? Did the lo mouth do any special treatment?
is still the traditional three strokes cracked: Read the principles of document learning, guess implementation, confirm the implementation
1. Read the principle of document learning the most direct is to first go to man tcpdump, the parameters in front of the detailed section can not see, only see the most behind notes or bugs part of the good, its bugs part has a detail center this topic:
BUGS
...
On Linux systems with 2.0[.x] kernels:
Packets on the loopback device would be seen twice;
Packet filtering cannot be do in the kernel, so then all packets must is copied from the kernel on order to being filtered In user mode;
All of a packet, not just the part that's within the snapshot length, would be copied from the kernel (the 2.0[.x] packet C Apture mechanism, if asked to copy only part of a packet to Userland, won't report the true
Length of the packet; This would cause most IP packets to get a error from tcpdump);
Capturing on some PPP devices won ' t work correctly.
It seems clear that the "packets on the loopback device would be seen twice" describes the problem, "packet filtering cannot is done in the kernel, so th At all packets must is copied from the kernel on order to being filtered in user mode "pretend to explain the reason."
2. Guess implementation if the LO is within the Linux kernel of the special packet capture filter, it is too unreliable, if there is such a need to filter this once, the kernel will be all over the if-else...switch-case ... It is not good to introduce the polymorphism of serious. As long as the kernel provides enough information, the user can filter by itself. It is reasonable to make the above guesses before looking at the code.
3. Identify the most straightforward PACKET_RCV function to see the kernel code First, this function is the entry function of the tcpdump grab (of course, if the pf_ring is optimized, this is not the case, but in simple terms, most of it):
static int Packet_rcv (struct sk_buff *skb, struct device *dev, struct packet_type *pt) {struct sock *sk;struct sockaddr _ll *sll = (struct sockaddr_ll*) skb->cb;/* *when We registered the protocol we saved the socket in the data *field for Just this event. */sk = (struct sock *) pt->data;//Note that Packet_loopback is only relevant to multicast, not related to our discussion if (Skb->pkt_type = = Packet_loopback {KFREE_SKB (SKB); return 0;} Skb->dev = dev;sll->sll_family = Af_packet;sll->sll_hatype = Dev->type;sll->sll_protocol = skb-> Protocol;sll->sll_pkttype = Skb->pkt_type;sll->sll_ifindex = Dev->ifindex;sll->sll_halen = 0; ...}
Then take a look at the processing of the Send path:
void Dev_queue_xmit_nit (struct sk_buff *skb, struct device *dev) {... skb2->pkt_type = Packet_outgoing;ptype->func (Skb2, Skb->dev, ptype);
It appears that packet_outgoing is a core flag that tells the tcpdump where the packet was sent from. Finally, let's take a look at the PCAP packet read function Pcap_read_linux_mmap:
Just look at the notes.
Unfortunately, the Linux 2.0 kernel, and did not provide this packet_outgoing information, grabbed a bare package, not enough information, of course, can not distinguish between two directions, which is tcpdmp manual the source of the bug. The resolution of this bug also helps us understand why the LO grab bag catches only one direction, not two times. Let us also know that the LO grab packet captures the incoming direction of the packet.
A detail about the Linux loopback mesh grab bag
