Re: No probe response from AP address after 500ms, disconnecting.
2010/1/15 Miklos Vajna vmik...@frugalware.org: On Fri, Jan 15, 2010 at 03:36:54AM +0100, Gábor Stefanik netrolller...@gmail.com wrote: 14E4:4315 is an LP-PHY (specifically, for most people,, it is the LP-PHY), for which 2.6.32 contains no calibration support, so performance/range problems can be expected. 2.6.33 should have improvements (part of calibration done), and 2.6.34 will (if I have time to do it) have full calibration support. What does calibration support mean? By performance problem I mean that after iwconfig eth0 essid it's working for ~5sec, and then it's down till the next iwconfig eth0 essid, so it's basically unusable. :/ By 2.6.33, you mean that I should give 2.6.33-rc4 a try? That's right. You can try wireless-testing as well, currently it contains same LP-PHY support level as 33-rc4. -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
On Fri, Jan 15, 2010 at 04:51:33AM +0100, Peter Stuge pe...@stuge.se wrote:
Should I include a section for the linksys (which has no encryption)
AP as well? if yes, what should it look like?
Yes, otherwise I don't think wpa_supplicant will do anything.
network={
ssid=linksys
key_mgmt=NONE
}
It could help to run it in foreground - you should see disconnect and
reauth then.
OK, when I add this, wpa_supplicant authenticates with the wpa ap on
startup. That's fine, but when I do an iwconfig eth0 essid linksys,
the wpa_supplicant stdout is:
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
ioctl[SIOCSIWSCAN]: Device or resource busy
Failed to initiate AP scan.
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:1b:2f:51:25:70 (SSID='wpa ap' freq=2462 MHz)
CTRL-EVENT-SCAN-RESULTS
Associated with 00:1b:2f:51:25:70
WPA: Key negotiation completed with 00:1b:2f:51:25:70 [PTK=CCMP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:1b:2f:51:25:70 completed (reauth) [id=0
id_str=]
The dmesg diff is:
--- a 2010-01-15 14:13:47.951510823 +0100
+++ b 2010-01-15 14:13:54.064510826 +0100
@@ -709,3 +709,11 @@
eth0: RX AssocResp from 00:1b:2f:51:25:70 (capab=0x431 status=0 aid=2)
eth0: associated
eth0: no IPv6 routers present
+eth0: deauthenticating from 00:1b:2f:51:25:70 by local choice (reason=3)
+eth0: direct probe to AP 00:1b:2f:51:25:70 (try 1)
+eth0: direct probe responded
+eth0: authenticate with AP 00:1b:2f:51:25:70 (try 1)
+eth0: authenticated
+eth0: associate with AP 00:1b:2f:51:25:70 (try 1)
+eth0: RX AssocResp from 00:1b:2f:51:25:70 (capab=0x431 status=0 aid=2)
+eth0: associated
The MAC you see is the wpa ap one, so basically I can't switch to the
linksys AP. (The MAC of the linksys AP - 00:12:17:D3:87:F5 - doesn't
show up in either outputs.)
pgpOw8Coak4D3.pgp
Description: PGP signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
On Fri, Jan 15, 2010 at 11:08:19AM +0100, Rafał Miłecki zaj...@gmail.com wrote: By 2.6.33, you mean that I should give 2.6.33-rc4 a try? That's right. You can try wireless-testing as well, currently it contains same LP-PHY support level as 33-rc4. How do I see what's improved? I just upgraded, and the only thing I could think of is to try iwconfig eth0 power off, but that's still not supported: # iwconfig eth0 power off Error for wireless request Set Power Management (8B2C) : SET failed on device eth0 ; Operation not supported. # uname -r 2.6.33-rc4 Thanks. pgpzvIL9Dw3jJ.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
W dniu 15 stycznia 2010 14:18 użytkownik Miklos Vajna vmik...@frugalware.org napisał: On Fri, Jan 15, 2010 at 11:08:19AM +0100, Rafał Miłecki zaj...@gmail.com wrote: By 2.6.33, you mean that I should give 2.6.33-rc4 a try? That's right. You can try wireless-testing as well, currently it contains same LP-PHY support level as 33-rc4. How do I see what's improved? I just upgraded, and the only thing I could think of is to try iwconfig eth0 power off, but that's still not supported: # iwconfig eth0 power off Error for wireless request Set Power Management (8B2C) : SET failed on device eth0 ; Operation not supported. # uname -r 2.6.33-rc4 Calibration is done initially, by + .pwork_15sec= b43_lpphy_op_pwork_15sec, + .pwork_60sec= lpphy_calibration, To see what has changed, use git log for git or changelog for kernel from archive. -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
On Fri, Jan 15, 2010 at 02:16:37PM +0100, Miklos Vajna vmik...@frugalware.org wrote: The MAC you see is the wpa ap one, so basically I can't switch to the linksys AP. (The MAC of the linksys AP - 00:12:17:D3:87:F5 - doesn't show up in either outputs.) I just tried what happens when the wpa ap is not available, just the linksys one. It still can't associate, but at least the MAC of the linksys shows up in the wpa_supplicant output: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:12:17:d3:87:f5 (SSID='linksys' freq=2462 MHz) Associated with 00:12:17:d3:87:f5 CTRL-EVENT-CONNECTED - Connection to 00:12:17:d3:87:f5 completed (reauth) [id=1 id_str=] So it's like: it's avilable for about 5 secs, then it goes down for 2, and this loops forever. :/ Again, this is with 2.6.33-rc4. Now my hope is that wireless-testing has some changes which are not in 2.6.33-rc4 and that solves this issue, but I'll wait for your experience first. :) Thanks, Miklos pgpuJtdSCENw5.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCHes] b43: all N-PHY patches
John, I spend whole day preparing all that patches to let you apply them easily, but I am not able to create and prepare 32 mails. Please exceptionally accept that patches sent as archive which I attach. That patches include fixes from all comments (Michael's mostly). For example (stopped grabbing after few): 0001: used Michael's suggestion to use fls 0002: Gábor Stefanik noticed we lack rev 14, but we didn't meet such device yet 0003: used Michael's suggestion to make tables static and drop definitions 0004: - 0005: formatted to match kernel coding style (thanks Michael for pointing out) 0006: we have to add some over-80-chars-lines there for readability 0007: - 0008: one table definition needs over 80 chars line 0009: this implements init with already corrected condition block noticed recently b43: N-PHY: implement getting TX gains: some lines over 80 chars I decided to add tables, structs, definitions as separated patches to make other cleaner. I didn't add any new code than what last posted. Just updated some comments to don't cause warning (//comment) and don't be more than 80 chars. 0001-b43-use-standard-fls-for-finding-the-most-significan.patch 0002-b43-add-new-SSB-s-core-id-for-BCM4328.patch 0003-b43-N-PHY-clean-table-init-check-PHY-rev.patch 0004-b43-N-PHY-add-shared-memory-offsets-definitions.patch 0005-b43-N-PHY-add-needed-struct-definitions.patch 0006-b43-N-PHY-add-missing-register-definitions.patch 0007-b43-N-PHY-add-global-variables-to-b43_phy_n-struct.patch 0008-b43-N-PHY-add-various-tables.patch 0009-b43-N-PHY-update-init-code-to-match-current-specs.patch 0010-b43-N-PHY-update-CCA-reset.patch 0011-b43-N-PHY-split-RSSI-calibration-into-2-functions-re.patch 0012-b43-N-PHY-add-clip-detection-reading-writing-and-som.patch 0013-b43-N-PHY-implement-RSSI-selection-and-offset-scalin.patch 0014-b43-N-PHY-add-RSSI-polling-and-setting-2055-radio-VC.patch 0015-b43-N-PHY-RSSI-calibration-for-rev-3.patch 0016-b43-N-PHY-implement-PA-overriding-RF-control-related.patch 0017-b43-N-PHY-add-RSSI-calibration-restore.patch 0018-b43-N-PHY-add-function-than-forces-not-staying-in-ca.patch 0019-b43-N-PHY-implement-RX-IQ-coeffs.patch 0020-b43-N-PHY-implement-workaround-for-TX-IQ.patch 0021-b43-N-PHY-implement-restoring-general-configuration.patch 0022-b43-N-PHY-implement-RX-IQ-estimation.patch 0023-b43-N-PHY-implement-calculating-RX-IQ-comp.patch 0024-b43-N-PHY-implement-getting-TX-gains.patch 0025-b43-N-PHY-add-TX-LP-FBW-TX-filter-40-related.patch 0026-b43-N-PHY-add-RX-radio-cores-calibration.patch 0027-b43-N-PHY-update-TX-calibration-ladder.patch 0028-b43-N-PHY-implement-calculating-IQ-gain-params.patch 0029-b43-N-PHY-add-huge-calculating-TX-IQ-LO.patch 0030-b43-N-PHY-add-RX-IQ-calibrationi-for-rev-3.patch 0031-b43-N-PHY-implement-TX-power-control-coef-setup.patch 0032-b43-N-PHY-drop-unused-definition-uncomment-needed-ca.patch -- Rafał b43-N-PHY.tar.gz Description: GNU Zip compressed data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: PHY Transmission error and radio turned off with b43legacy
On 01/15/2010 06:12 AM, Jochen Friedrich wrote: Daniel Schmitt wrote: hostapd doesn't continue to work after controller is restarted. I also have the problem that the wlan0-interface shall not be upped with ifconfig wlan0 0.0.0.0 up before starting hostapd, otherwise no beacons will be send. The interface must be down before starting hostapd. If I terminate a not daemonized hostapd with CTRL+C and restart if without rmmod+modprobe b43legacy, no beacons are sent, too. And I cannot connect the AP. This happens with the bleeding-edge wireless drivers 2009-11-13. I noticed the same on MN700 hardware running OpenWrt bleeding edge. The init scripts enable and disable wlan0 once before starting hostapd. Here, beacons are still being sent, but hostapd is unable to transmit any packet. When reloading b43legacy and starting hostapd manually it works, but only once. The attached patch resolves the problem for me. Daniel: Does this patch fix your problem as well? Has this problem been reported in the kernel bugzilla? If so, what is the number? How far back does this problem go? From the date of your compat-wireless package, it seems that 2.6.32 would be affected. How about 2.6.31? I have tested the patch on my system where it does no harm. I do not run that system as an AP and had not seen the problem. As soon as I have the answers to these questions, I will push the patch to wireless testing. Thanks for resolving this issue. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
Miklos Vajna wrote: reboot pending to try the latest wireless-testing, Please let me know if that helped (which git repo, which branch?). It did not help. I merged git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git master into my kernel, and have posted a message about it to the ath9k list. Miklos Vajna wrote: So it's like: it's avilable for about 5 secs, then it goes down for 2, and this loops forever. :/ My disconnects are nowhere nearly as frequent. I can provoke them with power management on but with it off my card is very usable. I suspect there may be a similar problem in the reception path of both ath9k and b43, leading to the same error in mac80211. Again, this is with 2.6.33-rc4. Now my hope is that wireless-testing has some changes which are not in 2.6.33-rc4 and that solves this issue, but I'll wait for your experience first. :) Not for me, but I'm also not exercising the b43 code at all, so maybe there is something for you.. Dunno. $ git log --oneline dec18..master drivers/net/wireless/b43|grep b43: 81f14df b43: LP-PHY: note and explain specs inconsistency 55afc80 Revert b43: Enforce DMA descriptor memory constraints b02914a b43: Allow PIO mode to be selected at module load 214ac9a b43: Remove reset after fatal DMA error df98a49 b43: fix two warnings c2ff581 b43: avoid PPC fault during resume 07681e2 b43: Rewrite DMA Tx status handling sanity checks 9bd568a b43: Enforce DMA descriptor memory constraints f54a520 b43: Rewrite TX bounce buffer handling c1b84ab b43: Remove deprecated 'qual' from returned RX status 2c0d610 b43: LP-PHY: Begin implementing calibration software RFKILL support 72f5f45 b43: use ieee80211_rx_ni() 88499ab b43: Optimize PIO scratchbuffer usage bdcf8ff b43: Comment unused functions lpphy_restore_dig_flt_state and lpphy_disable_rx_gain_override //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
On Sat, Jan 16, 2010 at 05:49:48AM +0100, Peter Stuge pe...@stuge.se wrote: Please let me know if that helped (which git repo, which branch?). It did not help. I merged git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git master into my kernel, and have posted a message about it to the ath9k list. :( OK, for now I think I'll just live with the binary driver (http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86_64-v5.10.91.9.3.tar.gz), I hate to use external modules, but that one at least works fine for me. pgpm7XwZJCYUI.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
