Re: how to tell a socket to use a specific interface...
Re: how to tell a socket to use a specific interface...
- Subject: Re: how to tell a socket to use a specific interface...
- From: Justin Walker <email@hidden>
- Date: Fri, 20 May 2005 19:38:39 -0700
On May 20, 2005, at 17:18, Philip George wrote:
On May 20, 2005, at 6:29 PM, Justin Walker wrote:
Without seeing netmasks, it's hard to tell, but note that IP routing
rules require that you *not* have addresses in the same subnet on two
different interfaces. What netmask are you using? If it's something
like 255.255.255.0 (or anything ending in .0), I think that is (part
of) your problem.
you're right. i hadn't thought of that. changing one of the routers'
gateway address to 192.168.0.250 helped a little.
so now it looks like:
GATEWAY of GOOD ROUTER : 192.168.1.1
ADDRESS of WIFI IFACE : 192.168.1.104
GATEWAY of DEAD ROUTER : 192.168.0.250
ADDRESS of CAT5 IFACE : 192.168.0.101
..with netmasks of 255.255.255.0 on both
(here, "DEAD" means: the LAN side works fine, but the WAN side has no
connection to the internet.)
You have way too much terminology here. Can't we just stick to
addresses and interface names? Forget WIFI, CAT5, DEAD, ...
As best I can tell, you have one box, with two interfaces, en0 and en1.
en0 has network 192.168.0 attatched; en1 has network 192.168.1
attached. Is this correct?
Router 192.168.1.1 connects to The Internet
Router 192.168.0.250 connects to nothing.
Correct?
Do you have routing enabled? Check "sysctl net.inet.ip.forwarding".
the symptoms are still the same for pretty much everything i've
described, but since i last wrote, i've been playing around with the
'route' commandline tool (only for display info, not changing
anything). before changing the lan-side address on the "DEAD" router,
it was constantly opting to choose en1 (WIFI) to route packets that
were impossible to reach via en0 (CAT5).
for instance, before the change (assume the only difference is that
DEAD ROUTER = 192.168.1.1 and CAT5 IFACE = 192.168.1.105):
route get -host 192.168.1.1 192.168.1.106
...would choose en1 (WIFI) even though 192.168.1.106 is ONLY reachable
by the CAT5 line.
You've got me as confused as you are now. Either you have a totally
hosed network, or you have typos above. The reason the route command
chooses what you call WIFI (en1, I guess) is that WIFI is on the same
subnet as the .106 address.
after changing the networks so that there could be no confusion, this
problem vanished.
but still, the following code still gets autorouted, even after the
call to bind():
// setup local address stuff...
struct sockaddr_in LOCaddr;
LOCaddr.sin_family = AF_INET;
LOCaddr.sin_addr.s_addr = inet_addr(local_ip);
// bind to specific interface...
if (bind(sockethandle, (struct sockaddr *)&LOCaddr,
sizeof(LOCaddr))==0) {
// send()...
// recv()...
// ...
}
Perhaps you need to spend some time with a book like W. Richard
Stevens' "Unix Network Programming, v1, 2ed (or 3ed)". First, what do
you mean "code ... gets autorouted"? Second, bind() has *no* effect on
routing. Routing is dictated by the destination address of the packet
you want to be sent.
The comment may be old, but just in case: you *can't* bind to an
interface.
i want it to bind to the bad route and then fail, as opposed to
picking the next best thing and proceeding as if nothing were wrong
with the selected route. also, in the situation where i had two good
routes to two separate networks, i'd still need to send certain
requests thru one network and certain requests thru the other.
You can't do this. The only way to utilize a "bad" route is to send a
packet to an address that lies "in that direction".
the end goal is to be able to get the user's public ip address for ANY
and ALL active network connections that can reach the internet. A cgi
is called on my web server that spits back the caller's address, which
will of course be the public address. none of this works without
being able to distinguish between the different interfaces when
sending the request for the cgi.
right now, it looks like en1 AND en0 both have the same public
address. there should, of course, be only the public address for en1
and **nothing** for en0, since it can't even get to the internet.
Forget about en0 and en1; they are of interest (and are accessible)
only to the routing infrastructure. When a protocol handler has a
packet to send, it gets a route indicator from the routing
infrastructure, and uses the address from that indicator as the next
hop for the packet.
Your description of your problem is as confusing to me as the rest of
this. What is the *real* goal?
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for General Semantics
--------
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden