No IPV4 , IPV6 packets on NDIS interface when i connect with a adapter interface ?

vinay_kp · June 6, 2016, 3:43am

I am Checking Wireless Mobile broadband Adapter Connectivity on my VPN application . I am using NDIS Wireless adapter and my VPN has NDIS 6.2 LWF driver , miniport driver .
This Mobile broadband Adapter is NdisMediumWirelessWan Medium type . My VPN application is working pretty well on Ethernet , Wifi adapter . Now i can't connect with NDIS Mobile Broadband adapter . I print all packet dumps when sending over filter driver .I compare this dump with working Wifi adapter . But i don't know why i can't get full packet size . any idea ?

Wifi packet :

Wifi Sending packet ( Working code

Wifi MAC Address : 81:17:35:AF:94:25

Filter::PacketOutput() start

---packet dump start---

Filter::PacketOutput(): 81:17:35:AF:94:25->FF:FF:FF:FF:FF:FF 0806

--packet dump end --

Filter::PacketOutput(): exited

Filter::SendNetBufferLists():
Filter::OutgoingNetBufferInput():

---packet dump start---

packet length = 355

(pBuffer[12] == 0x08) && (pBuffer[13] == 0x00)

81:17:35:AF:94:25->FF:FF:FF:FF:FF:FF 0800 17 0.0.0.0:68->255.255.255.255:67

--packet dump end --

calling InterfaceManager::OutgoingPacketInput
InterfaceManager::OutgoingPacketInput():
PacketFilter::Filter

-- packet dump start --

pEthHeader->nProto == ETH_PROTO_IPV4

OUT 81:17:35:AF:94:25-> FF:FF:FF:FF:FF:FF IPV4 UDP 0.0.0.0:68 -> 255.255.255.255:67

filterRecord.nEthProto == ETH_PROTO_IPV4

--packet dump end ---

2 . But in case of Wireless adapter ( NDIS Dongle)

Dongle : sending packet

Dongle MAC address : 00:1C:11:1G:00:00

Filter::PacketOutput() start

---packet dump start---

Filter::PacketOutput(): 00:1C:11:1G:00:00->FF:FF:FF:FF:FF:FF 0806

--packet dump end --

Filter::PacketOutput(): exited

Filter::SendNetBufferLists():
Filter::OutgoingNetBufferInput():

---packet dump start---

packet length = 62

Filter::OutgoingNetBufferInput(): 00:00:80:11:BE:9D->45:00:00:3E:50:0B 0AAD

--packet dump end --

calling InterfaceManager::OutgoingPacketInput
InterfaceManager::OutgoingPacketInput():
PacketFilter::Filter

-- packet dump start --

-- Not ipv4 , ipv6 & arp --
OUT 00:00:80:11:BE:9D -> 45:00:00:3E:50:0B AD0A

--packet dump end ---

After analyzing these 2 logs , i can see that i can't get any IPV4 , IPV6 (TCP/UDP) packets
on dongle interface . But in case of Wifi , i am getting .

And the size of packet is different in case of dongle when i compared with Wifi .

Mobile broadband adapter is sending RAW IP instead of ether net packet . That may be the reason ?

How can i fix this problem as per the NDIS perspective ? Any idea or suggestions ?

Chris_Aseltine · June 6, 2016, 11:08am

vinay kp wrote:

This Mobile broadband Adapter is NdisMediumWirelessWan
Medium type . My VPN application is working pretty well on
Ethernet , Wifi adapter . Now i can’t connect with NDIS Mobile
Broadband adapter .

I’m just curious. What sort of situation are you in where it’s acceptable to just spin your wheels on the same exact problem for 6+ months?

David_R_Cattley · June 6, 2016, 3:28pm

> Mobile broadband adapter is sending RAW IP instead of ether net packet . That may be the reason ?

At the risk of offending you…. Yes. That is what MBB stack sends & receives. This is well documented.

How can i fix this problem as per the NDIS perspective ? Any idea or suggestions ?

Sorry, what problem? The problem with your code or your understanding.

Your code: Interpret the frames according to the media format for the stack (e.g. Raw IP).

Your understanding: Your filter must conform to the stack behavior it is bound into. You cannot force the system to make everything look like Ethernet just because that would be convenient for you.

BTW, I believe I answered this the first time you asked it (oh, so long ago). And I also pointed out that you should be capturing IP traffic via a WFP callout and not an LWF.

Good luck storming the castle.
Dave Cattley

vinay_kp · June 7, 2016, 3:02am

Thanks for suggestion Chris Aseltine , David R. Cattley

@Chris Aseltine yeah i am looking this problem around 6+ months . But i didn’t get exact solution for this .

@David R. Cattley yeah . i know this MBB is different than Ethernet . But as per the Microsoft document
i done MB Raw IP Packet Processing Support .

https://msdn.microsoft.com/en-us/library/windows/hardware/ff559110(v=vs.85).aspx

But why i didn’t get any IPV4/IPV6 packets from stack ? I done binding MB with my filter using INF chnages . But i don’t know why stack not sending packets .

I think this is my 8+ post related to this issue . When ever i do something related to this , i am stuck with some problems . that is why i am posting my queries .

Now i want to know :

1 ) Is it any documentation for MBB stack send/receive or what are the support should i do for getting stack packet for MBB .

