Ok, just got it working. Seems like broadcast and multicast get into libipq just fine. Since I only have half the solution, the other half was to get the message back into the receiving sides' network. If I try to use a RAW socket to deliver the packet, will it loop back into libipq? Sorry I didn't state it before but this is the only config that I'm using for iptables right now: iptables -t mangle -A PREROUTING -p all -j QUEUE Can I use something like this to prevent this potential loop? iptables -t filter -A OUTPUT -p all -j ACCEPT Thanks, Tuan On Fri, 29 Jun 2001, Tuan Hoang wrote: > Ah, I thought that might be the case. > I think that a RAW socket with the IP_HDRINCL socket opt > will do quite nicely in my case on the receiving bridges > since I already have the entire IP packet. > > Seem reasonable? > > Another question is if iptables (mangle table) will pick > up all broadcast and multicast data too. If not, any suggestions? > > Tuan > > > On Fri, 29 Jun 2001, James Morris wrote: > > > On Thu, 28 Jun 2001, Tuan Hoang wrote: > > > > > Hi, > > > > > > I'm starting to test libipq.a and see if it is part of the solution to > > > my problem. My problem is that I'm trying to write a user-space bridge. > > > My question is if I can take packets captured by a Linux box using > > > libipq and send them over a serial link (eg: null-modem cable) to another > > > Linux box running libipq. I want the other Linux box to > > > re-inject the packet with NF_ACCEPT and let the packet take it's course. > > > What I'm worried about is if Netfilter will reject my packet on the > > > receiving end because of the "packet_id" somehow. > > > > With libipq (and Netfilter userspace packet queuing generally), you can > > only inject packets back in to the stack on the same box. > > > > - James > > > > -- Tuan Hoang The MITRE Corporation tuan@optimus.mitre.org - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
