Wired and wireless connection to the same router cause confusion

network-manager 0.7~~svn20080928t225540+eni0-0ubuntu2~nm3~hardy1 ?
The Intrepid version of network-manager is 0.7~~svn20080908t183521+eni0-0ubuntu4...
Can you give us the result of 'aptitude show network-manager', please.

It is from "deb http://ppa.launchpad.net/network-manager/ubuntu hardy main".

Package: network-manager
State: installed
Automatically installed: yes
Version: 0.7~~svn20080928t225540+eni0-0ubuntu2~nm3~hardy1
Priority: optional
Section: net
Maintainer: Ubuntu Core Dev Team <email address hidden>
Uncompressed Size: 2044k
Depends: dbus (>= 0.60), hal (>= 0.5.7.1), iproute, iputils-arping, libc6 (>=
         2.4), libdbus-1-3 (>= 1.1.1), libdbus-glib-1-2 (>= 0.74), libglib2.0-0
         (>= 2.16.0), libhal1 (>= 0.5.8.1), libnl1, libnm-glib0 (>=
         0.7~~svn20080908), libnm-util0 (>= 0.7~~svn20080908), libnspr4-0d,
         libnss3-1d, libpolkit-dbus2, libpolkit2, libuuid1, lsb-base (>= 2.0-6),
         update-notifier-common, wpasupplicant (>= 0.6.1~)
Recommends: network-manager-gnome | network-manager-kde
Conflicts: network-manager-pptp (< 0.7~~)
Replaces: network-manager-pptp (< 0.7~~)
Description: network management framework daemon
 NetworkManager attempts to keep an active network connection available at all
 times. It is intended only for the desktop use-case, and is not intended for
 usage on servers. The point of NetworkManager is to make networking
 configuration and setup as painless and automatic as possible. If using DHCP,
 NetworkManager is _intended_ to replace default routes, obtain IP addresses
 from a DHCP server, and change nameservers whenever it sees fit.

 This package provides the userspace daemons.

 Homepage: http://www.gnome.org/projects/NetworkManager/

I've noticed the same thing occur (if I boot up with the ethernet cable attached network traffic is fine, however after unplugging and plugging the ethernet cable back in traffic is quite slow) using Intrepid and the following network-manager package version:

0.7~~svn20080908t183521+eni0-0ubuntu4

Attached is the output of ping'ing Launchpad.net after reconnecting the ethernet cable:

Here is /var/log/daemon.log covering the most recent boot and the period of time when the ethernet cable was disconnected and then connected again.

Here is the output of route -n after reconnecting.

I also used tcpdump to monitor both interfaces and saw ICMP echo requests leave one interface and the replies show up on another.

tcpdump for the other interface.

Here are files containing the output of route -n, the results of ping,
and packet traces for both interfaces after booting with an ethernet
cable attached and wireless connected.

The problem stems from the way the routes are set. In my case (two different subnets I am connected to , one wired at 192.168.2.0/24, eth0, and one wireless at 192.168.3.0/24, eth1), the routes get set as:

hggdh@xango2:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0
hggdh@xango2:~ $

So... there is a route specifically to 192.168.3.0/24, one for 192.168.2.0/24, and one *single* route to the world. So... when the plug is pulled from the single outside route, two things happen:

(1) any currently to-the world established connection is slowly fail: since there is a single outbound route, it will have, as a source IP, the local IP on the interface; since this IP is unrouteable elsewhere, it is probable that we will eventually get a timeout, but it is certain we will never leave the local node.

(2) the moment the interface is disconnected, n-m automagically resets the default route to the other interface. So *new* connections to-the-world will get the (new) source IP assigned to the surviving interface, and should work fine.