Now binding my adapter is working fine . Now i think i need packet flow only . Is any other configuration required other than stack send/receive ?
I have some doubt about mini port driver related to MBB . I am using a MBB adapter , so it has a mini port and My VPN has also a mini port . My VPN mini port is NDIS 6.20 but not handled for MBB .
what is the role for MBB adapter mini port ? will it send / receive any packet ?
my understanding is RAW IP means ip frames with out Ethernet packets . My VPN is supporting Ethernet packets . So how should i support RAW IP packet with using Ethernet support ? or should i add any Ethernet header with that RAW packet ? i am beginner in RAW IP .

Thanks

anton_bassov · June 7, 2016, 6:13pm

Statement of the year…

Anton Bassov

vinay_kp · June 8, 2016, 12:08am

Is my understanding is wrong ? Can I know that ?

vinay_kp · June 8, 2016, 9:34am

what are the changes should i done in NDIS for supporting RAW IP frames ?

vinay_kp · June 9, 2016, 4:43am

This is the NDIS 6.20 Media extensible feature .NDIS 6.20 and later provide raw IP frame support with a new media type for raw IP (NdisMediumIP). For example, NDIS WWAN support uses raw IP.

So now my miniport consist of :

MediaSupported = NdisMedium802_3 ;
MediaInUse = NdisMedium802_3 ;
PhysicalMedium = NdisPhysicalMediumUnspecified;

and OID’s are :

ULONG uIdx = 0;
m_ulSupportedOidsSize = 44;
m_pSupportedOids = new NDIS_OID[m_ulSupportedOidsSize];

m_pSupportedOids[uIdx++] = OID_GEN_HARDWARE_STATUS;
m_pSupportedOids[uIdx++] = OID_GEN_TRANSMIT_BUFFER_SPACE;
m_pSupportedOids[uIdx++] = OID_GEN_RECEIVE_BUFFER_SPACE;
m_pSupportedOids[uIdx++] = OID_GEN_TRANSMIT_BLOCK_SIZE;
m_pSupportedOids[uIdx++] = OID_GEN_RECEIVE_BLOCK_SIZE;
m_pSupportedOids[uIdx++] = OID_GEN_VENDOR_ID;
m_pSupportedOids[uIdx++] = OID_GEN_VENDOR_DESCRIPTION;
m_pSupportedOids[uIdx++] = OID_GEN_VENDOR_DRIVER_VERSION;
m_pSupportedOids[uIdx++] = OID_GEN_CURRENT_PACKET_FILTER;
m_pSupportedOids[uIdx++] = OID_GEN_CURRENT_LOOKAHEAD;

m_pSupportedOids[uIdx++] = OID_GEN_DRIVER_VERSION;
m_pSupportedOids[uIdx++] = OID_GEN_MAXIMUM_TOTAL_SIZE;
m_pSupportedOids[uIdx++] = OID_GEN_XMIT_OK;
m_pSupportedOids[uIdx++] = OID_GEN_RCV_OK;
m_pSupportedOids[uIdx++] = OID_GEN_STATISTICS;
m_pSupportedOids[uIdx++] = OID_GEN_TRANSMIT_QUEUE_LENGTH;
m_pSupportedOids[uIdx++] = OID_GEN_LINK_PARAMETERS;
m_pSupportedOids[uIdx++] = OID_GEN_INTERRUPT_MODERATION;
m_pSupportedOids[uIdx++] = OID_GEN_MEDIA_SUPPORTED;
m_pSupportedOids[uIdx++] = OID_GEN_MEDIA_IN_USE;

