WiFi Network issues in new kernel?

English Network/Internet
1

I have OpenSuse 11.4 (on an HP nc6400 laptop) which has been regularly patched and updated.

lspci gives me this…

08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5753M Gigabit Ethernet PCI Express (rev 21)
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Occasionally (often) I witness temporary lockups when using ssh to a local server and also the same “lockups” when accessing a web page. I quote that because what is witnessed is a “non page load within an expected time frame” (ie I wait several seconds and then issue a page reload request which returns instantly).

Another laptop, running windows, “appears” not to have any of these issues. Another laptop running Ubuntu 9.04 (not current) also appears not to have this issue.

I have just downgraded the kernel to 2.6.37.1-1.2.2 (x64) using YaST software manager from the latest 2.6.37.6-0.7.1 (x64) which I suspect is causing the issue.

So far I have not witnessed the issue again (within a time frame in which I would have expected to see it repeat).

I have not tried the new kernel release on the wired connection to see if it still occurs.

Is there some change in the kernel/“intel pro wireless module”/“network stack” which could cause this?

My suspicion is that it is the pro wireless module at fault but … that’s where I would like help.

Thanks,

Here is the output from lsmod.


Module                  Size  Used by
autofs4                30087  1 
ndiswrapper           275278  0 
ip6t_LOG                9192  5 
xt_tcpudp               3812  2 
xt_pkttype              1288  3 
ipt_LOG                 8721  5 
xt_limit                2591  10 
fuse                   80436  3 
vmsync                  4224  0 
vmblock                13479  1 
af_packet              23463  4 
rfcomm                 75967  4 
sco                    19079  2 
bnep                   17601  2 
l2cap                  71721  16 rfcomm,bnep
cpufreq_conservative    11828  0 
cpufreq_userspace       3264  0 
cpufreq_powersave       1290  0 
acpi_cpufreq            8367  1 
mperf                   1555  1 acpi_cpufreq
edd                     9664  0 
ip6t_REJECT             4709  3 
nf_conntrack_ipv6       9399  3 
nf_defrag_ipv6         11699  1 nf_conntrack_ipv6
ip6table_raw            1627  1 
xt_NOTRACK              1224  4 
ipt_REJECT              2640  3 
iptable_raw             1686  1 
iptable_filter          1946  1 
ip6table_mangle         2036  0 
nf_conntrack_netbios_ns     1822  0 
nf_conntrack_ipv4      10168  3 
nf_defrag_ipv4          1737  1 nf_conntrack_ipv4
ip_tables              22270  2 iptable_raw,iptable_filter
xt_conntrack            2880  6 
nf_conntrack           88175  5 nf_conntrack_ipv6,xt_NOTRACK,nf_conntrack_netbios_ns,nf_conntrack_ipv4,xt_conntrack
ip6table_filter         1855  1 
ip6_tables             22656  4 ip6t_LOG,ip6table_raw,ip6table_mangle,ip6table_filter
x_tables               28281  16 ip6t_LOG,xt_tcpudp,xt_pkttype,ipt_LOG,xt_limit,ip6t_REJECT,ip6table_raw,xt_NOTRACK,ipt_REJECT,iptable_raw,iptable_filter,ip6
table_mangle,ip_tables,xt_conntrack,ip6table_filter,ip6_tables
snd_pcm_oss            53391  0 
snd_mixer_oss          20225  1 snd_pcm_oss
snd_seq                66675  0 
snd_seq_device          7770  1 snd_seq
dm_mod                 86272  0 
btusb                  17839  2 
sierra                 19755  0 
usbserial              41812  1 sierra
tpm_infineon            8540  0 
bluetooth             107148  9 rfcomm,sco,bnep,l2cap,btusb
arc4                    1601  2 
ecb                     2463  2 
snd_hda_codec_si3054     4812  1 
sg                     33426  0 
sr_mod                 16781  0 
cdrom                  43280  1 sr_mod
iwl3945               155939  0 
iwlcore               173388  1 iwl3945
snd_hda_codec_analog    87892  1 
pcmcia                 62047  0 
mac80211              300859  2 iwl3945,iwlcore
snd_hda_intel          28391  2 
tifm_7xx1               6212  0 
tifm_core               8230  1 tifm_7xx1
tpm_tis                11938  0 
hp_accel               14888  0 
tpm                    17721  2 tpm_infineon,tpm_tis
tpm_bios                7068  1 tpm
lis3lv02d              13917  1 hp_accel
hp_wmi                  6818  0 
input_polldev           4727  1 lis3lv02d
sparse_keymap           4466  1 hp_wmi
snd_hda_codec         108050  3 snd_hda_codec_si3054,snd_hda_codec_analog,snd_hda_intel
tg3                   144120  0 
iTCO_wdt               12266  0 
cfg80211              177329  3 iwl3945,iwlcore,mac80211
snd_hwdep               7772  1 snd_hda_codec
serio_raw               5318  0 
snd_pcm               104468  4 snd_pcm_oss,snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec
iTCO_vendor_support     3118  1 iTCO_wdt
ppdev                   9183  0 
yenta_socket           37627  0 
shpchp                 31135  0 
pcspkr                  2190  0 
parport_pc             37259  0 
joydev                 12166  0 
pcmcia_rsrc            12620  1 yenta_socket
sdhci_pci               9243  0 
sdhci                  23960  1 sdhci_pci
mmc_core               94127  1 sdhci
pci_hotplug            32310  1 shpchp
parport                40234  2 ppdev,parport_pc
pcmcia_core            20749  3 pcmcia,yenta_socket,pcmcia_rsrc
snd_timer              26774  2 snd_seq,snd_pcm
irda                  138088  0 
snd                    84374  15 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_codec_si3054,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_h
wdep,snd_pcm,snd_timer
soundcore               8782  1 snd
crc_ccitt               1739  1 irda
rfkill                 21955  4 bluetooth,hp_wmi,cfg80211
snd_page_alloc          9569  2 snd_hda_intel,snd_pcm
video                  15929  0 
battery                12334  0 
container               3191  0 
button                  6829  0 
wmi                    11161  1 hp_wmi
ac                      4151  0 
ext4                  397962  2 
jbd2                   91654  1 ext4
crc16                   1747  2 l2cap,ext4
radeon                984687  3 
ttm                    74373  1 radeon
drm_kms_helper         36694  1 radeon
drm                   232019  5 radeon,ttm,drm_kms_helper
i2c_algo_bit            6246  1 radeon
fan                     3215  0 
thermal                14914  0 
processor              39669  3 acpi_cpufreq
thermal_sys            17462  4 video,fan,thermal,processor
2

