Can a miniport driver be configured to only receive packets?

Jason_Summerour · December 16, 2009, 10:29am

Hi guys,

So, I’ve been writing this deserialized miniport driver, which uses a direct call interface between itself and my bus driver to communicate. The bus driver handles communication over the PCI bus to a card which receives IP data (via an external ASI feed). The IP data is pushed from the card to the bus driver, and will stream up through the direct call interface, into my mp driver, then up through NDIS, and eventually end up in an app listening on a socket.

Currently, I have the upper edge of the mp driver registered w/ NDIS, the direct call interface set up, and it installs as a mp driver correctly (as a child device of my bus driver).

So, I really have no need for the mp driver to handle sending packets down the stack. I just need the IP data to stream up the stack. Is it possible to disable the send functionality alltogether, by nulling out the SendPacketsHandler in the NDIS_MINIPORT_CHARACTERISTICS? Does NDIS require the ability to send packets to the mp driver? Is there anything else that would be required? This will simplify the mp driver, and require less code.

I currently have it wired up, and I see that MPSend() is called for a packet as the mp driver is initializing…Not sure what NDIS is attempting to send out…Evidently it’s something required to bind the procotol?

Also, I’m able to use the direct call interface to query information from the bus driver, like MAC address, and whatever else I will need (IP address maybe).

This brings me to another question, we have a range of MAC addresses to use with our new hardware, and I’ve been wondering if, for the mp driver, if I can pick one MAC address from our range of addresses, and use the same address on every machine (about 2000 of them). I don’t see why this wouldnt’ work, but maybe you guys could pointout pitfalls in using this idea.

What about the IP address? What’s the best solution for coming up w/ a static IP address, since there won’t be any kind of DHCP’d server that our hardware is talking to, to get an IP address? Can I use something like 192.168.1.100? What would happen if another NIC adapter in the system was assigned that IP address by an actual DHCP server? Would it matter since they would have differing MAC addresses?

By the way (and I’m sure it’s obvious) I’m new to mp drivers, NDIS, and how it works…LoL I have a general idea of the network stack, etc., but I’m not sure what info NDIS needs during the configuration stage fo the mp driver.

Thanks for any tips!

Jason

Chris_Aseltine · December 16, 2009, 10:53am

Jason Summerour wrote:

I currently have it wired up, and I see that MPSend() is called for a
packet as the mp driver is initializing…Not sure what NDIS is attempting
to send out…Evidently it’s something required to bind the procotol?

Could be DHCP, or some NetBIOS host announcements, etc…

This brings me to another question, we have a range of MAC addresses
to use with our new hardware, and I’ve been wondering if, for the mp
driver, if I can pick one MAC address from our range of addresses, and
use the same address on every machine (about 2000 of them).

If none of the drivers will be on the same “subnet” as another, you can probably reuse MAC addresses, yes.

What’s the best solution for coming up w/ a static IP address, since
there won’t be any kind of DHCP’d server that our hardware is talking
to, to get an IP address? Can I use something like 192.168.1.100? What
would happen if another NIC adapter in the system was assigned that IP
address by an actual DHCP server?

You’re free to use any address from the normal range of private addresses. If you got assigned that same address on another adapter, I expect you’d get the usual warning tooltip in your systray…

Jason_Summerour · December 16, 2009, 11:17am

Thanks for the input Chris! That’s very helpful information.

So, I attempted to NULL out the mpChar.SendPacketsHandler in my mp driver to see what happens, and I got an exception. Looking at the stack seemed to answer one of my questions with regards to what NDIS is sending a packet out for…DHCP…(see below).

WARNING: Frame IP not in any known module. Following frames may be wrong.
be779718 f5beb985 fc5755b8 fc26bb38 00000002 0x0
be779740 f50c0528 fc3ab538 fc26bb38 fc26bb00 NDIS!ndisMSendX+0x1d6
be77977c f5beb985 fb322db8 fc26bb38 00000002 psched!MpSend+0x706
be7797a4 f2cd8696 fc25b6c8 fc26bb38 fc54e1b0 NDIS!ndisMSendX+0x1d6
be7797c8 f2cd873a 0054e10e ffffffff fc26bb38 tcpip!ARPSendBCast+0x2a8
be7797f4 f2cd665a fc54e1b0 be779800 00000001 tcpip!ARPTransmit+0x125
be779824 f2ce8c7c fb31d6a8 ffffffff fc26bb38 tcpip!SendIPPacket+0x193