m_pSupportedOids[uIdx++] = OID_GEN_MAXIMUM_SEND_PACKETS;
m_pSupportedOids[uIdx++] = OID_GEN_XMIT_ERROR;
m_pSupportedOids[uIdx++] = OID_GEN_RCV_ERROR;
m_pSupportedOids[uIdx++] = OID_GEN_RCV_NO_BUFFER;
m_pSupportedOids[uIdx++] = OID_802_3_PERMANENT_ADDRESS;
m_pSupportedOids[uIdx++] = OID_802_3_CURRENT_ADDRESS;
m_pSupportedOids[uIdx++] = OID_802_3_MULTICAST_LIST;
m_pSupportedOids[uIdx++] = OID_802_3_MAXIMUM_LIST_SIZE;
m_pSupportedOids[uIdx++] = OID_802_3_RCV_ERROR_ALIGNMENT;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_ONE_COLLISION;

m_pSupportedOids[uIdx++] = OID_802_3_XMIT_MORE_COLLISIONS;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_DEFERRED;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_MAX_COLLISIONS;
m_pSupportedOids[uIdx++] = OID_802_3_RCV_OVERRUN;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_UNDERRUN;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_HEARTBEAT_FAILURE;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_TIMES_CRS_LOST;
m_pSupportedOids[uIdx++] = OID_802_3_XMIT_LATE_COLLISIONS;
m_pSupportedOids[uIdx++] = OID_PNP_CAPABILITIES;
m_pSupportedOids[uIdx++] = OID_RECEIVE_FILTER_ALLOCATE_QUEUE;

m_pSupportedOids[uIdx++] = OID_RECEIVE_FILTER_QUEUE_ALLOCATION_COMPLETE;
m_pSupportedOids[uIdx++] = OID_RECEIVE_FILTER_FREE_QUEUE;
m_pSupportedOids[uIdx++] = OID_RECEIVE_FILTER_CLEAR_FILTER;
m_pSupportedOids[uIdx++] = OID_RECEIVE_FILTER_SET_FILTER;

so for supporting MB . should i add any media type ? i want to get support both Ethernet and MB in my VPN application .

How MB Stack shows different than Ethernet Stack ? any suggestion please …

David_R_Cattley · June 9, 2016, 9:15pm

Are you asking a question about a Virtual Adapter you have created or are you asking a question about a LWF?
You seem to be bouncing back & forth.
Since the last thing you asked was about a Miniport, I suppose then you must have bounced back to Virtual Adapter.
The question I have is why would you create a MBB Virtual Adapter (if that is what you have attempted to do)?
A simple virtual Ethernet adapter is perfectly capable of getting IPv4 and IPv6 frames from the network stack. The sample NETVMINI does a fine job of illustrating that.
If that is not what you are asking about then please ask again but take the time to focus your question and not jump between topics.
Good Luck,Dave Cattley

NILC · July 14, 2019, 1:55pm

I am working on a similar problem with filter drivers, WIFI/MBB, and capturing the proper packets. Since this post was the closest one that I ran across (so far) I figured I would share my current understanding from basically “bumping around in the dark”…there is very little documentation on how to handle capturing packets (both inbound and outbound) using WFP (not LWF).
This is what I have found to be true about WFP callout filters, VPN connections, and WIFI/MBB type network interfaces:

Only the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types will be able to capture both inbound and outbound packets during a secured VPN connection without having to deal with upper layer TCP IPSEC related issues (even the infamous FWPS_LAYER_OUTBOUND_MAC_FRAME_ETHERNET and FWPS_LAYER_INBOUND_MAC_FRAME_ETHERNET will get bypassed by the VPN connection).
Additionally, WIFI/MBB devices seem to completely bypass the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types. I am not quite sure why this was designed this way, but I think it has to do with WIFI/MBB devices using NWIFI.SYS? (anyone want to shed some light on this?)

So, if you are developing a WFP Callout Filter driver and plan on doing any form of packet inspection and/or manipulation with both a WIFI/MBB device during a secured VPN connection (tunneling through the device) then it would appear it is literally impossible (using only the WFP driver for packet modification/inspection) as VPN connections bypass everything above the MAC_FRAME_NATIVE filters up to the TCP IPSEC related filters and WIFI/MBB devices bypass the MAC_FRAME_NATIVE filter layers! doh

This brings me to two general questions (would love a response if you know the answers):

If I were to port my WFP filter down to an NDIS LWF, would I see the exact same behavior (as described above) or would I be able to see the inbound and outbound frames prior to being sent to the WIFI/MBB device?
If yes (same behavior as described above), then is there any other way to capture the 802.3 frames (not 802.11) prior to them being sent to the WIFI/MBB device that would not get bypassed by a secured VPN connection?

