NdisMedium802_3 vs NdisMediumWan

NTDEV
1

Hello all,

I’m new to NDIS, but I’ve written custom PCI drivers before. I’ve taken the netvmini\5x example driver in the WDK and hacked off the packet duplication bit and stitched on a serial port in its place. My target platform is XP. Yes, I’ve tried the built in PPP adapter and to my dismay it seems to lock up when errors occur on the serial line (*sigh*). I’ve got my modified driver working fairly well. I can ping and make TCP connections across my serial cable. I have a piece of test gear that allows me to add bit errors and delay on the serial line. Things where working great until I put 2 seconds of delay on each direction (4s roundtrip). Wireshark shows lots of ARP requests/responses and not much else. I’m figuring whatever part of the OS is handling ARP has a 4 second timeout. When the OS can’t figure out the MAC address of the default route, not much else happens. I ran the “arp -a” command and saw nothing in the list despite the ARP responses that where coming in correctly. So I looked for ARP tuning registry entries to not find anything about a response timeout. I know I can add a static ARP entry, but I would like a better solution. It occurred to me that I might want to change the medium type to something more fitting to a serial port. I looked down the medium enumeration to see NdisMediumWan. It’s seems to indicate a point-to-point adapter type (which fits a serial port pretty well I think). Being a NDIS newbie, I have no idea what that will do. Will I still get an Ethernet header on packets sent down to me? Seems like the OID list should change. If there is no Ethernet header, it would seem like the filtering flags might change? Is changing the medium type to NdisMediumWan even the right way to go? There isn’t much out there about NdisMediumWan based drivers and I found no examples in the WDK. Any advice is greatly appreciated!

Thanks,
-Daniel

2

A few things:

  1. Tell us what it is you are trying to accomplish at a high level.

  2. Tell us again why Windows SLIP/PPP (RAS) does not work for you (and in
    some detail since RAS *does* deal with link errors)

  3. For point-to-point links ARP rarely makes any sense and is typically
    spoofed by the driver, not encapsulated and sent to be processed by the
    peer. That is why PPP does not carry (encapsulate) ARP.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@ngc.com
Sent: Monday, November 29, 2010 9:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NdisMedium802_3 vs NdisMediumWan

Hello all,

I’m new to NDIS, but I’ve written custom PCI drivers before. I’ve taken the
netvmini\5x example driver in the WDK and hacked off the packet duplication
bit and stitched on a serial port in its place. My target platform is XP.
Yes, I’ve tried the built in PPP adapter and to my dismay it seems to lock
up when errors occur on the serial line (*sigh*). I’ve got my modified
driver working fairly well. I can ping and make TCP connections across my
serial cable. I have a piece of test gear that allows me to add bit errors
and delay on the serial line. Things where working great until I put 2
seconds of delay on each direction (4s roundtrip). Wireshark shows lots of
ARP requests/responses and not much else. I’m figuring whatever part of the
OS is handling ARP has a 4 second timeout. When the OS can’t figure out the
MAC address of the default route, not much else happens. I ran the “arp -a”
command and saw nothing in the list despite the ARP responses that where
coming in correctly. So I looked for ARP tuning registry entries to not find
anything about a response timeout. I know I can add a static ARP entry, but
I would like a better solution. It occurred to me that I might want to
change the medium type to something more fitting to a serial port. I looked
down the medium enumeration to see NdisMediumWan. It’s seems to indicate a
point-to-point adapter type (which fits a serial port pretty well I think).
Being a NDIS newbie, I have no idea what that will do. Will I still get an
Ethernet header on packets sent down to me? Seems like the OID list should
change. If there is no Ethernet header, it would seem like the filtering
flags might change? Is changing the medium type to NdisMediumWan even the
right way to go? There isn’t much out there about NdisMediumWan based
drivers and I found no examples in the WDK. Any advice is greatly
appreciated!

