AW: dns-lookup problem on eth1

[Jim Carter]

On Thu, 17 Apr 2003, Zuern, Frank wrote:
> one router 192.168.1.1
> one Access Point 192.168.1.11
> both NIC's get the information from the same point.
> NIC's get 192.168.1.13 and 192.168.1.14 depending on the order, they
> where plugged in
> So, after my opinion nothing wrong with the network setup

Agreed, it's a simple case, not the subnetted situation I drew.

> If I deactivate my internal NIC(wired) and configure WLAN as eth0
> everything works perfectly.

Hmmm.  Here's the converse: if the wired NIC is up as eth0, and you
activate the wireless NIC as eth1, the default route is still through eth0,
whether or not eth0 is plugged in.  Am I correct that eth0 still has the IP
address of 192.168.1.13?  If so, I think I have to conclude: that's not a
bug, that's a feature :-)  A NIC which is up, configured and broken (cable
unplugged) is still responsible for handling packets to the net it is on.

> But I want to keep both of them configured, only switching the assigning
> of the default gateway from eth0 to eth1 if WLAN is plugged in

If 2 NICs are configured on the same net, I imagine that the kernel routing
code picks one or the other according to implementation defined rules which
you can't influence.  That situation probably was not anticipated when the
code was designed.  The "right" solution is for the unused eth0 to be "up"
with an IP address of 0.0.0.0 -- this is what dhcpcd does before it has
been granted an IP address.  You might also investigate "trunking", but
I've never looked at it beyond reading the description in kernel
configuration.  It may or may not have automatic failover of some kind.

In my own setup, the internal NIC's driver is loaded and dhcpcd starts on
it, and then the wireless NIC's driver is loaded and another instance
of dhcpcd starts on it.  This way they consistently get their device IDs
eth0 and eth1.  When the cable is plugged in or when/if I'm in range of an
access point, one or the other dhcpcd gets an IP address and sets whatever
default route the DHCP server tells it.  When I want to use the other
interface, I eject the wireless NIC, or manually kill dhcpcd on the wired
NIC, and the card is taken down and the unuseable default route is removed
automatically.  I restart dhcpcd on the other NIC if I killed it before,
plug in the cable, and it takes off.

If someone has an idea how to reliably but unobtrusively recognize when a
NIC has lost its connection, I think that's what is really needed here.
And it would be a good addition to the dhcp client.  The problem would be
distinguishing a transient glitch (SIGNUKE, network traffic can no longer
be routed through Chicago) from a truly lost signal, because in the
latter case you want to bring the card down, murdering all open TCP/IP
connections, whereas in the former you want to keep the connections open
and hope the network comes back.


James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc at math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)