be779858 f2ce3f7e ffffffff fc26bb38 fb379020 tcpip!SendDHCPPacket+0x4b

be779990 f2cdd308 f2d14bb4 fb4753e0 fb379020 tcpip!IPTransmit+0x240e
be779a30 f2cdd0cf fb391b20 fb4753e0 fb4f48c0 tcpip!UDPSend+0x41b
be779a54 f2cdd135 00779a78 fb4f4fa0 fb379060 tcpip!TdiSendDatagram+0xd5
be779a8c f2cd9881 fb4f48c0 fb4f4978 fb4f4fa0 tcpip!UDPSendDatagram+0x4f
be779aa8 e0bbb19f fc1ed030 fb4f48c0 fb38ec80 tcpip!TCPDispatchInternalDeviceControl+0xff
be779ab8 f2c46807 be779ba8 00000008 be779b1c nt!IopfCallDriver+0x31
fc237030 fc2a1030 00000012 f2cd3000 00058480 afd!AfdFastDatagramSend+0x2fd
fc237044 fc2370d8 001a001a e10133f0 e0d49260 0xfc2a1030
fc53d620 fc529378 f2d12970 00000001 00000000 0xfc2370d8
fc613080 fc53d620 f2c9e3d8 00000001 00000000 0xfc529378
fc613084 f2c9e3d8 00000001 00000000 00000000 0xfc53d620
fc613088 00000000 00000000 00000000 f2c83000 netbt!_load_config_used+0x48

So, this would seem to indicate that my mp driver has to have a SendPacketsHandler registered?
I guess my mp driver can interrogate the MpSendPacket() calls to see if they’re DHCP requests, and respond back w/ an IP address? Thoughts on how best to handle this? Is there a way to proactively tell NDIS about the IP address that I wish to use before it asks for one?

Thanks again!

Jason

Here’s my entire debug output of the mp driver coming up…

TS_II_NDIS DriverEntry()
ts_ii_ndis sample is built with NDIS Version 5.1
TS_II_NDIS DriverEntry built on Dec 16 2009 at 10:48:55
Calling NdisMRegisterMiniport
TS_II_NDIS MPInitialize()
NICAllocAdapter()–>
<– NICAllocAdapter
–> NICReadRegParameters()
NdisReadConfiguration for promiscuous key failed
Permanent Address = 02-50-f2-00-01-81
Current Address = 02-50-f2-00-01-81
<– NICReadRegParameters()
–> InitializeAdapter
–> NICInitAdapterWorker FC5755B8
Waiting on the InitEvent…
NICAllocSendResources()–>
<– NICAllocSendResources() 0
–> NICAllocRecvResources
–> NICAllocRecvResources 0
Current Address = 02-50-f2-00-01-81
<– NICInitAdapterWorker 0
<– InitializeAdapter, Status=0
TS_II_NDIS GetPCIBusInterfaceStandard()
TsiiBusEvtDeviceProcessQueryInterfaceRequest()
TS_II_NDIS GetPCIBusInterfaceStandard() complete!
Querying for Tsii bus NIC cfg…
TsiiNdisQueryNicConfiguration()Tsii Nic Config: MAC Addr: 17:34:51:68:85:102
NICAttachAdapter()–> NICAttachAdapter
<– NICAttachAdapter
<— MPInitialize Status = 0x00000000
OID_GEN_VENDOR_DRIVER_VERSION
OID_GEN_MAXIMUM_LOOKAHEAD
OID_GEN_MAC_OPTIONS
OID_802_3_MAXIMUM_LIST_SIZE
OID_802_3_CURRENT_ADDRESS
OID_GEN_PHYSICAL_MEDIUM
OID_PNP_CAPABILITIES
OID_GEN_SUPPORTED_LIST
OID_GEN_SUPPORTED_LIST
OID_GEN_SUPPORTED_GUIDS
MPPnPEventNotify: NdisDevicePnPEventPowerProfileChanged
The host system is running on AC power
OID_GEN_MAXIMUM_FRAME_SIZE
OID_GEN_MAXIMUM_TOTAL_SIZE
OID_GEN_MAC_OPTIONS
OID_802_3_CURRENT_ADDRESS
OID_GEN_PHYSICAL_MEDIUM
OID_PNP_CAPABILITIES
OID_GEN_LINK_SPEED
OID_GEN_SUPPORTED_LIST
OID_GEN_SUPPORTED_LIST
OID_GEN_SUPPORTED_LIST
OID_GEN_SUPPORTED_LIST
OID_GEN_LINK_SPEED
OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_RCV_OK
OID_GEN_RCV_ERROR
OID_802_3_CURRENT_ADDRESS
OID_GEN_MAXIMUM_FRAME_SIZE
OID_GEN_LINK_SPEED
OID_GEN_MAC_OPTIONS
OID_GEN_MEDIA_CAPABILITIES
<** UNKNOWN OID **>
<** UNKNOWN OID **>
OID_PNP_CAPABILITIES
OID_GEN_LINK_SPEED
MPSetInformation–> OID_GEN_TRANSPORT_HEADER_OFFSET
MPSetInformation–> OID_GEN_CURRENT_LOOKAHEAD
MPSetInformation–> OID_GEN_CURRENT_PACKET_FILTER
–> NICSetPacketFilter
<– NICSetPacketFilter
OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_SUPPORTED_LIST
OID_GEN_SUPPORTED_LIST
OID_GEN_LINK_SPEED
OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_RCV_OK
OID_GEN_RCV_ERROR
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_RCV_OK
OID_GEN_RCV_ERROR
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
OID_GEN_LINK_SPEED
Access violation - code c0000005 (!!! second chance !!!)
<>