Any input on this would be greatly appreciated…
One would think that the WFP lower stack (i.e. MAC_NATIVE) would still show the 802.3 frames on WIFI/MBB devices…but then again I am not an expert in that area and as such it could just be “the way it is” (if so that would kind of suck for me).

NILC · July 14, 2019, 2:02pm

I am working on a similar problem with filter drivers, WIFI/MBB, and capturing the proper packets. Since this post was the closest one that I ran across (so far) I figured I would share my current understanding from basically “bumping around in the dark”…there is very little documentation on how to handle capturing packets (both inbound and outbound) using WFP (not LWF).
This is what I have found to be true about WFP callout filters, VPN connections, and WIFI/MBB type network interfaces:
—Only the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types will be able to capture both inbound and outbound packets during a secured VPN connection without having to deal with upper layer TCP IPSEC related issues (even the infamous FWPS_LAYER_OUTBOUND_MAC_FRAME_ETHERNET and FWPS_LAYER_INBOUND_MAC_FRAME_ETHERNET will get bypassed by the VPN connection).

—Additionally, WIFI/MBB devices seem to *completely bypass the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types. I am not quite sure why this was designed this way, but I think it has to do with WIFI/MBB devices using NWIFI.SYS? (anyone want to shed some light on this?)

So, if you are developing a WFP Callout Filter driver and plan on doing any form of packet inspection and/or manipulation with both a WIFI/MBB device during a secured VPN connection (tunneling through the device) then it would appear it is literally impossible (using only the WFP driver for packet modification/inspection) as VPN connections bypass everything above the MAC_FRAME_NATIVE filters up to the TCP IPSEC related filters and WIFI/MBB devices bypass the MAC_FRAME_NATIVE filter layers! doh
This brings me to two general questions (would love a response if you know the answers):

If I were to port my WFP filter down to an NDIS LWF, would I see the exact same behavior (as described above) or would I be able to see the inbound and outbound frames prior to being sent to the WIFI/MBB device?
If yes (same behavior as described above), then is there any other way to capture the 802.3 frames (not 802.11) prior to them being sent to the WIFI/MBB device that would not get bypassed by a secured VPN connection?
Any input on this would be greatly appreciated…
One would think that the WFP lower stack (i.e. MAC_NATIVE) would still show the 802.3 frames on WIFI/MBB devices…but then again I am not an expert in that area and as such it could just be “the way it is” (if so that would kind of suck for me).

NILC · July 26, 2019, 8:50pm

I am working on a similar problem with filter drivers, WIFI/MBB, and capturing the proper packets. Since this post was the closest one that I ran across (so far) I figured I would share my current understanding from basically “bumping around in the dark”…there is very little documentation on how to handle capturing packets (both inbound and outbound) using WFP (not LWF).
This is what I have found to be true about WFP callout filters, VPN connections, and WIFI/MBB type network interfaces:
—Only the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types will be able to capture both inbound and outbound packets during a secured VPN connection without having to deal with upper layer TCP IPSEC related issues (even the infamous FWPS_LAYER_OUTBOUND_MAC_FRAME_ETHERNET and FWPS_LAYER_INBOUND_MAC_FRAME_ETHERNET will get bypassed by the VPN connection).

—Additionally, WIFI/MBB devices seem to *completely bypass the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types. I am not quite sure why this was designed this way, but I think it has to do with WIFI/MBB devices using NWIFI.SYS? (anyone want to shed some light on this?)

So, if you are developing a WFP Callout Filter driver and plan on doing any form of packet inspection and/or manipulation with both a WIFI/MBB device during a secured VPN connection (tunneling through the device) then it would appear it is literally impossible (using only the WFP driver for packet modification/inspection) as VPN connections bypass everything above the MAC_FRAME_NATIVE filters up to the TCP IPSEC related filters and WIFI/MBB devices bypass the MAC_FRAME_NATIVE filter layers! doh

This brings me to two general questions (would love a response if you know the answers):

If I were to port my WFP filter down to an NDIS LWF, would I see the exact same behavior (as described above) or would I be able to see the inbound and outbound frames prior to being sent to the WIFI/MBB device?
If yes (same behavior as described above), then is there any other way to capture the 802.3 frames (not 802.11) prior to them being sent to the WIFI/MBB device that would not get bypassed by a secured VPN connection?

Any input on this would be greatly appreciated…
One would think that the WFP lower stack (i.e. MAC_NATIVE) would still show the 802.3 frames on WIFI/MBB devices…but then again I am not an expert in that area and as such it could just be “the way it is” (if so that would kind of suck for me).

NILC · July 26, 2019, 8:50pm