As a data point, I’ll mention that I am not seeing any of these problems.

Back when I was running 11.3, on my work desktop system that used ethernet, I did notice that it was always failing to renew its DHCP lease (that’s where it “leases” use of an IP address). The effect was than when the lease ran out, the network would be reset and then a new lease acquired. That would have disrupted any ongoing ssh connection, though I was usually not logged on at the time of such failures. I switched to using “dhclient” instead of “dhcpd” and that fixed the problem. It seems to have been due to a miscommunication between my system and the dhcp server.

At home, I have not seen that. But I have seen something similar. I use uverse, and I have a separate router behind the uverse modem. For a while, I had setup my router to share the public IP address with the modem (really a router/modem combo). When the modem handles a shared IP, it uses DHCP lease times of 10 minutes. I was noticing that occasionally (once every 2 or three days), router would fail to renew its DHCP lease, reset the network and renegotiate a new lease. This caused a temporary outage similar what you are describing. I eventually resolved that problem by giving up having my router share the public IP with the modem. That leaves me depending on double-NAT, but it seems more reliable this way.

The above lengthy details are intended as a hint that the problem might be somewhere other than in your kernel.

3

I appreciate the hints. I don’t know where the issue lies as yet and am willing to accept all possibilities. There are many variables in this.
It could be the start of a HW failure in the mobo. Perhaps the WiFi component getting cooked affecting antenna performance. There is no indication of dropped signal strength. Nothing in the system logs pertaining to lost signal.
The router between the ssh server and the laptop with issue is one Netgear wnr3500 with dd-wrt on it. I read somewhere in the past that there had been issues with WPA personal in some flavors of linux so I added another virtual interface to the router with WEP instead. WEP has served well in the past until I changed it to WPA in July. Returning to WEP did not alter the “pauses”.

I have not witnessed the issues since I moved back to the older kernel but perhaps, if it is a potential HW issue, the box is cooler at the moment. Unknown.

This issue started manifesting itself a few days? (less than 2 weeks?) ago I think. I don’t know when the newer kernel was installed. I don’t know how to find that info in Suse. It seems not to be in the Software Manager. I have not used Suse since 1999 so I am a little out of date. Been on other flavors for a while.

