Intel PRO/Wireless 5300 AGN stopped working for me with openSUSE-11.2

The wireless on my 64-bit openSUSE-11.2 installed on my Dell Studio 1537 laptop stopped working some time back (possibly more than a one or two months back).

I just discovered this last week when on business. I have not used the wireless under openSUSE-11.2 for a while so I am not certain what broke it, but I am suspicious of an update. I note openSUSE-11.3 milestone-7 works great with the wireless (on a liveCD).

I note possibly two related threads, although I note no failed request for firmware in my case:
- request for firmware file ‘iwlwifi-5000-2.ucode’ failed [INTEL 5300 AGN] [OPENSUSE 11.2] - openSUSE Forums, and I see another thread here:

In my case I can scan for the network, and see the SSID. An ip address is assigned. But a ping does not work.

Some details, the wireless is:


04:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 5300 AGN [Shiloh] Network Connection [8086:4235]
        Subsystem: Intel Corporation Device [8086:1121]
        Kernel driver in use: iwlagn 

In terms of installed apps:

rpm -qa '*wireless*'

wireless-tools-30.pre8-5.1.x86_64
wireless-regdb-2009.09.08-2.2.noarch

rpm -qa '*network*'
libproxy0-networkmanager-0.3.1-2.2.x86_64
kdenetwork4-filesharing-4.3.5-0.1.2.x86_64
yast2-network-2.18.53-1.1.1.x86_64

In terms of recent updates:

rpm -qa --last | grep network
yast2-network-2.18.53-1.1.1                   Thu 04 Mar 2010 10:27:11 PM CET
kdenetwork4-filesharing-4.3.5-0.1.2           Thu 04 Mar 2010 10:24:15 PM CET
libproxy0-networkmanager-0.3.1-2.2            Thu 04 Mar 2010 06:05:03 PM CET

The “wireless” app rpms date back to 9-Nov.

Kernel updates:

rpm -qa --last | grep kernel
kernel-syms-2.6.31.12-0.2.1                   Thu 25 Mar 2010 11:13:27 PM CET
kernel-desktop-devel-2.6.31.12-0.2.1          Thu 25 Mar 2010 11:13:19 PM CET
kernel-xen-devel-2.6.31.12-0.2.1              Thu 25 Mar 2010 11:12:59 PM CET
kernel-default-devel-2.6.31.12-0.2.1          Thu 25 Mar 2010 11:12:47 PM CET
kernel-debug-devel-2.6.31.12-0.2.1            Thu 25 Mar 2010 11:12:29 PM CET
kernel-desktop-2.6.31.12-0.2.1                Thu 25 Mar 2010 11:11:58 PM CET
kernel-source-2.6.31.12-0.2.1                 Thu 25 Mar 2010 11:11:13 PM CET
kernel-firmware-20090821-4.1                  Thu 04 Mar 2010 06:02:36 PM CET
linux-kernel-headers-2.6.31-3.4               Thu 04 Mar 2010 06:02:10 PM CET

Its possible I have not used the wireless since before the 25-March kernel update (indeed possible not used since February) and hence it may have been the kernel or other update that broke the wireless.

My /var/log/messages is here: #993635 - Pastie](http://pastie.org/993635)

I note a number of “martian source” messages in the /var/log/messages which strike me as not appropriate, but in truth I really do not know.

The dmesg output is here: #993636 - Pastie](http://pastie.org/993636) Other than the “martian source” I don’t see anything that helps me there, but I confess I know little to nothing here with wireless.

iwlist-scan shows our SSID (rijira). I did not include the output here, although I could.

Here is an extract from iwconfig (with encryption key deleted by me):

wlan0     IEEE 802.11abgn  ESSID:"rijira"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1F:3F:16:37:FB
          Bit Rate=0 kb/s   Tx-Power=15 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key: .... deleted .......... [2]
          Power Management:off
          Link Quality=70/70  Signal level=-32 dBm  Noise level=-89 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

ifconfig (extract) output:

wlan0     Link encap:Ethernet  HWaddr 00:16:EA:ED:80:76
          inet addr:192.168.2.4  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::216:eaff:feed:8076/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:415 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:132050 (128.9 Kb)  TX bytes:6455 (6.3 Kb)

wmaster0  Link encap:UNSPEC  HWaddr 00-16-EA-ED-80-76-00-00-00-00-00-00-00-00-00-00
          UP RUNNING  MTU:0  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)

“ip a” output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:21:70:85:8d:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.136/24 brd 192.168.2.255 scope global eth0
3: wmaster0: <UP,LOWER_UP> mtu 0 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ieee802.11 00:16:ea:ed:80:76 brd 00:00:00:00:00:00
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:ea:ed:80:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.4/24 brd 192.168.2.255 scope global wlan0
    inet6 fe80::216:eaff:feed:8076/64 scope link
       valid_lft forever preferred_lft forever
5: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
6: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether c6:43:e3:42:f1:55 brd ff:ff:ff:ff:ff:ff


