TDI Filter Driver - Will this work?

[Nicholas_Nack]

NdisSend() and NdisSendPackets() send packets down the stack to the miniport, i.e. to the network. However, you want to forward them to TCPIP that, in turn, will forward them to the client app. Therefore, instead of sending packets with NdisSend(), you have to indicate them up the stack with NdisMIndicatePackets() from your IM…

So then the loopback interface lies above this level? Since all packets are being sent to localhost, if the loopback interface were below my IM driver, I would just have to use NdisSend/NdisSendPackets.

I am afraid you are much too optimistic. The complexity of modifying NDIS IM filter lies not with actually sending and indicating its own packets… [cut the rest]

Which ultimately seems to make it about as hard as the TDI filter driver (except that the TDI filter driver cannot properly handle the chained event). Seems to be a difficult problem either way!

Thanks,

[Maxim_S_Shatskih]

> features of IP, rather that of higher-level protocols. All IP implementations
must

be able to reassemble datagrams of some certain size (IIRC, the minimum
required size is 576 bytes), but some may be able to deal with larger
transmissions. Unlike TCP, UDP has no mechanism of discovering the
maximum datagram that can be reassembled by a remote host. Therefore, all
UDP-based protocols are normally designed to work within 576-byte limit, so
that they normally send datagrams that don’t exceed 576 bytes - assuming
underlying media is Ethernet, any datagram that these protocols send fits
within
Ethernet MTU,and, hence, does not get fragmented…

Not so.

IP fragment size limit is 576 bytes if the destination is not on the local
network, and the MTU size queried from the NIC driver if the destination is on
the local network.

Path MTU discovery changes even that, so, IP fragment size can be > 576 even
across gateways.

This is IP, not UDP. UDP datagram can have several reassembled IP fragments,
and be up to 64K.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[Maxim_S_Shatskih]

> So then the loopback interface lies above this level?

127.0.0.1 is implemented inside TCPIP and is not reflected by NDIS anyway.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[anton_bassov]

> IP fragment size limit is 576 bytes if the destination is not on the local

network, and the MTU size queried from the NIC driver if the destination is on
the local network.

Path MTU discovery changes even that, so, IP fragment size can be > 576 even
across gateways.

This is IP, not UDP. UDP datagram can have several reassembled IP fragments,
and be up to 64K.

Actually, what I am speaking about is not UDP itself but UDP-based protocols, i.e. UDP *clients*.
If UDP client does not send more than 576 bytes in one go, all the above mentioned things do not apply, for undertstandable reasons. Therefore, I just explained why it is unwise to send datagrams in excess of 576 bytes on UDP client’s behalf - once UDP has no way of knowing the maximum packet that IP implementation on the remote host can reassemble, it may well happen that large transmission gets fragmented by IP on the local host but the remote one’s IP implementation fails to reassemble it, i.e. there is always a chance that UDP sends large packets to the “black hole”. This is why, in practical terms, UDP-based protocols normally limit themselves to 576 bytes, although *theoretically* they may, indeed, send up to 64K in one go…

Anton Bassov

[anton_bassov]

> So then the loopback interface lies above this level? Since all packets are

being sent to localhost, if the loopback interface were below my IM driver, I
would just have to use NdisSend/NdisSendPackets.

To begin with, loopback interface is not related to the network layer - it is implemented at protocol layer by TCPIP itself. Therefore, if a packet with the source address 127.0.0.1 arrives from the network (i.e. gets indicated to TCPIP by lower-level driver), TCPIP will, apparently, just discard it as invalid one.

In any case, loopback interface does not apply to you - you are going to inject packets, i.e. make TCPIP believe that they have arrived from the network and not from your app. Therefore, your packets must have remote source addresses specified in MAC and IP headers…

Anton Bassov

[Nicholas_Nack]

Maxim -> 127.0.0.1 is implemented inside TCPIP and is not reflected by NDIS anyway.

Anton -> In any case, loopback interface does not apply to you - you are going to inject packets, i.e. make TCPIP believe that they have arrived from the network and not from your app. Therefore, your packets must have remote source addresses specified in MAC and IP headers…

Yes, that makes sense (stupid of me). Question - do you know what happens if I send via a miniport driver packets that have remote source addresses in MAC and IP headers, and a local NIC’s mac address as destination address?

Hmm - Anton, if a packet with IP -destination- not source address of 127.0.0.1 arrives from the network, would it get discarded similarly?

Thanks for the educative responses - even if I don’t use some of this knowledge directly here, it will come in handy for future work.

[anton_bassov]

> do you know what happens if I send via a miniport driver packets that have remote

source addresses in MAC and IP headers, and a local NIC’s mac address as destination address?

It depends on miniport driver - if its MPSend() handler does some validation, it is going to detect this error…

arrives from the network, would it get discarded similarly?

Well, if packet’s *destination* address is 127.0.0.1, sending host’s TCPIP implementation should have looped it back to itself - objectively, this packet should not have ever reached a network, in the first place. Therefore, if a packet with destination address 127.0.0.1 arrives from the network, it must be obvious to TCPIP that this packet is forged, so that, unless TCPIP.SYS happens to be buggy, it should discard it…

Anton Bassov