Networks and wireless etc
Simon Jefferies
Please can you tell me if I'm doing this right or not?
I'm trying to get winsock to use the relevant network adapter to connect to
an IP address. I have enumerated the list of devices and have e.g. network
card, wireless network and loopback (using the GetAdaptersAddresses() WIN32
function). Do I simply use the SOCKADDR structure?
Or am I doing this completely wrong? What i'm trying to do is get the user
to select that they may want to connect using the wireless or bluetooth
device? Can this be done or is it up to Windows to decide etc?
Please help,
Simon.
Eugene Gershnik
> Hello,
>
> Please can you tell me if I'm doing this right or not?
>
> I'm trying to get winsock to use the relevant network adapter to
> connect to an IP address. I have enumerated the list of devices and
> have e.g. network card, wireless network and loopback (using the
> GetAdaptersAddresses() WIN32 function). Do I simply use the SOCKADDR
> structure?
bind() to a sepcific local address before connecting.
> Or am I doing this completely wrong? What i'm trying to do is get the
> user to select that they may want to connect using the wireless or
> bluetooth device? Can this be done or is it up to Windows to decide
> etc?
It can be done but it is usually a bad idea *especially* when volatile
things like Wi-Fi and BT are involved. The network config may change when I
move a few feet but the preferences I selected for your app won't
--
Eugene
http://www.gershnik.com
Arkady Frenkel
( 20 + ) so that if ( very rear ) the same network used for
wired and wireless the preference is for wired as default case is
Modem/wired/wireless . Usually they differ so bind() will be enough
but you can change metric with IPHLPAPI route functions
Arkady
"Eugene Gershnik" <gers...@hotmail.com> wrote in message
news:etrta3Ce...@TK2MSFTNGP14.phx.gbl...
Alun Jones [MSFT]
>> Hello,
>>
>> Please can you tell me if I'm doing this right or not?
>>
>> I'm trying to get winsock to use the relevant network adapter to
>> connect to an IP address. I have enumerated the list of devices and
>> have e.g. network card, wireless network and loopback (using the
>> GetAdaptersAddresses() WIN32 function). Do I simply use the SOCKADDR
>> structure?
>
> bind() to a sepcific local address before connecting.
Binding will not directly affect which NIC is chosen to route outgoing
traffic.
Changing the information in the routing table will do that. Binding is only
an association between an IP network interface and a socket; while that IP
network interface is associated with a NIC, the NIC that is chosen to send a
packet out on depends on the _destination_ of that packet.
Thinking a little on this, it's perfectly sensible - if you have two
physically separate networks that your machine can get to, the only way to
get to network one is through the card that is connected to network one.
That's what your routing table is for, to tell the system where to send
packets for various network destinations.
Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.
Eugene Gershnik
> "Eugene Gershnik" <gers...@hotmail.com> wrote in message
> news:etrta3Ce...@TK2MSFTNGP14.phx.gbl...
>> Simon Jefferies wrote:
>>> Hello,
>>>
>>> Please can you tell me if I'm doing this right or not?
>>>
>>> I'm trying to get winsock to use the relevant network adapter to
>>> connect to an IP address. I have enumerated the list of devices and
>>> have e.g. network card, wireless network and loopback (using the
>>> GetAdaptersAddresses() WIN32 function). Do I simply use the SOCKADDR
>>> structure?
>>
>> bind() to a sepcific local address before connecting.
>
> Binding will not directly affect which NIC is chosen to route outgoing
> traffic.
>
> Changing the information in the routing table will do that. Binding
> is only an association between an IP network interface and a socket;
> while that IP network interface is associated with a NIC, the NIC
> that is chosen to send a packet out on depends on the _destination_
> of that packet.
So what interface is SYN-ACK going to come from? That is are you saying that
I can bind to 127.0.0.1 and have packets delivered to me that arrived on
192.168.2.1? The way I see it you need *both* to bind correctly and have a
workable routing table.
--
Eugene
http://www.gershnik.com
Arkady Frenkel
have different :) ) the one with less metric route for NIC with be chosen
Arkady
"Eugene Gershnik" <gers...@hotmail.com> wrote in message
news:OVg$0N3eFH...@TK2MSFTNGP09.phx.gbl...
Eugene Gershnik
> What Alun mean is if you have 2 IPs going to the same network ( your
> example have different :) ) the one with less metric route for NIC
> with be chosen Arkady
If you don't bind, sure. But that's, in my understanding, not what the OP
wanted. Actually re-reading the original post I start to doubt that I
understand what OP wanted. In any case my point is if you explicitly bind()
before connect the traffic should go out from the interface you have bound
the socket to. If there is no route to destination the connect() should
fail. I have no suitable machine to verify this right now but I would be
very surprised if this wasn't the case.
--
Eugene
http://www.gershnik.com
Arkady Frenkel
autentication/autorization process through ZeroConfigure or similar custom
service , OTOH IIRC that not work for wired too , for multihomed computer
bind not helped me and routing of data went due to metric and not bind.
For long period I'm not played with multihomed computers ( from
http://www.codeguru.com/network/pfwredun.shtml ) but that what happened ,
obviously IIRC ( I became older :( )
Arkady
"Eugene Gershnik" <gers...@hotmail.com> wrote in message
news:ezVDMu6e...@TK2MSFTNGP10.phx.gbl...
Eugene Gershnik
> In wireless , routing done by STA before connection() happen during
> autentication/autorization process through ZeroConfigure or similar
> custom service , OTOH IIRC that not work for wired too , for
> multihomed computer bind not helped me and routing of data went due
> to metric and not bind. For long period I'm not played with
> multihomed computers ( from
> http://www.codeguru.com/network/pfwredun.shtml ) but that what
> happened , obviously IIRC ( I became older :( )
Hmmm. I'll try it tomorrow in the office where I have wireless and wired
connection to the same network.
--
Eugene
http://www.gershnik.com
Arkady Frenkel
multihomed computer of 2 wired cards on the same network, but be aware of
feature described in Q139334(
http://support.microsoft.com/default.aspx?kbid=139334 ) - I fell once . Ping
worked on unconnected NIC sure without MediaSense ( NT times )
Arkady
P.S. Multihomed computer - good topic for your FAQ btw :)
"Eugene Gershnik" <gers...@hotmail.com> wrote in message
news:upNx%23n7eF...@TK2MSFTNGP14.phx.gbl...
Alun Jones [MSFT]
Here's a routing table entry that shows what happens for 127.0.0.1:
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
Note that the metric is "1". No other entry in the routing table has a
lower entry, so _all_ packets destined for 127.*.*.* (or 127/8 if you prefer
CIDR format) will go through the NIC associated with interface 127.0.0.1.
If you bind a socket to a particular IP address, that will be the source
address indicated in outgoing packets on that socket, and must be the
destination address on incoming packets for that socket. However, outgoing
packets will go out whichever NIC is the "closest" (by metric) and "most
exact match" for network destination in the routing table, regardless of the
source address.
127.0.0.1 is a bad example, because you should never receive packets from
outside destined for that address. But, example or not, it still follows
the same rules. A better question to match your concern is "if I bind to IP
address 10.0.0.1, which is an address of a real NIC on my machine, and send
to 127.0.0.1, will there be any network traffic generated?" Clearly, the
answer is "no - the destination address is internal, so no network traffic
will be generated".
Eugene Gershnik
> If you bind a socket to a particular IP address, that will be the
> source address indicated in outgoing packets on that socket, and must
> be the destination address on incoming packets for that socket. However,
> outgoing packets will go out whichever NIC is the "closest"
> (by metric) and "most exact match" for network destination in the
> routing table, regardless of the source address.
So it appears you predict the following behavior:
Case 1: Two disjoint networks A and B (both non-loopback). Routing table
properly configured.
bind(A);
connect(B);
Result: SYN goes out on B but SYN-ACK is never delivered. connect times out
Case 2: One network A accessible through two adapters A1 and A2. Routing
tables are properly configured with A1 having the lower metric.
bind(A2);
connect(A);
Result: SYN goes out on A1 but SYN-ACK is delivered on A2. And so on. All
outgoing traffic goes from A1 and incoming is received on A2. connect is
successfull as are all subsequent communications.
Does this correctly describe what you are saying?
If this is true this would be a big usability and possibly security hole but
who knows. I have been wrong in the past and I didn't have time to check
this directly yet. FWIW my expectations would be
Case 1: No SYN packet goes out as destination is unreachable
Case 2: The SYN packet and the rest of outgoing traffic goes from A2. The
connection is established in the usual manner.
--
Eugene
http://www.gershnik.com
Arkady Frenkel
in network chat annouced in this NG I receive from Eric Cross (Windows
Networking MVP) link
http://support.microsoft.com/default.aspx?scid=kb;en-us;299540
describing all big numbers I wrote about when you see wireless connections
( not only )
Arkady
"Eugene Gershnik" <gers...@hotmail.com> wrote in message
news:uYD3juN...@TK2MSFTNGP14.phx.gbl...
Alun Jones [MSFT]
> Alun Jones [MSFT] wrote:
>> If you bind a socket to a particular IP address, that will be the
>> source address indicated in outgoing packets on that socket, and must
>> be the destination address on incoming packets for that socket. However,
>> outgoing packets will go out whichever NIC is the "closest"
>> (by metric) and "most exact match" for network destination in the
>> routing table, regardless of the source address.
>
> So it appears you predict the following behavior:
>
> Case 1: Two disjoint networks A and B (both non-loopback). Routing table
> properly configured.
>
> bind(A);
> connect(B);
>
> Result: SYN goes out on B but SYN-ACK is never delivered. connect times
> out
I believe that is the behaviour you would expect, if the machine on network
B does not have a route back to your source machine that will actually reach
it. (Would you expect anything else? After all, if the packet was sent out
on network A, it would not be replied to either, under those circumstances)
> Case 2: One network A accessible through two adapters A1 and A2. Routing
> tables are properly configured with A1 having the lower metric.
>
> bind(A2);
> connect(A);
>
> Result: SYN goes out on A1 but SYN-ACK is delivered on A2. And so on. All
> outgoing traffic goes from A1 and incoming is received on A2. connect is
> successfull as are all subsequent communications.
That is mostly correct. The route that the SYN-ACK comes back in on will
depend on the routing table at the remote machine.
> Does this correctly describe what you are saying?
Yes, it does seem to - but trying it out on a simple machine would be the
easiest way to verify it.
> If this is true this would be a big usability and possibly security hole
> but who knows. I have been wrong in the past and I didn't have time to
> check this directly yet. FWIW my expectations would be
It's not a security hole - unless you don't understand it, and make security
decisions based on it happening in a different way.
> Case 1: No SYN packet goes out as destination is unreachable
The "destination is unreachable" message is received at the host on network
B that you connect to, when it tries to send the SYN-ACK back.
> Case 2: The SYN packet and the rest of outgoing traffic goes from A2. The
> connection is established in the usual manner.
Nope - the bind() doesn't do anything except establish the local IP address
of the socket in use.
Here's an article from December 2001 detailing IP routing for IPv4:
http://www.microsoft.com/technet/community/columns/cableguy/cg1201.mspx
The wrinkle comes in IPv6, where it acts more like you want:
http://www.microsoft.com/technet/community/columns/cableguy/cg1002.mspx
[In each article, look for the part labeled "Route Determination Process"]
Note - this is one more reason why it's a bad idea to call bind() before
calling connect().
Arkady Frenkel
I read both ( btw I have and read almost all books of Joseph Davies (
CableGuy ) ) but only now I saw how changed the meaning of metric espesially
in connection with MSDN Q I mentioned too
Arkady
"Alun Jones [MSFT]" <al...@online.microsoft.com> wrote in message
news:OblVZ2cf...@TK2MSFTNGP12.phx.gbl...
Eugene Gershnik
> "Eugene Gershnik" <gers...@hotmail.com> wrote in message
> news:uYD3juN...@TK2MSFTNGP14.phx.gbl...
>> Alun Jones [MSFT] wrote:
Well I just made a simple test of my scenarios 1 and 2 on XP SP2. I am happy
to report that as far as I could determine we both were somewhat right and
somewhat wrong. ;-) (Disclaimer: my test may be wrong or I could do
something stupid. What follows is "as far as I could determine")
I tried various cases including the ones mentioned in my post and the end
result seems to be this:
When bind() assigns an interface that contradicts the routing table the
connect() always fails with WSAEHOSTUNREACH *regardless* of whether a good
route exist to the destination host. *No* SYN is sent on an interface
different from the one assigned by bind() and *no* SYN is sent on the bound
interface.
IOW neither my expectations nor yours were entirely correct
The only correct conslusion is what I said in one of my older posts "The way
I see it you need *both* to bind correctly and have a workable routing
table." (Of course we agree that the best thing is not to bind() at all)
That calms my worries about usability and security ("if I said use X than
use X or fail").
> Here's an article from December 2001 detailing IP routing for IPv4:
>
> http://www.microsoft.com/technet/community/columns/cableguy/cg1201.mspx
>
> The wrinkle comes in IPv6, where it acts more like you want:
>
> http://www.microsoft.com/technet/community/columns/cableguy/cg1002.mspx
These are nice articles which explain what I know pretty well i.e. how the
routing table works. What the first one doesn't mention and the second one
mentiones in a non-conclusive way (i.e. "interface assigned the source
address") is how Winsock level bind() interacts with routing.
I beleive that the following text from the second article applies both to
IPv4 and IPv6 on Winsock
"For a sending host, if the source address is specified by the sending
application, the only routes that are checked are those that apply to the
interface assigned the source address. For a sending host, if the source
address is not specified by the sending application, or for a forwarding
router, all the routes are checked"
> Note - this is one more reason why it's a bad idea to call bind()
> before calling connect().
Agreed. Still, very rarely you may want to force the client to talk only on
a given interface.
--
Eugene
http://www.gershnik.com