Re: Bug#661056: please re-open Bug#610553: installation-reports: does not cleanly deconfigure network configured with DHCP

[Jeffrey Sheinberg <jeff@bsrd.net>]

On Wed, Jan 02, 2013 at 07:47:00PM +0100, Cyril Brulebois wrote:
> Control: tag -1 moreinfo
> 

...

> netcfg has the following finish-install script:
> ,---[ finish-install.d/97release-dhcp-lease ]---
> | #!/bin/sh
> |
> | set -e
> |
> | pid=$(pidof udhcpc) || true
> | [ -n "$pid" ] && kill -USR2 $pid
> |
> | if [ "$(pidof dhclient || true)" ]; then
> | 	dhclient -r || true
> | 	dhclient -6 -r || true
> | fi
> `---
> 
> which seems to match what you proposed in #610553:
> | Solution - please send SIGUSR2 to the "udhcpc" process at end of
> | installation (menu items: finish up the installation, or abort the
> | installation).
> 
> AFAICT, $(pidof udhcpc) works, and the script quoted above looks
> reasonable. From a quick strace, it looks like udhcpc is properly
> releasing the lease on SIGUSR2.
> 
> Any chance you could catch a network trace during the end of
> installation, and one on normal shutdown? To make sure DHCPRELEASE
> happens properly, you could also compare to a network trace when
> calling “kill -USR2 $(pidof udhcpc)” from a console after you obtained
> a lease.

Hi Cyril,

I recently installed wheezy-7.0.0, for the following versions of Debian,
and the results for this are,

    GNU/Linux amd64 - this bug is still occurring (install was completed).

    GNU/kfreebsd amd64 - this bug did not occur after network had been
    detected successfully, (install aborted by C-A-Delete - couldn't get
    past recognize disks).  Note - I think that GNU/kfreebsd maybe uses
    dhclient rather than udhcpc.

perhaps something weird is happening with the "kill -USR2 $pid".

Since I had to do something to get my internet connection up after
installing "GNU/Linux amd64", here is what I did to have udhcpc release
the lease,

    udhcpc -n -q -R -r <ipv4-address>

on my production wheezy system.  Then I just ran "ifup eth0" and my
internet access had been restored.

As far as a network trace is concerned, I reget that I cannot do this
for you, as I have just a single PC to work with.

I *know* that the lease is released after I ran "udhcpc -n -q -R -r
<ipv4-address>", because udhcpc says so - actually udhcpc first
(re)acquires the lease for the specified <ipv4-address>, and then
immediately releases it.  If the lease had not been outstanding, then
udhcpc would not have been able to (re)acquire it, because this policy is
strictly enforced by my ISP.

I am not familiar with the D-I environment under which busybox udhcpc is
being run, so I cannot comment on the code snippet that you provided.  I
do have udhcpc package installed on my production system, it may be
running different up / down scripts then those that are being run in the
D-I environment.

In closing, I am able to reliably reproduce this reported bug at will.

Can't you just print something like "ip addr show" *after* netcfg has
been called in order to see what is happening here?

Thanks,
-- 
Jeffrey Sheinberg