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
