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 (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. > > 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.
