The working environment for all of this was the following:

Acting as the USBIP client and development platform is a Xen PVH
amd64 guest running NetBSD 10.0_RC1 from 2023-11-26.  This VM has 1GB
of memory and one CPU.

Acting as another USBIP client is a SIMH Vax VM running some version
of NetBSD 10.0_RC1.  This VM uses a bridged network interface and has
a real local IP address.  This VM was given 128MB of memory and one
CPU.

In both cases, the kernel config looks likes something like this:

include "arch/amd64/conf/GENERIC"

#options USBHIST_PRINT

options USBVERBOSE

pseudo-device  vhci
usb*   at vhci?


Both clients are technically on the same LAN segment, but are running
on different hypervisors.


Acting as the USBIP server is a Framework laptop connected via
802.11n.  The laptop runs MS-WINDOWS 10 and can have Virtualbox
virtual machines.  A Archlinux VM was used for some of the testing,
but a USBIP server was most often used from MS-WINDOWS itself.

There are a few usbipd-win ports / packages / etc. out there.  The one
I used was from:

https://github.com/dorssel/usbipd-win

Usually I would utilize the "--force" option when binding devices as
this will keep MS-WINDOWS from messing with them, in as much as that
is possible.

Archlinux simply uses the normal Linux usbip / usbipd package.  It was
run as "usbipd -D" or sometimes "usbipd -d", but the debugging to
stdout / stderr is not very robust.

Please note that this is probably one of the worst possible places to
have a USBIP server as the devices are hanging at the end of a
wireless network on a different segment from the clients.  It would
have been another matter if the client was on a Virtualbox VM on the
laptop.