Taking eth0/wlan0 down in g-s-t deconfigures the loopback interface?

[Matthew East]

If I take either one of my network devices down (wlan0, eth0) and then bring
them up again using the "deactivate" and "activate" functions in network-admin,
bad things begin to happen. This problem does not occur if I do a simple
"/etc/init.d/networking restart". The problems are as follows:

Opening the following programs doesn't work: firefox, rhythmbox, network-admin,
gnome-terminal, and probably others. Evolution takes 5 minutes or more before it
opens. I can't log out of gnome, and if I kill the xserver and log back in, it
stalls.

I've tried killing every single process I can think of (gnome-settings-daemon,
gnome-sm-proxy etc etc) and nothing helps. Only a restart does the trick.

Obviously this is a major problem.

I installed the system at array 5 and it is up to date.

Hope this is a fault my end!!

Matt

[Matthew East (mdke)]

sorry got priority wrong

[Matt Zimmerman (mdz)]

Can you check whether the loopback interface (lo) is being affected?

[Matthew East (mdke)]

Please could you explain a bit more what information you need about the loopback
device? Many thanks

M

[Matt Zimmerman (mdz)]

Whether the interface status (up/down) or configuration is changed as a result
of your actions

[Matthew East (mdke)]

Ah wonderful you have tracked it down.

ifconfig lo tells me that lo is up and running. However I can't ping myself.

ifdown lo, ifup lo solves the problem.

I hope this will make this bug easy to fix :)

[Carlos Garnacho (carlosg)]

Just for the record, network-admin tries to leave the loopback interface
untouched, and I wasn't able to reproduce this, please could you tell whether
the loopback interface has an IP address when you say it's up and running and
paste the localhost line(s) in the /etc/hosts file?

thanks

[Matthew East (mdke)]

hi thanks for your reply.

You are right I have misled you: in fact the lo device does NOT have an inet
address after I deactivate and reactivate my network card in network-admin. When
I do "ifdown lo, ifup lo", then it acquires it and things start working again.

The line in hosts is:

127.0.0.1 localhost.localdomain localhost kallisto

thanks, hope this helps to sort the problem out.

M

[Matt Zimmerman (mdz)]

Please do this test:

- Reboot the system
- Check that the loopback interface is up and has an IP of 127.0.0.1
- Ping 127.0.0.1 to verify
- Reproduce the original problem using gnome-system-tools
- Check the configuration of the loopback interface again

[Matthew East (mdke)]

I thought I'd reported doing all of those things in this bug already, but
perhaps I haven't made it clear. I am writing this in real time, i.e. as I do it.

1. Reboot, fine

2. ifconfig lo shows

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:2696 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2696 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:135276 (132.1 KiB) TX bytes:135276 (132.1 KiB)

3. ping localhost, 127.0.0.1, kallisto all work fine.

4. network-admin, deactivating wlan0 and reactivating it.

5. Problem is repeated: Many programs take around 5 minutes to load. However,
the programs that were ALREADY open before reproducing the problem are running
fine, hence firefox (this window), evolution and gnome-terminal are working ok.

6. ifconfig lo now reads:lo Link encap:Local Loopback
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:2703 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2703 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:137016 (133.8 KiB) TX bytes:137016 (133.8 KiB)
7. Pinging myself gives:

matt@kallisto:~$ ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.

--- localhost.localdomain ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11001ms

8. Resolution:
$ sudo ifdown lo
$ sudo ifup lo

matt@kallisto:~$ ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.069 ms

It seems relatively clear that network-admin is messing up my lo device and
gnome can't find my hostname right? Hope this helps.

yours, Matt

[Hal Finkel (hal-finkel)]

I have exactly the same problem with a clean Hoary install (updated to the
latest package versions). Additionally, I believe this to be the cause of bug
14187 (as the lack of a valid ipv4 loopback caused the cups daemon to fail to start).

[Matt Zimmerman (mdz)]

This needs to be fixed for Hoary. Carlos, is there anything more we can do to
assist?

[Hal Finkel (hal-finkel)]

As far as I can tell, the following happens when an interface is activated from
the network-admin application:

network-admin calls /usr/share/setup-tool-backends/scripts/network.pl
which executes a command similar to:
LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /sbin/dhclient -pf /var/run/dhclient.ra0.pid
-e ra0 2> /dev/null > /dev/null
which calls /etc/dhcp3/dhclient-script with reason=PREINIT and interface=lo (it
seems to call dhclient-script with reason=PREINIT for every interface on the
system, and this just so happens to include the loopback interface).
dhclient-script then issues the command:
ifconfig lo 0 up
which removes the IPv4 address 127.0.0.1 from the loopback interface.

I am running kernel 2.6.10-5-686 and have dhcp3-client and dhcp3-common package
version 3.0.1-1ubuntu1.

[Carlos Garnacho (carlosg)]

Created an attachment (id=1848)
Patch to fix this

Ok, found the problem (Thanks Hal for helping)

The dhclient v2. (In the debian package dhcp-client) uses -e behaving correctly
inside shell scripts, returning errors and so if it couldn't configure the
interface, in dhclient v3. -e is used for passing envvars to the dhclient
internal environment.

I couldn't find any equivalence for this in the version 3 client, so the
behavior might be a bit broken if there isn't a correctly configured dhcp
network for the interface (dhclient3 will simply use the last assigned IP
address, which might not be what the user desires), but anyway it will be less
broken that how it's now :)

This patch is already in GST CVS

[Sebastien Bacher (seb128)]

thanks for the patch Carlos. This upload fixes the issue:

 system-tools-backends (1.2.0-0ubuntu4) hoary; urgency=low
 .
   * debian/patches/07_dhcp3.patch:
     - fix an issue with the loopback due to dhcp3 (Hoary: #7602).