Re: tap+bridge: arp reply not forwarded
On Sun, 2018-05-06 at 17:51 -0400, Xavier Guerin wrote:
> 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.pa
> > > tc
> > > 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
>
I'm running out of luck apparently... Now that ARP is out of the way,
the user-space client sends an S frame to the user-space server through
tap2. The server uses tap1, which sees the frame (per tcpdump).
However, the read() function on tap1 never returns any data.
Re: tap+bridge: arp reply not forwarded
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
Re: tap+bridge: arp reply not forwarded
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
Re: tap+bridge: arp reply not forwarded
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.patch. > 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
Re: tap+bridge: arp reply not forwarded
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 > You could try adding your own arp entry with `arp -s' and see what happens.
Re: tap+bridge: arp reply not forwarded
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.patch.sig +--+ Carlos
tap+bridge: arp reply not forwarded
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