David_R_Cattley · December 16, 2009, 1:36pm

Yes, you need a send handler. It can be trivial and in your case, probably
ought to be.

The MAC address can be nearly anything reasonable - a locally administered
address with the ability to override in the registry is probably a good
idea.

Windows is probably sending you DHCP and ARP messages in an attempt to
acquire an IP address. I presume your “system” must know the IP address
somehow and you can just write that into the registry at the appropriate
place prior to enumerating the adapter so that TCPIP.SYS will treat it as
statically addressed. Alternatively, you can jump through all the hoops to
spoof DHCP.

None the less, somehow you need to get Windows to understand that it should
treat packets sent to an IP address (the destination IP address in your
packets) as being sent to the local host.

Have you looked at whether or not the Broadcast Driver Architecture might
afford you another avenue for introducing IP packets received via your ASI
feed (is this EPG data?) In other words, are you sure that creating a
virtual Ethernet adapter is actually the best (or only) way to get your
half-duplex IP data stream into the system?

Good Luck,
Dave Cattley

Chris_Aseltine · December 16, 2009, 1:39pm

Jason Summerour wrote:

I guess my mp driver can interrogate the MpSendPacket() calls
to see if they’re DHCP requests, and respond back w/ an IP address?
Thoughts on how best to handle this?

Well, yes, you can embed a DHCP server inside your driver. The initial DHCP sequence is four steps though, not two (fortunately, the two responses that you have to give, OFFER and ACKNOWLEDGEMENT, are very similar). You’ll need to read the RFC on DHCP, and then get some code to craft UDP packets from scratch (and properly checksum them too…)

Is there a way to proactively tell NDIS about the IP address that I
wish to use before it asks for one?

You can use “netsh” to set a static IP for your driver once it’s installed. I think you’ll get some 802.3 address OID with the IP in it.

Chris_Aseltine · December 16, 2009, 1:39pm

fdfsfadsf

Pavel_A1 · December 16, 2009, 1:51pm

No, the send handler can not be NULL!
What do you reply to OID_GEN_MEDIA_CONNECT_STATUS?
Don’t indicate connected status unless it actually is.

–pa

