Jason Mitchell wrote:
On 5/30/21 11:29 AM, Robert Swindells wrote:Staffan Thomén <staffan%shangtai.net@localhost> wrote:Robert Swindells wrote:Staffan Thomén<staffan%shangtai.net@localhost> wrote:No takers for this? Can someone at least check that I'm not crazy?Which bit of "this" ? Your last message suggests to me that you have a working bridged network.It works partially; DHCP replies don't seem to show up on the tap device so it does not configure an address. I kept a tcpdump on the tap while running dhcpcd and I can see dhcpcd retrying the sending to no avail.Do you need to use DHCP to get an address ? I have a theory that the MAC address learning feature of bridge(4) doesn't work well with BOOTP/DHCP, I have a local change to explicitly add the MAC address of each interface. You could look at the state of the address cache by running 'brconfig -a'. People use tap(4) in two ways: 1) To add an extra IP address for the host machine. 2) To connect a software emulator like qemu to the host. In usage 2, you don't setup an IP address for the tap(4) device, the virtual network device in the emulator has a different MAC address to the tap(4) device and can get an IP address using DHCP. Also, there is a shortcut in bridge(4) if it detects that a packet is for an "internal" address. If you do add an IP address for the tap(4) device then that will be treated as an internal one.Additionally, even if I manually configure an address on the tap interface and I can use it to connect using ssh, tcpdump on the tap device doesn't show the unicast packets, which I don't think is right either.I think that usage will be hitting the shortcut I described above, the packets are treated as being for the host machine so don't get sent to the tap interface.Okay, I got this working with a wired interface but only by adding an IP address to the physical nic (in my case axe0). The address wasn't in the same subnet as the address for tap1 (I used 169.254.169.254). Here are my commands (below). At some point I'll try to get DHCP up and running.
Thanks for looking into this, but I think the original premise got lost somewhere. I know what tap is for, but it was what was hinted to me to use instead of dedicated psedo-interface for the host system like OpenBSD's (or NetBSD-current:s) vether(4) interface. The scenario here is a system with multiple NICs deployed on premise somewhere, the physical interfaces are bridged together so that the users don't have to worry about plugging into the right one, they can just pick one and it will Just Work(tm). The problem that I ran into when trying to set this up was that if an address is configured on one of the physical interfaces, it will work with a bridge _so long as it is one of those with a cable connected_. The workaround I was given for this was not to try to force the interface to be up so that the address wouldn't be set to <detached> and effectively disabled, but to use tap(4) or the new vehter(4) device from current for the host address. DHCP and broadcast packets not arriving only came in later when I tried using tap(4) and found that it didn't quite work as I would have expected. I also have to apologise for muddling the issue, last night when I tried fidding with bridges again I could not make things work by manually assignin an address to the tap interface. I have a sneaking suspicion that there were still addresses in my ARP table last time from when the system had been configured normally on one of the physical interfaces that made manual configuration work on tap (but no proof that this is even possible). This whole issue is mostly academic in that it's not a big deal for me that one cable must always be connected to a particular port, but I feel like there's a problem worth solving here. If I didn't already have too may hobby projects I'd dive in and to to track it down myself, but I have very little experience with kernel hacking and a vague idea that normal rules might not apply so I was hoping that someone would wake up and go "oh damn, I know why that happens!" and fix it :-) Neat trick of using a LL address, but it's kind of moot if a cable must be attached to a particular interface. Staffan