On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > Hello list,
> > >
> > > Working with a user-space TCP-IP, I tried to setup a local bridge
> > > between two taps, each tap being driver by a user-space client
> > > and
> > > server.
> > >
> > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > >
> > > I am interestingly stuck at the ARP discovery phase. When the
> > > client
> > > send its ARP request, the server receives it and replies.
> > > However,
> > > the
> > > client never gets the reply back.
> > >
> > > Some research indicated that since the client is getting an
> > > echoed
> > > version of its request, the bridge learns its address preventing
> > > the reply from being forwared.
> > >
> > > Would my understanding be correct? If so, is there any way to
> > > correct
> > > this behavior?
> > >
> > > Thanks,
> > > xavier
> > >
> >
> > What version are you running?
> >
> > I ask because of the following:
> > https://www.openbsd.org/errata63.html
> > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patc
> > h.
> > sig
> >
> > +--+
> > Carlos
> >
>
> I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> long time). I just applied the patch and tried again, but no cigar.
>
> Here is exactly what is happening:
>
> 1. On TAP0, the server waits for any request on 10.1.0.1 (user-space
> stack address)
> 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> (also
> user-space address)
> 3. The ARP table of the client is empty, so it sends a broadcast ARP
> request.
> 4. Both the server AND the client receive that request, the client
> ignores it
> 5. The server responds to the client but the client never receives
> the
> reply
>
> I can see the reply packet leaving TAP0 and passing through BRIDGE0.
> It
> just simply never show up on TAP1.
>
> /x
>
Looking at the source code for the bridge and doing some debugging in
VMM, it looks like the reply gets dropped at that point:
sys/net/if_bridge.c:1182
if (bridge_ourether(ifl, eh->ether_shost)) {
m_freem(m);
return;
}
In my case, ifl is the sending address and, of course, the source
ethernet is ours.
Doing some barbaric massaging of the inner FOREACH got me to the point
where my ARP reply was received by my stack. I also was able to get a
S/SA/A sequence but eventually the stack failed after its first P.
I'll investigate the TCP misbehaving using static ARP routes as Edgar
suggested.
/x
