Tagged: windows-7 linux rndis bridge
January 23, 2017 at 8:14 am #9564erminParticipant
I have a Linux device that exposes it’s network interface over USB port and in order to interface with Windows host it makes use of composite gadget driver offering RNDIS protocol for that purposes.
I made Windows driver installation that relies on netrndis.inf driver installation file and for linux device’s Ethernet over USB NIC I prepared INF file, based on template for NDIS 6 protcol, that relates specifically to device’s Vendor and Product ID data.
Driver installs and runs correctly as far as I can see.
When device’s USB NIC is kept unabridged I can get DHCP assigned address on linux side while having DHCP server running on Windows side for that network interface.
But putting device’s USB NIC to bridge with Ethernet adapter on Windows side prevents NIC exposed on Linux side to obtain DHCP IP address.
As far as I can conclude problem is in not receiving proper value for OID_GEN_CURRENT_PACKET_FILTER on Linux side of USB NIC.
For example when having unabridged NIC and after issuing command:
, I get this trace in kernel’s messages file:
Jan 9 15:39:31 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 00000009
Jan 9 15:39:31 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 0000000b
Jan 9 15:39:31 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 0000000f
When having interface bridged on Windows side and after issuing command:
, I get this:
Jan 9 15:54:14 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 00000020
Jan 9 15:54:14 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 00000000
Jan 9 15:56:02 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 00000002
Jan 9 15:56:07 (none) kern.debug kernel: gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 00000020
It should be noted that maximum possible value for ID_GEN_CURRENT_PACKET_FILTER should be 0x0f and not 0x20, and I think that’s the problem and my guess is that it’s coming from MAC Bridge Miniport driver!
Does anyone know is there’s some workaround for this issue like adding some registry keys for MAC Bridge Miniport driver installation so Linux kernel driver for composite gadget receives correct value for OID_GEN_CURRENT_PACKET_FILTER?
ErminJanuary 23, 2017 at 8:54 am #9565Vadim SmirnovModerator
Hmm, I don’t think you can alter Windows native bridge behavior, however you can try an alternative network bridging approach suggested here https://www.ntkernel.com/bridging-networks-with-windows-packet-filter/. It should work for your setup.
If your task is connecting RNDIS USB device to laptop network then you can also use NAT approach instead bridge. I have had such experience in the past with USB connected NetTalk DUO device.
And the last, you can try to play around OID_GEN_CURRENT_PACKET_FILTER by setting it directly for underlying USB RNDIS miniport. WinpkFilter driver allows you to bind above and below Windows native Ethernet Bridge, so you can bind to USB RNDIS miniport directly even with enabled bridging. And then try try set different filter for USB RNDIS by using CNdisApi:SetHwPacketFilter. Al least you can find out if setting different packet filter can help here.January 24, 2017 at 7:48 am #9566erminParticipant
Thank you for the reply.
I’ll see what can be done with suggestions you gave and get back eventually if there’s something I’m missing to come to final solution.
- You must be logged in to reply to this topic.