Hi: I am writing a socket filter program and using "tcpdump -dd vlan and arp" to filter out the arp packet whose protocol field is 8100(vlan). Everything is fine if I call recvfrom to receive the packet. However, if I open two packet socket in parallel (and use the select to demultiplex among them, then the program will sacrifice the arp protocol handling! My program get arp request/reply as usual, but the kernel cannot get any arp request anymore. And the linux kernel no longer receives any packet if I flush the arp table since kernel cannot get arp request.
I insert debug information (printk) next to the ptype handling loop, netif_receive_skb (ret = pt_prev->func(skb, skb->dev, pt_prev)), and the kernel exactly print out the information. Does that mean the packet is exactly inserted into the queue of the socket and kernel path returns to the processing loop? How could user space program steal the packet? (Note that the two interface involved are the member of the bridge, but I think the ptype looping is after the handle bridge and should not sacrifice the arp handling.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
