NDIS 6.2 Windows 8 x64 and LLDP

NTDEV
1

Are there separate events or any registered callbacks being called when NDIS miniport be started with cables plugged into other physical ports of machine on windows 8 machine.
Bcoz I am running into an issue where if NDIS miniport starts while cables are plugged in my driver does not report correct link status hence I cannot see any outgoing or incoming data, versus when cables are unplugged it does report correct status…

Also on a side note windows 8 virtual machine works perfectly fine. So can be that my virtual miniport is acting differently under Virtual environment versus on physical machine. Just want to isolate where the issue can be so that I can diagnose the problematic key areas…

I tried capturing traffic on both setups, First frame that goes out of miniport on physical machine is of type LLDP versus on a working virtual machine I do not see any LLDP type of frames. Not sure if this can be a real issue…

BTW I am running an NDIS 6.2 on windows 8 machine.

2

Can you clarify. Are you writing the NDIS miniport driver? What sort of miniport is it, that works in both a VM and in physical machine?

If you are writing the miniport, you should have a call to NdisMIndicateStatusEx(NDIS_STATUS_LINK_STATE, MediaConnectStateConnected) as soon as you detect the link is present. You can technically also report this during MiniportInitializeEx, but most miniports don’t know their media state yet then. Most miniports’ initialize handlers report NdisMSetMiniportAttributes (NDIS_MINIPORT_ADAPTER_GENERAL_ATTRIBUTES::MediaConnectState = MediaConnectStateUnknown). Then they send up NDIS_STATUS_LINK_STATE later, once the real media state is known.

LLDP is not always enabled; it depends on the SKU and its configuration. So it might not be surprising that LLDP is transmitted on some machines but not others.

Can you paste the output of “!ndiskd.miniport ” in both the good and bad cases?

3

Hello Jeffrey,
I am developing NDIS miniport driver, started off netvmini sample part of WDK 7600.16385.0 . I do not expect to work under VM though I was just using VM environment for debugging the issue that I am encountering and found that it works well as expected and onto windows8 x64 physical machine it does not. It sounds like there can be key differences in regards to both environments…

following is the output from !ndiskd.miniport From windbg outout both shows as connected status but under non-working case within my “SendNetBufferListsHandler” I create a workItem to offload NBL and NBs for futher processing and I see that I get some additional NBLs and NBs which breaks my processing logic and hence everything falls apart. So after doing further debugging pinpointed that’s where the issue is but now what I really want to know is why there are extra frames being sent out when physical cables are connected verus not plugged in…

Working Case :

MINIPORT

Windows Virtual Ethernet Adapter

Ndis Handle fffffa800667c1a0
Ndis API Version v6.20
Adapter Context fffffa80069060c0
Miniport Driver fffffa800672b310 - MyVMini.sys v1.3
Ndis Verifier [No flags set]

Media Type 802.3
Physical Medium 802.3
Device Path ??\ROOT#NET#0000#{ad498944-762f-11d0-8dcb-00c04fc3358c}{473DA412-7715-418D-BFDA-84BC7715AE30}
Device Object fffffa800667c050
MAC Address 02-50-f2-8b-23-00

STATE

Miniport Running
Device PnP Started
Datapath Normal
Interface Up
Media Connected
Power D0
References 9
User Handles 0
Total Resets 0
Pending OID None
Flags 2c452400
? NOT_BUS_MASTER, PROCESSING_REQUEST, DEFAULT_PORT_ACTIVATED,
SUPPORTS_MEDIA_SENSE, DOES_NOT_DO_LOOPBACK, MEDIA_CONNECTED
PnPFlags 00410002
? VIRTUAL_DEVICE, RECEIVED_START, NDIS_WDM_DRIVER

BINDINGS

Filter List Filter Filter Driver Context _
WFP 802.3 MAC Layer LightWeight Filter-0000
fffffa80067e9c80 fffffa8005dada00 fffffa8006988790
QoS Packet Scheduler-0000
fffffa800675e010 fffffa8006499d80 fffffa80068b5860
WFP Native MAC Layer LightWeight Filter-0000
fffffa800692cc80 fffffa8005dfcd60 fffffa8006966640

