Hello,
I am writing a WinXP kernel mode TDI client to the RawIp device on a multihomed system (ie, more than one NIC). The NICs are assigned static IP addresses 169.254.1.2 and 169.254.1.1 When examining captured traffic, I have discovered that an attempt to bind to either of these local addresses using ZwCreateFile seems to always select the 169.254.1.1 NIC and associate the specified IP address to all packets sent. That is, packets with source address 169.254.1.2 will be sent through the 169.254.1.1 interface (!).
Has anyone experienced this before? Is there any other way to instruct the TDI to bind to the correct NIC?
Thanks,
Michael Gozzo
I’m a little surprised this configuration works even from user mode.
Your interfaces are either using a /32 netmask (which I imagine
doesn’t work exceedingly well) or /16 (which is default for the
reserved auto-configuration space that these addresses are in). In
the latter case, that means you have two interfaces on the same subnet.
What happens if you re-address these NICs into their own subnets?
Say, 192.168.0.1/24 and 192.168.1.1/24. In any case, you shouldn’t be
manually assigning 168.254.x.y addresses.
-sd
On Sep 15, 2006, at 8:16 AM, xxxxx@gmail.com wrote:
Hello,
I am writing a WinXP kernel mode TDI client to the RawIp device on
a multihomed system (ie, more than one NIC). The NICs are assigned
static IP addresses 169.254.1.2 and 169.254.1.1 When examining
captured traffic, I have discovered that an attempt to bind to
either of these local addresses using ZwCreateFile seems to always
select the 169.254.1.1 NIC and associate the specified IP address
to all packets sent. That is, packets with source address
169.254.1.2 will be sent through the 169.254.1.1 interface (!).
Has anyone experienced this before? Is there any other way to
instruct the TDI to bind to the correct NIC?
Thanks,
Michael Gozzo
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
Hi Steve,
Thanks for your response, I did repeat my experiment with the NICs on different subnets… to no avail. I still see packets from 192.168.0.1 on the 192.168.1.1 interface. Basically the code I run does the following:
void SomeNetworkFunc()
{
build udp datagram socket;
initialize source addr structure with local NIC ip 192.168.0.1;
initialize dest addr structure to point to broadcast 255.255.255.255;
bind(datagram socket, source addr);
connect(datagram socket, dest addr);
send(datagram socket, someData);
}
In my driver, the packet gets broadcast on the first network interface, irregardless of its source address. In the user mode code equivalent I just wrote, the packet is sent on all network interfaces in my system(Which are all on different physical networks) and each packet shares the source IP set during the call to bind().
So I guess my question is… is it possible as a TDI client to select a NIC to broadcast a UDP packet in a multihomed system? Has anybody bumped into this before?
Michael
Well, after poking around extensively, it turns out that one cannot be absolutely certain using this method of the network interface used to transmit a UDP packet due to the underlying implementation in Win 2000.
From : http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
“When an IP datagram is sent from a multihomed host, it is passed to the interface with the best apparent route to the destination. Accordingly, the datagram may contain the source IP address of one interface in the multihomed host, yet be placed on the media by a different interface. The source media access control address on the frame is that of the interface that actually transmitted the frame to the media, and the source IP address is the one that the sending application sourced it from, not necessarily one of the IP addresses associated with the sending interface in the Network Connections UI.”
Hope this helps somebody!
xxxxx@gmail.com wrote:
Well, after poking around extensively, it turns out that one
cannot be absolutely certain using this method of the network
interface used to transmit a UDP packet due to the underlying
implementation in Win 2000.
From : http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
“When an IP datagram is sent from a multihomed host, it is
passed to the interface with the best apparent route to the
destination. Accordingly, the datagram may contain the source
IP address of one interface in the multihomed host, yet be
placed on the media by a different interface. The source media
access control address on the frame is that of the interface
that actually transmitted the frame to the media, and the
source IP address is the one that the sending application
sourced it from, not necessarily one of the IP addresses
associated with the sending interface in the Network
Connections UI.”
Hope this helps somebody!
The only other comments I could add are that we had run into something
similar with sending a DHCP Inform request via TDI. (Destination in
that case is IP-level broadcast address, for what its worth.) Message
always went out all interfaces, regardless of which interface/address
was intended or appropriate.
User-mode DHCP Client API (DhcpRequentParams, etc.) appears to have a
private IOCTL with TCPIP that gets around exactly this point; causing
DHCP Inform request to only go out through the expected/intended
interface during an otherwise normal Winsock-based UDP send. This
interface has not been documented as available to other user- or
kernel-mode code.
This problem is expected to be a moot point on the rewritten TCPIP
stack of Windows Vista/Longhorn, because the stack defaults to the
“strong ES” (“strong end system”, or “strong host”) model that is
optional (“may”) for multi-homed Internet hosts. (RFC 1122, section
3.3.4.2 “Multihoming Requirements”.) The strong host model limits the
IP packet to go out through only the interface that corresponds with
the packet’s source IP address.
Alan Adams