madwimax stops dhclient non-gracefully, leaving behind invalid nameserver addresses

Please show the contents of /run/resolvconf/interface/ on the affected system.

$ cd /run/resolvconf/interface/
$ ls *
wimax0.dhclient wlan0.dhclient
$ for f in *; do echo "=== $f ==="; cat "$f"; echo; done
=== wimax0.dhclient ===
nameserver 94.25.128.74
nameserver 94.25.208.74

=== wlan0.dhclient ===
nameserver 192.168.129.129
nameserver 8.8.8.8

Actually these servers left from my last wimax connection, I missed that file :(
Mmm… anyway, why are they added to resolv.conf?
I have wimax device plugged out:

$ ifconfig wimax0
wimax0: error fetching interface information: Device not found

When correct servers disappear from /etc/resolv.conf, the file /run/resolvconf/interface/wlan0.dhclient vanishes too.

> Actually these servers left from my last wimax connection, I missed that
> file :(
> Mmm… anyway, why are they added to resolv.conf?

Well, because that's how resolvconf works; when a network interface comes up, and that interface provides nameserver information, it gets added to /etc/resolv.conf. But the question then is, why is it still there if your interface is disconnected? Was the interface brought up using ifupdown, or by some other method? Was there a dhclient process left running for the wimax interface after the interface itself went away?

I use madwimax to connect that modem, I do not use ifup/ifdown at all. Both ifup and ifdown respond smth like «ignoring unknown device wimax0». When I'm done with my wimax network, I just unplug the modem from the usb port without manual invocation of any command.

There is no dhclient for wimax in the process list.
However there are lots of dhclients for wlan0, I'm surprised:

# ps aux|grep dhcl
root 461 0.0 0.0 7256 672 ? Ss May03 0:00 /sbin/dhclient -v wlan0
root 1037 0.0 0.0 7256 1076 ? Ss 00:25 0:00 dhclient wlan0
root 1917 0.0 0.0 7256 1080 ? Ss 00:26 0:00 dhclient wlan0
root 2896 0.0 0.0 7256 1080 ? Ss 00:28 0:00 dhclient wlan0
root 3125 0.0 0.0 7256 612 ? Ss 09:14 0:00 /sbin/dhclient -v wlan0
root 5662 0.0 0.0 7256 1076 ? Ss 00:31 0:00 /sbin/dhclient -v wlan0
root 5844 0.0 0.0 7256 1076 ? Ss 00:31 0:00 dhclient wlan0
root 6000 0.0 0.0 7256 1076 ? Ss 00:31 0:00 dhclient wlan0
root 8735 0.0 0.0 7256 672 ? Ss Apr29 0:02 /sbin/dhclient -v wlan0
root 9921 0.0 0.0 7256 672 ? Ss Apr29 0:02 /sbin/dhclient -v wlan0
root 10393 0.0 0.0 7256 660 ? Ss Apr29 0:02 /sbin/dhclient -v wlan0
root 12605 0.0 0.0 9344 928 pts/8 S+ 11:02 0:00 grep --color=auto dhcl
root 13280 0.0 0.0 7256 616 ? Ss 09:26 0:00 dhclient wlan0
root 14263 0.0 0.0 7256 1076 ? Ss 00:43 0:00 dhclient wlan0
root 17101 0.0 0.0 7256 1076 ? Ss May03 0:00 /sbin/dhclient -v wlan0
root 17651 0.0 0.0 7256 1080 ? Ss May03 0:00 dhclient wlan0
root 23960 0.0 0.0 7256 1080 ? Ss 00:13 0:00 /sbin/dhclient -v wlan0
root 24726 0.0 0.0 7256 1072 ? Ss 00:58 0:00 /sbin/dhclient -v wlan0
root 25175 0.0 0.0 7256 1080 ? Ss 00:58 0:00 dhclient wlan0
root 26028 0.0 0.0 7256 1080 ? Ss 00:15 0:00 dhclient wlan0
root 27123 0.0 0.0 7256 276 ? Ss Apr30 0:02 /sbin/dhclient -v wlan0
root 30309 0.0 0.0 7256 1072 ? Ss 07:37 0:00 /sbin/dhclient -v wlan0
root 32204 0.0 0.0 7256 1080 ? Ss 00:24 0:00 dhclient wlan0

And again now wlan0.dhclient has disappeared, while wimax0.dhclient is present…

> When I'm done with my wimax network, I just unplug the modem from the usb port without manual invocation of any command.

The dhclient process for your wimax interface adds nameserver addresses to the system (via resolvconf) that are accessible over the wimax interface. When the wimax interface is disabled, those nameserver addresses should be removed. If dhclient doesn't do this automatically you may have to help it by stopping the process gracefully. See dhclient(8), especially the part about the -r and -x options.

What's mysterious about the behavior your originally reported is (IIUC) that the dhclient process for wlan0 adds nameserver addresses and then removes them a few seconds later. Have you figured out why this happens?

Sounds like this is probably an issue with madwimax not integrating with resolvconf or not handling dhclient correctly on disconnect.

Okay… now I rebooted, and resolvconf with wlan0 works fine. When I'm at the area with wimax, I'll test madwimax again.

I didn't find out, why did wlan0.dhclient disappear, after reboot this error has gone. May be it was some conflict of these many dhclients somehow launched at the same time…

The file wlan0.dhclient now does not disappear.Seems, that annoying bug does not affect me anymore.

Anyway, I have the file wimax0.dhclient still existing, even though my wimax modem is plugged off with no dhclient left for wimax0, and no madwimax process running:

$ ps aux | egrep '(dhcl|wimax)'
root 5236 0.0 0.0 7256 608 ? Ss 20:02 0:00 /sbin/dhclient -v wlan0
gluk47 12679 0.0 0.0 9336 924 pts/3 S+ 20:14 0:00 egrep --color=auto (dhcl|wimax)
$ cd /run/resolvconf/interface
$ ls *.dhclient
wimax0.dhclient wlan0.dhclient

Seems, it's really madwimax problem, it should tell dhclient to remove this file when it's no longer needed.

Egor: Thanks for the additional information.

The culprit is /etc/madwimax/event.sh which doesn't stop dhclient gracefully. Here's a snippet showing the handling of dhclient3 and dhclient (version 4).

[...]
if-up)
        if [ -x /sbin/dhclient3 ]; then
                /sbin/dhclient3 -nw -pf /var/run/dhclient."$2".pid -lf /var/lib/dhcp3/dhclient."$2".leases "$2" >/dev/null 2>&1
        elif [ -x /sbin/dhclient ]; then
                /sbin/dhclient -pf /var/run/dhclient."$2".pid -lf /var/lib/dhcp/dhclient."$2".leases "$2"
[...]
if-down)
        if [ -x /sbin/dhclient3 ]; then
                /sbin/dhclient3 -r -pf /var/run/dhclient."$2".pid -lf /var/lib/dhcp3/dhclient."$2".leases "$2" >/dev/null 2>&1
        elif [ -x /sbin/dhclient ]; then
                kill -TERM $(cat /var/run/dhclient."$2".pid)

On the last line, not "kill", but "dhclient -r" should be used, as in the /sbin/dhclient3 case.

Stéphane, do you mind following through on this?

Uploaded a (untested) fix to precise and quantal replacing the kill call by a dhclient -r call similar to dhclient3.

This bug was fixed in the package madwimax - 0.1.1-1ubuntu2

---------------
madwimax (0.1.1-1ubuntu2) quantal; urgency=low

  * Properly stop dhclient instead of killing it, this should fix inconsistency
    issues with resolvconf. (LP: #994227)
 -- Stephane Graber <email address hidden> Mon, 01 Oct 2012 15:40:21 -0400

Needs test case, etc for SRU.

Oops, for some reason I had marked that bug as ready to upload on my side even though I forgot to update the description...
fixed.

Hello Egor, or anyone else affected,

Accepted madwimax into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/madwimax/0.1.1-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The fix for this bug has been awaiting testing feedback in the -proposed repository for precise for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

It's a pity: wimax has been shut down in my city, now I have neither device, nor environment to test the fix. Home, someone else could test the fix.

The version of madwimax in precise-proposed has been removed as the bugs it was fixing (including this one) were not verified in a timely fashion.

Moving to won't fix as apparently nobody cares.