If I don’t see the issue for a few days, I will definitely have to point the finger at the kernel/module(s)(ndis?). If I do, then I will try dropping in an old WRTSL54GS with an older v of dd-wrt on it instead of the Netgear and reverting to the newer kernel to try that for a while.

4

OK so I sit corrected. Or at least I have more info. The issue returns, with the older kernel. A ping -s 1024 gives

ping -s 1024 bebe
PING bebe.home (192.168.0.19) 1024(1052) bytes of data.
1032 bytes from bebe.home (192.168.0.19): icmp_req=2 ttl=64 time=1.30 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=21 ttl=64 time=1.28 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=38 ttl=64 time=2.86 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=40 ttl=64 time=1.93 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=53 ttl=64 time=1.46 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=63 ttl=64 time=2.34 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=64 ttl=64 time=1.43 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=65 ttl=64 time=2.00 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=66 ttl=64 time=3.68 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=67 ttl=64 time=1.93 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=68 ttl=64 time=2.42 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=69 ttl=64 time=2.40 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=70 ttl=64 time=1.57 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=71 ttl=64 time=3.46 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=72 ttl=64 time=1.39 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=73 ttl=64 time=7.87 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=74 ttl=64 time=3.21 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=75 ttl=64 time=1.30 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=76 ttl=64 time=1.95 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=77 ttl=64 time=19.6 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=78 ttl=64 time=2.33 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=79 ttl=64 time=1.70 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=80 ttl=64 time=1.29 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=81 ttl=64 time=2.10 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=82 ttl=64 time=1.26 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=83 ttl=64 time=1.88 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=84 ttl=64 time=1.29 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=85 ttl=64 time=1.60 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=86 ttl=64 time=1.78 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=87 ttl=64 time=1.32 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=88 ttl=64 time=2.58 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=89 ttl=64 time=1.32 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=90 ttl=64 time=1.50 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=91 ttl=64 time=2.91 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=92 ttl=64 time=5.82 ms
1032 bytes from bebe.home (192.168.0.19): icmp_req=93 ttl=64 time=5.30 ms
^C
— bebe.home ping statistics —
93 packets transmitted, 36 received, 61% packet loss, time 92049ms

Not good. A similar ping, running in parallel on the ubuntu 10.04 laptop (my mistake earlier, I thought is was 9.04) gives 0% packet loss after 200 secs.

OK - now to find a 10.04 CD and drop it into the laptop with the issue.

5

From the times I see, and the packet loss you describe, and you say your connecting wirelessly, it sounds like wireless interference. Have you tried doing this with ethernet cable?

6

If you believe your problems are related to a poor wireless connection, you can try changing your TCP/IP Congestion Control algorithm to veno to better manage those kinds of latencies and losses. If you’re doing any kind of “non-typical” file transfers over varying distances you can try other algorithms as well.

You can skip to the Congestion Control algorithm page on my TCP/IP tuning paper

Optimize and Fix your Network Connection - Su Networking Technical

HTH,
Tony

7

Thanks for the further suggestions. I will poke around over the next few days to see what I can find. Unfortunately for the scientific method I am changing several things at the same time rather than taking a rigorous approach. It has to the right side of the brain taking control.

Yesterday I noticed a new wireless signal only one channel away from my WiFi channel. Obvious interference possibilities. However, there is no other transmitter within 300ft of here so any signal should(!?) be weak.

I switched out the WiFi card in the laptop for another from an identical spare.

I returned to the newest kernel release using YaST.

I’ll report some time next week on what appears to be happening.

8

On 10/14/2011 04:06 PM, lawsonim1 wrote:

> Yesterday I noticed a new wireless signal only one channel away from my
> WiFi channel. Obvious interference possibilities. However, there is no
> other transmitter within 300ft of here so any signal should(!?) be weak.

Be aware the wifi channels are 5 MHz apart, but that the signal is 20 MHz wide
for 802.11g and may be 40 MHz wide for 802.11n. If you do the math for 802.11g,
the only “clear” channels are 1, 6, and 11. If there are radios that differ by
only 1 channel, then one of you does not understand the principle.

9

Well I switched out the router and have not seen the issue since. Pity. I really want to use that router. I will check the router settings and if necessary try another firmware release.

10

On 10/27/2011 10:16 AM, lawsonim1 wrote:
>
> Well I switched out the router and have not seen the issue since. Pity.
> I really want to use that router. I will check the router settings and
> if necessary try another firmware release.

What model is that Netgear? I have a Netgear WNDR3300 that works perfectly with
the firmware that was shipped with it, but I don’t have a 3945.