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


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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to