One socket per interface, then how to select the correct socket ?
Skybuck Flying
The tcp/ip stack does not fill the packet.sourceip with the
outgoing_interface.ip, instead the packet is always filled with the
default_interface.ip which could be a problem for computers with multiple
interfaces. (At least this seems to be the behaviour for udp, not sure about
tcp but it could be affected as well)
Some have mentioned a trick:
Create a socket for each interface. Then bind the socket to the
interface.ip.
(The assumption is the socket will always fill packet.sourceip with the
bound interface.ip... I am not sure if that's true... but let's assume it is
for the sake of this discussion)
I like to keep the application efficient, therefore given a Destination IP,
the application should somehow select the correct socket.
The application could use the ip helper api to retrieve extra information
for each interface.
Like:
Subnet mask.
Gateway settings.
DHCP settings.
Maybe even routing tables.
However I don't know much about routing...
So the question is given all this information how could my application
select the correct socket ?
Bye,
Skybuck.
Skybuck Flying
The situation could be as follows:
Interface 1, LAN-IP
Interface 2, INTERNET-IP
When the stack sends the packets to the internet-ip, via interface 2 it sets
packet.sourceip to the default interface which interface1.lan-ip.
Therefore when the internet hosts try to reply... they are replying to
lan-ip... so the replies will never reach back.
Bye,
Skybuck.
Skybuck Flying
Since it seems to work just fine under the mentioned specific situation ?!
Apperently it must be using a special fix ;)
Hmm ;)
Bye,
Skybuck.
Skybuck Flying
Since Internet Explorer is using TCP, which is connection-oriented, internet
explorer would not need to bind every interface.
It could bind only to the correct interface just once per destination ip.
Since there is only one destination ip per connection ;)
Bye,
Skybuck.
Skybuck Flying
solution... since it would definetly need a solution.
My bet is it's using the ip helper api to select the correct interface based
on some routing information or so.
Bye,
Skybuck.
Skybuck Flying
destination to destination basis.
Would be nice if microsoft came forward with the solution.
Maybe mozilla/firefox browser uses this solution as well..
Digging into the source code might uncover the solution ;)
Bye,
Skybuck.
David Schwartz
Patient: Doctor, it hurts when I do this.
Doctor: So don't do that.
There are two possible cases:
1) The machine is a gateway between the LAN and the Internet. In that
case, it should NAT packets with sources on the LAN and destinations
on the Internet. If it doesn't NAT that connection, it's broken. So
even if it first choose the LAN address as the source, the NAT should
rewrite it.
2) The machine is not a gateway between the LAN and the Internet. In
that case, it should send packets with LAN source addresses and
Internet destinations to the gateway. If it doesn't send that
connection to the NAT machine over the LAN, it's broken.
So in either case, if this happens, it is because the machine is
misconfigured.
It's tricky to connect a machine to both a LAN and the Internet when
that LAN uses private addresses. Yes, it's possible to do it wrong and
break things. No, the OS won't magically make it all work in every
case.
DS
Skybuck Flying
Iphlpapi.h was found zero times in *.c
Iphlpapi.h was found one time in *.cpp:
mozilla\netwerk\system\win32\nsNotifyAddrListener.cpp(56): #include
<iphlpapi.h>
Iphlpapi.h was found zero times in *.h
Iphlpapi.h was found zero times in *.hpp
Most interesting.
It seems firefox does do special network interface/adapter querying to learn
if there is a suitable interface.
Bye,
Skybuck.
Skybuck Flying
It probably uses that to see what is online and what not..
Though I am not sure if this completely solves it..
There was also something else in there which looked kinda strange
do_GoServe("mozilla/blblabla"
Like it was calling some services or so... but that's probably not it..
because that stuff is everywhere in the source.
Bye,
Skybuck.
Skybuck Flying
structure _MIB_IFROW.dwOperStatus:
IF_OPER_STATUS_NON_OPERATIONAL LAN adapter has been disabled, for example
because of an address conflict.
IF_OPER_STATUS_UNREACHABLE WAN adapter that is not connected.
IF_OPER_STATUS_DISCONNECTED For LAN adapters: network cable disconnected.
For WAN adapters: no carrier.
IF_OPER_STATUS_CONNECTING WAN adapter that is in the process of connecting.
IF_OPER_STATUS_CONNECTED WAN adapter that is connected to a remote peer.
IF_OPER_STATUS_OPERATIONAL Default status for LAN adapters
Firefox and Internet Explorer probably learn which interface is the internet
interface because it would have a connected status and lan would not have
connected status ?
Hmmm ^ Just a theory ;)
Bye,
Skybuck.
Skybuck Flying
the browser... would probably work as well ?
So maybe the browsers do some "ip thinking" to know which interface to use
when just an ip giving ;)
I am not so sure how they figure that part out ;) Maybe again with some ip
helper info ? who knows ;)
Bye,
Skybuck.
Skybuck Flying
if IP is a LAN-IP then use a lan interface.
ip > 192.168.0.1 < 1928.168.x.x or so <- use netmask or so.
Otherwise use WAN-IP interface.
However... what if there are multiple lan network cards ;)
Maybe then use subnet mask to figure out where it's supposed to go or so ;)
Oh well for udp... if one socket should be able to communicate with lan and
wan.. then for each destination ip... some ip thinking would need to be
done...
That's how I would probably do it... and then if outcome is lan use lan or
if it s wan use wan ;) hehehe.
Filthy solution but might work ;)
Bye,
Skybuck.
Barry Margolin
"Skybuck Flying" <Blood...@hotmail.com> wrote:
Am I missing half the conversation? I see lots of messages by Skybuck
in this thread, but I can't see the messages that he's respondong to.
Or is he replying to himself?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
robert...@yahoo.com
> In article <aa4f$48975bf0$541981a9$...@cache5.tilbu1.nb.home.nl>,
> "Skybuck Flying" <BloodySh...@hotmail.com> wrote:
>
>
>
>
>
> > With ip thinking I mean ofcourse something like so:
>
> > if IP is a LAN-IP then use a lan interface.
>
> > ip > 192.168.0.1 < 1928.168.x.x or so <- use netmask or so.
>
> > Otherwise use WAN-IP interface.
>
> > However... what if there are multiple lan network cards ;)
>
> > Maybe then use subnet mask to figure out where it's supposed to go or so ;)
>
> > Oh well for udp... if one socket should be able to communicate with lan and
> > wan.. then for each destination ip... some ip thinking would need to be
> > done...
>
> > That's how I would probably do it... and then if outcome is lan use lan or
> > if it s wan use wan ;) hehehe.
>
> > Filthy solution but might work ;)
>
> > Bye,
> > Skybuck.
>
> Am I missing half the conversation? I see lots of messages by Skybuck
> in this thread, but I can't see the messages that he's respondong to.
> Or is he replying to himself?
Skybuck Flying is widely considered a troll, or worse, and is well
known for dumping streams of consciousness on Usenet, usually with
considerable crossposting, often in groups with minimal relevance.
But yes, he's replying to himself.
Skybuck Flying
other for lan.
So this can't be used to tell which one is connected to the internet.
This leaves the dhcp as a possible indication, however lan's could have
dhcp's too.
Bye,
Skybuck.
Skybuck Flying
Then it does something with GetIpAddrTable
Maybe it assumes there is an internet connection if there are routers or
something in that table...
Further investigating...
Bye,
Skybuck.
Skybuck Flying
My internet connection has these flags set:
MIB_IPADDR_PRIMARY
MIB_IPADDR_DYNAMIC
It's like the dhcp techniques except this should work on older os-es as
well.
Not sure if it's much use... since a lan might have dynamic flags set to..
But if users doesn't use dhcp on lan/local stuff then this is better than
nothing ;)
Also I am still not sure what the observer service does... maybe the web
browser tries to reach a pre-determined website to see if it can be reached
via a certain interface or so... how it would go about using tcp/http
remains unclear... maybe it's a special com/dcom service or something ;)
Bye,
Skybuck.
Skybuck Flying
>
> The tcp/ip stack does not fill the packet.sourceip with the
> outgoing_interface.ip, instead the packet is always filled with the
> default_interface.ip which could be a problem for computers with multiple
> interfaces. (At least this seems to be the behaviour for udp, not sure
> about tcp but it could be affected as well)
Another explanation could be the stack simply sends the replies back out the
wrong interface.
Somehow it could select the wrong interface.
Not sure how that happens.
Let's see my computer receives:
Packet.DestIP = Internet IP = My Public IP
My computer tries to respond to
Packet.DestIP with NewPacket.DestIp = Packet.SourceIp
but somehow select the wrong interface.
The socket was not bound to any interface.
The computer must select an interface to reply on...
At this point somehow it goes wrong.
How would the stack select the correct interface anyway ?
Same question really... answer probably routing information... maybe routing
information is wrong or the operating system just sucks. Well it sucks
anyway hehe ;)
Bye,
Skybuck.
Skybuck Flying
WSPSendTo (
// If this socket is not yet bound to an address, bind it to an
// address. We only do this if the helper DLL for the socket
supports
// a get wildcard address routine--if it doesn't, the app must bind
// to an address manually.
So it seems when civilization 3 conquest sends it's packets to the clients
it's socket gets bound.
Maybe it gets bound to the wrong interface.
Which could explain the problems.
Bye,
Skybuck.
Skybuck Flying
IPHLPAPI:
GetBestInterface function.
So far seems to work... but not yet tested with weird situations ;)
Bye,
Skybuck.
David Schwartz
> Both lan adapters are in the operational state, one is for internet, the
> other for lan.
>
> So this can't be used to tell which one is connected to the internet.
There is no reason the application can or should care.
> This leaves the dhcp as a possible indication, however lan's could have
> dhcp's too.
Indication of what?
1) This computer is connected to the LAN.
2) This computer is connected to the Internet.
3) Therefore the LAN is connected to the Internet.
So it doesn't matter which interface is chosen or used. It is
perfectly legal to choose the LAN source address for an Internet
connection. That's why LANs that are gatewayed to the Internet have a
gateway that does NAT.
DS
David Schwartz
> Another explanation could be the stack simply sends the replies back out the
> wrong interface.
Impossible.
> Somehow it could select the wrong interface.
Impossible.
You are really confused. I'll try one more time to straighten you out.
1) If the machine is not a gateway, it is perfectly reasonable to send
this packet over the LAN interface so that it will get to the Internet
through the gateway.
2) If this machine is a gateway, the mistake would be not NATting the
packet even though it has a LAN source address and an Internet
destination address. That would have nothing to do choosing the wrong
interface but be a completely different problem.
3) If there is no gateway on the LAN and the machine is not the
gateway, then it should be impossible for it to send the packet on the
LAN interface. There would be no route pointing that way.
So you are trying to solve a problem that cannot exist.
DS
Shems
I think you all are making the 'problem' bigger then it is. As far as I
understand your ip is linked to the Mac-address/physical address of the
adapter; be it virtual, wireless or cabled. Taking in account the fact that
the net is composed of layers, inherent dependencies & permissions and the
introduction of ipv6, the possibilities are directly proportional to the
complications. Unless the sockets bindings are contradictory, the command
'ipconfig /renew' should be sufficient. Manually binding the sockets would
require a lot more knowledge and experience.
Shems
----------------
When the machne breaks down, we break down.
"Skybuck Flying" wrote:
> Hello,
>
> The tcp/ip stack does not fill the packet.sourceip with the
etcetera...