Missing SYN packets in NDIS IM driver

NTDEV
1

I have an NDIS intermediate driver which works fine in all places it has been installed. We have recently installed it on several iMac Minis, which have a Marvell Yukon 88E8053 PCI-E Gigabit Ethernet controller.

In debug builds, this driver optionally prints out all packets received and sent. The odd thing with this iMac setup is that I never see the initial SYN, SYN-ACK, ACK portion of the TCP handshake, but the TCP connection is established, and the driver sees all subsequent packets, and all is well - the application works and the driver does it’s thing - unless, of course, it needed the SYN packet to kick off “doing its thing”.

I updated the driver for the NIC with a different driver from the manufacturer’s web site, and now I DO see all SYN/SYN-ACK/ACK packets. My question is, how did the older driver do this (manage to establish a connection without my driver seeing the packets), and why would it want to? I understand that it would probably make more sense to ask the manufacturer why they are doing whatever it is that they are doing, but I don’t hold out much hope of getting a useful answer. I was hoping someone here might have some insight on how they are bypassing (apparently) NDIS.

Another interesting note: when the SYN/SYN-ACK/ACK packets are not visible in my driver, TCPView does not see an established (via Telnet) connection either. With the updated driver from the manufacturer, the connection IS visible in TCPView.

Thanks,

Ed Lau
Artera Group, Inc.
900 Straits Tpke.
Middlebury, CT 06762

2

Ed,

Does a packet capture made at the top of the NDIS stack for that interface
(NetMon or Ethereal/WireShark) also show that the SYN/SYN-ACK/ACK exchange
is missing?

Also, what OS is running. and what version of NDIS is operative (or more
importantly what version is the NDIS Miniport for the Mavell Yukon).

It is possible for a Miniport to offload TCP connection management to
improve performance. The WDK goes into some information on this (it is part
of the “Chimney” work). If you are running Vista with an NDIS6 miniport
that has Connection Offload enabled that could explain the behavior
observed.

Offload (but I did not think TCP connection offload - maybe NDIS 5.2
Scalable Network Pack?) is in NDIS5 as well and is documented in the DDK.

An IM driver that needs to see ‘pristine’ IP packets often supresses the
response by the under-bound adapter to OID_TCP_TASK_OFFLOAD. That way,
TCPIP.SYS will not negotiate any of the offload features and all IP packets
will be passed to TCPIP.SYS (and through your IM) for processing as they
appear on the wire. Otherwise, you will need to track the context
information passed out-of-band by TCPIP.SYS and the Miniport (or just work
without it).

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ed Lau
Sent: Friday, February 16, 2007 4:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Missing SYN packets in NDIS IM driver

I have an NDIS intermediate driver which works fine in all places it has
been installed. We have recently installed it on several iMac Minis, which
have a Marvell Yukon 88E8053 PCI-E Gigabit Ethernet controller.

In debug builds, this driver optionally prints out all packets received and
sent. The odd thing with this iMac setup is that I never see the initial
SYN, SYN-ACK, ACK portion of the TCP handshake, but the TCP connection is
established, and the driver sees all subsequent packets, and all is well -
the application works and the driver does it’s thing - unless, of course, it
needed the SYN packet to kick off “doing its thing”.

I updated the driver for the NIC with a different driver from the
manufacturer’s web site, and now I DO see all SYN/SYN-ACK/ACK packets. My
question is, how did the older driver do this (manage to establish a
connection without my driver seeing the packets), and why would it want to?
I understand that it would probably make more sense to ask the manufacturer
why they are doing whatever it is that they are doing, but I don’t hold out
much hope of getting a useful answer. I was hoping someone here might have
some insight on how they are bypassing (apparently) NDIS.

Another interesting note: when the SYN/SYN-ACK/ACK packets are not visible
in my driver, TCPView does not see an established (via Telnet) connection
either. With the updated driver from the manufacturer, the connection IS
visible in TCPView.

Thanks,

Ed Lau
Artera Group, Inc.
900 Straits Tpke.
Middlebury, CT 06762

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

One possible culprit could be the callback that is used for receive packets.

One version of the miniport driver version could be calling your NDIS IM at
ProtocolReceive (this probably works) while the other could be calling at
ProtocolReceive (which you might not have implemented completely). Further,
some really bad miniports might call ProtocolReceive with partial packets -
which requires you to call NdisTransferData to fetch the “residual data”.
Finally, could be the original driver is briken.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Saturday, February 17, 2007 9:17 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Missing SYN packets in NDIS IM driver

Ed,

Does a packet capture made at the top of the NDIS stack for that interface
(NetMon or Ethereal/WireShark) also show that the SYN/SYN-ACK/ACK exchange
is missing?

Also, what OS is running. and what version of NDIS is operative (or more
importantly what version is the NDIS Miniport for the Mavell Yukon).

It is possible for a Miniport to offload TCP connection management to
improve performance. The WDK goes into some information on this (it is part
of the “Chimney” work). If you are running Vista with an NDIS6 miniport
that has Connection Offload enabled that could explain the behavior
observed.

Offload (but I did not think TCP connection offload - maybe NDIS 5.2
Scalable Network Pack?) is in NDIS5 as well and is documented in the DDK.

An IM driver that needs to see ‘pristine’ IP packets often supresses the
response by the under-bound adapter to OID_TCP_TASK_OFFLOAD. That way,
TCPIP.SYS will not negotiate any of the offload features and all IP packets
will be passed to TCPIP.SYS (and through your IM) for processing as they
appear on the wire. Otherwise, you will need to track the context
information passed out-of-band by TCPIP.SYS and the Miniport (or just work
without it).

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ed Lau
Sent: Friday, February 16, 2007 4:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Missing SYN packets in NDIS IM driver