I am working on a similar problem with filter drivers, WIFI/MBB, and capturing the proper packets. Since this post was the closest one that I ran across (so far) I figured I would share my current understanding from basically “bumping around in the dark”…there is very little documentation on how to handle capturing packets (both inbound and outbound) using WFP (not LWF).
This is what I have found to be true about WFP callout filters, VPN connections, and WIFI/MBB type network interfaces:
—Only the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types will be able to capture both inbound and outbound packets during a secured VPN connection without having to deal with upper layer TCP IPSEC related issues (even the infamous FWPS_LAYER_OUTBOUND_MAC_FRAME_ETHERNET and FWPS_LAYER_INBOUND_MAC_FRAME_ETHERNET will get bypassed by the VPN connection).

—Additionally, WIFI/MBB devices seem to *completely bypass the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types. I am not quite sure why this was designed this way, but I think it has to do with WIFI/MBB devices using NWIFI.SYS? (anyone want to shed some light on this?)

So, if you are developing a WFP Callout Filter driver and plan on doing any form of packet inspection and/or manipulation with both a WIFI/MBB device during a secured VPN connection (tunneling through the device) then it would appear it is literally impossible (using only the WFP driver for packet modification/inspection) as VPN connections bypass everything above the MAC_FRAME_NATIVE filters up to the TCP IPSEC related filters and WIFI/MBB devices bypass the MAC_FRAME_NATIVE filter layers! doh

This brings me to two general questions (would love a response if you know the answers):

If I were to port my WFP filter down to an NDIS LWF, would I see the exact same behavior (as described above) or would I be able to see the inbound and outbound frames prior to being sent to the WIFI/MBB device?
If yes (same behavior as described above), then is there any other way to capture the 802.3 frames (not 802.11) prior to them being sent to the WIFI/MBB device that would not get bypassed by a secured VPN connection?

Any input on this would be greatly appreciated…
One would think that the WFP lower stack (i.e. MAC_NATIVE) would still show the 802.3 frames on WIFI/MBB devices…but then again I am not an expert in that area and as such it could just be “the way it is” (if so that would kind of suck for me).

NILC · July 26, 2019, 8:50pm

I am working on a similar problem with filter drivers, WIFI/MBB, and capturing the proper packets. Since this post was the closest one that I ran across (so far) I figured I would share my current understanding from basically “bumping around in the dark”…there is very little documentation on how to handle capturing packets (both inbound and outbound) using WFP (not LWF).
This is what I have found to be true about WFP callout filters, VPN connections, and WIFI/MBB type network interfaces:
—Only the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types will be able to capture both inbound and outbound packets during a secured VPN connection without having to deal with upper layer TCP IPSEC related issues (even the infamous FWPS_LAYER_OUTBOUND_MAC_FRAME_ETHERNET and FWPS_LAYER_INBOUND_MAC_FRAME_ETHERNET will get bypassed by the VPN connection).

—Additionally, WIFI/MBB devices seem to *completely bypass the FWPS_LAYER_OUTBOUND_MAC_FRAME_NATIVE and FWPS_LAYER_INBOUND_MAC_FRAME_NATIVE filter types. I am not quite sure why this was designed this way, but I think it has to do with WIFI/MBB devices using NWIFI.SYS? (anyone want to shed some light on this?)

So, if you are developing a WFP Callout Filter driver and plan on doing any form of packet inspection and/or manipulation with both a WIFI/MBB device during a secured VPN connection (tunneling through the device) then it would appear it is literally impossible (using only the WFP driver for packet modification/inspection) as VPN connections bypass everything above the MAC_FRAME_NATIVE filters up to the TCP IPSEC related filters and WIFI/MBB devices bypass the MAC_FRAME_NATIVE filter layers! doh

This brings me to two general questions (would love a response if you know the answers):

If I were to port my WFP filter down to an NDIS LWF, would I see the exact same behavior (as described above) or would I be able to see the inbound and outbound frames prior to being sent to the WIFI/MBB device?
If yes (same behavior as described above), then is there any other way to capture the 802.3 frames (not 802.11) prior to them being sent to the WIFI/MBB device that would not get bypassed by a secured VPN connection?

Any input on this would be greatly appreciated…
One would think that the WFP lower stack (i.e. MAC_NATIVE) would still show the 802.3 frames on WIFI/MBB devices…but then again I am not an expert in that area and as such it could just be “the way it is” (if so that would kind of suck for me).

anton_bassov · July 26, 2019, 10:33pm

OMG - yet another thread is brought back from the dead. I guess Peter must be already fed up with locking them…

Anton Bassov