TCP Data Not captured by NDIS Driver

Question

I am new to NDIS Driver Development. I am trying to clear my concept regarding NDIS by extending sample MUX Driver (WDK Sample).

I want to capture all the incoming and outgoing data from an interface. Then try some modification on the Packet and send them back again.

 

So far I was successful in capturing ARP, UDP & ICMP data. But failed to capture any TCP data. I was also able to pull up the data from driver to Win32 application using DeviceIOControl. The most frustrating part is when I run a web browser I get UDP packets (DNS lookup) for that query but cannot get the original TCP data (Web Content).

As I haven't done any modification on the packet itself yet, I am totally clueless regarding the issue.

Is it possible that the MUX driver was built in a way so that it ignores the TCP datas? Is there any other settings/configuration which prevents the TCP data to pass through the driver?

It would help me greatly if anyone suggest me where I might went wrong.

Thank you in advance & sorry for my English.

---

fadedreamz

Answer 1

>Is it possible that the MUX driver was built in a way so that it ignores the TCP datas? Is there any other settings/configuration which prevents the TCP data to pass through >the driver?

No.It likely could not be happened. NDIS drivers operates with Ethernet packet and don't care even with IP header. Theoretically you could ignore TCP packets in MUX driver but you need to do parsing Ethernet frames to find a TCP header. Such stuff usually isn't done in MUX driver. I would suggest to you to make tracing of all receiving packets in your driver and analyze them. 

Igor Sharovar

Answer 2

>Is it possible that the MUX driver was built in a way so that it ignores the TCP datas? Is there any other settings/configuration which prevents the TCP data to pass through >the driver?

No.It likely could not be happened. NDIS drivers operates with Ethernet packet and don't care even with IP header. Theoretically you could ignore TCP packets in MUX driver but you need to do parsing Ethernet frames to find a TCP header. Such stuff usually isn't done in MUX driver. I would suggest to you to make tracing of all receiving packets in your driver and analyze them. 

Igor Sharovar

Thanks Igor Sharovar,

My initial impression was same as you. NDIS Driver works with PACKETS and does not care about TCP/IP upper layer protocol. But I have tried checking all the captured packet from PtReceive & MPSendPackets. Those examined packet never reported having 24th byte of there IP header as 0x06 (TCP). All I got was ARP, ICMP & UDP (0x11), which is very unlikely to happen. I haven't done any filtering based on ethernet frame. I just captured the sending & receiving data, made a copy and then send them to a Win32 application. No routing change has been introduced to the sample MUX Driver.

Any clue what might be wrong?

Thank you again for your response.

---

fadedreamz

Answer 3

Are you sure that you look at the right offset? "Protocol" field in IP header starts with 72-bits or 9 bytes offset from beginning of the header.
You could also run any network analyzer and compare its result with your tracing.

Igor Sharovar

Answer 4

Thank you Igor Sharovar for your reply,

I verified the position using Omnipeek. It shows that 23 byte offset from the beginning, a 9 bytes offset from ip header.

Any other clues?

regards,

---

fadedreamz

Answer 5

From a position of knowing nothing about nothing, in particular NDIS.  Are you testing with other TCP-using applications?  I seem to remember that MSIE does something different with its TCP/IP traffic.

---

http://www.alanjmcf.me.uk/ Please follow-up in the newsgroup. If I help, mark the question answered

Answer 6

Check if a miniport driver in your system supports TCP offload. If TCP offload is supported and enabled your MUX intermediate driver may not get Ethernet frames with TCP data.  

Igor Sharovar

 

Answer 7

From a position of knowing nothing about nothing, in particular NDIS.  Are you testing with other TCP-using applications?  I seem to remember that MSIE does something different with its TCP/IP traffic.

---

http://www.alanjmcf.me.uk/ Please follow-up in the newsgroup. If I help, mark the question answered

Thank you Alan for your suggestion.

I have tested with a SVN Client. Still It was unable to capture the TCP packets.

Any other suggestion?

regrads,

---

fadedreamz

Answer 8

Check if a miniport driver in your system supports TCP offload. If TCP offload is supported and enabled your MUX intermediate driver may not get Ethernet frames with TCP data.  

Igor Sharovar

 

I will check that and then post here.

Thanks Igor for your advice.

---

fadedreamz

Answer 9

Thanks all for their suggestions & advice.

It seems that I if I put the packet reading mechanism on PtReceive of the MUX-IM Driver (WDK Sample), It can capture the incoming TCP Packets. But Still I cannot capture the outgoing TCP Packets.

Any clue?

regards,

 

 

---

fadedreamz

Answer 10

From your description, it appears that you're an NDIS 5 intermediate driver, right?  You can get called to send packets in either your Send or SendPacket entry points.  Are you checking both of them?

 -Brian

 

---

Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information

Answer 11

From your description, it appears that you're an NDIS 5 intermediate driver, right?  You can get called to send packets in either your Send or SendPacket entry points.  Are you checking both of them?

 -Brian

 

---

Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information

Thank you Brian for your suggestion.

Yes it is NDIS MUX-IM Driver. In the Miniport characteristics structure, only the SendPacketHandler callback is registered. The SendHandler is set to NULL. So, It should call the SendPackets (MPSendPackets in my case) for every packet, shouldn't it be? I can get the UDP, ARP, ICMP data from the MPSendPackets but cannot get the outgoing TCP data from MPSendPackets.

Another question, Is there any chance that NDIS calls directly NIC's MPSendPackets bypassing the MUX-IM Driver? If that is the case then, how can I get a copy of the outgoing TCP Packet from NDIS?

Thank you again,

---

fadedreamz

Answer 12

The packet payload will be stored accross multiple ndis buffers.  For outbound packets the first buffer usually contains just the ethernet header, the second contains the ip header, the third contains the tcp header, etc.