Thanks,
-Daniel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

  1. I have a 2 PCs running Windows XP connected with a null-modem cable (no modems, just a cable). I have a piece of hardware connected to 1 PC via Ethernet and a control application running on the other PC. I need the application to be able to connect to the piece of hardware via sockets. The goal beyond that would be to move the application to a PC further away on an IP based network.

  2. My first thought was to setup a PPP connection. Using the ?New Connection? wizard I added a direct connection PPP server on one end, and the client setup on the other. That worked fine until I put my data link simulator in the serial link and added bit errors. The PPP connection would run ok for a while and then it would stop working. I?d have to drop the connection and reestablish it. Again, it would work for a while and then just lock up. So I brought up the status window for the connection to watch the error count. I excepted to see it go up occasionally as the simulator would add bit errors. When the error counter hit 1, it stopped working. I did that a few times and I could easily repeat the problem. I figured PPP wasn?t recovering from the errors reliably. So, I poked around the WDK NDIS folder thinking maybe I could write my own PPP like driver.

  3. I agree. In fact, Ethernet doesn?t make sense for a point-to-point link either. I just don?t know enough about NDIS to make an intelligent decision on what medium type is best. I also don?t know what behavioral changes happen in NDIS when the medium type changes. That?s what I?m trying to figure out. The ARP spoofing thing is a good idea. I could build a small ARP table of my own in the driver. I was hoping for a solution where I could eliminate the Ethernet layer all together.

Thanks,
-Daniel

4

> I was hoping for a solution where I could eliminate the Ethernet layer
all together.

Can you instead eliminate the serial layer?
Replace the serial cable with a ethernet cross cable (and couple of cheap USB to ethernet dongles) ?

– pa

5

I wish I could eliminate the serial layer! I have limited options when it comes to changing the hardware. I am stuck with the serial link. I’m currently trying to see if I can replace the PCs with routers. But, for the time being, I?m having fun working on this driver and I?d like to learn more about NDIS.

Thanks
-Daniel

6

The story about how error simulation breaks PPP is interesting. Maybe someone could give insight here.
If you chose the NDIS direction: you need a driver that works with a serial port and also is a NDIS protocol that binds to the 2nd ethernet interface on which the “test gear” is connected.
This way you’ll have full control over the connection (is it something/IP or raw ethernet?).
Or, the other end of your serial driver can be virtual ethernet miniport, plus some other software to bridge it with the other ethernet interface. Examples for both miniport and protocol variants are in WDK.

Good luck.
– pa

7

I took the netvmini WDK example and added a framer and serial port I/O to it already. When NDIS hands me a packet, I frame it up (start of frame, frame size, CRC), and queue an IRP to the serial port. I always keep a pending read IRP on the serial port, and when I get a completed frame, I indicate it up the stack. I turned on IP routing in the registry and I can ping, make TCP connections and everything.

The problem I?m facing now is ARP. Because windows thinks my driver is Ethernet, it wants to resolve the MAC address of the destination route. When there is too much latency on the link, the ARP request times out and no traffic flows to my driver (other than more ARP requests). I?m using the medium type NdisMedium802_3 because that is what the example used. I?m wondering if NdisMediumWan would be more appropriate. Since it?s a point-to-point link, no ARP really needs to happen. No Ethernet addressing needs to happen either. If NdisMediumWan is the better way to go, how does that change the packet format I will see from the protocol drivers? What other behavioral changes will occur?

Thanks,
-Daniel

8

If I understand you correctly then PPP link between the PCs is acting as your WAN connection. The PCs are acting in part as routers. That’s fine.

Why did you introduce link errors on the PPP link? If your intention is to simulat a ‘real world’ link condition I assume your real world involves modems and not a long piece of wire. Bit errors between a modem and a PC are pretty infrequent and bit errors between two error correcting modems are, well, non-existent (due to error correction! yeah MNP).

So if this has just devolved into a science experiment, then, fine. I have no expanation for why RAS (NDISWAN/ASYNCMAC) is getting confused by whatever sort of error you are injecting. BTW, you might be confusing the UART. Who knows.

I recall dial-up internet being pretty reliable save for the occasional extension phone being picked up and blowing the modem EQ to hell causing it to hang up. I would go back to plan A.

As for ARP spoofing - the point is that a P2P link (like PPP, SLIP, or your own concoction whatever it might be) does not need MAC level address resolution. The MAC address plays no part in delivering frames. Typically such a ‘virtual’ adapter spoofs all ARP requests regardless of the requested IP address. The only tricky one being that it cannot answer an ARP for ‘self’. After doing so, Windows will deliver Ethernet encapsulated IP packets to your miniport and you can dutifully strip the Ethernet header and send the IP packet directly. In otherwords, behave like SLIP.

