skybuck flying

Hello,

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

Maybe this problem is only for a specific situation.

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

Also, Internet Explorer must be aware of this problem.

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

Well,

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

Still though this does mean internet explorer is using a different
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

The solution internet explorer uses could probably be applied to udp one a
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

Search report:

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

Yeah it seems to return some operational status or so...

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

Yes this probably clarifies it:

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.