New networkmanager null assert in Hardy

Bug #227819 reported by Marc MERLIN
8
Affects Status Importance Assigned to Milestone
NetworkManager
Won't Fix
Low
network-manager (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

This problem started happening after upgrading from gutsy to hardy:
When I unplug my ethernet cable:
May 7 08:39:34 gandalf kernel: tg3: eth0: Link is down.
May 7 08:39:34 gandalf NetworkManager: <info> SWITCH: terminating current connection 'eth0' because it's no longer valid.
May 7 08:39:34 gandalf NetworkManager: <info> Deactivating device eth0.
May 7 08:39:34 gandalf avahi-daemon[4206]: Withdrawing address record for 192.168.205.2 on eth0.
May 7 08:39:34 gandalf avahi-daemon[4206]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.205.2.
May 7 08:39:34 gandalf avahi-daemon[4206]: Interface eth0.IPv4 no longer relevant for mDNS.
May 7 08:39:34 gandalf NetworkManager: nm_device_is_802_3_ethernet: assertion `dev != NULL' failed
May 7 08:39:34 gandalf NetworkManager: nm_device_is_802_11_wireless: assertion `dev != NULL' failed

Revision history for this message
Gezim Hoxha (hgezim) wrote :

I'm getting the exact same issue:

Jun 14 22:58:48 gezim-laptop kernel: [ 1641.898529] tg3: eth0: Link is down.
Jun 14 22:58:48 gezim-laptop NetworkManager: <info> SWITCH: terminating current connection 'eth0' because it's no longer valid.
Jun 14 22:58:48 gezim-laptop NetworkManager: <info> Deactivating device eth0.
Jun 14 22:58:48 gezim-laptop dhclient: There is already a pid file /var/run/dhclient.eth0.pid with pid 7928
Jun 14 22:58:48 gezim-laptop dhclient: killed old client process, removed PID file
Jun 14 22:58:48 gezim-laptop dhclient: wmaster0: unknown hardware address type 801
Jun 14 22:58:48 gezim-laptop dhclient: wmaster0: unknown hardware address type 801
Jun 14 22:58:48 gezim-laptop dhclient: DHCPRELEASE on eth0 to 192.168.0.1 port 67
Jun 14 22:58:48 gezim-laptop avahi-daemon[5292]: Withdrawing address record for 192.168.0.102 on eth0.
Jun 14 22:58:48 gezim-laptop avahi-daemon[5292]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.102.
Jun 14 22:58:48 gezim-laptop avahi-daemon[5292]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 14 22:58:49 gezim-laptop avahi-daemon[5292]: Withdrawing address record for fe80::20f:1fff:fe1e:240d on eth0.
Jun 14 22:58:49 gezim-laptop NetworkManager: nm_device_is_802_3_ethernet: assertion `dev != NULL' failed
Jun 14 22:58:49 gezim-laptop NetworkManager: nm_device_is_802_11_wireless: assertion `dev != NULL' failed

This is after I followed the instructions in http://linuxwireless.org/en/users/Drivers/b43#fw-b43-old.

Revision history for this message
Andreas Moog (ampelbein) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* What version of Network-manager are you running?
* Does this still happen to you?

Thanks in Advance.

Changed in network-manager:
assignee: nobody → andreas-moog
status: New → Incomplete
Revision history for this message
Marc MERLIN (marc-soft) wrote :

Still happening, yes
ii network-manage 0.6.6-0ubuntu5 network management framework daemon

Revision history for this message
Andreas Moog (ampelbein) wrote :

And what does the syslog look like when you plug the cable back in?

Revision history for this message
Marc MERLIN (marc-soft) wrote :
Download full text (9.5 KiB)

No errors or problems.

Aug 17 07:21:50 gandalf kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 17 07:21:50 gandalf kernel: tg3: eth0: Flow control is on for TX and on for RX.
Aug 17 07:21:50 gandalf kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 17 07:21:50 gandalf NetworkManager: <info> Will activate wired connection 'eth0' because it now has a link.
Aug 17 07:21:50 gandalf NetworkManager: <info> SWITCH: no current connection, found better connection 'eth0'.
Aug 17 07:21:50 gandalf NetworkManager: <info> Will activate connection 'eth0'.
Aug 17 07:21:50 gandalf NetworkManager: <info> Device eth0 activation scheduled...
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) started...
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Aug 17 07:21:50 gandalf NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Aug 17 07:21:51 gandalf NetworkManager: <info> Activation (eth0) Beginning DHCP transaction.
Aug 17 07:21:51 gandalf NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Aug 17 07:21:51 gandalf NetworkManager: <info> DHCP daemon state is now 12 (successfully started) for interface eth0
Aug 17 07:21:51 gandalf dhclient: There is already a pid file /var/run/dhclient.eth0.pid with pid 134519072
Aug 17 07:21:51 gandalf dhclient: wmaster0: unknown hardware address type 801
Aug 17 07:21:51 gandalf avahi-daemon[6156]: Registering new address record for fe80::216:36ff:feff:8085 on eth0.*.
Aug 17 07:21:53 gandalf dhclient: wmaster0: unknown hardware address type 801
Aug 17 07:21:53 gandalf NetworkManager: <info> DHCP daemon state is now 1 (starting) for interface eth0
Aug 17 07:21:56 gandalf dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
Aug 17 07:21:56 gandalf dhclient: DHCPOFFER of 192.168.205.2 from 192.168.205.254
Aug 17 07:21:56 gandalf dhclient: DHCPREQUEST of 192.168.205.2 on eth0 to 255.255.255.255 port 67
Aug 17 07:21:56 gandalf kernel: IN=eth0 OUT= MAC=00:16:36:ff:80:85:00:90:27:79:49:2f:08:00 SRC=192.168.205.254 DST=192.168.205.2 LEN=335 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=315
Aug 17 07:21:56 gandalf dhclient: DHCPACK of 192.168.205.2 from 192.168.205.254
Aug 17 07:21:56 gandalf kernel: IN=eth0 OUT= MAC=00:16:36:ff:80:85:00:90:27:79:49:2f:08:00 SRC=192.168...