wrote in message news:xxxxx@ntdev…
> Thanks for the input Chris! That’s very helpful information.
>
> So, I attempted to NULL out the mpChar.SendPacketsHandler in my mp driver
> to see what happens, and I got an exception. Looking at the stack seemed
> to answer one of my questions with regards to what NDIS is sending a
> packet out for…DHCP…(see below).
>
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> be779718 f5beb985 fc5755b8 fc26bb38 00000002 0x0
> be779740 f50c0528 fc3ab538 fc26bb38 fc26bb00 NDIS!ndisMSendX+0x1d6
> be77977c f5beb985 fb322db8 fc26bb38 00000002 psched!MpSend+0x706
> be7797a4 f2cd8696 fc25b6c8 fc26bb38 fc54e1b0 NDIS!ndisMSendX+0x1d6
> be7797c8 f2cd873a 0054e10e ffffffff fc26bb38 tcpip!ARPSendBCast+0x2a8
> be7797f4 f2cd665a fc54e1b0 be779800 00000001 tcpip!ARPTransmit+0x125
> be779824 f2ce8c7c fb31d6a8 ffffffff fc26bb38 tcpip!SendIPPacket+0x193
>
> be779858 f2ce3f7e ffffffff fc26bb38 fb379020 tcpip!SendDHCPPacket+0x4b
>
> be779990 f2cdd308 f2d14bb4 fb4753e0 fb379020 tcpip!IPTransmit+0x240e
> be779a30 f2cdd0cf fb391b20 fb4753e0 fb4f48c0 tcpip!UDPSend+0x41b
> be779a54 f2cdd135 00779a78 fb4f4fa0 fb379060 tcpip!TdiSendDatagram+0xd5
> be779a8c f2cd9881 fb4f48c0 fb4f4978 fb4f4fa0 tcpip!UDPSendDatagram+0x4f
> be779aa8 e0bbb19f fc1ed030 fb4f48c0 fb38ec80
> tcpip!TCPDispatchInternalDeviceControl+0xff
> be779ab8 f2c46807 be779ba8 00000008 be779b1c nt!IopfCallDriver+0x31
> fc237030 fc2a1030 00000012 f2cd3000 00058480 afd!AfdFastDatagramSend+0x2fd
> fc237044 fc2370d8 001a001a e10133f0 e0d49260 0xfc2a1030
> fc53d620 fc529378 f2d12970 00000001 00000000 0xfc2370d8
> fc613080 fc53d620 f2c9e3d8 00000001 00000000 0xfc529378
> fc613084 f2c9e3d8 00000001 00000000 00000000 0xfc53d620
> fc613088 00000000 00000000 00000000 f2c83000 netbt!_load_config_used+0x48
>
> So, this would seem to indicate that my mp driver has to have a
> SendPacketsHandler registered?
> I guess my mp driver can interrogate the MpSendPacket() calls to see if
> they’re DHCP requests, and respond back w/ an IP address? Thoughts on how
> best to handle this? Is there a way to proactively tell NDIS about the IP
> address that I wish to use before it asks for one?
>
> Thanks again!
>
> Jason
>
> Here’s my entire debug output of the mp driver coming up…
>
> TS_II_NDIS DriverEntry()
> ts_ii_ndis sample is built with NDIS Version 5.1
> TS_II_NDIS DriverEntry built on Dec 16 2009 at 10:48:55
> Calling NdisMRegisterMiniport
> TS_II_NDIS MPInitialize()
> NICAllocAdapter()–>
> <– NICAllocAdapter
> –> NICReadRegParameters()
> NdisReadConfiguration for promiscuous key failed
> Permanent Address = 02-50-f2-00-01-81
> Current Address = 02-50-f2-00-01-81
> <– NICReadRegParameters()
> –> InitializeAdapter
> –> NICInitAdapterWorker FC5755B8
> Waiting on the InitEvent…
> NICAllocSendResources()–>
> <– NICAllocSendResources() 0
> –> NICAllocRecvResources
> –> NICAllocRecvResources 0
> Current Address = 02-50-f2-00-01-81
> <– NICInitAdapterWorker 0
> <– InitializeAdapter, Status=0
> TS_II_NDIS GetPCIBusInterfaceStandard()
> TsiiBusEvtDeviceProcessQueryInterfaceRequest()
> TS_II_NDIS GetPCIBusInterfaceStandard() complete!
> Querying for Tsii bus NIC cfg…
> TsiiNdisQueryNicConfiguration()Tsii Nic Config: MAC Addr:
> 17:34:51:68:85:102
> NICAttachAdapter()–> NICAttachAdapter
> <– NICAttachAdapter
> <— MPInitialize Status = 0x00000000
> OID_GEN_VENDOR_DRIVER_VERSION
> OID_GEN_MAXIMUM_LOOKAHEAD
> OID_GEN_MAC_OPTIONS
> OID_802_3_MAXIMUM_LIST_SIZE
> OID_802_3_CURRENT_ADDRESS
> OID_GEN_PHYSICAL_MEDIUM
> OID_PNP_CAPABILITIES
> OID_GEN_SUPPORTED_LIST
> OID_GEN_SUPPORTED_LIST
> OID_GEN_SUPPORTED_GUIDS
> MPPnPEventNotify: NdisDevicePnPEventPowerProfileChanged
> The host system is running on AC power
> OID_GEN_MAXIMUM_FRAME_SIZE
> OID_GEN_MAXIMUM_TOTAL_SIZE
> OID_GEN_MAC_OPTIONS
> OID_802_3_CURRENT_ADDRESS
> OID_GEN_PHYSICAL_MEDIUM
> OID_PNP_CAPABILITIES
> OID_GEN_LINK_SPEED
> OID_GEN_SUPPORTED_LIST
> OID_GEN_SUPPORTED_LIST
> OID_GEN_SUPPORTED_LIST
> OID_GEN_SUPPORTED_LIST
> OID_GEN_LINK_SPEED
> OID_GEN_MEDIA_CONNECT_STATUS
> OID_GEN_RCV_OK
> OID_GEN_RCV_ERROR
> OID_802_3_CURRENT_ADDRESS
> OID_GEN_MAXIMUM_FRAME_SIZE
> OID_GEN_LINK_SPEED
> OID_GEN_MAC_OPTIONS
> OID_GEN_MEDIA_CAPABILITIES
> < UNKNOWN OID >
> < UNKNOWN OID >
> OID_PNP_CAPABILITIES
> OID_GEN_LINK_SPEED
> MPSetInformation–> OID_GEN_TRANSPORT_HEADER_OFFSET
> MPSetInformation–> OID_GEN_CURRENT_LOOKAHEAD
> MPSetInformation–> OID_GEN_CURRENT_PACKET_FILTER
> –> NICSetPacketFilter
> <– NICSetPacketFilter
> OID_GEN_MEDIA_CONNECT_STATUS
> OID_GEN_MEDIA_CONNECT_STATUS
> OID_GEN_MEDIA_CONNECT_STATUS
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_SUPPORTED_LIST
> OID_GEN_SUPPORTED_LIST
> OID_GEN_LINK_SPEED
> OID_GEN_MEDIA_CONNECT_STATUS
> OID_GEN_RCV_OK
> OID_GEN_RCV_ERROR
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_MEDIA_CONNECT_STATUS
> OID_GEN_RCV_OK
> OID_GEN_RCV_ERROR
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> OID_GEN_LINK_SPEED
> Access violation - code c0000005 (!!! second chance !!!)
> <>
>
>
>

