9

I run a home wlan and a few days ago I upgraded a hp dv7 pavilion laptop from Oneiric to Precise. I had the proprietary Broadcom STA driver (wl module) activated.

Whenever this laptop was connected to WiFi had speedtest.net result of 8 Mbps (down) and all other machines (laptops, smartphones) could only get speedtest.net results well below 1 Mbps (mostly 500 Kbps) with severe ping problems and other bizarre effects. When the laptop was off everything was OK for the other machines.

Thinking about this a little I decided to remove the STA proprietary driver and use the opensource one. Everything works perfectly now for all the machines on the Wifi.

I wonder if the STA driver update in precise is rotten since it appears that it transformed my machine into a WiFi jammer. Is this possible ?

It seems that this issue is lined to the BCM 4314 itself, not a particular laptop.

What may be the possible reason for such a peculiar behavior? Can I overcome it without disabling the proprietary driver? What can I do to troubleshoot this problem?

Rafał Cieślak
  • 20,494
t koun
  • 91
  • The driver installs and activates OK on the DV7 machine which gets a stable and good connection. No legacy drivers present. The problem is for the other machines on the WiFi when the Broadcom machine is connected. – t koun Apr 02 '13 at 09:09
  • sorry for my mistake. :) – Web-E Apr 02 '13 at 09:50
  • I can confirm this is also a problem on Dell Latitude 35430, which also has BCM4313 (using Precise). It appears this issue may be characteristic for this wireless controller. However, in my case disabling the driver is not an option, as the open-source one does not work at all. – Rafał Cieślak Jun 10 '13 at 19:59
  • I have the same device and I had problems, I think that askcan help you: http://askubuntu.com/questions/265553/broadcom-corp-bcm4313-wirelss-not-detected-in-ubuntu-12-10 I am not having any problem with the propietary drivers. – ssoto Jun 11 '13 at 07:37
  • @RafałCieślak - please check if installing the hardware-enablement stack (https://wiki.ubuntu.com/Kernel/LTSEnablementStack) together with reinstalling the broadcom source module as per ssoto link above resolves your issue. – fossfreedom Jun 13 '13 at 08:30
  • It's not a definitive answer, buy my best guess is poor broadcast power control on the closed source blob resulting in other well managed cards turning down their sensitivity so they don't get blown by the power. I'll put it as an answer if you want, but it sounds like a non-fixable problem since it's in the blob unless you script a bunch of power control. – RobotHumans Jun 16 '13 at 00:05
  • @RafałCieślak --^ – RobotHumans Jun 16 '13 at 00:06
  • @fossfreedom Thanks for the link and sorry for a late reply. Unfortunately, installing any newer versions of kernel/drivers from consequent releases did not help. – Rafał Cieślak Jun 16 '13 at 12:29
  • @CallmeV That sounds reasonable. Is there any way I could measure the power in order to confirm your guess? Also, I might try checking whether these other devices turn down their sensitivity, if the open-source driver they use allows that - is this possible? – Rafał Cieślak Jun 16 '13 at 12:30
  • @RafałCieślak - if you have three test boxes: I'ld test it like this - install some tool that lets you see a packet's network's relative power. I'm sure there's a CLI util to do it at a whack, but kismet is already installed on my laptops and gives me enough information. With the broadcom box OFF, check the power of your box number 3 in kismet. Next turn it off and place the broadcom box in the same location. Check in kismet again. If my guess is right, the broadcom box should show significantly more signal strength. – RobotHumans Jun 16 '13 at 23:01
  • Also, you can't have them right next to each other. That could goof up the test and they need to be not a 5% signal distance from the AP either. Something like 80% strength from the AP would be an ideal test distance. It may even be that the AP turns down its sensitivity not the host... so checking host sensitivity would be a non-event. – RobotHumans Jun 16 '13 at 23:02
  • @tkoun you can enable qos on router... – Qasim Jun 17 '13 at 15:07

1 Answers1

3

My guess:

It's not a definitive answer, but my best guess is poor broadcast power control on the closed source blob resulting in other well managed cards (hosts or AP) turning down their sensitivity so they don't get blown by the power.

If I'm right:

It sounds like a non-fixable problem since it's in the blob unless you script a bunch of power control.

How could it theoretically be tested:

If you have three test boxes, I'ld test it like this

1) Install some tool that lets you see a packet's network's relative power.

I'm sure there's a CLI util to do it at a whack, but kismet is already installed on my laptops and gives me enough information.

2) With the broadcom box OFF, check the power of your box number 3 in kismet.

3) Next turn it off and place the broadcom box in the same location.

4) Check in kismet again. If my guess is right, the broadcom box should show significantly more signal strength.

RobotHumans
  • 29,530
  • Thank you for this hint! Here, grab the bounty for your effort :) – Rafał Cieślak Jun 17 '13 at 16:15
  • @RafałCieślak - just a follow-up. I can confirm that the iwlagn 5xxx I have evinces this behavior from my ath9k box. Sensitivity settings for my card are not exposed to userland though. it's iw sens something to see if your card exposes that functionality. – RobotHumans Jun 25 '13 at 17:17
  • oh, nice. Thanks for the tip with iw, though I really doubt this card would expose any supplemential functionality. – Rafał Cieślak Jun 25 '13 at 22:54
  • @RafałCieślak - on the other hand, your broadcom may let you turn down the broadcast power with iw set txpower. it might work. – RobotHumans Jun 26 '13 at 02:40