I was a bit surprised to see an ip assigned to eth0, given there was no ethernet cable plugged in.

As noted, ping does not work:

ping -c 5 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.2.136: icmp_seq=2 Destination Host Unreachable
From 192.168.2.136 icmp_seq=2 Destination Host Unreachable
From 192.168.2.136 icmp_seq=3 Destination Host Unreachable
From 192.168.2.136 icmp_seq=4 Destination Host Unreachable
From 192.168.2.136 icmp_seq=5 Destination Host Unreachable

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4001ms
, pipe 3

====================
I know the router wireless network is good, because I can connect to the router via wireless with another laptop (old Fujitsu-Siemens Amilo 7400M with older Intel wireless), and the router wireless also works with this Dell Studio 1537 PC (with same hardware) but with openSUSE-11.3 milestone7 version.

What does

ip route

show? (Reads like missing default gateway).

What happens, when the thing is configured with static IP, Google’s public DNS’s (8.8.8.8 and 8.8.4.4), and 192.168.2.1 as the gateway address ?

This gives (with no wired connection):

.... :~> ip route
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.136
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.4
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.2.1 dev eth

A dynamic ip address worked before. What software could have changed such that it is now necessary to test to see if a static ip works?

I confess I am very reluctant to try to force a static ip address, given my limited understanding in this area. I am worried I will mess things around such that I won’t be able to restore my settings afterward. And given I may not even succeed in setting up a static ip properly - hence any negative result I get with a static ip could be suspect.

Hi oldcpu. I think this is the issue

default via 192.168.2.1 dev eth

Try adding a default gateway (assuming 192.168.2.1 is correct address) for your wireless interface

route add default gw 192.168.2.1 wlan0

Then see if you can ping/browse ok.

To make it permanent, you’ll have to add it via YaST.

My wireless knowledge is very limited. After adding that, then what? I note ping still does not reach the wireless router.

Assuming one needs to restart the wireless ( ? ) for that to take effect, I went to yast > network devices > network settings and reset the wireless, but all that does is wipe he settings.

So I ran that again:

route add default gw 192.168.2.1 wlan0

again, still no functional ping, and again ran “ip route”

.... :~> ip route
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.136
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.148
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.2.1 dev eth
default via 192.168.2.1 dev wlan0

and as noted, no functional ping yet.

Apologies, but don’t let my post count fool you. I know very little about wireless. Typically in the past my wireless ‘just worked’.

Ok, that gave me the hint I needed.

Many thanks !!

Wireless is working again.

The problem was I had my WIRED connection set inappropriately in YaST, and hence my wireless did NOT work. My wired kept being set as a default device, even though there was no wired cable attached.

I went and checked my wired connection in YaST, and it was inappropriately set to connect “on boot” when it should NOT be, from what I recall from an lwfinger post. Instead it should be “upon cable connect” or something like that. So I changed the wired to “upon cable connect” and wireless now functions.

… Apologies for wasting your time, but I DO appreciate the help. … Someday I need to sit down and teach myself more about this !

Hmmm … I spoke too soon. It worked briefly. I ran to the washroom, came back, and 11.2 was frozen solid. Only a hardware shutdown (hold power switch down for 8 seconds) recovered (ie complete power down followed by a reboot). … So some success, but clearly I have another problem. … Likely something I messed up previous in trying to recover.

The problem was I had my WIRED connection set inappropriately in YaST, and hence my wireless did NOT work. My wired kept being set as a default device, even though there was no wired cable attached.

That makes sense.

BTW,I’m no guru either. :slight_smile:

Edit: Just read your previous post. I can see you have other issues to sort first…

Indeed. After the reboot I immediately reproduced the problem (ie the freeze), although I am not clear as to what sequence causes it. I rebooted, looked in /var/log/messages (with kwrite), opened firefox (wireless worked), opened some terminals, ran “ping” (it worked), and “ip a” and looked away for 10 seconds, … looked back and it was frozen again.

I am VERY suspicious it is network related. The fact that it can be reproduced is hopefully good. :slight_smile:

I am now booting it to a liveCD to see if I can capture any error logs.

While booting to the liveCD, I captured some log files from the PC, … but they don’t tell ME much about the freeze (in fact I can’t see anything relevant).

I have the network setup via Network Manger disabled (and using the traditional method in YaST). I am going to change the settings back to have Network Manager in an auto configuration and see if the freeze still occurs there. If no freeze in an auto configuration, that would suggest I have something misconfigured in YaST for the traditional method.

… thats about all I can think of doing for now.

Scratch that line of investigation. … I managed to reproduce the freeze with the auto configuration with networkmanager.

One thing I note, when the freeze happens, the light next to the CAPS LOCK on that laptop (I assume that means the CAPS LOCK key light) flashes continually until I hold the power button down for 8 seconds or so. Hold the button down for increments any less than the 8 has no effect.

That has me thinking power management may also be at fault, although that could be a wild goose chase.

I’m going to now plug the wired ethernet cable in for a while and see if the freeze occurs.

