Re: Wireless issues -- Lenovo R61 ThinkPad -- still cannot enable connection on boot-up ...
- To: email@example.com
- Subject: Re: Wireless issues -- Lenovo R61 ThinkPad -- still cannot enable connection on boot-up ...
- From: Ken Heard <firstname.lastname@example.org>
- Date: Sun, 05 Oct 2008 10:41:54 +0200
- Message-id: <48E87DD2.email@example.com>
- In-reply-to: <20080930164706.GB11192@pc0197>
- References: <48D51DA3.firstname.lastname@example.org> <48D74ADB.email@example.com> <20080925160846.GA10493@pc0197> <48E0863B.firstname.lastname@example.org> <20080930164706.GB11192@pc0197>
-----BEGIN PGP SIGNED MESSAGE-----
As Florian Kulzer suggested, I purged network-manager,
network-manager-kde, network-manager-openvpn, network-manager-vpnc and
the packages they depend upon, but which are not dependencies of any
other packages, a total of 12 packages in all.
I then added "auto wlan0" to file "/etc/network/interfaces" and then
rebooted. The boot process still did not successfully activate the
wireless connection. Syslog showx that it tried to by running
"DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 'n'" several
times and ultimately reported "No DHCPOFFERS received." and "No working
leases in persistent database - sleeping."
Activating a connection after failure to do so during boot-up, with
"auto wlan0" still in "/etc/network/interfaces" is revealing. First I
discovered that running "ifup wlan0" returned "ifup: interface wlan0
already configured". So, ifupdown thinks the connection is activated
even though it is not.
Apparently the developers are aware that a false configuration reading
is possible, because in directory "/usr/share/doc/ifupdown/contrib" are
two shell script files and a perl script file -- all dating from 2006 --
to determine whether the interfaces are "really" up. One of these shell
scripts, "ensureifup", does not work because it is probably outdated.
It apparently needs file "/usr/local/sbin/ifstate" which does not exist
in the laptop.
The other two, "ifstate" and "ifstate-check" report that all interfaces
are activated or "up", when in fact only "lo" is "up"; "eth0" and wlan0"
So, to activate the wireless connection when the boot process tried to
do so but failed because "auto wlan" was in file
"/etc/network/interfaces", first I have to run "ifdown wlan0". Doing so
has the effect of deleting the PID file.
If however I next run "ifup wlan0" wireless still is not activated.
"Ifup" nevertheless thinks it is, as running the command again returns
"ifup: interface wlan0 already configured".
After considerable experimentation I discovered that to activate the
connection in this situation I have first to run "ifdown wlan0". Next,
in order to confirm the existence of the "cell" I want to connect to, I
have to run "iwlist wlan0 scan". Finally, running "ifup wlan0" only
then will activate the connection.
Booting without line "auto wlan0" in file "/etc/network/interfaces"
obviates the cumbersome procedure just described. The interface will be
enacted simply by running "ifup wlan0" (as root of course, like all the
other commands mentioned herein) after the boot process is finished.
All the foregoing raises the three questions, if not more.
1. Why cannot the wlan0 be activated on boot?
2. Why does command "ifup" report that the specified interface is
already configured when it may not be? It appears that it will say the
interface is already configured if by finding the PID file, rather than
actually testing the connection.
3. Why, to activate an interface after an unsuccessful attempt, do I
need to do what I have described above? Surely "ifup" should be able to
tell whether an interface is *really* connected, and act accordingly: if
*really* connected, say so; if not, activate the interface and so report.
I am inclined to think that these are bugs in the ifupdown application,
rather than problems specific to my computer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----