Network unreachable with Edgy

Confirm this problem with Edgy knot3 upgraded from Dapper. Can't get an IP for eth0, message is same as "send_packet: Message too long".

$lspci | grep Ethernet
00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller

$lsmod | grep nat*
natsemi 30112 0

And, "sudo dhclient wlan0" (zd1211) is OK to get an IP, however there is "SIOCSIFMTU: Invalid argument" message.

eth0 Link encap:Ethernet HWaddr (...)
          UP BROADCAST MULTICAST MTU:64 Metric:1
          RX packets:70 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9191 (8.9 KiB) TX bytes:1200 (1.1 KiB)
          Interrupt:5 Base address:0x4000

wlan0 Link encap:Ethernet HWaddr (...)
          inet addr:10.0.0.19 Bcast:255.255.255.255 Mask:255.255.255.0
          inet6 addr: fe80::213:49ff:fe22:feed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:5485 errors:120 dropped:0 overruns:0 frame:120
          TX packets:3512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7197061 (6.8 MiB) TX bytes:372786 (364.0 KiB)

eth0 is fine to get IP while booted from a live CD I have (5.04), and piece of info, during "sudo dhclient eth0" I can't see "sent packet count" increased with Gnome Network Monitor so seems no packets are sent for dhcp, because of the "send_packet: Message too long" message ? Only ping packets were sent at the end of dhcp'ng, I'd checked both within lease term and after lease term, several times FYI.

I saw, from the net, natsemi kernel driver changed for 2.6.17, but unsure it's one of possible reasons causing this problem.

I have the same problem now with edgy (upgraded from dapper around knot3), in dapper this used to work fine. On my home network dhcp fails with "Message too long".

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
send_packet: Message too long

I tried to look at the traffic with wireshark but not even a single packet was sent. This felt a bit weird, but the reason was simple: interface mtu was set to 64, so a single dhcp query packet was too large. If I set the interface mtu by hand (ifconfig eth0 mtu 1400) and then tried to obtain an address it worked fine but it reset the mtu back to 64, which is not good. However, everything was working as expected because dhclient was asking for interface mtu and the crappy adsl-router returned mtu=64 (confirmed with wireshark).

It is not possible to change the mtu-value returned by the adsl-router, so dhcp must be set to not ask the mtu (edit /etc/dhcp3/dhclient.conf and remove "interface mtu" from "request" line). This way default mtu will be used and the network works fine.

I assume this config change for dhcp was done after dapper as my network used to work fine then? If the setting is left as it is now (dhcp3-client version 3.0.4-6ubuntu5), there will be many with non-working networks. Those A-Link Roadrunners (model 44E for me, but I doubt the problem exists only for a single model) are very common here at least as ISPs have been giving them for new customers.

A bit of additional data about the "interface mtu" request and debian/ubuntu dhcp3 packages:

The setting was disabled during hoary (from changelog):

dhcp3 (3.0.1-1ubuntu4) hoary; urgency=low
  * Revert changes to debian/dhclient.conf, apparently at least some DHCP servers supply broken interface-mtu information, so this isn't safe to enable without broader testing (Ubuntu #8241)

Then the request was enabled in debian and imported to ubuntu:

dhcp3 (3.0.4-6) unstable; urgency=high
  * debian/dhclient.conf: also request the interface-mtu setting (closes: #372689)

The closed bug is a mere wishlist bug, not fixing any actual use case. So I'd suggest the "interface mtu" request is removed because of (very real) potential of still causing breakage.

Manually changing mtu works for me too.

I can confirm this bug with the Edgy beta release. I upgraded a Dapper box to Edgy on the day of the beta release, and lost wired Internet connectivity. The fix of manually editing dhclient.conf worked for me.

Some info:

Before applying the dhclient.conf fix, if I set the network card to connect via DHCP, I could not ping either my router or www.google.com, receiving 'unknown host' in response to each.

If I set the network card to a static IP and gave the routers address as gateway, then I got response when ping'ing the router, but still 'unknown host' when ping'ing google.

I then ran 'sudo dhclient eth0', and got this output. I could see that it was sending out DHCPREQUEST's and was receiving 'send_packet: Message too long'. Whether this came from the router or a local process I don't know. dhclient then found a previous and still valid dhcp lease and tried that, ping'ed the router successfully. I could then ping my router, google.com, or ubuntu.com, but I could not get any web pages (including google and ubuntu) in my web browser. I will attach the output of this dhclient run.

Next, I removed "interface mtu" from "request" line in /etc/dhcp3/dhclient.conf as Jarmo suggests. I also did 'sudo ifconfig eth0 mtu 1400'. Then ran dhclient again, it receives a new dhcp lease, Internet connection is fine, I'm now filing this bug report online. I will attach output from the successful dhclient run also, and info about my network card and configuration.

The router I am using is a Q-TEC 584AA ADSL modem & 4 port router. Item no. 13565: http://www.qtec.info/products/hirespics.htm?artnr=13565

The Internet connection that I gained soon disappeared and on running dhclient again I got the message too long error again, I had to change the mtu with ifconfig again and then run dhclient again, to once again successfully get a connection.

The attached file contains outputs from various commands, separated by:

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

I got this exact same problem with another machine after upgrading to edgy, when connecting via the same modem. The same solution works. I'm guessing from Jarmo's comments that it's the router, not the machine, that matters, so I won't post any details about this machine.

I think it is not a router problem. On the same router at home, Edgy works on my computer while it doesn't works on my laptop.
   But the same laptop that has the bug at home has no problem at university.
   It should be a combination of the router and the internal network card.

It is definitely a router dependent problem which happens when DHCP asks for interface-mtu and the router reports some too low value (which is 64 in all ifconfig outputs attached to this report). A simple way to check if this is the problem, and not something else, is to check what "ifconfig" says for the MTU value after DHCP has asked the address. MTU is 1500 by default, but anything over 576 is ok, lower than that can cause problems.

Moky, if one computer with edgy works ok with that router and another not, maybe you have set up the network with static IP in the computer which works? In that case DHCP would have no chance to set the MTU to wrong value. Network card or driver should have no effect to this...

Anyway, the best way to fix this is to remove "interface-mtu" from /etc/dhcp3/dhclient.conf request-line and reboot the computer (so that MTU is reset to default value). And some ubuntu dev should do that for the dhcp3-client package so that we won't have to take a count how many ~broken routers there are in the world ;)

Right, we have the bug confirmed by multiple people, and we have a
solution confirmed by multiple people, we should people to get a patch
committed for this now!

--
<email address hidden>
SDF Public Access UNIX System - http://sdf.lonestar.org

I confirm the fact that I have two DHCP computers on the same router. The one has the bug while the orther has not.
   However the proposed solution works.

  Thanks you. Without your help, I would still be on Dapper ;)

Laurent