Jason_Summerour · December 16, 2009, 2:21pm

David,

Windows is probably sending you DHCP and ARP messages in an attempt to
acquire an IP address. I presume your “system” must know the IP address
somehow and you can just write that into the registry at the appropriate
place prior to enumerating the adapter so that TCPIP.SYS will treat it as
statically addressed. Alternatively, you can jump through all the hoops to
spoof DHCP.

Before, I wasn’t setting the network address using the INF file, but now I am, and one the mp driver is installed, I see it in the properties (just used 192.168.1.200). But I guess NDIS still doesn’t know about it. I’d rather not have to spoof a DCHP server in the driver, but I guess it wouldn’t be that difficult.

None the less, somehow you need to get Windows to understand that it should
treat packets sent to an IP address (the destination IP address in your
packets) as being sent to the local host.

Yeah, how do I do that?

Have you looked at whether or not the Broadcast Driver Architecture might
afford you another avenue for introducing IP packets received via your ASI
feed (is this EPG data?) In other words, are you sure that creating a
virtual Ethernet adapter is actually the best (or only) way to get your
half-duplex IP data stream into the system?

Nope, haven’t looked into that, but I will peruse for information. I’m guessing this won’t be an option at this point, as I have a tight deadline to meet, and the only thing I have left to resolve w/ this driver is making NDIS happy, so I can send up the IP packets from the bus driver.