Read more...

Revision history for this message
Andreas Moog (ampelbein) wrote :

So basically your only problem is the message appearing? Or do you have an issue with using your network?

Revision history for this message
Marc MERLIN (marc-soft) wrote :

from what I can tell, the networking pieces are working, unless I'm missing a side function that networkmanager was supposed to provide before it finds its null assert.
Honestly, I didn't look at the code, I'm hoping the programmer didn't put NULL assert statements in there if they aren't important, but maybe they aren't. I'll leave that up to you to decide/find out/push upstream.

Revision history for this message
Andreas Moog (ampelbein) wrote :

I will report this bug upstream even though the network seems to be fully functional. But there should not be "Null asserts" without a reason.

Changed in network-manager:
assignee: andreas-moog → nobody
status: Incomplete → Confirmed
Changed in network-manager:
status: Unknown → New
Revision history for this message
C de-Avillez (hggdh2) wrote :

marking as triaged. Reasoning is sound.

Changed in network-manager:
status: Confirmed → Triaged
Changed in network-manager:
status: New → Confirmed
Andreas Moog (ampelbein)
Changed in network-manager:
assignee: nobody → desktop-bugs
importance: Undecided → Low
Revision history for this message
Davias (davias) wrote :

Same problem:

 NetworkManager: <info> SWITCH: terminating current connection 'eth0' because it's no longer valid...

And it's happening every minute! This because I looked in the logs after I started having serious problems.

In fact as soon as I start to increase the loads on the LAN eth0 crash and then it's up again.
It will do that with VNC, copying a large file or streaming video.

My LAN (CAT5 100Mbps) is very simple:
Ubuntu 7.10 PC
Ubuntu 8.04 PC
Pirelli router on adsl as DHCP

And it all started after an auto-upgrade of something, could not recall, but very recent... before everything was fine

Revision history for this message
Magnus Wissler (gmw) wrote :

*bump* :-)

Second the previous comment about traffic being relevant; I recently clean-installed 8.10 (with network-manager) on an old box. Sure enough, as soon as I started transferring larger amounts of data across the network (be it streaming or copying large files), network-manager thinks the network card (eth0, in my case) link goes down repeatedly.

When copying a large file (it's on a 100 Mbps switch) this happens every 1 to 30 seconds. When streaming video on the other hand, it happens every 2 to 15 MINUTES. So it definitely seems related to the amount of traffic going through the network card.

Uninstalling network-manager and configuring /etc/network/interfaces myself fixed it. I haven't had a single "eth0: link down" in my log since uninstalling network-manager.

For reference, here's my current (working)/etc/network/interfaces (though the ppp0 is obviously not relevant here):

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

iface ppp0 inet ppp
provider ppp0

auto ppp0

Revision history for this message
Marc MERLIN (marc-soft) wrote :

My recommendation at this point is apt-get remove networkmanager and try wicd or just nothing, it's become even worse in intrepid:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/303476

Revision history for this message
Marc MERLIN (marc-soft) wrote :

As an update, network-manager now finally works again in karmic, no more of those various random crashes and non handling of my network interfaces. Documentation is still poor, but at least it works.
So, after around 2 years in being broken in various ways in each release after dapper, it seems to finally behave for me and do what it was supposed to.

Not a moment too soon I suppose, although it doesn't close this bug for those sticking with hardy since it's LTS.

Changed in network-manager:
importance: Unknown → Low
status: Confirmed → Won't Fix
Thomas Hood (jdthood)
Changed in network-manager (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.