[ale] home networking difficulties

[Joseph A. Knapka]

Geoffrey wrote:
> 
> Joseph A. Knapka wrote:
> > Geoffrey wrote:
> >
> >>You might try networking the Linux box to itself.  That is, set the two
> >>nics to be in the same subnet and connect them both to the hub.  This
> >>way you might reduce the possible issues substantially.  From that
> >>point, you could verify the cables/cards are functional.
> >
> >
> > Does that work? I'm under the impression that the Linux network
> > layer, confronted with this situation, will just say, "Oh,
> > both IPs point to this machine, so there's no reason to
> > actually touch any hardware."
> 
> I seem to recall doing this.  I believe if you ping ip1 from ip2, it's
> going to go through the wire.  Does it really know that both ip's are
> connected to the same machine.

It certainly knows this, since it must have routes for those
interfaces in order for networking to function at all.

>  Rather, does it check it, I doubt it.

I imagine it does whatever checking is required to honor
the route table.

> Certainly it knows, but I find it unlikely that it checks for it.  Hmmm,
> now you've got me thinking of retesting it myself.

Thinking out loud:

ISTR when I tried this on a 2.4 kernel, I found that the pings
would succeed whether the cables were plugged into the hub or
not. For example:

2 NIC's, 192.168.1.1 and 192.168.1.2

What does "ping 192.168.81.1" do? The routing subsystem
knows that the route to 192.168.1.1 is the 192.168.1.1
interface, so the packet has already arrived at its
destination, and the packet immediately appears (software
wise) at the 192.168.1.1 interface. The behavior is
identical to that when there's only a single NIC card
in the machine.

How about 192.168.1.1 and 192.168.2.1, different subnets?
The same argument applies, as far as I can see.

Could you force the routing layer to send stuff on
one interface preferentially? Yes, by setting the
route to 192.168.1.1 be 192.168.2.1. But in that
case *every* packet, even replies to ICMP packets
received at 192.168.1.1, will go out via 192.168.1.2.
So you'd never be able to actually make the
192.168.1.1 NIC send any data. Though I presume
you could test the NIC receiver that way. And if
you reversed the routes you could test the other
way. Maybe this would work... I would think the
kernel would honor the routing info even if it
"knew" the source and destination were both
physically in the machine. I don't remember if I
tried this or not...

-- Joe
  "I'd rather chew my leg off than maintain Java code, which
   sucks, 'cause I have a lot of Java code to maintain and
   the leg surgery is starting to get expensive." - Me

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.