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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