Open List Open Protocol Context _
RSPNDR fffffa80073a0c30 fffffa800781d750 fffffa80073a0010
NDISUIO fffffa8007219730 fffffa80073aac50 fffffa8006531010
LLTDIO fffffa8006f77010 fffffa800723cc50 fffffa80071a2010
TCPIP6 fffffa800725da10 fffffa800631e010 fffffa800725bb10
TCPIP fffffa800692dc30 fffffa8005db97a0 fffffa800692c780

Non Working Case:

MINIPORT

Windows Virtual Ethernet Adapter

Ndis Handle fffffa800666d1a0
Ndis API Version v6.20
Adapter Context fffffa80066cb740
Miniport Driver fffffa800650a020 - MyVMini.sys v1.3
Ndis Verifier [No flags set]

Media Type 802.3
Physical Medium 802.3
Device Path ??\ROOT#NET#0000#{ad498944-762f-11d0-8dcb-00c04fc3358c}{473DA412-7715-418D-BFDA-84BC7715AE30}
Device Object fffffa800666d050
MAC Address 02-50-f2-8b-23-00

STATE

Miniport Running
Device PnP Started
Datapath Normal
Interface Up
Media Connected
Power D0
References 0n166
User Handles 0
Total Resets 0
Pending OID None
Flags 2c456400
? NOT_BUS_MASTER, PROCESSING_REQUEST, CHECK_FOR_LOOPBACK,
DEFAULT_PORT_ACTIVATED, SUPPORTS_MEDIA_SENSE, DOES_NOT_DO_LOOPBACK,
MEDIA_CONNECTED
PnPFlags 00410002
? VIRTUAL_DEVICE, RECEIVED_START, NDIS_WDM_DRIVER

BINDINGS

Filter List Filter Filter Driver Context _
WFP 802.3 MAC Layer LightWeight Filter-0000
fffffa8006905010 fffffa8005dcd3c0 fffffa80068fd450
QoS Packet Scheduler-0000
fffffa80066c9650 fffffa800658e6b0 fffffa80068c0960
WFP Native MAC Layer LightWeight Filter-0000
fffffa80068fe410 fffffa8005dc7010 fffffa80066a5620

Open List Open Protocol Context _
PACKETDRIVER fffffa8006690af0 fffffa8007c2e010 fffffa8005024000
MSLLDP fffffa8007f73c30 fffffa8007f7c010 fffffa8007f77970
RSPNDR fffffa8007215830 fffffa80079b0010 fffffa80079ad010
NDISUIO fffffa80068ab6d0 fffffa80079b8710 fffffa80068ab010
LLTDIO fffffa80079bb280 fffffa8007966c50 fffffa80079bb660
TCPIP6 fffffa800720a430 fffffa8005dc8690 fffffa80063ff010
TCPIP fffffa80068f2b60 fffffa8005dcb690 fffffa80068f35d0

Let me know if you need any additional details…

Thanks Much…

4

I have also noticed that when I plug my cable my PauseHandler and than RestartHandler gets invoked, how would I avoid that as well…

5

> I have also noticed that when I plug my cable my PauseHandler and than RestartHandler gets invoked, how would I avoid that as well…

Hmm, that doesn’t sound familiar to me. The my only guess is that some driver is calling NdisFRestartFilter when it sees the media get connected.

The cause might become evident from a stacktrace taken at the time of MiniportPause. Or, if you repro that on Windows 8.1, we have really good traces on why drivers are paused/restarted. http://blogs.msdn.com/b/ndis/archive/2011/04/06/diagnostics-with-wpp.aspx

why there are extra frames being sent out when physical cables are connected verus not plugged in…

Let’s see if I understand correctly.

* When running in a VM, you have no actual NIC, but you still fake the media status of connected. You don’t see very much outbound traffic. And of course, there’s no inbound traffic at all.
* When running in a physical host, you do have a NIC. You see more outbound traffic. And there’s “real” inbound traffic from the network?

If that’s all true, the additional outbound traffic is likely caused by the inbound traffic. Protocols replying to messages, etc. Also, I notice one case has PACKETDRIVER installed, while the other doesn’t. I believe that guy will change the RX filter on the NIC - check with !ndiskd.miniport -filterdb to see if promiscuous mode is enabled on one case but not the other.

6

Thanks for the info of tracing down this helps me very much…