Since you are running with Windows XP you don’t get the cool new WWAN framing modes of Windows 7 that will give you IP packets directly without the ARP nonsense.

And in regards to ‘changing’ the medium - stick with Ethernet. TCPIP.SYS will bind to your adapter with an ARP media interface and expect it to behave like an Ethernet. Getting TCPIP.SYS to bind with another low level interface is undocumented (impossible?).

Good Luck,
Dave Cattley

9

I have no idea how the serial data will be transported, modem or otherwise. What I know is I?ll get a 4800 baud 8-n-1 async serial port on both ends and I must be able to withstand a bit error rate of 1e-5 with 10 seconds of latency. It?s not ideal, but if it was, what would you need engineers for?? :slight_smile:

And in regards to ‘changing’ the medium - stick with Ethernet. TCPIP.SYS will bind to your adapter with an ARP media interface and expect it to behave like an Ethernet. Getting TCPIP.SYS to bind with another low level interface is undocumented (impossible?).

Thanks, that?s the info I was looking for! Time to spoof some ARP?.

Thanks,
-Daniel

10

W.r.t. changing the media type - you’d need to make several changes to convert an 802.3 miniport to WAN (see the instructions here: http://msdn.microsoft.com/en-us/library/ff546794.aspx ). However, WAN is considered deprecated, and the cool new^H^H^Hless old thing is CoWAN (see a comparison here: http://msdn.microsoft.com/en-us/library/ff544228.aspx ). Although CoWAN is less klunky than legacy WAN, it is even more dramatically different from netvmini, so you would find the conversion non-trivial. (If you really do need to go that route, you might try to dig up the old coisdn sample driver. It was yanked from the kit because it has design issues, however, so you want to be cautious about copying its design wholesale.) In any case, you’d wind up spending a lot of time toying with the NDIS layer, when it sounds like you’re already pretty close with the current fake-802.3 solution.

I’m having fun working on this driver and I’d like to learn more about NDIS.

Yay :slight_smile:

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dave Cattley
Sent: Tuesday, November 30, 2010 2:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NdisMedium802_3 vs NdisMediumWan

If I understand you correctly then PPP link between the PCs is acting as your WAN connection. The PCs are acting in part as routers. That’s fine.

Why did you introduce link errors on the PPP link? If your intention is to simulat a ‘real world’ link condition I assume your real world involves modems and not a long piece of wire. Bit errors between a modem and a PC are pretty infrequent and bit errors between two error correcting modems are, well, non-existent (due to error correction! yeah MNP).

So if this has just devolved into a science experiment, then, fine. I have no expanation for why RAS (NDISWAN/ASYNCMAC) is getting confused by whatever sort of error you are injecting. BTW, you might be confusing the UART. Who knows.

I recall dial-up internet being pretty reliable save for the occasional extension phone being picked up and blowing the modem EQ to hell causing it to hang up. I would go back to plan A.

As for ARP spoofing - the point is that a P2P link (like PPP, SLIP, or your own concoction whatever it might be) does not need MAC level address resolution. The MAC address plays no part in delivering frames. Typically such a ‘virtual’ adapter spoofs all ARP requests regardless of the requested IP address. The only tricky one being that it cannot answer an ARP for ‘self’. After doing so, Windows will deliver Ethernet encapsulated IP packets to your miniport and you can dutifully strip the Ethernet header and send the IP packet directly. In otherwords, behave like SLIP.

Since you are running with Windows XP you don’t get the cool new WWAN framing modes of Windows 7 that will give you IP packets directly without the ARP nonsense.

And in regards to ‘changing’ the medium - stick with Ethernet. TCPIP.SYS will bind to your adapter with an ARP media interface and expect it to behave like an Ethernet. Getting TCPIP.SYS to bind with another low level interface is undocumented (impossible?).

Good Luck,
Dave Cattley

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

WOOHOO! I?ve got lots of reading to do. Thanks for all the info! Oooooh, look at PASS_THROUGH_MODE in the FramingBits field of NDIS_WAN_INFO. Is it wrong to get giddy about this stuff??

Thanks,
-Daniel