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 (0xffff), 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 (0x00000000), on OpenBSD it's Unknown (0x0000000d). 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 0x00000000 (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 &buf, &bufsz) != 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
