notoneofmyseeds wrote:
> "one ethernet interface that you sometimes connect to one wired network and 
> sometimes to a different wired network?"
> For now, this is a laptop that is located in one place.
> All networks are DHCP.

Those are good clarifications.  Let me mention a few problems to be
overcome with it.

DHCP is the Dynamic Host Configuration Protocol that configures a
network interface.  Among the things it configures is the default
gateway router.

  $ ip route show | grep ^default
  default via 93.184.216.34 dev eth0

Normally there will be one interface active at a time configured with
DHCP.  Therefore there will be one default route.  However if you have
several interfaces configured with DHCP all active at the same time
then each interface will configure a default route.  Let me write this
contrived example showing the problem.

  $ ip route show | tac | grep ^default
  default via 93.184.216.34 dev eth0
  default via 93.184.216.34 dev eth1
  default via 93.184.216.34 dev wlan0

Or maybe:

  $ ip route show | tac | grep ^default
  default via 93.184.216.34 dev eth1
  default via 93.184.216.34 dev eth0
  default via 93.184.216.34 dev wlan0

Or maybe:

  $ ip route show | tac | grep ^default
  default via 93.184.216.34 dev wlan0
  default via 93.184.216.34 dev eth1
  default via 93.184.216.34 dev eth0

The order of the default routes is important because the first one
matched is the one used.  The order is set by the last one
configured.  The last interface to have dhcp'd an address will set a
default route and it will be the first one matched.

Also note that until recently the kernel listed routes in top-down
order.  The first route matched as displayed from the top-down was the
one that matched.  This was true of *BSD and SystemV and others.
Newer Linux kernels since some version I forget have unfortunately
reversed this order.  Now the Linux kernel lists routes in bottom-top
priority listing.  I think that is simply a bug but so it is.  I often
pipe the output of ip route show through 'tac' to reverse the order in
order to get a sane top-bottom ordering.  That is why I have tac in
the above.  To make it display in the Right order.

There is an old saying that goes, "... if you have to ask then ..."
which applies here.  If you don't know and have to ask about default
routes then you should only ever have *one* default route on the
system.  There are only some few special cases where it would be
otherwise.  One default route normally makes the most sense.

Another question: When you are connected to both as you have done what
is the output of these commands so that we can see the (as you say
broken) state of things?

  ip addr show

  ip route show | tac

================

Another question.  Are all of the subnets on each of the networks
different?  A subnet is something like 192.168.1.0/24.  For example
having different subnets would mean 192.168.1.0/24 on one and
192.168.20.0/24 on another and 192.168.42.0/24 on the third.  All
different.

Along with the default route every IP address assigned will create a
route in the route table for that subnet.

  $ ip route show | tac
  192.168.230.0/24 dev eth0  proto kernel  scope link  src 192.168.230.120 
  default via 192.168.230.1 dev eth0 

Routes match top to bottom (in the sane ordering after reversing them
with tac to restore the order to the way other kernels report it) and
therefore addresses on the local subnet are matched before the default
route.  For example in the above an address 192.168.230.27 would match
on the local subnet and would be routed directly using the listed src
address of the host.  Addresses such as 8.8.8.8 would fall through all
of the routes until hitting the default route at the bottom and would
then be routed through the default route to the router and out to the
Internet.

A more complicated routing table could be this example.  Routes are
matched from the top down and the first one matched indicates which
interface the packet is routed through.

  $ ip route show | tac
  216.17.153.56/29 dev eth0  proto kernel  scope link  src 216.17.153.62 
  192.168.240.0/24 dev eth0  proto kernel  scope link  src 192.168.240.1 
  192.168.230.0/24 dev eth1  proto kernel  scope link  src 192.168.230.1 
  192.168.94.0/24 dev eth2  proto kernel  scope link  src 192.168.94.1 
  192.168.93.0/24 dev wlan0  proto kernel  scope link  src 192.168.93.1 
  172.27.61.2 dev tun0  proto kernel  scope link  src 172.27.61.1 
  172.27.61.0/24 via 172.27.61.2 dev tun0 
  default via 216.17.153.57 dev eth0 

Normally it is important to ensure that every interface has a
different subnet so that routing is sane.  A typical problem is that
people don't think about this and then set up the same subnet on
multiple different interfaces.  If that happens the result is order
dependent depending upon the order the interfaces were brought up.
Things usually don't work very well.

================

Now that you have learned this I have another question.  Which
interface do you wish to keep as the default route?

================

In my experience NetworkManager and wicd try to keep one network
online at a time.  When a better network becomes available, say a
wired network, then they disconnect from the previous and connect to
the better one.  Normally that is exactly what you want to have
happen.  If it isn't then special things need to be done to change the
behavior.  Being connected to several different subnets at the same
time isn't a problem as long as the default route issue is handled
appropriately.

================

So...  There are the problems.  If you have different subnets on each
of the three interfaces then things should be possible to work.
However if you use DHCP on each then each will want to set a default
route when you really want to only have one default route.  I have
never had your particular task and do not know how to accomplish that
result.  I believe there are ways to override the default behavior
through configuration, hook scripts, other modifications.  There are
probably several different ways to do it some better and some worse.

Perhaps someone else on the mailing list will have additional
suggestions.  Hopefully they will be better than my poor contributions
here.

> Would I need to remove network manager to use the guessnet option?

No.  Because guessnet uses explicit configuration in the file
/etc/network/interfaces and therefore NetworkManager will ignore that
interface.  The programs will ignore each other.

> ...and not to make matters any complicated, would guessnet allow me to
> be connected to the wifi and Ethernet at the same time, without

Yes.  Because guessnet uses ifupdown /etc/network/interfaces
configuration and ifupdown is designed to handle multiple active
network devices.

> loosing access to the Internet? It is the case now that if I connect
> with both, I loose Internet and can only access the local network.

I think it likely that you have a default route problem which is why I
explained it in as much detail as I could above.

You say "without loosing access to the Internet" and that triggers me
to think maybe you are wanting something different yet.  Normally when
switching from one interface to another active connections will be
broken, will eventually reset, and will need to be re-established.

I hesitate to mention it but there are advanced configurations where
multiple interfaces are bonded together (trunked) such that networking
will fallback to the active interface.  I haven't set this up but
friends of mine have used that configuration to bond the wired and
wireless devices together so that networking will be continuous as
long as one or the other remain online.  Plus there are VPN solutions,
which I have implemented, that allow connections to be continuous over
the VPN as the underlying host networking is changed.  I hesitate to
mention these because those configurations are not simple and crank up
the complexity significantly.  However having mentioned them perhaps a
kind soul on the mailing list will be operating with such a
configuration and perhaps would show us their setup for it.

Bob

Attachment: signature.asc
Description: Digital signature

Reply via email to