Although a good idea, the current implementation pretty much restricts usage to one single network (except for connections directed to one machine in the other network's address range).

I would be more useful (and increase survivability) if *any* of the networks could be used.

i have similar problem
only difference is im using 2 wired nics

also when unplugging one of the cables (phisicly) the connection becomes pretty much normal

I think the problem is because of the two default routes with the same destination isn't it?

This is the output of 'nl-route-dump detailed' after first booting with both the wired and wireless networks connected. Network traffic works normally under these circumstances.

This the output of 'nl-route-dump detailed' after disconnecting the wired connection and reconnecting it, so both the wired and wireless networks are connected. Network traffic is sluggish and ping replies are dropped under these circumstances.

Speaking with Alexandar Sack he believes this will be fixed with upstream commits 4156 and 4157 which will be available in Ubuntu soon.

http://svn.gnome.org/viewvc/NetworkManager/trunk/src/?view=log

On Wed, Oct 08, 2008 at 09:48:03PM -0000, Brian Murray wrote:
> Speaking with Alexandar Sack he believes this will be fixed with
> upstream commits 4156 and 4157 which will be available in Ubuntu soon.
>
> http://svn.gnome.org/viewvc/NetworkManager/trunk/src/?view=log

lets set to fixcommitted

 status fixcommitted

 - Alexander

This bug was fixed in the package network-manager - 0.7~~svn20081008t224042-0ubuntu1

---------------
network-manager (0.7~~svn20081008t224042-0ubuntu1) intrepid; urgency=low

  new upstream snapshot: Wed 2008-10-08 22:40:42 +0000 (bzrrev 3615) from
  lp:~vcs-imports/network-manager/main branch

  * fix LP: #277063 - routing randomness
  * fix save system settings feature for keyfile plugin
  * Fix LP: #278631 - NM output not going cleanly on console; we use
    /lib/lsb/init-functions to do proper logging
    - add debian/patches/lp278631-initscript-polishing.patch
    - update debian/patches/series
  * drop upstreamed patches:
    000-FIXCRASH-in-add_default_dhcp_connection.loom.patch,
    001-IFUPDOWN-wep-tx-keyidx.loom.patch, 002-IFUPDOWN-hostname.loom.patch
    - update debian/patches/series
    - delete debian/patches/000-FIXCRASH-in-add_default_dhcp_connection.loom.patch
    - delete debian/patches/001-IFUPDOWN-wep-tx-keyidx.loom.patch
    - delete debian/patches/002-IFUPDOWN-hostname.loom.patch
  * adjust patches to new upstream codebase
    - update debian/patches/003-IFUPDOWN-remove-unused-callbacks.loom.patch
    - update debian/patches/004-IFUPDOWN-devtracking.loom.patch
    - update debian/patches/005-IFUPDOWN-unmanaged-mode.loom.patch
    - update debian/patches/006-IFUPDOWN-parse-system-settings.loom.patch
    - update debian/patches/007-IFUPDOWN-managed-mode.loom.patch
    - update debian/patches/008-BACKEND-debian-fallback-to-generic-loopback.loom.patch

 -- Alexander Sack <email address hidden> Thu, 09 Oct 2008 16:13:09 +0200

this bug still exists. just upgraded to 8.10 today (30-Oct) and the wireless connection works ok to my router, but when i plug in the wire it goes dumb.

it stalls trying to get the router to assign a network address. i tried manually setting one which got me connected to the router, but no internet.

is there any info i should post?

collapse: at the very least I would think /var/log/syslog and the output of "ifconfig -a"

On Fri, Oct 31, 2008 at 01:52:42AM -0000, collapse wrote:
>
> is there any info i should post?
>
> ** Changed in: network-manager (Ubuntu)
> Status: Fix Released => Incomplete
>

Please open new bug with the info Chris asked for instead of opening
old bugs.

 status fixreleased

attach complete syslog after reproducing
attach ifconfig output when you are in the busted state
attach route output when you are in the busted state

 - Alexander

I was directed here by hggdh who posted above, I have filed another bug report that is the same as this current issue: https://bugs.launchpad.net/ubuntu/+bug/299284

Same here, when working on wireless and plugging in the wired internet, web pages won't load. I have to right click and uncheck wireless. That fixes it.