Chris, thanks for the netsh tip about the 802.3 address OID! I’ll play around with that.

Pavel,

I’m replying with a NdisMediaStateConnected to OID_GEN_MEDIA_CONNECT_STATUS. Since I’m new to mp drivers, I figured I could set this to connected once the MAC address was configured, and my direct call interface was configured and working.

Thanks for everyone’s replies…I’m learning more and more about mp driver configuration…I’d be happy to hear more comments! I can sure use the help at this point. Actually, all of my original questions have been answered…Now I just need to decide the best way to to get an IP address to NDIS, and how to handle each Send request…

Jason_Summerour · December 16, 2009, 4:05pm

David,

Windows is probably sending you DHCP and ARP messages in an attempt to
acquire an IP address. I presume your “system” must know the IP address
somehow and you can just write that into the registry at the appropriate
place prior to enumerating the adapter so that TCPIP.SYS will treat it as
statically addressed. Alternatively, you can jump through all the hoops to
spoof DHCP.

Do you happen to know which registry settings that I’ll have to change to trick TCPIP.sys as treating it as statically addressed? This seems to be the easiest and simplest solution…

Also, is there a finite number of requests that NDIS will ‘send out’. Obviously one is a DHCP message for an IP address, but what about other important requests? For all others, could I just drop them on the ground, and immediately complete the request? If I can somehow statically set the IP address before the adapter is enumerated, and the DHCP request wasn’t sent out, would there be other requests?

Thanks again!

David_R_Cattley · December 16, 2009, 4:38pm

http://support.microsoft.com/kb/314053
http://msdn.microsoft.com/en-us/library/aa921093.aspx

In general
MACHINE\SYSTEM\CurrentControlSet\Service\TCPIP\Parameters\Interfaces<netcfg>InstanceIdGUID-For-your-adapter>.…

The NetCfgInstanceId is a device (software key) registry property of your
NIC that shows up after PnP has installed the Net class driver via the
Network Class Installer.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, December 16, 2009 4:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can a miniport driver be configured to only receive
packets?

David,

>Windows is probably sending you DHCP and ARP messages in an attempt to
>acquire an IP address. I presume your “system” must know the IP address
>somehow and you can just write that into the registry at the appropriate
>place prior to enumerating the adapter so that TCPIP.SYS will treat it as
>statically addressed. Alternatively, you can jump through all the hoops to
>spoof DHCP.

Do you happen to know which registry settings that I’ll have to change to
trick TCPIP.sys as treating it as statically addressed? This seems to be
the easiest and simplest solution…

Also, is there a finite number of requests that NDIS will ‘send out’.
Obviously one is a DHCP message for an IP address, but what about other
important requests? For all others, could I just drop them on the ground,
and immediately complete the request? If I can somehow statically set the
IP address before the adapter is enumerated, and the DHCP request wasn’t
sent out, would there be other requests?

Thanks again!

—
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

Jason_Summerour · December 16, 2009, 5:39pm

Cool, thanks David!

Chris_Aseltine · December 16, 2009, 8:18pm

Jason Summerour wrote:

If I can somehow statically set the IP address before the
adapter is enumerated, and the DHCP request wasn’t sent
out, would there be other requests?

Yes, you’re always going to see a bunch of NetBIOS announcements, UPnP, spyware trying to phone home, etc…

Chris_Aseltine · December 16, 2009, 8:21pm

Jason Summerour wrote:

Do you happen to know which registry settings that I’ll have to
change to trick TCPIP.sys as treating it as statically addressed?
This seems to be the easiest and simplest solution…

Also: don’t hack the registry to set your adapter to static IP addressing. Just use ‘netsh’.

Maxim_S_Shatskih · December 17, 2009, 5:20am

>which receives IP data (via an external ASI feed).

What is ASI?

What you have described is something like DVB/IP over satellite TV. Is it so?

So, I really have no need for the mp driver to handle sending packets down the stack.

Then there is a very major question - who is the owner of the IP address in your architecture?

