Re: Mysteries of WiFi #1 - which interface?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Tim:

I've just been going through this with a iwl3945 driver for Intel
Wireless device ipw3945. I'm not an expert, but I have asked enough
experts to point you in some directions. You and I are on the same
journey--to find our way through these piles of competing
configurations.  Not only is there the config in
/etc/sysconfig/networking-scripts, there is also a separate setup for
NetworkManager and wifi-radar and wicd or whatever other wireless
thing you are trying.  For me, NetworkManager does not generally work
for WEP key encrypted routers, but it may work on others.  wifi-radar
has helped in the past, but today does not work at all.

The first thing that struck me about your note is that you don't have
much detail on your wireless card--the hardware itself, and your
version of the kernel.  Since so many cards exist, and the kernel has
good support for only some, it is an important detail.  You can
usually see what you have by running "/sbin/lspci"

I have the lpw3945 wireless and, at least until the kernel 2.6.24, I
had a very stable setup using an addon kernel module from
http://ipw3945.sf.net.  Now, I can't get that kernel module to compile
anymore and I'm trying to make the iwl3945 that is in the kernel work.
 But I've found that there are plenty of people who can't make it
work, or think it needs to be patched for some conditions.

So if you don't make some progress, you should start googling for your
specific network hardware.

See details below. I hope I'm not just telling you what you already know.

On Sun, Mar 9, 2008 at 10:03 AM, Timothy Murphy <gayleard@xxxxxxxxxx> wrote:
>
>  I've had endless trouble with WiFi on one laptop (ThinkPad T43)
>  out of four - it works perfectly on the other three.
>
>  Reluctantly, I'm trying to work out how WiFi works,
>  or is meant to work.
>
>  My initial thought is that it is an incredible mess,
>  at least under Fedora.
>  To start with, there seem to be a large number of files involved,
>  each of which may or may not have a vital role to play.
>
>  I'm assuming for the purposes of this exercise that NM (NetworkManager)
>  is not running, but the network service is.
>  (I think this is the default under Fedora-8?)

Maybe not default, but it does not matter.  If you use
system-config-services,  you can decide if either should be on. I
leave both off lately because neither works in a dependable way.

 After logging in, I try to make wireless work manually. I start by
trying system-config-network to see if it spots the right hardware and
can try to create a setup.

>
>  As far as I can see, the most important files
>  are /etc/sysconfig/network-scripts/ifcfg-eth?
>  (or ifcfg-<if> if some other interface is called).
>

These result from using system-config-network to try to configure
wireless devices.  These are closer to the "network" service than
NetworkManager, but I notice now that the config tool offers an option
"controlled by NetworkManager".

s-c-n creates names in /etc/modprobe.conf.  Note in there it names
"eth0" or "eth1" to certain device drivers.  At the current moment, I
have this:

alias ipv6 off
alias eth0 tg3
alias eth1 iwl3945
options iwl3945 disable_hw_scan=1

Suppose you try to use system-config-network to create a config for a
wireless network. In my experience, it can work sometimes, for some
routers.  But you do have to go through the ritual of specifying an
ssid and a WEP key.  I've got no WPA networks to use, don't bother
with it.

You find out a lot about your situation by running

/sbin/iwlist scan

and

/sbin/ifconfig

Run those early and often :)


>  But there are also the files in /etc/sysconfig/networking/devices
>  and /etc/sysconfig/networking/profiles/default .
>
As far as I can see, these are also created by system-config-network
and are part of its data storage/backup arrangement.

As far as I can tell, hitting the activate button in
system-config-network is doing the exact same thing as the command
line /sbin/ifup eth1 .

If s-c-n does not connect,   I often open a terminal and run "dmesg"
over and over again while testing commands in the other terminal.  It
is NOT as good to just monitor /var/log/messages because that omits
some information.

I go like this at least 3 times before giving up.

/sbin/ifup eth1

where eth1 is the name that is after "ifcfg-eth1" in
/etc/sysconfig/network-scripts.


>  I don't understand the relation between these
>  (or how anyone in their right mind could have introduced them all).
>
>  But as well as these, and earlier in the booting story,
>  are various other files, listed in the order I think Linux reads them:
>
>  1. /etc/udev/rules.d/70-persistent-net.rules
>  with lines like
>  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>         ATTR{address}=="00:02:2d:1d:43:b7", ATTR{type}=="1", NAME="eth0"
>

These are re-written when you log out/in.  Some people say the
persistance interferes with efforts to fix systems.  I was having a
lot of trouble changing drivers, some people said it was because of
this.  People recommend that, when  you have trouble, you can just
delete 70-persistent-net.rules and then restart.  This was one way
people said you had to make the transition from using the device name
eth1 (chosen by the traditional s-c-n approach in RedHat/Fedora) and
the wlan0 device name that seems to be preferred by newer wireless
setups.  It seemed to me that did not good until I temporarily turned
off the udev service before logging out.

>  2. /etc/modprobe.conf
>  with lines like "alias eth0 orinoco_cs"
>

There's some information. you have an orinoco wireless?  and you
system-config-network has tried to attach the name eth0 to it.

That is somewhat unusual, usually it will have eth0 set aside for the
wire network and either eth1 or wlan0 for wireless.  But if you remove
those bits from /etc/modprobe.conf, turn off NetworkManager and
network, and re-start, you can get a "clean start" on the
system-config-network setup.

>  3. /etc/dhclient-eth0.conf
>  which in my case is empty.
>  Assuming it is not necessary, why is it there?
>
Mine is empty too.