I have an NDIS intermediate driver which works fine in all places it has
been installed. We have recently installed it on several iMac Minis, which
have a Marvell Yukon 88E8053 PCI-E Gigabit Ethernet controller.

In debug builds, this driver optionally prints out all packets received and
sent. The odd thing with this iMac setup is that I never see the initial
SYN, SYN-ACK, ACK portion of the TCP handshake, but the TCP connection is
established, and the driver sees all subsequent packets, and all is well -
the application works and the driver does it’s thing - unless, of course, it
needed the SYN packet to kick off “doing its thing”.

I updated the driver for the NIC with a different driver from the
manufacturer’s web site, and now I DO see all SYN/SYN-ACK/ACK packets. My
question is, how did the older driver do this (manage to establish a
connection without my driver seeing the packets), and why would it want to?
I understand that it would probably make more sense to ask the manufacturer
why they are doing whatever it is that they are doing, but I don’t hold out
much hope of getting a useful answer. I was hoping someone here might have
some insight on how they are bypassing (apparently) NDIS.

Another interesting note: when the SYN/SYN-ACK/ACK packets are not visible
in my driver, TCPView does not see an established (via Telnet) connection
either. With the updated driver from the manufacturer, the connection IS
visible in TCPView.

Thanks,

Ed Lau

Artera Group, Inc.

900 Straits Tpke.

Middlebury, CT 06762

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

4

Thomas,

One possible culprit could be the callback that is used for receive packets.

Judging from the description of the problem, there is a good chance that the OP just has some crappy PF software installed on the target machine. Some PF software just loves bypassing IM drivers. For example, kaspersky has its own “scheduler” that hooks TCPIP-WANARP protocol driver, and passes all outgoing packets from TCPIP-WANARP directly to ndiswanip adapter, thus bypassing PSCHED (and, apparently, all other IM drivers). The fact that we speak only about TCP packets with SYN flag is quite indicative - quite often PF software has “quite unhealthy interest”, so to say, in outgoing TCP packets with SYN flag set, although it may overlook other packets, particularly non-TCP ones …

Anton Bassov

5

Marvell Yukon is not a TCP offloaded nic/toe device.

Connection setup (syn, syn-ack, ack) is always handled
by the OS stack (control and security reasons as
mandated by the offload architecture), not the device.

TCP offload is in NDIS 6.0 (Vista/Longhorn), as well
as SNP and SP2 for Windows 2003 Server (NDIS 5.2).

The problem is most likely in the IM driver if the
connection is indeed being established. You need to
look there.

Cheers

— “David R. Cattley” wrote:

> Ed,
>
> Does a packet capture made at the top of the NDIS
> stack for that interface
> (NetMon or Ethereal/WireShark) also show that the
> SYN/SYN-ACK/ACK exchange
> is missing?
>
> Also, what OS is running. and what version of NDIS
> is operative (or more
> importantly what version is the NDIS Miniport for
> the Mavell Yukon).
>
> It is possible for a Miniport to offload TCP
> connection management to
> improve performance. The WDK goes into some
> information on this (it is part
> of the “Chimney” work). If you are running Vista
> with an NDIS6 miniport
> that has Connection Offload enabled that could
> explain the behavior
> observed.
>
> Offload (but I did not think TCP connection offload
> - maybe NDIS 5.2
> Scalable Network Pack?) is in NDIS5 as well and is
> documented in the DDK.
>
> An IM driver that needs to see ‘pristine’ IP packets
> often supresses the
> response by the under-bound adapter to
> OID_TCP_TASK_OFFLOAD. That way,
> TCPIP.SYS will not negotiate any of the offload
> features and all IP packets
> will be passed to TCPIP.SYS (and through your IM)
> for processing as they
> appear on the wire. Otherwise, you will need to
> track the context
> information passed out-of-band by TCPIP.SYS and the
> Miniport (or just work
> without it).
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf
> Of Ed Lau
> Sent: Friday, February 16, 2007 4:20 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Missing SYN packets in NDIS IM
> driver
>
>
> I have an NDIS intermediate driver which works fine
> in all places it has
> been installed. We have recently installed it on
> several iMac Minis, which
> have a Marvell Yukon 88E8053 PCI-E Gigabit Ethernet
> controller.
>
> In debug builds, this driver optionally prints out
> all packets received and
> sent. The odd thing with this iMac setup is that I
> never see the initial
> SYN, SYN-ACK, ACK portion of the TCP handshake, but
> the TCP connection is
> established, and the driver sees all subsequent
> packets, and all is well -
> the application works and the driver does it’s thing
> - unless, of course, it
> needed the SYN packet to kick off “doing its thing”.
>
> I updated the driver for the NIC with a different
> driver from the
> manufacturer’s web site, and now I DO see all
> SYN/SYN-ACK/ACK packets. My
> question is, how did the older driver do this
> (manage to establish a
> connection without my driver seeing the packets),
> and why would it want to?
> I understand that it would probably make more sense
> to ask the manufacturer
> why they are doing whatever it is that they are
> doing, but I don’t hold out
> much hope of getting a useful answer. I was hoping
> someone here might have
> some insight on how they are bypassing (apparently)
> NDIS.
>
> Another interesting note: when the SYN/SYN-ACK/ACK
> packets are not visible
> in my driver, TCPView does not see an established
> (via Telnet) connection
> either. With the updated driver from the
> manufacturer, the connection IS
> visible in TCPView.
>
> Thanks,
>
> Ed Lau
> Artera Group, Inc.
> 900 Straits Tpke.
> Middlebury, CT 06762
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR
> Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR
> Online at
http://www.osronline.com/page.cfm?name=ListServer

_______________________________________________________________________________
Bored stiff? Loosen up…
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front