Re: urndis0: IOERROR
: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: ehci_idone: EHCI_QTD_ACTIVE break Nov 26 21:30:50 edge /bsd: cmd=0x00020031, sts=0xc008, ien=0x0037 Nov 26 21:30:50 edge /bsd: frindex=0x3717 ctrdsegm=0x periodic=0xd844b000 async=0xd8443000 Nov 26 21:30:50 edge /bsd: port 1 status=0x1005 Nov 26 21:30:50 edge /bsd: port 2 status=0x1000 Nov 26 21:30:50 edge /bsd: port 3 status=0x00001000 Nov 26 21:30:50 edge /bsd: ehci_idone: set USBD_IOERROR Nov 26 21:30:50 edge /bsd: urndis0: IOERROR Nov 26 21:30:50 edge /bsd: urndis0: init failed Nov 26 21:30:50 edge /bsd: ehci_check_qh_intr: status & EHCI_QTD_HALTED Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438f80) at 0xd8438f80: Nov 26 21:30:50 edge /bsd: next=0xd8438e80<> altnext=0xd8438e80<> Nov 26 21:30:50 edge /bsd: status=0x00080248: toggle=0 bytes=0x8 ioc=0 c_page=0x0 Nov 26 21:30:50 edge /bsd: cerr=0 pid=2 stat=0x48 Nov 26 21:30:50 edge /bsd: buffer[0]=0xd8439ac0 Nov 26 21:30:50 edge /bsd: buffer[1]=0x Nov 26 21:30:50 edge /bsd: buffer[2]=0x Nov 26 21:30:50 edge /bsd: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e80) at 0xd8438e80: Nov 26 21:30:50 edge /bsd: next=0xd8438e00<> altnext=0xd8438e00<> Nov 26 21:30:50 edge /bsd: status=0x801c0c80: toggle=1 bytes=0x1c ioc=0 c_page=0x0 Nov 26 21:30:50 edge /bsd: cerr=3 pid=0 stat=0x80 Nov 26 21:30:50 edge /bsd: buffer[0]=0xd8459dc0 Nov 26 21:30:50 edge /bsd: buffer[1]=0x Nov 26 21:30:50 edge /bsd: buffer[2]=0x Nov 26 21:30:50 edge /bsd: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e00) at 0xd8438e00: Nov 26 21:30:50 edge /bsd: next=0x0001 altnext=0x0001 Nov 26 21:30:50 edge /bsd: status=0x80008d80: toggle=1 bytes=0x0 ioc=1 c_page=0x0 Nov 26 21:30:50 edge /bsd: cerr=3 pid=1 stat=0x80 Nov 26 21:30:50 edge /bsd: buffer[0]=0x Nov 26 21:30:50 edge /bsd: buffer[1]=0x Nov 26 21:30:50 edge /bsd: buffer[2]=0x Nov 26 21:30:50 edge /bsd: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: ehci_idone: EHCI_QTD_ACTIVE break Nov 26 21:30:50 edge /bsd: cmd=0x00020031, sts=0xc008, ien=0x0037 Nov 26 21:30:50 edge /bsd: frindex=0x371d ctrdsegm=0x periodic=0xd844b000 async=0xd8443000 Nov 26 21:30:50 edge /bsd: port 1 status=0x1005 Nov 26 21:30:50 edge /bsd: port 2 status=0x1000 Nov 26 21:30:50 edge /bsd: port 3 status=0x1000 Nov 26 21:30:50 edge /bsd: ehci_idone: set USBD_IOERROR Nov 26 21:30:50 edge /bsd: urndis0: IOERROR Nov 26 21:30:50 edge /bsd: urndis0: query failed Nov 26 21:30:50 edge /bsd: : unable to get hardware address Nov 26 21:30:50 edge /bsd: ehci_check_qh_intr: no EHCI_QTD_ACTIVE Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438f00) at 0xd8438f00: Nov 26 21:30:50 edge /bsd: next=0x0001 altnext=0x0001 Nov 26 21:30:50 edge /bsd: status=0x80008d00: toggle=1 bytes=0x0 ioc=1 c_page=0x0 Nov 26 21:30:50 edge /bsd: cerr=3 pid=1 stat=0x0 Nov 26 21:30:50 edge /bsd: buffer[0]=0xd8459f01 Nov 26 21:30:50 edge /bsd: buffer[1]=0x Nov 26 21:30:50 edge /bsd: buffer[2]=0x Nov 26 21:30:50 edge /bsd: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: cmd=0x00020031, sts=0xc008, ien=0x0037 Nov 26 21:30:50 edge /bsd: frindex=0x3845 ctrdsegm=0x periodic=0xd844b000 async=0xd8443000 Nov 26 21:30:50 edge /bsd: port 1 status=0x1005 Nov 26 21:30:50 edge /bsd: port 2 status=0x1000 Nov 26 21:30:50 edge /bsd: port 3 status=0x1000 Nov 26 21:30:50 edge /bsd: ehci_check_qh_intr: no EHCI_QTD_ACTIVE Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e00) at 0xd8438e00: Nov 26 21:30:50 edge /bsd: next=0xd8438f80<> altnext=0xd8438f80<> Nov 26 21:30:50 edge /bsd: status=0x8e00: toggle=1 bytes=0x0 ioc=0 c_page=0x0 Nov 26 21:30:50 edge /bsd: cerr=3 pid=2 stat=0x0 Nov 26 21:30:50 edge /bsd: buffer[0]=0xd8439f48 Nov 26 21:30:50 edge /bsd: buffer[1]=0x Nov 26 21:30:50 edge /bsd: buffer[2]=0x Nov 26 21:30:50 edge /bsd: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438f80) at 0xd8438f80: Nov 26 21:30:50 edge /bsd: next=0xd8438e80<> altnext=0xd8438e80<> Nov 26 21:30:50 edge /bsd: status=0x0d00: toggle=0 bytes=0x0 ioc=0 c_page=0x0 Nov 26 21:30:50 edge /bsd: cerr=3 pid=1 stat=0x0 Nov 26 21:30:50 edge /bsd: buffer[0]=0xd8459dc4 Nov 26 21:30:50 edge /bsd: buffer[1]=0x Nov 26 21:30:50 edge /bsd: buffer[2]=0x Nov 26 21:30:50 edge /bsd: buffer[3]=0x Nov 26 21:30:50 edge /bsd: buffer[4]=0x Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e80) at 0xd8438e
Re: urndis0: IOERROR
On 11/22/21 10:47, Mikhail wrote: On Mon, Nov 22, 2021 at 12:32:30PM +0300, Mikhail wrote: On Mon, Nov 22, 2021 at 09:31:59AM +0100, Gerhard Roth wrote: On 11/20/21 17:12, Mikhail wrote: Comparing Windows and OpenBSD tcpdumps I noticed some differences: 1) In REMOTE_NDIS_INITIALIZE_MSG (I patched the kernel to send it before getting MAC address and with proper minor version) bInterfaceClass on OpenBSD is set to Unknown (0x), on Windows it's properly set to Wireless Controller (0xe0). 2) The control transfer stage for this message on OpenBSD is set to Data, on Windows it is Setup. 3) The answer for the message on Windows is with USBD_STATUS_SUCCESS (0x), on OpenBSD it's Unknown (0x000d). 4) The answer for the message on Windows contains "Control transfer stage: Complete" message, on OpenBSD it's set to Status. Maybe someone can prompt me: 1) Does those differences matter at all? 2) Where to look regarding changing bInterfaceClass for outgoing messages? I can see it's properly set in urndis driver (line 133 of if_urndis.c), but not passed anywhere down to USB stack. You're getting something wrong here. It is the USB function that sets bInterfaceClass in its device descriptor, not the host. It's what I see in wireshark - bInterfaceClass is set for outgoing packets, for windows it is in frame 27, in patched openbsd it is in fram 172. Oh, I think I understand what's happening - this line about bInterfaceClass in the capture is in square brackets, and according to the docs it is generated by wireshark: https://www.wireshark.org/docs/wsug_html_chunked/AppMessages.html Wireshark provides you with additional information generated out of the plain packet data or it may need to indicate dissection problems. Messages generated by Wireshark are usually placed in square brackets (“[]”). But it is still a difference between windows and openbsd, not sure how critical it is. Your OpenBSD pcap contains not "URB_CONTROL in" packets. Don't know where they got lost but since you cannot see any data sent by the function on the control pipe, it is almost impossible to do any debugging here. You only see what the host sends to the function by miss the replies. smime.p7s Description: S/MIME cryptographic signature
Re: urndis0: IOERROR
On Mon, Nov 22, 2021 at 12:32:30PM +0300, Mikhail wrote: > On Mon, Nov 22, 2021 at 09:31:59AM +0100, Gerhard Roth wrote: > > On 11/20/21 17:12, Mikhail wrote: > > > Comparing Windows and OpenBSD tcpdumps I noticed some differences: > > > > > > 1) In REMOTE_NDIS_INITIALIZE_MSG (I patched the kernel to send it before > > > getting MAC address and with proper minor version) bInterfaceClass on > > > OpenBSD is set to Unknown (0x), on Windows it's properly set to > > > Wireless Controller (0xe0). > > > > > > 2) The control transfer stage for this message on OpenBSD is set to > > > Data, on Windows it is Setup. > > > > > > 3) The answer for the message on Windows is with USBD_STATUS_SUCCESS > > > (0x), on OpenBSD it's Unknown (0x000d). > > > > > > 4) The answer for the message on Windows contains "Control transfer > > > stage: Complete" message, on OpenBSD it's set to Status. > > > > > > Maybe someone can prompt me: > > > > > > 1) Does those differences matter at all? > > > > > > 2) Where to look regarding changing bInterfaceClass for outgoing > > > messages? I can see it's properly set in urndis driver (line 133 of > > > if_urndis.c), but not passed anywhere down to USB stack. > > > > You're getting something wrong here. It is the USB function that sets > > bInterfaceClass in its device descriptor, not the host. > > It's what I see in wireshark - bInterfaceClass is set for outgoing > packets, for windows it is in frame 27, in patched openbsd it is in fram > 172. Oh, I think I understand what's happening - this line about bInterfaceClass in the capture is in square brackets, and according to the docs it is generated by wireshark: https://www.wireshark.org/docs/wsug_html_chunked/AppMessages.html Wireshark provides you with additional information generated out of the plain packet data or it may need to indicate dissection problems. Messages generated by Wireshark are usually placed in square brackets (“[]”). But it is still a difference between windows and openbsd, not sure how critical it is.
Re: urndis0: IOERROR
On 11/20/21 17:12, Mikhail wrote:
Comparing Windows and OpenBSD tcpdumps I noticed some differences:
1) In REMOTE_NDIS_INITIALIZE_MSG (I patched the kernel to send it before
getting MAC address and with proper minor version) bInterfaceClass on
OpenBSD is set to Unknown (0x), on Windows it's properly set to
Wireless Controller (0xe0).
2) The control transfer stage for this message on OpenBSD is set to
Data, on Windows it is Setup.
3) The answer for the message on Windows is with USBD_STATUS_SUCCESS
(0x), on OpenBSD it's Unknown (0x000d).
4) The answer for the message on Windows contains "Control transfer
stage: Complete" message, on OpenBSD it's set to Status.
Maybe someone can prompt me:
1) Does those differences matter at all?
2) Where to look regarding changing bInterfaceClass for outgoing
messages? I can see it's properly set in urndis driver (line 133 of
if_urndis.c), but not passed anywhere down to USB stack.
You're getting something wrong here. It is the USB function that sets
bInterfaceClass in its device descriptor, not the host.
On Sun, Nov 14, 2021 at 02:39:33PM +0300, Mikhail wrote:
On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote:
Hello, I get aforesaid error when trying to plug in my 4G usb modem, it
works well on another laptop with windows 10.
I enabled debug info, but seem the failure somewhere deeper in usb stack
and I wasn't able to catch it, can someone advice me on further
debugging efforts?
I did some further investigation with wireshark - in attachment two
captures - from windows (modem is working) and from openbsd (not
working).
I also found some differences in behavior of the device attachment and
processing. According to RNDIS specs[1]:
1) MinorVersion of REMOTE_NDIS_INITIALIZE_MSG must be set to 0x
(paragraph 2.2.2), but in our code it's set to 1:
sys/dev/usb/if_urndis.c:
459 msg->rm_ver_minor = htole32(1);
2) The REMOTE_NDIS_INITIALIZE_MSG message must come first, but in
OpenBSD first message is getting hardware address (same file):
1462 if (urndis_ctrl_query(sc, OID_802_3_PERMANENT_ADDRESS, NULL, 0,
1463 , ) != RNDIS_STATUS_SUCCESS) {
1464 printf(": unable to get hardware address\n");
1465 splx(s);
1466 return;
1467 }
In yota-windows.pcapng the REMOTE_NDIS_INITIALIZE_MSG is in frame 27.
In yota-openbsd.pcapng OID_802_3_PERMANENT_ADDRESS is in fram 290.
Maybe someone with USB protocol understanding can take a look at the
captures and note the problems in device responses?
I also tried latest snapshot, the problem still persist.
[1] -
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/WinArchive/%5BMS-RNDIS%5D.pdf
smime.p7s
Description: S/MIME cryptographic signature
Re: urndis0: IOERROR
Comparing Windows and OpenBSD tcpdumps I noticed some differences:
1) In REMOTE_NDIS_INITIALIZE_MSG (I patched the kernel to send it before
getting MAC address and with proper minor version) bInterfaceClass on
OpenBSD is set to Unknown (0x), on Windows it's properly set to
Wireless Controller (0xe0).
2) The control transfer stage for this message on OpenBSD is set to
Data, on Windows it is Setup.
3) The answer for the message on Windows is with USBD_STATUS_SUCCESS
(0x), on OpenBSD it's Unknown (0x000d).
4) The answer for the message on Windows contains "Control transfer
stage: Complete" message, on OpenBSD it's set to Status.
Maybe someone can prompt me:
1) Does those differences matter at all?
2) Where to look regarding changing bInterfaceClass for outgoing
messages? I can see it's properly set in urndis driver (line 133 of
if_urndis.c), but not passed anywhere down to USB stack.
On Sun, Nov 14, 2021 at 02:39:33PM +0300, Mikhail wrote:
> On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote:
> > Hello, I get aforesaid error when trying to plug in my 4G usb modem, it
> > works well on another laptop with windows 10.
> >
> > I enabled debug info, but seem the failure somewhere deeper in usb stack
> > and I wasn't able to catch it, can someone advice me on further
> > debugging efforts?
>
> I did some further investigation with wireshark - in attachment two
> captures - from windows (modem is working) and from openbsd (not
> working).
>
> I also found some differences in behavior of the device attachment and
> processing. According to RNDIS specs[1]:
>
> 1) MinorVersion of REMOTE_NDIS_INITIALIZE_MSG must be set to 0x
>(paragraph 2.2.2), but in our code it's set to 1:
>
> sys/dev/usb/if_urndis.c:
> 459 msg->rm_ver_minor = htole32(1);
>
> 2) The REMOTE_NDIS_INITIALIZE_MSG message must come first, but in
>OpenBSD first message is getting hardware address (same file):
>
> 1462 if (urndis_ctrl_query(sc, OID_802_3_PERMANENT_ADDRESS, NULL, 0,
> 1463 , ) != RNDIS_STATUS_SUCCESS) {
> 1464 printf(": unable to get hardware address\n");
> 1465 splx(s);
> 1466 return;
> 1467 }
>
> In yota-windows.pcapng the REMOTE_NDIS_INITIALIZE_MSG is in frame 27.
>
> In yota-openbsd.pcapng OID_802_3_PERMANENT_ADDRESS is in fram 290.
>
> Maybe someone with USB protocol understanding can take a look at the
> captures and note the problems in device responses?
>
> I also tried latest snapshot, the problem still persist.
>
> [1] -
> https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/WinArchive/%5BMS-RNDIS%5D.pdf
>
>
yota-patched2.pcapng
Description: Binary data
Re: urndis0: IOERROR
On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote:
> Hello, I get aforesaid error when trying to plug in my 4G usb modem, it
> works well on another laptop with windows 10.
>
> I enabled debug info, but seem the failure somewhere deeper in usb stack
> and I wasn't able to catch it, can someone advice me on further
> debugging efforts?
I did some further investigation with wireshark - in attachment two
captures - from windows (modem is working) and from openbsd (not
working).
I also found some differences in behavior of the device attachment and
processing. According to RNDIS specs[1]:
1) MinorVersion of REMOTE_NDIS_INITIALIZE_MSG must be set to 0x
(paragraph 2.2.2), but in our code it's set to 1:
sys/dev/usb/if_urndis.c:
459 msg->rm_ver_minor = htole32(1);
2) The REMOTE_NDIS_INITIALIZE_MSG message must come first, but in
OpenBSD first message is getting hardware address (same file):
1462 if (urndis_ctrl_query(sc, OID_802_3_PERMANENT_ADDRESS, NULL, 0,
1463 , ) != RNDIS_STATUS_SUCCESS) {
1464 printf(": unable to get hardware address\n");
1465 splx(s);
1466 return;
1467 }
In yota-windows.pcapng the REMOTE_NDIS_INITIALIZE_MSG is in frame 27.
In yota-openbsd.pcapng OID_802_3_PERMANENT_ADDRESS is in fram 290.
Maybe someone with USB protocol understanding can take a look at the
captures and note the problems in device responses?
I also tried latest snapshot, the problem still persist.
[1] -
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/WinArchive/%5BMS-RNDIS%5D.pdf
OpenBSD 7.0-current (GENERIC.MP) #32: Sun Nov 14 13:50:09 MSK 2021
mi...@edge.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 4117065728 (3926MB)
avail mem = 3976323072 (3792MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (65 entries)
bios0: vendor LENOVO version "H0ET96WW (2.56 )" date 06/12/2015
bios0: LENOVO 3259KNG
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI UEFI
POAT UEFI DBG2
acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S3) RP01(S4)
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S5) RP05(S4)
PXSX(S4) RP06(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.72 MHz, 06-3a-09
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.35 MHz, 06-3a-09
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr
urndis0: IOERROR
Hello, I get aforesaid error when trying to plug in my 4G usb modem, it works well on another laptop with windows 10. I enabled debug info, but seem the failure somewhere deeper in usb stack and I wasn't able to catch it, can someone advice me on further debugging efforts? urndis0 at uhub3 port 2 configuration 2 interface 0 "Yota Devices LTD Modem YOTA 4G LTE" rev 2.00/3.34 addr 5 urndis0: using RNDIS ehci_idone: len=0, actlen=0, cerr=0, status=0x80008108 ehci_idone: ex=0xfd811de86de0 done urndis0: in=0x81, out=0x2 urndis0: urndis_ctrl_query send: type 4 len 28 rid 0 oid 0x1010101 infobuflen 0 infobufoffset 0 devicevchdl 0 ehci_alloc_sqtd_chain: start len=28 ehci_alloc_sqtd_chain: dataphys=0xd8459dc0 dataphyslastpage=0xd8459000 len=28 curlen=28 ehci_idone: len=28, actlen=0, cerr=0, status=0x80248 ehci_idone: ex=0xfd811de86de0 done urndis0: IOERROR urndis0: query failed : unable to get hardware address ehci_alloc_sqtd_chain: start len=4 ehci_alloc_sqtd_chain: dataphys=0xd8459dc0 dataphyslastpage=0xd8459000 len=4 curlen=4 ehci_idone: len=4, actlen=4, cerr=3, status=0x8c00 ehci_idone: ex=0xfd811de86de0 done ehci_idone: len=0, actlen=0, cerr=3, status=0x8d00 ehci_idone: ex=0xfd811de86de0 done urndis_detach: urndis0 flags 1 urndis0 detached