Have you assumed that all the payload is in the first buffer?  You must check that the size of the buffer is <= sizeof(someHeader) and if it is you call NdisGetNextBuffer() to get the next one.

Answer 13

The packet payload will be stored accross multiple ndis buffers.  For outbound packets the first buffer usually contains just the ethernet header, the second contains the ip header, the third contains the tcp header, etc.

Have you assumed that all the payload is in the first buffer?  You must check that the size of the buffer is <= sizeof(someHeader) and if it is you call NdisGetNextBuffer() to get the next one.

Those are by no means hard and fast rules.  The format of a packet/buffer is very dependent upon the drivers loaded on either side of the intermediate driver, and which operating system you're running on.

Which operating systems do you have to support?

 -Brian

---

Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information

Answer 14

Brian is right.  There may be an intermediate driver above yours that copies the payload into a single buffer before the packet reaches your driver.  My experience, however, is that in the absence of other intermediates, the outbound packet contains multiple buffers, each one prepared by different components in the stack ... ndis fills the first with the ethernet header, IP fills the second with the IP header, TCP fills the third with the TCP header, etc.  Inbound packets usually contain a single buffer, which the NIC has copied the entire received packet payload into.

I have written my driver to deal with single or multiple buffer packets for inbound and outbound.

Answer 15

The packet payload will be stored accross multiple ndis buffers.  For outbound packets the first buffer usually contains just the ethernet header, the second contains the ip header, the third contains the tcp header, etc.

Have you assumed that all the payload is in the first buffer?  You must check that the size of the buffer is <= sizeof(someHeader) and if it is you call NdisGetNextBuffer() to get the next one.

Those are by no means hard and fast rules.  The format of a packet/buffer is very dependent upon the drivers loaded on either side of the intermediate driver, and which operating system you're running on.

Which operating systems do you have to support?

 -Brian

---

Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information

Thanks Brian for your reply,

I think you are right. Previously I was making fake ARP response from the driver itself to a fixed ARP query. While testing sometimes the whole ethernet_frame & the arp data was in a single buffer, sometimes it way distributed across two buffers.

So, I wrote a serialize & a de-serialize function to copy the content to an array, modify them, and write them back to original packet. I know this introduces overhead to the driver.

My target system is WinXP & I am using NDIS 5.1x MUX-IM Driver (WDK sample).

Thank you again.

---

fadedreamz

Answer 16

The best thing is not to make any assumptions.  Just loop through the packets and buffers until you've consumed them all.

Yes, an intermediate driver will always add overhead, but with resonably modern processors you could probably calculate the overhead, but I'm not sure you could measure it, so don't worry about it

 -Brian

---

Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information

Answer 17

Brian is right.  There may be an intermediate driver above yours that copies the payload into a single buffer before the packet reaches your driver.  My experience, however, is that in the absence of other intermediates, the outbound packet contains multiple buffers, each one prepared by different components in the stack ... ndis fills the first with the ethernet header, IP fills the second with the IP header, TCP fills the third with the TCP header, etc.  Inbound packets usually contain a single buffer, which the NIC has copied the entire received packet payload into.

I have written my driver to deal with single or multiple buffer packets for inbound and outbound.

Thanks Mirage2k2 for your reply.

I didn't know why the outbound packet was splitted across multiple buffer. Thanks to you I know it now :D .

My main concern was why the MUX-IM driver unable to catch outbound TCP packet? I couldn't think of any possible reason to not capture the outbound TCP packet by MUX-IM. Any suggestion on it?

Thanks again.

---

fadedreamz

Answer 18

Is your packet filter being set?

 -Brian

---

Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information

Answer 19

If you bridge your network adapter then you can perform packet captures on the bridge or on the NIC.  Packet capture on the bridge will show you outbound packets above your driver, packet capture on the NIC will show you outbound packets below your driver.  You may find that you see the TCP packets on the bridge but not on the NIC, or on the NIC but not on the bridge ... this might help you figure out what is going on!

Are there any other intermediate drivers on your system?  Perhaps there is one above yours that is tunneling the outbound TCP packets (i.e. using ESP, GRE or UDP, etc.)  Are you looking at the correct binding?   If there is asymmetric routing then packets will come in on one device but go out on another ... if you are only looking at one binding you will only see them in one direction.

Have you tried the more simple passthru (filter intermediate) driver.  Put your code in there and see if you can see the packets.

Good luck.

Answer 20

Thank you Mirage for your reply.

The passthru driver works like a charm. But I still didn't understand why the same code works in the passthru but does not work in the MUX-IM driver?

And if it was suppose to not work then how can I get only the UDP & ARP datas?

Anyway, Thanks for the advice.

regards,

Shovon.

---

fadedreamz

Answer 21

hello, i'm also working in driver development for pcie and virtual ethernet in windows 7 environment, using NDIS functions.

could u plz send me some related articles?

Answer 22

kindly contact me through [e-mail] or [e-mail]

Answer 23

hello, i'm also working in driver development for pcie and virtual ethernet in windows 7 environment, using NDIS functions.

could u plz send me some related articles?

WDK Sample (netvmini 620) already has a working virtual MP driver for Win 7. Also you can check the MSDN library reference to learn about NDIS more.

[MSDN Ndis 6+] http://msdn.microsoft.com/en-us/library/ff570021%28v=VS.85%29.aspx

[Good Overview of NetBufferLists] http://www.codemachine.com/article_ndis6nbls.html

For PCIE driver I think you will be using some IO control functions (see msdn) for mapping address and perfoming IO operations.

I am also a newbie in NDIS DD. Experienced guys can point you to more better reference.

regards,

fadedreamz

 

---

fadedreamz