If some special settings were needed, they would go here.


>  4. /var/lib/dhclient/dhclient-eth0.leases
>
>  But I get my present headache by reading in /var/log/messages:
>  --------------------------------------------
>  Mar  9 13:10:32 elizabeth kernel:
>         udev: renamed network interface eth0 to eth2
>  Mar  9 13:10:32 elizabeth kernel:
>         udev: renamed network interface eth1 to eth0
>  --------------------------------------------

This renaming is happening because of the mismatch between devices set
in /etc/modprobe.conf and in the udev thing.

I think that, if you really want to get down to basics and find out
what works, you turn off NetworkManager and network services, and try
to really understand.

The true experts on wireless recommend we use iwconfig directly.
Here's a sample series of commands I copied from another post. I think
this approach is "as close to the basics" as you can get.

iwconfig wlan0 ssid SSID-NAME
iwconfig wlan0 key YOUR-KEY
iwconfig wlan0 mode RESTRICTED or OPEN

ifconfig wlan0 up

maybe you need /sbin/iwconfig and /sbin/ifconfig if you dont have
/sbin in  your path.

If you can make this work, then you know the hardware can be made to
work, and the problem is just finding out which pimpy pointy clicky
thing works.

For your info, here's what I see now that it is working. In this
particular session, NetworkManager failed to associate, wifi-radar
couldn't find any working devices, but on the third try ("patience!!")
"/sbin/ifup wlan0" did work




$ /sbin/iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wmaster0  no wireless extensions.

wlan0     IEEE 802.11  ESSID:"caliope"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:19:5B:48:2F:8D
          Bit Rate=54 Mb/s   Tx-Power=14 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Link Quality=78/100  Signal level=-56 dBm  Noise level=-98 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ /sbin/ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:23188 (22.6 KiB)  TX bytes:23188 (22.6 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:18:DE:9B:6B:66
          inet addr:192.168.0.105  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:607661 errors:0 dropped:0 overruns:0 frame:0
          TX packets:341238 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:812162305 (774.5 MiB)  TX bytes:33744124 (32.1 MiB)

wmaster0  Link encap:UNSPEC  HWaddr
00-18-DE-9B-6B-66-68-DE-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Here's the end of dmesg, which shows several failed connects, an
apparent crash of a kernel module, and then the eventual success. I do
not know why I get those alternating "long barker protocol" and "short
barker protocol" messages.


$ dmesg
wlan0: authenticated
wlan0: associate with AP 00:19:5b:48:2f:8d
wlan0: RX AssocResp from 00:19:5b:48:2f:8d (capab=0x31 status=0 aid=3)
wlan0: associated
printk: 9 messages suppressed.
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: No ProbeResp from current AP 00:19:5b:48:2f:8d - assume out of range
RTNL: assertion failed at net/mac80211/key.c (272)
Pid: 6330, comm: iwl3945 Tainted: P        2.6.24.3-22.fc8 #1
 [<f8d7358f>] ieee80211_key_free+0x36/0xa9 [mac80211]
 [<f8d6462a>] sta_info_free+0x71/0x114 [mac80211]
 [<c042f775>] printk+0x1b/0x1f
 [<f8d6a19b>] ieee80211_associated+0xb2/0x15e [mac80211]
 [<f8d6bcd7>] ieee80211_sta_work+0x0/0x57d [mac80211]
 [<f8d6c0b4>] ieee80211_sta_work+0x3dd/0x57d [mac80211]
 [<c0404210>] __switch_to+0xcb/0x147
 [<c062ad0f>] schedule+0x624/0x663
 [<f8d6bcd7>] ieee80211_sta_work+0x0/0x57d [mac80211]
 [<c043bca1>] run_workqueue+0x7d/0x109
 [<c043f1eb>] prepare_to_wait+0x24/0x3f
 [<c043c50a>] worker_thread+0x0/0xc6
 [<c043c5c4>] worker_thread+0xba/0xc6
 [<c043f0a1>] autoremove_wake_function+0x0/0x35
 [<c043efd8>] kthread+0x38/0x60
 [<c043efa0>] kthread+0x0/0x60
 [<c0405e0b>] kernel_thread_helper+0x7/0x10
 =======================
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:19:5b:48:2f:8d
wlan0: RX authentication from 00:19:5b:48:2f:8d (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:19:5b:48:2f:8d
wlan0: RX AssocResp from 00:19:5b:48:2f:8d (capab=0x31 status=0 aid=3)
wlan0: associated
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to short barker preamble (BSSID=00:19:5b:48:2f:8d)
wlan0: switched to long barker preamble (BSSID=00:19:5b:48:2f:8d)

When the association fails, I usually see this in dmesg

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:0f:b5:51:7f:2c
eth1: RX authentication from 00:0f:b5:51:7f:2c (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:0f:b5:51:7f:2c
eth1: RX ReassocResp from 00:0f:b5:51:7f:2c (capab=0x5 status=0 aid=76)
eth1: associated
eth1: disassociate(reason=3)


Because the iwl3945 is my big question, I probably have some troubles
you don't.  Look what happens, even though the wireless is connected:


$ /sbin/iwlist scan
lo        Interface doesn't support scanning.

eth0      Interface doesn't support scanning.

wmaster0  Interface doesn't support scanning.

wlan0     No scan results


This happens because hw_scan is disabled in the modprobe.conf and
software scanning just doesn't work yet in iwl3945.  So I'm in a
pretty bad situation.  I need to restart the module with and without
that option in order to see available networks.



>  --
>  Timothy Murphy
>  e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux