You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using WSLAttachSwitch to create a secondary Hyper-V ethernet adapter for WSL. My secondary Ethernet connection is set up as:
Physical NIC is connected to a Hyper-V switch that I created manually.
My Hyper-V switch has one tap for Windows, and one tap for WSL (this shows up as eth1 in WSL).
WSLAttachSwitch is used to connect the second Ethernet link.
This creates a WSL environment where there are two routes from WSL to Windows. One is the regular WSL<->Windows bridge, and the other is an "accidental" route that flows from eth1 in Linux to my WSLAttachSwitch-connected Hyper-V switch, and from there into Windows on the secondary port (the intended purpose is to give WSL and Windows independent access to some lab equipment that's plugged into the NIC).
In this mode, usbipd.exe attach -w -b <device> chooses the IP address of the Windows port on my manually-created Hyper-V adapter instead of choosing WSL's primary adapter.
I took a capture of usbipd's logs using your recommended troubleshooting method, and have attached them below:
PS C:\Users\test_user> usbipd server Logging:LogLevel:Default=Trace
dbug: Microsoft.Extensions.Hosting.Internal.Host[1]
Hosting starting
dbug: Usbipd.PcapNg[1000]
usbipd:PcapNg:Path = ''
dbug: Usbipd.Server[1000]
usbipd:Port = 3240
dbug: Usbipd.Server[1000]
4.1.0+52.Branch.master.Sha.b0b7589d2dc4481b1af481787d6d773f46d0758a
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: C:\Users\qdt1fe
dbug: Microsoft.Extensions.Hosting.Internal.Host[2]
Hosting started
dbug: Usbipd.Server[1000]
new connection from 10.1.0.47
dbug: Usbipd.Server[1000]
connection close: Unable to read beyond the end of the stream.
dbug: Usbipd.Server[1000]
connection closed
dbug: Usbipd.Server[1000]
new connection from 10.1.0.47
dbug: Usbipd.ConnectedClient[1000]
Received opcode: OP_REQ_IMPORT
dbug: Usbipd.ConnectedClient[1000]
Claiming took 107 ms
info: Usbipd.ConnectedClient[1]
Client 10.1.0.47 claimed device at 4-1 (USB\VID_0403&PID_6011\6&9382108&0&1).
dbug: 4-1.0[1000]
Endpoint created
dbug: 4-1.0[1000]
Endpoint created
dbug: 4-1.0[1000]
Trapped SET_CONFIGURATION: 1
Inside of wsl, I attached my device with this command: /mnt/c/Program\ Files/usbipd-win/usbipd.exe attach -w -b 4-1.
Do you have any insight on what could be causing this? Is there any workaround I can do that will force usbipd.exe's attach -w mode to use WSL's primary connection instead of the secondary one?
The text was updated successfully, but these errors were encountered:
I'm using WSLAttachSwitch to create a secondary Hyper-V ethernet adapter for WSL. My secondary Ethernet connection is set up as:
eth1
in WSL).WSLAttachSwitch
is used to connect the second Ethernet link.This creates a WSL environment where there are two routes from WSL to Windows. One is the regular WSL<->Windows bridge, and the other is an "accidental" route that flows from
eth1
in Linux to myWSLAttachSwitch
-connected Hyper-V switch, and from there into Windows on the secondary port (the intended purpose is to give WSL and Windows independent access to some lab equipment that's plugged into the NIC).In this mode,
usbipd.exe attach -w -b <device>
chooses the IP address of the Windows port on my manually-created Hyper-V adapter instead of choosing WSL's primary adapter.I took a capture of
usbipd
's logs using your recommended troubleshooting method, and have attached them below:Inside of
wsl
, I attached my device with this command:/mnt/c/Program\ Files/usbipd-win/usbipd.exe attach -w -b 4-1
.Do you have any insight on what could be causing this? Is there any workaround I can do that will force
usbipd.exe
'sattach -w
mode to use WSL's primary connection instead of the secondary one?The text was updated successfully, but these errors were encountered: