On Sat, 21 Sep 2024 08:51:01 -0400 Greg Troxel <g...@lexort.com> wrote:
> Sad Clouds <cryintotheblue...@gmail.com> writes: > > > Hi, current documentation at: > > https://www.netbsd.org/docs/rump/sptut.html > > > > suggests using tap(4) and bridge(4) on the host, then within rump > > server virt(4) can be used to provide connectivity via tap(4). > > > > However, NetBSD-10 tap(4) man page states: > > > > CAVEATS > > Starting from NetBSD 10.0, the tap driver can no longer be used as a > > bridge(4) endpoint because it supports a link state based on if it has > > been opened or not. Use the vether(4) driver instead as it's been > > explicitly designed for this purpose. > > > > So the question is - what is the alternative for rump server virt(4) as > > it seems to only want to open tap(4) devices and not vether(4)? > > My guess is that in 10, vether is split off from tap, and that rump/virt > was simply not updated to use it instead. If so, it simply remains for > someone to fix the code and docs. This is on NetBSD-10 and I tried tap(2) with bridge(4) and initially it seemed to work. After a few network tests sending data between rump_server and the host, it simply grinds to a halt and no more packets get through. Not sure if this is related to tap(2) or issues with rump implementation. TCP throughput performance is quite poor, but I guess this may be expected with rump.