Most IP protocols cannot work uni-directional, for instance, TCP is such.

So, there must be another network adapter on the same machine which will handle outgoing traffic.

In this case, I would suggest your card to have no IP address at all (now will you assign it without the ability to send?), and the IP address of another adapter (with the ability to send) to be used for all traffic.

This is how DVB/IP worked in early 2000ies IIRC (before being replaced by ADSL).

In such a case, your card is not a network adapter at all, it is kinda a helper for the main network adapter. So, I would write the driver as NDIS IM filtering the main network adapter, and injecting the packets received by your card in the main adapter’s stack as if it was the main adapter who received them.

This brings me to another question, we have a range of MAC addresses to use with our new
hardware,

The hardware cannot send. So, it cannot run ARP. So, MAC addresses are not needed.

I really have major doubts about how this hardware can be used, except as a helper to another full featured network adapter.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · December 17, 2009, 5:20am

> Also, is there a finite number of requests that NDIS will ‘send out’. Obviously one is a DHCP

message for an IP address, but what about other important requests?

Your adapter cannot send. This means - no DHCP and no ARP. So, the IP address of this adapter should be assigned by some external means - some app of your product.

Why not just use the IP Helper API and set the address from the app?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Jason_Summerour · December 17, 2009, 10:18am

Hi Maxim,

ASI is the feed that’s coming over a TV satellite into our box that contains MPEG and IP data. Our card splits the two out, and sends the IP data up to our bus driver.

The IP data will actually be Multicast UDP, sent out using a 224.x.x.x IP address.

The box actually, already has two NICs that will be used for other external communication.

In such a case, your card is not a network adapter at all, it is kinda a
helper for the main network adapter. So, I would write the driver as NDIS IM
filtering the main network adapter, and injecting the packets received by your
card in the main adapter’s stack as if it was the main adapter who received
them.

Hmm…That’s an interesting idea…Didn’t think about doing that. That might actually work better.

Late last night, I changed the MPSendPackets() handler to immediately complete all requests, and I also set the IP address of the adapter to be a static one (just chose 192.168.1.200). I no longer see any DHCP requests coming down (since it’s static), and the adapter *appears* to be happy. I’m going to write a quick app to connect to it, and attempt to read UDP packets from it today. One thing that I do see is that every second, I see the following OIDs come across:

OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_RCV_OK
OID_GEN_RCV_ERROR
OID_GEN_LINK_SPEED
LinkSpeed: 100000
OID_GEN_LINK_SPEED
LinkSpeed: 100000
OID_GEN_LINK_SPEED
LinkSpeed: 100000

Does NDIS always query these OIDs so frequently? Why does it query OID_GEN_LINK_SPEED 3 subsequent times?

I will put heavy thought into making it an NDIS IM driver though…Anyone have any reason why this wouldn’t work for what I’m looking to do?

Also, I’m not familiar w/ the IP Helper API, but I’ll look into that.

Thanks guys!

Jason_Summerour · December 17, 2009, 10:47am

Actually, one reason to keep it as a separate mp driver is that we know that we’ll only be getting our IP data coming across the adpater, and won’t have to worry about other traffic, which we would receive if we were go with an IM driver.

David_R_Cattley · December 17, 2009, 11:06am

So what does your card do with the MPEG data? Did you create a KS driver
for the MPEG? The infrastructure built to support digital broadcast tuners
already contains the facilities to take an IP packet multicast stream of
(ostensibly for EPG data but it surely does not matter what the multicast
data is) and feed it into the networking subsystem in an ‘appropriate’ way
(appropriate meaning it works on each supported platform and you do not need
to worry about the details like what is the IP address, etc.)

I recall somewhere that broadcast unidirectional (receive only) adapters
often use a ‘made-up’ IP address from a reserved range of some sort. I wish
I could find that. Maybe one of our Kernel Streaming / Multimedia / Tuner
contributors would know (Ok, TimR, this is where you jump in!)

And yes, the system queries those statistics quite often and yes, it might
ask you the link speed three or three hundred times in a row. Nothing is
‘caching’ the result but plenty of things might want to know the value,
instantaneously, and repeatedly. So don’t make it expensive with lots of
logging - just log when it changes not when it is read.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, December 17, 2009 10:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can a miniport driver be configured to only receive
packets?

