We have a mux driver over the top of a miniportdriver. This is all working perfectly ok on Windows 7. We are testing the driver setup on windows 8.1 and have found that when we call NdisSendNetBufferLists to pass down the packet list to our bottom driver the completion routine immediately gets called and the lower driver never see’s the packet??? The bindings are spot on, I have checked all the binding handle addresses. The routes are spot on for the packet etc… At a loss as to why the packets are not being send to our lower driver using the binding handle supplied??? any suggestions?
It is a basic 3:1 mux. The packets in the mux are none altered from the tcpip stack they are forwarded based on he binding. The mux is configured to only bind to our lower miniport as per windows 7.
NDIS does very little in the NdisSendNetBufferLists path. The NBLs will be bounced by NDIS only if:
-
The lower miniport is not media-connected. The NBLs will be completed with NDIS_STATUS_MEDIA_DISCONNECTED.
-
The lower miniport is currently resetting. The NBLs will be completed with NDIS_STATUS_NOT_SUPPORTED or NDIS_STATUS_RESET_IN_PROGRESS.
-
The lower miniport is in a low power state. The NBLs will be completed with NDIS_STATUS_LOW_POWER_STATE.
Each of the three states above is visible in !ndiskd.miniport. Run that on your lower miniport, and check that the miniport looks healthy. Also check if the NBLs are completed with any interesting status code. Do this by
- Ensure that NET_BUFFER_LIST::Status is set to some neutral value before you send them down.
- Check NET_BUFFER_LIST::Status when the NBLs are returned to your MUX’s protocol edge.
Finally, it’s worth double-checking that your lower miniport’s send handler *really* isn’t getting called. (I know this seems redundant, but I’ve been fooled by wrapper functions and macros more than once.) Use !ndiskd.minidriver to find the actual MiniportSendNetBufferLists handler that the OS knows about. Then set a breakpoint on that function, and see if it hits.
Thanks Jeffrey…
I will check the status’s on completion…
I have actually got it working last night… but its a bit strange… In order to make it work I have clobbered the destination mac address with all ff’s and it now passes it through !!!.. so what’s the difference between Windows 7 and Windows 8/8.1… the Dest mac was the lower adapter’s mac!.. and IMO it should not matter as the mux is only bound to the bottom adapter??
So what the hell is going on!!
Steve
NDIS doesn’t look at the packet payload on the TX path. There’s something else going on.
One other idea that comes to mind - ndiskd can track the path of a packet through the network stack. The output is a bit hard to read, but you might discover something interesting by comparing a working packet from a non-working packet. http://blogs.msdn.com/b/ndis/archive/2013/12/27/ndiskd-nbl-log.aspx
Assuming that all things being equal (compatible) between Windows 7 and Windows 8/8.1 with respect to NDIS. and the code is identical… The only possibility is that the default stack bindings have placed a filter of some sort in the way that is processing packets. So what has changed between Windows 7 and Windows 8/8.1 with respect to the windows default stack bindings?
It must be a change of this or there is a bug on Windows 8.1? The packet btw is a simple ping packet with Dest mac of the lower Adapter and Src mac of the mux, nothing could be simpler…
I am suspecting some sort of bug or a packet filter that should not be in the path… The Mux only filters on receive so nothing on the tx path…?
The bottom adapter is hidden so that the user only see’s the mux adapters to set addresses… just in the process of making it visible for testing so I can see what protocols and filters / services are attached…
Are you sure that on Windows 8.1 that the packet processing of TCP/IP packets are not filtered between a protocol binding and a miniport binding? on the send path?
Further information. UNHIDING the adapter, shows no other bound protocols / services or filers attached to the stack?? and it is only bound to our mux protocol?
Interestingly using bindview the bind path shows that TCP/IP is showing a path to the lower adapter? even though the dialog says it isn’t used? BUT then so is Windows 7 and that is working. I am going to try Windows 8 not Windows 8.1
Hi Jeffery,
On Friday, I discovered that the issue is with the new 8.1 MUX LWF driver that IS filtering packets, despite the firewall being disabled and despite the adapter showing no filters attached in the adapters service display. In Bind view uninstalling these filters make the packet send path work to our lower adapter. So my question is what filter algorithm is deciding to block our packet, even when it is outgoing and what rule in the firewall would be causing this problem despite it being disabled.? It is a MS filter driver that is forcible inserted into the path of the stack. I could add code to remove it, but that means no firewall? It more like some bug in the LWF driver?
Regards
Steve
Just to clarify. If I uninstall the WFP Native MAC Layer Light Weight Filter driver from our lower adapter the packet is seen by our lower adapter from the MUX. So what is he best way to control this filter or is there a bug in his filter as it should not be dumping our packet?
Nope its a clean system each time from my MSDN lib. the mux is the template DDK no changes. the template sets the no loopback flag on TX. The destination mac address is the lower adapters mac and the src is the mac of the mux, the base mac are the same except the lower mac is zero last byte and mux is 02, so I am suspecting that despite you saying its in bypass it is inspectecting the packet, remember that if I set the dest mac to broadcast ‘ff’s’ it works!!! … using netcfg I can not remove the binding to filters… just altering the DEST. mac should not make any difference, but it does. My last test is to use a completely different MAC as it wont matter as the VPN strips the MAC header off on the lower driver before I sends it to the real hardware device. So still think there is a bug in the MS filter… as when you uninstall it using bind view… it all works…
But that is the way the sample works, it disables the loop back and forwards the packet… and this works in Windows 7, Windows 8 and 8.1 does not work without removing, (uninstalling), the WFP Native MAC Layer LW filter, so it has to be in that filter, somewhere… Netcfg wont let you unbind the filter… see my comments in Jeff’s post…
A bit stuck now!!!
Nope its a clean system each time from my MSDN lib. the mux is the template DDK
no changes. the template sets the no loopback flag on TX. The destination mac
address is the lower adapters mac and the src is the mac of the mux, the base
mac are the same except the lower mac is zero last byte and mux is 02, so I am
suspecting that despite you saying its in bypass it is inspecting the packet,
remember that if I set the dest mac to broadcast ‘ff’s’ it works!!! … using
netcfg I can not remove the binding to filters… just altering the DEST. mac
should not make any difference, but it does. My last test is to use a completely
different MAC as it wont matter as the VPN strips the MAC header off on the
lower driver before I sends it to the real hardware device. So still think there
is a bug in the MS filter… as when you uninstall it using bind view… it all
works…
Its multiplexing the lower NIC that’s all… the “Binding” of the mux is only to our lower adapter. MS have forcible loaded a new filter in-between our mux and lower hidden adapter on Windows 8 / 8.1 and it doesn’t appear to be transparent. It is almost like the outgoing MAC filter rule has a problem… it’s maybe that is does not like 00 mac addresses as the last byte, just guessing… as its a stack of miniport / protocols the order is more important. As jeff say’s the send function does very little and just sends the packets to the binding handle… there is no protocol intelligence in-between other than filters… So IMO it still looking like a bug…
A question to Jeff… how can we escalate this call… should I but a issue on my MSDN to get this escalated… and if it turns out to be a bug do we get refunded?
Have run the command on the Native MAC Layer and I Get
FILTER DRIVER
WFP Native MAC Layer LightWeight Filter
blah blah…
Driveobject … 85746f30
Driver Image … wfplwfs.sys
Filter Type … MODIFYING_FILTER
Run Type … MODIFYING_FILTER
Class … ms_medium_convertor_bottom
HANDLERS
SendNetBufferListHandler … 82e48dc9 … wfplwfs!LwfLowerSendNetBufferLists
Your command did not work, invalid is not a valid filter???