My miniport driver is working properly with send/receive. However, it does not have an ip address.
Is there anyway to have it get an ip address automatically?
What bytes should be reported on the network settings screen in windows? The number of directed packets?
You need to have a functioning DHCP server on the network if you don’t want
to assign static IP. Of course, you need to have TCPIP bound to your
miniport. If you are still not getting IP address, you need to hookup a
shark trace to debug the DHCP protocol.
Directed packet means packet directed to your MAC address. You don’t count
MC or BC packets.
On Mon, Jul 2, 2012 at 1:53 PM, wrote:
> My miniport driver is working properly with send/receive. However, it does
> not have an ip address.
>
> 1. Is there anyway to have it get an ip address automatically?
>
> 2. What bytes should be reported on the network settings screen in
> windows? The number of directed packets?
>
> —
> 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
>
My driver is successfully sending and receiving data. However, I’m having a hard time testing directed packet transmission and reception. When I connect my test hardware directly to the Intel Ethernet jack on my machine, set them up with static IP address, and use ping, I can see the packets being sent and received. However, the packets are broadcast packets, and not directed packets (at least this is what ETH_IS_BROADCAST tells me in my code).
What is a good way to test for directed packets?
Should I be seeing ‘Destination host unreachable’ as the response on ping?
My test hardware doesn’t set an automatic IP address even though our network assigns IPs dynamically…what could be the problem? Does it have something to do with a missing OID?
Thanks for your help.
On 09-Jul-2012 21:57, xxxxx@gmail.com wrote:
My driver is successfully sending and receiving data. However, I’m having a hard time testing directed packet transmission and reception. When I connect my test hardware directly to the Intel Ethernet jack on my machine, set them up with static IP address, and use ping, I can see the packets being sent and received. However, the packets are broadcast packets, and not directed packets (at least this is what ETH_IS_BROADCAST tells me in my code).
- What is a good way to test for directed packets?
NdisTest (part of the test kit)
- Should I be seeing ‘Destination host unreachable’ as the response on ping?
No. Tcpip believes that it has path to the destination.
- My test hardware doesn’t set an automatic IP address even though our network assigns IPs dynamically…what could be the problem? Does it have something to do with a missing OID?
What means “automatic IP” - APIPA or DHCP?
– pa
@Pavel It assigns IP address using DHCP I think.
In my trace, I am getting a DHCP discover, but not a DHCP offer…what could be the problem?
Is that capture done on the system sending the Discover or on the DHCP server (or a monitor port on the switch)? The first thing to establish is that the discover actually was observed by a (the) DHCP server from which you expect the offer to come from. Good Luck,Dave Cattley
I will check that out @David. Thanks. Also, I am not updating the link state right now. It is currently always set as connected (still determining how to query link state from the hardware). Would this effect it in any way?
> It is currently always set as connected
That is unlikely to prevent packet flow so I would not immediately expect
this to be related.
However, the incredibly helpful !ndiskd.miniport extension run in Windbg and
pointed at your miniport will tell you for certain if NDIS thinks your
‘connected’ state is actually sufficient to have the wrapper pass your
receive traffic to bound protocols. I suggest you have a go with that.
Good Luck,
Dave Cattley
I installed wireshark on two machines and did the following:
Ping from the test machine (test hardware) to my test server (Intel NIC), and saw the broadcast ARP being sent out. However, on the test server, the packets are never received…
Any thoughts?
On 12-Jul-2012 00:57, xxxxx@gmail.com wrote:
I installed wireshark on two machines and did the following:
Ping from the test machine (test hardware) to my test server (Intel NIC), and saw the broadcast ARP being sent out. However, on the test server, the packets are never received…
Any thoughts?
And what do you think? It is something in your driver. The Intel’s NIC
probably is good.
By the way, use a real hub to connect the machines, not a cross-cable.
– pa
When I ping from my server (INTEL NIC) to my test client (test hardware), I am able to receive a ping, and an ACK is transmitted out (I can see this in wireshark), however, a direct packet is never received on the server side. Same thing if I send out (ping) a packet from my test client to my server. I can see the transmit show up in wireshark on my test client, but no packet received on my server side. Is it safe to assume that this is a hardware problem, and the packets aren’t actually being sent by the hardware???
I think you can only safely assume that the driver/hardware combination is
failing to send packets.
You can argue that out with the HW folks. This is your NIC hardware right?
I don’t know how folks on the list could tell you it is a HW failure.
Good Luck,
Dave Cattley
@David I only ask this because the packets are being reported in Wireshark. I’m meeting with the hardware guys to check this problem out soon.
However, I think I really want to know whether packets reported in wireshark are packets reported to NDIS by the miniport driver???
Wireshark (via WinPCAP) shows packets presented to its protocol/adapter
binding by NDIS.
Wireshark commands WinPCAP to place that binding into promiscious mode by
default or at least to set the packet filter to enable all local packets
(that is, sent & received).
However, a ‘sent’ packet in Wireshark (or NetMon3) is only evidence that the
packet made it as far as the NDIS miniport ‘wrapper’ around your miniport
code. The logic to take a send and loop it back as a receive into a
binding with the packet filter set to promiscious (or local) is all NDIS
code. Your Miniport could be hopelessly broken in the TX path and yet NDIS
would make someone reading the capture think “hey, the packet got sent”.
That is, if your capture is being taken on the machine doing the sending.
Which I assume you are doing. Because if you saw this packet in a capture
taken from an independent machine then you would not be having a chat with
the HW guys.
So sorry, your capture in hand is not terribly strong evidence that the
driver is doing anything other than loading, returning from Miniport
Initialize, and responding to a few boilerplate OIDs. It does not say much
about your TX path.
But don’t show them this note. Go in gun’s a blazing. Of course it?s the
hardware 
Good Luck,
Dave Cattley
Thanks Dave. On the receive side, if I am seeing the packets in wireshark, it’s safe to assume those packets are being processed, since my driver is the one passing the data to NDIS correct?
I’m also assuming that one of the higher level drivers is the one that instructs my driver to transmit an ACK packet?
Thanks.
Absolutely. There is no way that packet can get into the system unless it
goes through your driver.
Yes again.
By ACK I think you mean ‘response’ in so far as I think you said you were
using ICMP (Ping). The ‘response’ would be an ICMP Echo Reply. Since the
system is not actually getting TX traffic ‘to the wire’ TCP (for example)
would not get to ‘ACK’ packets (only as far as SYN-ACK in the handshake at
best).
Good Luck,
Dave Cattley
Thanks Dave! This is my first NDIS driver, and it’s been a while since I utilized my networking knowledge.
Nice to know I’m halfway there…
For some reason my transmits started working (i have no idea). Anyway, whenever I ping with packets 1000 bytes or >, I get a request timeout. Any suggestions?
Also, I’m still not able to get an IP address from DHCP. I see the request being sent out…but no response. However, pings work, and so I’ve assumed that transmit is working correctly now.