Hi Maxim,

ASI is the feed that’s coming over a TV satellite into our box that contains
MPEG and IP data. Our card splits the two out, and sends the IP data up to
our bus driver.

The IP data will actually be Multicast UDP, sent out using a 224.x.x.x IP
address.

The box actually, already has two NICs that will be used for other external
communication.

In such a case, your card is not a network adapter at all, it is kinda a
helper for the main network adapter. So, I would write the driver as NDIS
IM
filtering the main network adapter, and injecting the packets received by
your
card in the main adapter’s stack as if it was the main adapter who received

them.

Hmm…That’s an interesting idea…Didn’t think about doing that. That
might actually work better.

Late last night, I changed the MPSendPackets() handler to immediately
complete all requests, and I also set the IP address of the adapter to be a
static one (just chose 192.168.1.200). I no longer see any DHCP requests
coming down (since it’s static), and the adapter *appears* to be happy. I’m
going to write a quick app to connect to it, and attempt to read UDP packets
from it today. One thing that I do see is that every second, I see the
following OIDs come across:

OID_GEN_MEDIA_CONNECT_STATUS
OID_GEN_RCV_OK
OID_GEN_RCV_ERROR
OID_GEN_LINK_SPEED
LinkSpeed: 100000
OID_GEN_LINK_SPEED
LinkSpeed: 100000
OID_GEN_LINK_SPEED
LinkSpeed: 100000

Does NDIS always query these OIDs so frequently? Why does it query
OID_GEN_LINK_SPEED 3 subsequent times?

I will put heavy thought into making it an NDIS IM driver though…Anyone
have any reason why this wouldn’t work for what I’m looking to do?

Also, I’m not familiar w/ the IP Helper API, but I’ll look into that.

Thanks guys!

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

Jason_Summerour · December 17, 2009, 11:24am

David,

Okay, that’s nice to know those queries for link speed are normal.

This is a custom PCI-X card that we have developed, which takes the MPEG data, and allows us to overlay video (from a Windows app) on top of it. That’s where my bus driver comes in…It provides an interface to allow a rendering app in Windows to overlay video and audio data over the top of the incoming MPEG from the satellite stream.

Yeah, the IP address that I’m using is totally made up.

Thanks Dave!

Hey Chris A…netsh works nicely!

<note: this is saved in a .cmd file>
netsh interface ip set address name=“TSII” static 192.168.1.200 255.255.255.0 gateway=192.168.1.1 1

Ethernet adapter TSII:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TWC TS_II_NDIS Driver #2
Physical Address. . . . . . . . . : 11-22-33-44-55-66
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.1.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1</note:>

David_R_Cattley · December 17, 2009, 11:34am

Jason,

ChrisA’s advice about avoiding the registry is good advice

I had assumed that the IP address is known to your system and might change.
Since this really is like DB/EPG data with an entirely made-up address, you
need only provision that once at device install time and it can stay that
way forever.

To that end, you can handle that with a device co-installer for your virtual
miniport driver which would be responsible for ‘synthesizing’ the
appropriate (phantom) IP address and provisioning the TCP/IP interface with
the address.

The other thing you can think about is just letting IP AutoConfig do its
thing and assign it a 169.254.xxx.xxx address. You don’t care what the
address is …

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, December 17, 2009 11:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can a miniport driver be configured to only receive
packets?

David,

Okay, that’s nice to know those queries for link speed are normal.

This is a custom PCI-X card that we have developed, which takes the MPEG
data, and allows us to overlay video (from a Windows app) on top of it.
That’s where my bus driver comes in…It provides an interface to allow a
rendering app in Windows to overlay video and audio data over the top of the
incoming MPEG from the satellite stream.

Yeah, the IP address that I’m using is totally made up.

Thanks Dave!

Hey Chris A…netsh works nicely!

<note: this is saved in a .cmd file>
netsh interface ip set address name=“TSII” static 192.168.1.200
255.255.255.0 gateway=192.168.1.1 1

Ethernet adapter TSII:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TWC TS_II_NDIS Driver #2
Physical Address. . . . . . . . . : 11-22-33-44-55-66
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.1.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

—
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</note:>