Re: bridging, libnet and libpcap

Hey Mike/John,

Been there, done that :)

Yes, the problem you're experiancing is "normal", at least on Linux boxen.
The issue has to do with where in the kernel libpcap and libnet bind
to the interfaces.  Basically, libpcap is closer to the actual network
card and so every packet (libnet or not) is seen.  On some OS's (BSD kernels
with bpf I think) and newer versions of libpcap you can specify to only 
watch for in or outbound frames, but it's not portable.

I actually implimented solution #2 (using mac addresses) in tcpreplay's 
bridge mode (v2.0.0 or better).  I store the MAC's in a red-black tree 
and the appropriate NIC.  It's BSD licensed so feel free to steal the 
code. :) 

Hope that helps...
-Aaron

-- 
Aaron Turner <aturner at pobox.com|synfin.net>  http://synfin.net/
They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety. -- Benjamin Franklin
All emails are PGP signed; a lack of a signature indicates a forgery.

On Wed, Feb 04, 2004 at 03:00:56PM -0800, Mike Schiffman wrote:
> First of all, what operating system? Second of all, are you sure you 
> have all of your interface logic setup properly? You have initialized 
> pcap and libnet twice on each interface? Are these interfaces on the 
> same network (and in promiscuous mode)?
> 
> The idea of using precomputed checksums for a performance increase is a 
> good one, and is one reason why I give users the option to specify a 
> value. Regarding performance criticality, there are certain nuances 
> between pcap implementations across different implementations. If you 
> read my book, you have that reference. Check out the BPF-based ioctl 
> from firewalk:
> 
> #if HAVE_BPF
>      /*
>       *  BPF, by default, will buffer packets inside the kernel until
>       *  either the timer expires (which we do not use) or when the 
> buffer
>       *  fills up.  This is not sufficient for us since we could miss
>       *  responses to our probes.  So we set BIOCIMMEDIATE to tell BPF
>       *  to return immediately when it gets a packet.  This is pretty 
> much
>       *  the same behavior we see with Linux which returns every time it
>       *  sees a packet.  This is less than efficient since we're spending
>       *  more time interrupting the kernel, but hey, we gotta get our
>       *  work done!
>       */
>      one = 1;
>      if (ioctl(pcap_fileno((*fp)->p), BIOCIMMEDIATE, &one) < 0)
>      {
>          snprintf((*fp)->errbuf, FW_ERRBUF_SIZE,
>                  "ioctl(): BIOCIMMEDIATE: %s", strerror(errno));
>          return (-1);
>      }
> #endif
> 
> 
> CC'd to the list for additional comments.
> 
> On Feb 2, 2004, at 1:40 PM, John Flynn wrote:
> 
> > Hey Mike,
> >
> >
> > I love/use your book on a daily basis as well as your excellent library
> > libnet. I have run into an unusual situation that I am having trouble 
> > finding
> > information on. When setting up a bridge program to forward packets
> > bidirectionally on an interface pair, I do a libnet_adv_write of the 
> > data to
> > one interface, say ethx. When the callback function returns to run the 
> > next
> > pcap_dispatch on ethx, it reads the packet that I just injected and 
> > reinjects
> > it on the other interface, resulting in a cycle that floods the 
> > network.
> >
> > 1) Why does this happen?
> > 2) I am writing a program with performance being critical... I have 
> > thought of
> > two possible methods around this: building a checksum database of 
> > packets and
> > making sure I don't grab them again or building an mac table (using 
> > ethernet)
> > and forwarding packets only the right way...
> > Is there something I'm missing? It seems like there should be a way to 
> > let the
> > libraries take care of this for me... like flushing the packets on the
> > outgoing before reading them back or tagging the packet data with the 
> > source
> > interface or something.... What do you think as a quick elegant 
> > solution to
> > this?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAI9zHhweYF/hu2uYRAi2CAJwN3CFLQj1AhCsxifJdKS6YqlB1MACgiQpL
rY7ggvOR4xHxH35pwf4+Cb4=
=JZc0
-----END PGP SIGNATURE-----