The freeze does not happen with wired. … I’ll keep the laptop running with wried Internet for a few more hours, but this is looking pretty likely that the wireless is at fault for causing the freeze. I’m now more suspicious that this is something that I have done (in settings), opposed to a problem elsewhere, although I can not be certain.

On 06/06/2010 06:26 AM, oldcpu wrote:
>
> oldcpu;2173249 Wrote:
>> Wireless is working again.
> Hmmm … I spoke too soon. It worked briefly. I ran to the washroom,
> came back, and 11.2 was frozen solid. Only a hardware shutdown (hold
> power switch down for 8 seconds) recovered (ie complete power down
> followed by a reboot). … So some success, but clearly I have another
> problem. … Likely something I messed up previous in trying to recover.

Several posts ago, you describe the system freeze as happening wit the
caps lock light flashing. This in an indication that the kernel has
found a panic condition, one that is so serious that trying to recover
might cause damage. Thus the kernel just gives up.

These are hard to diagnose as they leave no record in the logs. IF you
can reproduce the condition, then one way, at least for KDE users, is to
do something like “sleep 10 ; <start bad command>”. During the 10
seconds delay before the bad command starts, you can switch to the
logging console by using CTRL + ALT + F10. When the crash happens, the
log will scroll up the screen. You can then photograph it or write down
the traceback by hand.

As your crash seems to happen after some delay, just switch to the log
console and wait.

This is proving to be difficult to catch. I missed a few crashes where the camera was either not ready or tuned wrong. Some other occasions it crashed immediately upon KDE booting, with no chance to press <CNTRL><ALT><F10>

Here are some early attempts with camera tuned badly:
1.
http://thumbnails22.imagebam.com/8367/c2d84483668121.gif](ImageBam)
2.
http://thumbnails29.imagebam.com/8367/6b153883668133.gif](ImageBam)
3.
http://thumbnails29.imagebam.com/8367/de94da83668137.gif](ImageBam)
4.
http://thumbnails27.imagebam.com/8367/3bce2883668141.gif](ImageBam)
… cont …

http://thumbnails33.imagebam.com/8367/17728a83668153.gif](ImageBam)
6.
http://thumbnails31.imagebam.com/8367/1ce20483668157.gif](ImageBam)

… I’m still trying to get something better.

I should note that the above 6 images are taken in sequence , all from the same crash.

On 06/07/2010 03:46 PM, oldcpu wrote:
>
> oldcpu;2173823 Wrote:
>>
>> … I’m still trying to get something better.
> I should note that the above 6 images are taken in sequence , all from
> the same crash.

There has been considerable discussion of this crash on the wireless
list. It starts with microcode errors, then hits a BUG statement that
should have been a WARNING. You then hit a kernel panic due to a kernel
exception while in an interrupt routine.

Getting the compat-wireless package for your machine should fix it, as
your experience with 11.3 M7 shows.

Sorry to take so long to analyze your pictures - we were taking care of
our grandsons today.

Thanks. It now appears to be working after following that advice.

This is a new and educational experience for me.

Details: I note many users have packaged compat-wireless on the OBS. So I briefly added this repository:

http://download.opensuse.org/repositories/driver:/wireless/openSUSE_11.2/

and installed

  • compat-wireless-kmp-desktop version 2.6.34_2.6.31.05_0.1-2.1 (that was a new version numbering for me ! but I like it, … suggests it works with kernels from 2.6.31.05 to 2.6.34).
  • compat-wireless-scripts version 2.6.34-2.1

and I then removed the “wireless” repository (as is my practise to minimize my repos).

I note the description stated “compat-wireless” contains kernel modules for several WLAN adapters from linux wireless.org kernel based on the new mac80211-stack (mention of that stack is new to me - but was likely in the 11.3 milestone 2.6.34 and I was not aware of it as 11.3 milestone wireless in 2.6.34 “just worked” :slight_smile: ).

I note compat-wireless-scripts contains the load/unload scripts for compat-wireless.

I also saw a reference to the linux wireless.org download stating the rpms were built on the applications from that site. That site in turn noted:

This page is dedicated to the stable kernel compat-wireless releases. This started with the announcement of work for 2.6.30-rc series and will continue for all stable kernels releases. These stable releases are intended for users looking for more stability than what bleeding edge daily compat-wireless releases provide.
… all “old information” for you no doubt, but it was educational for me.

I currently have the laptop running on wireless with this “compat-wireless” rpm installation in place, and no crashes thus far. I have to run to work soon, so I will do a longer duration test this evening, but thus far so good.

No worries, … I was late in taking and posting pix due to a mix of social commitments and household chores (and my wife and I booked our flights to Asia in September which always take time, as we debate what flights to take, what seat assignments to get (based on information on the aircraft type … etc … )). We don’t have children (and hence no grandchildren) but we do have nephews and nieces and hence that reads to be a more rewarding activity than leaning over a keyboard. Hope all is well with the grandchildren.