| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <6eb6ed920703262344i5eec0dfdq169c14b8da2696c9@mail.gmail.com> Date: Tue, 27 Mar 2007 14:44:28 +0800 From: "railroad seeker" <railroad.seeker@...il.com> To: linux-kernel@...r.kernel.org Subject: About Linux Socket Filter 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists