[ANN] b43 LP-PHY support (BCM4310/4312/4315) now ready for testing!

[ANN] b43 LP-PHY support (BCM4310/4312/4315) now ready for testing!

[Gábor Stefanik]

Hello World!

Great news for Broadcom BCM4310/4312/4315 (PCI 14e4:4315) users:
LP-PHY support is now at the point where it can be tested for functionality!

There are still problems with channel switching (a few patches ago,
only 802.11b/g channels 7 and 8 were working - no tests have been
performed since then) & TX is untested, but Larry has reported that he
can get scan results from channels 7 and 8. He doesn't have any AP on
these channels, so can't test if association works, but it should be
working too. It's also possible that recent patches have fixed the
channel switching bug, as the codepaths for channel switching have
been touched extensively, probably fixing a major miscalculation issue
("Qdiv roundup" was completely wrong).

So, go ahead, give it a try, and let's rock!

Note that the code in wireless-testing is enough to start testing,
however it's recommended that you apply the following 2 pending fixes:
http://marc.info/?l=linux-wireless&m=125061590101156&w=2 and
http://marc.info/?l=linux-wireless&m=125062611720517&w=2

Tomorrow's compat-wireless tarball, together with the above patches,
should also be good for testing. Not sure about today's tarball.

--Gábor

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) now ready for testing!

[Luis R. Rodriguez]

2009/8/18 Gábor Stefanik <netrolller.3d@gmail.com>:
> Hello World!
>
> Great news for Broadcom BCM4310/4312/4315 (PCI 14e4:4315) users:
> LP-PHY support is now at the point where it can be tested for functionality!

Hey great stuff :)

> There are still problems with channel switching (a few patches ago,
> only 802.11b/g channels 7 and 8 were working - no tests have been
> performed since then) & TX is untested, but Larry has reported that he
> can get scan results from channels 7 and 8. He doesn't have any AP on
> these channels, so can't test if association works, but it should be
> working too. It's also possible that recent patches have fixed the
> channel switching bug, as the codepaths for channel switching have
> been touched extensively, probably fixing a major miscalculation issue
> ("Qdiv roundup" was completely wrong).
>
> So, go ahead, give it a try, and let's rock!
>
> Note that the code in wireless-testing is enough to start testing,
> however it's recommended that you apply the following 2 pending fixes:
> http://marc.info/?l=linux-wireless&m=125061590101156&w=2 and
> http://marc.info/?l=linux-wireless&m=125062611720517&w=2
>
> Tomorrow's compat-wireless tarball, together with the above patches,
> should also be good for testing. Not sure about today's tarball.

Except CONFIG_B43_PHY_LP was not enabled on compat-wireless. But now
it is. I kicked the cronjob and enabled CONFIG_B43_PHY_LP on
config.mk, please report any issues.

http://wireless.kernel.org/en/users/Download/

BTW I think it would be nice for those users looking only for b43 for
us to update scripts/driver-select to have b43 as just one driver
option. Should be easy to add but I don't have time right now. Patch
is greatly welcomed though.

  Luis

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) now ready for testing!

[Luis R. Rodriguez]

2009/8/18 Luis R. Rodriguez <mcgrof@gmail.com>:
> 2009/8/18 Gábor Stefanik <netrolller.3d@gmail.com>:
>> Hello World!
>>
>> Great news for Broadcom BCM4310/4312/4315 (PCI 14e4:4315) users:
>> LP-PHY support is now at the point where it can be tested for functionality!
>
> Hey great stuff :)
>
>> There are still problems with channel switching (a few patches ago,
>> only 802.11b/g channels 7 and 8 were working - no tests have been
>> performed since then) & TX is untested, but Larry has reported that he
>> can get scan results from channels 7 and 8. He doesn't have any AP on
>> these channels, so can't test if association works, but it should be
>> working too. It's also possible that recent patches have fixed the
>> channel switching bug, as the codepaths for channel switching have
>> been touched extensively, probably fixing a major miscalculation issue
>> ("Qdiv roundup" was completely wrong).
>>
>> So, go ahead, give it a try, and let's rock!
>>
>> Note that the code in wireless-testing is enough to start testing,
>> however it's recommended that you apply the following 2 pending fixes:
>> http://marc.info/?l=linux-wireless&m=125061590101156&w=2 and
>> http://marc.info/?l=linux-wireless&m=125062611720517&w=2
>>
>> Tomorrow's compat-wireless tarball, together with the above patches,
>> should also be good for testing. Not sure about today's tarball.
>
> Except CONFIG_B43_PHY_LP was not enabled on compat-wireless. But now
> it is. I kicked the cronjob and enabled CONFIG_B43_PHY_LP on
> config.mk, please report any issues.
>
> http://wireless.kernel.org/en/users/Download/


Oh and I forgot the release info:

Origin remote URL:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
git-describe for wireless-testing.git says: v2.6.31-rc6-31586-g80289f0
This is a bleeding edge compat-wireless release based on: master-2009-08-18
This is compat-release: master-2009-08-18

  Luis

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) now ready for testing!

[Mark Huijgen]

Gábor Stefanik wrote:
> Hello World!
>
> Great news for Broadcom BCM4310/4312/4315 (PCI 14e4:4315) users:
> LP-PHY support is now at the point where it can be tested for functionality!
>
> So, go ahead, give it a try, and let's rock!
>   
Patches applied, well manually, cause I wasn't able to extract a working
version from the emails or the weblink provided. Whats the recommended
method to apply these git patches on mailinglists?

Here goes:

# modprobe b43 verbose=3
[ 1596.228088] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor
0x4243)
[ 1596.228100] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F,
vendor 0x4243)
[ 1596.228110] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243)
[ 1596.228120] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243)
[ 1596.248050] ssb: Found rev 1 PMU (capabilities 0x02A62F01)
[ 1596.256780] ssb: SPROM revision 8 detected.
[ 1596.276093] ssb: Sonics Silicon Backplane found on PCI device
0000:10:00.0
[ 1596.281108] b43-phy2: Broadcom 4312 WLAN found (core revision 15)
[ 1596.324046] b43-phy2 debug: Found PHY: Analog 6, Type 5, Revision 1
[ 1596.324060] b43-phy2 debug: Found Radio: Manuf 0x17F, Version 0x2062,
Revision 2
[ 1596.348233] phy2: Selected rate control algorithm 'minstrel'
[ 1596.348349] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID:
FW13 ]

# ifconfig wlan0 up
SIOCSIFFLAGS: Input/output error

[ 1689.356055] b43 ssb0:0: firmware: requesting b43/ucode15.fw
[ 1689.703918] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
[ 1689.710418] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
[ 1689.852058] b43-phy2: Loading firmware version 410.2160 (2007-05-26
15:32:10)
[ 1689.854963] b43-phy2 debug: b2062: Using crystal tab entry 19200 kHz.
[ 1689.855468] b43-phy2 debug: RC calib: Failed to switch to channel 7,
error = -5
[ 1689.860016] b43-phy2 debug: Switch to init channel failed, error = -5.
[ 1689.860543] b43-phy2 ERROR: PHY init: Channel switch to default failed

Interface is not coming up, so cannot scan:
# iwlist wlan0 scan
wlan0     Interface doesn't support scanning : Network is down


# iwconfig wlan0
wlan0     IEEE 802.11bg  Mode:Managed  Access Point: Not-Associated
          Tx-Power=0 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

# iw dev wlan0 info
Interface wlan0
        ifindex 5
        type managed

# iw phy phy2 info
Wiphy phy2
        Band 1:
                Frequencies:
                        * 2412 MHz [1] (27.0 dBm)
                        * 2417 MHz [2] (27.0 dBm)
                        * 2422 MHz [3] (27.0 dBm)
                        * 2427 MHz [4] (27.0 dBm)
                        * 2432 MHz [5] (27.0 dBm)
                        * 2437 MHz [6] (27.0 dBm)
                        * 2442 MHz [7] (27.0 dBm)
                        * 2447 MHz [8] (27.0 dBm)
                        * 2452 MHz [9] (27.0 dBm)
                        * 2457 MHz [10] (27.0 dBm)
                        * 2462 MHz [11] (27.0 dBm)
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
                Bitrates (non-HT):
                        * 1.0 Mbps
                        * 2.0 Mbps (short preamble supported)
                        * 5.5 Mbps (short preamble supported)
                        * 11.0 Mbps (short preamble supported)
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
        max # scan SSIDs: 4
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * WDS
                 * monitor
                 * mesh point

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) now ready for testing!

[Gábor Stefanik]

2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> Hello World!
>>
>> Great news for Broadcom BCM4310/4312/4315 (PCI 14e4:4315) users:
>> LP-PHY support is now at the point where it can be tested for functionality!
>>
>> So, go ahead, give it a try, and let's rock!
>>
> Patches applied, well manually, cause I wasn't able to extract a working
> version from the emails or the weblink provided. Whats the recommended
> method to apply these git patches on mailinglists?
>
> Here goes:
>
> # modprobe b43 verbose=3
> [ 1596.228088] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor
> 0x4243)
> [ 1596.228100] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F,
> vendor 0x4243)
> [ 1596.228110] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243)
> [ 1596.228120] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243)
> [ 1596.248050] ssb: Found rev 1 PMU (capabilities 0x02A62F01)
> [ 1596.256780] ssb: SPROM revision 8 detected.
> [ 1596.276093] ssb: Sonics Silicon Backplane found on PCI device
> 0000:10:00.0
> [ 1596.281108] b43-phy2: Broadcom 4312 WLAN found (core revision 15)
> [ 1596.324046] b43-phy2 debug: Found PHY: Analog 6, Type 5, Revision 1
> [ 1596.324060] b43-phy2 debug: Found Radio: Manuf 0x17F, Version 0x2062,
> Revision 2
> [ 1596.348233] phy2: Selected rate control algorithm 'minstrel'
> [ 1596.348349] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID:
> FW13 ]
>
> # ifconfig wlan0 up
> SIOCSIFFLAGS: Input/output error
>
> [ 1689.356055] b43 ssb0:0: firmware: requesting b43/ucode15.fw
> [ 1689.703918] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
> [ 1689.710418] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
> [ 1689.852058] b43-phy2: Loading firmware version 410.2160 (2007-05-26
> 15:32:10)
> [ 1689.854963] b43-phy2 debug: b2062: Using crystal tab entry 19200 kHz.
> [ 1689.855468] b43-phy2 debug: RC calib: Failed to switch to channel 7,
> error = -5
> [ 1689.860016] b43-phy2 debug: Switch to init channel failed, error = -5.

Hmm, error -5 is EIO, which in the channel switch code is used to
represent "PLL charge pump out of range". This is specifically the
error I was trying to fix... could you try without the 2 extra
patches? Maybe I did something wrong. (Without the 2 patches, channels
1..6 and 9..11 (12...14 not tested) throw this error, but channels 7
and 8 work.)

Also try extracting firmware from
ftp://downloads.netgear.com/files/GPL/WNDR3300-V1.0.29_gpl_src.zip's
wl_apsta.o file (newer than the one on mirror.openwrt.org - you may
need to add the extraction defines to fwcutter first; there is a
script in the fwcutter git tree, probably also in tarballs, that
generates extraction lists.) This is the firmware the specs are
written for; it's possible that the current firmware is simply not
good for LP-PHY (or maybe it needs code based on older specs).

> [ 1689.860543] b43-phy2 ERROR: PHY init: Channel switch to default failed
>
> Interface is not coming up, so cannot scan:
> # iwlist wlan0 scan
> wlan0     Interface doesn't support scanning : Network is down

When testing mac80211 drivers, always use "iw dev wlan0 scan", not
"iwlist wlan0 scan". (Though this shouldn't affect your results in
this case.)

Try bringing up the interface in monitor mode.
Also, try changing get_default_chan to return 7 instead of 1.

>
>
> # iwconfig wlan0
> wlan0     IEEE 802.11bg  Mode:Managed  Access Point: Not-Associated
>          Tx-Power=0 dBm
>          Retry  long limit:7   RTS thr:off   Fragment thr:off
>          Encryption key:off
>          Power Management:off
>
> # iw dev wlan0 info
> Interface wlan0
>        ifindex 5
>        type managed
>
> # iw phy phy2 info
> Wiphy phy2
>        Band 1:
>                Frequencies:
>                        * 2412 MHz [1] (27.0 dBm)
>                        * 2417 MHz [2] (27.0 dBm)
>                        * 2422 MHz [3] (27.0 dBm)
>                        * 2427 MHz [4] (27.0 dBm)
>                        * 2432 MHz [5] (27.0 dBm)
>                        * 2437 MHz [6] (27.0 dBm)
>                        * 2442 MHz [7] (27.0 dBm)
>                        * 2447 MHz [8] (27.0 dBm)
>                        * 2452 MHz [9] (27.0 dBm)
>                        * 2457 MHz [10] (27.0 dBm)
>                        * 2462 MHz [11] (27.0 dBm)
>                        * 2467 MHz [12] (disabled)
>                        * 2472 MHz [13] (disabled)
>                        * 2484 MHz [14] (disabled)
>                Bitrates (non-HT):
>                        * 1.0 Mbps
>                        * 2.0 Mbps (short preamble supported)
>                        * 5.5 Mbps (short preamble supported)
>                        * 11.0 Mbps (short preamble supported)
>                        * 6.0 Mbps
>                        * 9.0 Mbps
>                        * 12.0 Mbps
>                        * 18.0 Mbps
>                        * 24.0 Mbps
>                        * 36.0 Mbps
>                        * 48.0 Mbps
>                        * 54.0 Mbps
>        max # scan SSIDs: 4
>        Supported interface modes:
>                 * IBSS
>                 * managed
>                 * AP
>                 * AP/VLAN
>                 * WDS
>                 * monitor
>                 * mesh point
>
>
>
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Mark Huijgen]

Gábor Stefanik wrote:
> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>   
>> Gábor Stefanik wrote:
>>     
>>> Hello World!
>>>
>>> Great news for Broadcom BCM4310/4312/4315 (PCI 14e4:4315) users:
>>> LP-PHY support is now at the point where it can be tested for functionality!
>>>
>>> So, go ahead, give it a try, and let's rock!
>>>
>>>       
>> Patches applied, well manually, cause I wasn't able to extract a working
>> version from the emails or the weblink provided. Whats the recommended
>> method to apply these git patches on mailinglists?
>>
>> Here goes:
>>
>> # modprobe b43 verbose=3
>> [ 1596.228088] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor
>> 0x4243)
>> [ 1596.228100] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F,
>> vendor 0x4243)
>> [ 1596.228110] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243)
>> [ 1596.228120] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243)
>> [ 1596.248050] ssb: Found rev 1 PMU (capabilities 0x02A62F01)
>> [ 1596.256780] ssb: SPROM revision 8 detected.
>> [ 1596.276093] ssb: Sonics Silicon Backplane found on PCI device
>> 0000:10:00.0
>> [ 1596.281108] b43-phy2: Broadcom 4312 WLAN found (core revision 15)
>> [ 1596.324046] b43-phy2 debug: Found PHY: Analog 6, Type 5, Revision 1
>> [ 1596.324060] b43-phy2 debug: Found Radio: Manuf 0x17F, Version 0x2062,
>> Revision 2
>> [ 1596.348233] phy2: Selected rate control algorithm 'minstrel'
>> [ 1596.348349] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID:
>> FW13 ]
>>
>> # ifconfig wlan0 up
>> SIOCSIFFLAGS: Input/output error
>>
>> [ 1689.356055] b43 ssb0:0: firmware: requesting b43/ucode15.fw
>> [ 1689.703918] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
>> [ 1689.710418] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
>> [ 1689.852058] b43-phy2: Loading firmware version 410.2160 (2007-05-26
>> 15:32:10)
>> [ 1689.854963] b43-phy2 debug: b2062: Using crystal tab entry 19200 kHz.
>> [ 1689.855468] b43-phy2 debug: RC calib: Failed to switch to channel 7,
>> error = -5
>> [ 1689.860016] b43-phy2 debug: Switch to init channel failed, error = -5.
>>     
>
> Hmm, error -5 is EIO, which in the channel switch code is used to
> represent "PLL charge pump out of range". This is specifically the
> error I was trying to fix... could you try without the 2 extra
> patches? Maybe I did something wrong. (Without the 2 patches, channels
> 1..6 and 9..11 (12...14 not tested) throw this error, but channels 7
> and 8 work.)
>   
Same error without the patches, but 1 less error in dmesg. The 'RC
calib: Failed to switch to channel 7, error = -5' is gone now.
> Also try extracting firmware from
> ftp://downloads.netgear.com/files/GPL/WNDR3300-V1.0.29_gpl_src.zip's
> wl_apsta.o file (newer than the one on mirror.openwrt.org - you may
> need to add the extraction defines to fwcutter first; there is a
> script in the fwcutter git tree, probably also in tarballs, that
> generates extraction lists.) This is the firmware the specs are
> written for; it's possible that the current firmware is simply not
> good for LP-PHY (or maybe it needs code based on older specs).
>   
After running the included python script, patching the cutter and
extracting firmware, I now get ucode version 478.104 in dmesg. Next test
is also without the 2 patches. Following log is from modprobe+ifconfig
wlan0 up:

[14600.712104] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor
0x4243)
[14600.712116] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F,
vendor 0x4243)
[14600.712126] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243)
[14600.712136] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243)
[14600.732052] ssb: Found rev 1 PMU (capabilities 0x02A62F01)
[14600.740727] ssb: SPROM revision 8 detected.
[14600.760093] ssb: Sonics Silicon Backplane found on PCI device
0000:10:00.0
[14600.816481] b43-phy5: Broadcom 4312 WLAN found (core revision 15)
[14600.860044] b43-phy5 debug: Found PHY: Analog 6, Type 5, Revision 1
[14600.860058] b43-phy5 debug: Found Radio: Manuf 0x17F, Version 0x2062,
Revision 2
[14600.884250] phy5: Selected rate control algorithm 'minstrel'
[14600.884367] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID:
FW13 ]
[14611.192054] b43 ssb0:0: firmware: requesting b43/ucode15.fw
[14611.206016] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
[14611.211387] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
[14611.364058] b43-phy5: Loading firmware version 478.104 (2008-07-01
00:50:23)
[14611.367051] b43-phy5 debug: b2062: Using crystal tab entry 19200 kHz.
[14611.371875] b43-phy5 debug: Switch to init channel failed, error = -5.
[14611.372406] b43-phy5 ERROR: PHY init: Channel switch to default failed

Still the "SIOCSIFFLAGS: Input/output error" on ifconfig wlan0 up.


>   
>> [ 1689.860543] b43-phy2 ERROR: PHY init: Channel switch to default failed
>>
>> Interface is not coming up, so cannot scan:
>> # iwlist wlan0 scan
>> wlan0     Interface doesn't support scanning : Network is down
>>     
>
> When testing mac80211 drivers, always use "iw dev wlan0 scan", not
> "iwlist wlan0 scan". (Though this shouldn't affect your results in
> this case.)
>   
OK will do. Never used iw before your other mail about iw phy and friends :)
> Try bringing up the interface in monitor mode.
> Also, try changing get_default_chan to return 7 instead of 1.
>   
Tested default_chan 7, *with* the 2 patches and the interface comes up!
Scan results show a lot of the AP's around here, but only AP's of
channel 6 and higher.
The closest AP here is actually on channel 1 and is not showing. It
seems there is a problem with channel 1?

Dmesg for modprobe+ifconfig wlan0 up:
[  478.516094] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor
0x4243)
[  478.516106] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F,
vendor 0x4243)
[  478.516116] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243)
[  478.516125] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243)
[  478.536053] ssb: Found rev 1 PMU (capabilities 0x02A62F01)
[  478.544729] ssb: SPROM revision 8 detected.
[  478.564094] ssb: Sonics Silicon Backplane found on PCI device
0000:10:00.0
[  478.569257] b43-phy3: Broadcom 4312 WLAN found (core revision 15)
[  478.612046] b43-phy3 debug: Found PHY: Analog 6, Type 5, Revision 1
[  478.612061] b43-phy3 debug: Found Radio: Manuf 0x17F, Version 0x2062,
Revision 2
[  478.636235] phy3: Selected rate control algorithm 'minstrel'
[  478.636347] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID:
FW13 ]
[  483.116055] b43 ssb0:0: firmware: requesting b43/ucode15.fw
[  483.120545] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
[  483.127002] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
[  483.280059] b43-phy3: Loading firmware version 478.104 (2008-07-01
00:50:23)
[  483.283053] b43-phy3 debug: b2062: Using crystal tab entry 19200 kHz.
[  483.296062] b43-phy3 debug: Chip initialized
[  483.296272] b43-phy3 debug: 64-bit DMA initialized
[  483.317545] Registered led device: b43-phy3::tx
[  483.317568] Registered led device: b43-phy3::rx
[  483.317589] Registered led device: b43-phy3::radio
[  483.317649] b43-phy3 debug: Wireless interface started
[  483.317669] b43-phy3 debug: Adding Interface type 2

# wpa_supplicant -Dwext -i wlan0 -c /etc/wpa_supplicant.conf
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 4 value 0x0 - Trying to associate with 00:30:f1:f9:10:45
(SSID='default' freq=2462 MHz)
Associated with 00:30:f1:f9:10:45
WPA: Key negotiation completed with 00:30:f1:f9:10:45 [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:30:f1:f9:10:45 completed (auth)
[id=0 id_str=]

Well, what do you know, it actually does WPA authentication already!
Means TX must be working too.
I am also able to get an IP address with a dhcp client.

dmesg from wpa_supplicant part:
[  618.820622] wlan0: direct probe to AP 00:30:f1:f9:10:45 (try 1)
[  618.824200] wlan0 direct probe responded
[  618.824204] wlan0: authenticate with AP 00:30:f1:f9:10:45 (try 1)
[  618.825886] wlan0: authenticated
[  618.825902] wlan0: associate with AP 00:30:f1:f9:10:45 (try 1)
[  618.828148] wlan0: RX AssocResp from 00:30:f1:f9:10:45 (capab=0x431
status=0 aid=10)
[  618.828151] wlan0: associated

This AP is on channel 11.

I don't have time for further testing today, but results are promising!

Mark

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Wed, 2009-08-19 at 14:43 +0200, Mark Huijgen wrote:

> After running the included python script, patching the cutter and
> extracting firmware, I now get ucode version 478.104 in dmesg. Next test
> is also without the 2 patches. Following log is from modprobe+ifconfig
> wlan0 up:

Not really surprising, the firmware is for the MAC _only_, it doesn't
really ever touch the PHY, so it's very unlikely to matter.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Gábor Stefanik]

On Wed, Aug 19, 2009 at 3:04 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-19 at 14:43 +0200, Mark Huijgen wrote:
>
>> After running the included python script, patching the cutter and
>> extracting firmware, I now get ucode version 478.104 in dmesg. Next test
>> is also without the 2 patches. Following log is from modprobe+ifconfig
>> wlan0 up:
>
> Not really surprising, the firmware is for the MAC _only_, it doesn't
> really ever touch the PHY, so it's very unlikely to matter.
>
> johannes
>

Actually, the output does change with the new firmware.

Current outputs:
1. Patches not applied, old firmware, default chan = 1: the channel
switch to 7 during calibration works, but nothing else.
2. Patches applied, old firmware, default chan = 1: no channels work
(not even the channel 7 switch in the calibration routine), ifup
fails.
3. Patches not applied, new firmware, default chan = 1 (I got this
from Larry in private mail): only channels 7 and 8 work, but ifup
works(?).
(4. Patches applied, new firmware, default chan = 1: please test!)
(5. Patches not applied, old firmware, default chan = 7: probably ifup
succeeds, but only channel 7 works. Not tested.)
(6. Patches applied, old firmware, default chan = 7: unknown, probably
doesn't work at all.)
(7. Patches not applied, new firmware, default chan = 7: Unknown.)
8. Patches applied, new firmware, default chan = 7: interface comes
up, scans (but only channels 6 and above show results), associates to
WPA AP on channel 11 and gets DHCP address (meaning, both TX and RX
working)!

Notice that 2 and 8 only differ in the FW ver and the default channel,
and in 8 (with new firmware), the switch to channel 7 during RC
calibration (before the switch to default channel) works - in 2, it
fails. Looks like the routines reverse-engineered from the newer
driver depend on the firmware included in that driver; or maybe the
old firmware simply doesn't properly handle LP-PHY. Initvals are also
a possible candidate for this. (Larry, what do you think about this?)

Mark, could you produce a dmesg output with the new firmware, patches
applied, and channel set to 1? Post the output of dmesg after scanning
& probably associating, if possible. (Scan/assoc may produce messages
in dmesg.)

(The news about TX working is great by the way!)

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Mark Huijgen]

Gábor Stefanik wrote:
> Mark, could you produce a dmesg output with the new firmware, patches
> applied, and channel set to 1? Post the output of dmesg after scanning
> & probably associating, if possible. (Scan/assoc may produce messages
> in dmesg.)
>   
I tested this already, but with default chan set to 1, I cannot get the
interface up.
This is somewhere in my mail, but it got a bit messy after I noticed
that after
changing some of the code my modules got installed in another directory
(-dirty).

I just restarted the notebook, but now the results are different again...

New firmware, with patches applied and default channel 7:
[   72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
00:50:23)
[   72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
error = -5
[   72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.

Recompile module with default chan 1, patches still applied and new
firmware,
# modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up

[  430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.

Recompile again, but with default chan back to 7, still patched and
still new firmware.
So same as in first situation:
# modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up

[  524.748062] b43-phy3 debug: Chip initialized

And I can get my interface up and working!

Without this procedure I have not been able to get a working chip. Seems
the partially
initialized state after each try, allows the next try to get a bit
further. And together with
the default channel switching between 1 and 7, I get a working chip, but
a chip that does
not seem to be able to find my AP thats on channel 1.

If I now change default chan to 1 again, I am getting the same error as
in step 2 above.
I have not been able to get the interface up with default chan set to 1.

Mark

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Gábor Stefanik]

2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> Mark, could you produce a dmesg output with the new firmware, patches
>> applied, and channel set to 1? Post the output of dmesg after scanning
>> & probably associating, if possible. (Scan/assoc may produce messages
>> in dmesg.)
>>
> I tested this already, but with default chan set to 1, I cannot get the
> interface up.
> This is somewhere in my mail, but it got a bit messy after I noticed
> that after
> changing some of the code my modules got installed in another directory
> (-dirty).
>
> I just restarted the notebook, but now the results are different again...
>
> New firmware, with patches applied and default channel 7:
> [   72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
> 00:50:23)
> [   72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
> error = -5
> [   72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>
> Recompile module with default chan 1, patches still applied and new
> firmware,
> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>
> [  430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>
> Recompile again, but with default chan back to 7, still patched and
> still new firmware.
> So same as in first situation:
> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>
> [  524.748062] b43-phy3 debug: Chip initialized
>
> And I can get my interface up and working!
>
> Without this procedure I have not been able to get a working chip. Seems
> the partially
> initialized state after each try, allows the next try to get a bit
> further. And together with
> the default channel switching between 1 and 7, I get a working chip, but
> a chip that does
> not seem to be able to find my AP thats on channel 1.
>
> If I now change default chan to 1 again, I am getting the same error as
> in step 2 above.
> I have not been able to get the interface up with default chan set to 1.
>
> Mark
>
>

What do you see in dmesg after running a scan?

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Mark Huijgen]

Gábor Stefanik wrote:
> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>   
>> Gábor Stefanik wrote:
>>     
>>> Mark, could you produce a dmesg output with the new firmware, patches
>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>> & probably associating, if possible. (Scan/assoc may produce messages
>>> in dmesg.)
>>>
>>>       
>> I tested this already, but with default chan set to 1, I cannot get the
>> interface up.
>> This is somewhere in my mail, but it got a bit messy after I noticed
>> that after
>> changing some of the code my modules got installed in another directory
>> (-dirty).
>>
>> I just restarted the notebook, but now the results are different again...
>>
>> New firmware, with patches applied and default channel 7:
>> [   72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>> 00:50:23)
>> [   72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>> error = -5
>> [   72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>
>> Recompile module with default chan 1, patches still applied and new
>> firmware,
>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>
>> [  430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>
>> Recompile again, but with default chan back to 7, still patched and
>> still new firmware.
>> So same as in first situation:
>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>
>> [  524.748062] b43-phy3 debug: Chip initialized
>>
>> And I can get my interface up and working!
>>
>> Without this procedure I have not been able to get a working chip. Seems
>> the partially
>> initialized state after each try, allows the next try to get a bit
>> further. And together with
>> the default channel switching between 1 and 7, I get a working chip, but
>> a chip that does
>> not seem to be able to find my AP thats on channel 1.
>>
>> If I now change default chan to 1 again, I am getting the same error as
>> in step 2 above.
>> I have not been able to get the interface up with default chan set to 1.
>>
>> Mark
>>
>>
>>     
>
> What do you see in dmesg after running a scan?
>   
After step 2, interface cannot be brought up:
# iw dev wlan0 scan
command failed: Network is down (-100)

No extra output in dmesg

After step 3 (so with default chan 7 again), interface comes up and I
can scan:
# iw dev wlan0 scan
<<list of scan results>>

No extra output generated in dmesg.

I must add that I do not have debugging messages enabled for any
mac80211 related options, only for b43 module.

Mark

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Gábor Stefanik]

2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>
>>> Gábor Stefanik wrote:
>>>
>>>> Mark, could you produce a dmesg output with the new firmware, patches
>>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>>> & probably associating, if possible. (Scan/assoc may produce messages
>>>> in dmesg.)
>>>>
>>>>
>>> I tested this already, but with default chan set to 1, I cannot get the
>>> interface up.
>>> This is somewhere in my mail, but it got a bit messy after I noticed
>>> that after
>>> changing some of the code my modules got installed in another directory
>>> (-dirty).
>>>
>>> I just restarted the notebook, but now the results are different again...
>>>
>>> New firmware, with patches applied and default channel 7:
>>> [   72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>>> 00:50:23)
>>> [   72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>>> error = -5
>>> [   72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>>
>>> Recompile module with default chan 1, patches still applied and new
>>> firmware,
>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>
>>> [  430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>>
>>> Recompile again, but with default chan back to 7, still patched and
>>> still new firmware.
>>> So same as in first situation:
>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>
>>> [  524.748062] b43-phy3 debug: Chip initialized
>>>
>>> And I can get my interface up and working!
>>>
>>> Without this procedure I have not been able to get a working chip. Seems
>>> the partially
>>> initialized state after each try, allows the next try to get a bit
>>> further. And together with
>>> the default channel switching between 1 and 7, I get a working chip, but
>>> a chip that does
>>> not seem to be able to find my AP thats on channel 1.
>>>
>>> If I now change default chan to 1 again, I am getting the same error as
>>> in step 2 above.
>>> I have not been able to get the interface up with default chan set to 1.
>>>
>>> Mark
>>>
>>>
>>>
>>
>> What do you see in dmesg after running a scan?
>>
> After step 2, interface cannot be brought up:
> # iw dev wlan0 scan
> command failed: Network is down (-100)
>
> No extra output in dmesg
>
> After step 3 (so with default chan 7 again), interface comes up and I
> can scan:
> # iw dev wlan0 scan
> <<list of scan results>>
>
> No extra output generated in dmesg.
>
> I must add that I do not have debugging messages enabled for any
> mac80211 related options, only for b43 module.

That's not needed.

However, try "iw dev wlan0 scan trigger".

Also, try switching to all B/G channels manually.

One more thing to try is create a monitor interface and run kismet on
it. In addition, you can use aireplay-ng on the monitor interface to
test TX.

>
> Mark
>
>
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Mark Huijgen]

Gábor Stefanik wrote:
> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>   
>> Gábor Stefanik wrote:
>>     
>>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>>
>>>       
>>>> Gábor Stefanik wrote:
>>>>
>>>>         
>>>>> Mark, could you produce a dmesg output with the new firmware, patches
>>>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>>>> & probably associating, if possible. (Scan/assoc may produce messages
>>>>> in dmesg.)
>>>>>
>>>>>
>>>>>           
>>>> I tested this already, but with default chan set to 1, I cannot get the
>>>> interface up.
>>>> This is somewhere in my mail, but it got a bit messy after I noticed
>>>> that after
>>>> changing some of the code my modules got installed in another directory
>>>> (-dirty).
>>>>
>>>> I just restarted the notebook, but now the results are different again...
>>>>
>>>> New firmware, with patches applied and default channel 7:
>>>> [   72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>>>> 00:50:23)
>>>> [   72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>>>> error = -5
>>>> [   72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>>>
>>>> Recompile module with default chan 1, patches still applied and new
>>>> firmware,
>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>
>>>> [  430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>>>
>>>> Recompile again, but with default chan back to 7, still patched and
>>>> still new firmware.
>>>> So same as in first situation:
>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>
>>>> [  524.748062] b43-phy3 debug: Chip initialized
>>>>
>>>> And I can get my interface up and working!
>>>>
>>>> Without this procedure I have not been able to get a working chip. Seems
>>>> the partially
>>>> initialized state after each try, allows the next try to get a bit
>>>> further. And together with
>>>> the default channel switching between 1 and 7, I get a working chip, but
>>>> a chip that does
>>>> not seem to be able to find my AP thats on channel 1.
>>>>
>>>> If I now change default chan to 1 again, I am getting the same error as
>>>> in step 2 above.
>>>> I have not been able to get the interface up with default chan set to 1.
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>>         
>>> What do you see in dmesg after running a scan?
>>>
>>>       
>> After step 2, interface cannot be brought up:
>> # iw dev wlan0 scan
>> command failed: Network is down (-100)
>>
>> No extra output in dmesg
>>
>> After step 3 (so with default chan 7 again), interface comes up and I
>> can scan:
>> # iw dev wlan0 scan
>> <<list of scan results>>
>>
>> No extra output generated in dmesg.
>>
>> I must add that I do not have debugging messages enabled for any
>> mac80211 related options, only for b43 module.
>>     
>
> That's not needed.
>
> However, try "iw dev wlan0 scan trigger".
>
> Also, try switching to all B/G channels manually.
>   
To summarize, all cases with patches and new firmware:
case 1: cold boot with default channel 7, RC calib error and 'init
channel failed' error,
case 2: recompile+reload b43 with default channel 1, just 'init channel
failed' error,
case 3: recompile+reload b43 with default channel 7, works


You mean 'iw dev wlan0 set channel 1' for example?

In case 2 (with default chan 1), ifconfig wlan0 gives error
"SIOCSIFFLAGS: Input/output error"

# iw dev wlan0 set channel 1
no output generated, also nothing in dmesg

# iw dev wlan0 scan trigger
command failed: Network is down (-100)
nothing in dmesg.

Both commands do not give any output in dmesg in case 3 either.

Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
argument (-22)', which is expected I think.



> One more thing to try is create a monitor interface and run kismet on
> it. In addition, you can use aireplay-ng on the monitor interface to
> test TX.
>   
Never done anything with monitor mode before, so when I have some time
I'll look into it.

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Gábor Stefanik]

2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>
>>> Gábor Stefanik wrote:
>>>
>>>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>>>
>>>>
>>>>> Gábor Stefanik wrote:
>>>>>
>>>>>
>>>>>> Mark, could you produce a dmesg output with the new firmware, patches
>>>>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>>>>> & probably associating, if possible. (Scan/assoc may produce messages
>>>>>> in dmesg.)
>>>>>>
>>>>>>
>>>>>>
>>>>> I tested this already, but with default chan set to 1, I cannot get the
>>>>> interface up.
>>>>> This is somewhere in my mail, but it got a bit messy after I noticed
>>>>> that after
>>>>> changing some of the code my modules got installed in another directory
>>>>> (-dirty).
>>>>>
>>>>> I just restarted the notebook, but now the results are different again...
>>>>>
>>>>> New firmware, with patches applied and default channel 7:
>>>>> [   72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>>>>> 00:50:23)
>>>>> [   72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>>>>> error = -5
>>>>> [   72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>>>>
>>>>> Recompile module with default chan 1, patches still applied and new
>>>>> firmware,
>>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>>
>>>>> [  430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>>>>
>>>>> Recompile again, but with default chan back to 7, still patched and
>>>>> still new firmware.
>>>>> So same as in first situation:
>>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>>
>>>>> [  524.748062] b43-phy3 debug: Chip initialized
>>>>>
>>>>> And I can get my interface up and working!
>>>>>
>>>>> Without this procedure I have not been able to get a working chip. Seems
>>>>> the partially
>>>>> initialized state after each try, allows the next try to get a bit
>>>>> further. And together with
>>>>> the default channel switching between 1 and 7, I get a working chip, but
>>>>> a chip that does
>>>>> not seem to be able to find my AP thats on channel 1.
>>>>>
>>>>> If I now change default chan to 1 again, I am getting the same error as
>>>>> in step 2 above.
>>>>> I have not been able to get the interface up with default chan set to 1.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>
>>>> What do you see in dmesg after running a scan?
>>>>
>>>>
>>> After step 2, interface cannot be brought up:
>>> # iw dev wlan0 scan
>>> command failed: Network is down (-100)
>>>
>>> No extra output in dmesg
>>>
>>> After step 3 (so with default chan 7 again), interface comes up and I
>>> can scan:
>>> # iw dev wlan0 scan
>>> <<list of scan results>>
>>>
>>> No extra output generated in dmesg.
>>>
>>> I must add that I do not have debugging messages enabled for any
>>> mac80211 related options, only for b43 module.
>>>
>>
>> That's not needed.
>>
>> However, try "iw dev wlan0 scan trigger".
>>
>> Also, try switching to all B/G channels manually.
>>
> To summarize, all cases with patches and new firmware:
> case 1: cold boot with default channel 7, RC calib error and 'init
> channel failed' error,
> case 2: recompile+reload b43 with default channel 1, just 'init channel
> failed' error,
> case 3: recompile+reload b43 with default channel 7, works
>
>
> You mean 'iw dev wlan0 set channel 1' for example?
>
> In case 2 (with default chan 1), ifconfig wlan0 gives error
> "SIOCSIFFLAGS: Input/output error"
>
> # iw dev wlan0 set channel 1
> no output generated, also nothing in dmesg
>
> # iw dev wlan0 scan trigger
> command failed: Network is down (-100)
> nothing in dmesg.
>
> Both commands do not give any output in dmesg in case 3 either.
>
> Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
> argument (-22)', which is expected I think.

Set your regulatory domain to something that allows higher channels
(e.g. iw reg set JP - this one unlocks channels 1-14 (14 is
CCK/802.11b only); or iw reg set HU - channels 1-13) to test channels
14 and up.

Also, test this:

Create a monitor interface (iw dev wlan0 interface add mon0 type monitor)
Up the interface (ifconfig mon0 up)
Set channel to 1 (iwconfig mon0 channel 1 or iw dev wlan0 set channel 1)
Run tcpdump on the interface (tcpdump -i mon0).

Try for other channel values as well. (You don't need to recreate the
interface for each channel, just use the channel-setting command to
switch the channel.) You should see packets on all channels.

Another thing to try: add a printk to b43_lpphy_op_set_channel and
print out new_channel. This will log all channel change requests
(including automatic ones) to dmesg, which can be helpful.

If you set your AP to channel 11, can you connect to it & use it as normal?

>
>
>
>> One more thing to try is create a monitor interface and run kismet on
>> it. In addition, you can use aireplay-ng on the monitor interface to
>> test TX.
>>
> Never done anything with monitor mode before, so when I have some time
> I'll look into it.
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Mark Huijgen]

Gábor Stefanik wrote:
> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>   
>> To summarize, all cases with patches and new firmware:
>> case 1: cold boot with default channel 7, RC calib error and 'init
>> channel failed' error,
>> case 2: recompile+reload b43 with default channel 1, just 'init channel
>> failed' error,
>> case 3: recompile+reload b43 with default channel 7, works
>>
>>
>> You mean 'iw dev wlan0 set channel 1' for example?
>>
>> In case 2 (with default chan 1), ifconfig wlan0 gives error
>> "SIOCSIFFLAGS: Input/output error"
>>
>> # iw dev wlan0 set channel 1
>> no output generated, also nothing in dmesg
>>
>> # iw dev wlan0 scan trigger
>> command failed: Network is down (-100)
>> nothing in dmesg.
>>
>> Both commands do not give any output in dmesg in case 3 either.
>>
>> Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
>> argument (-22)', which is expected I think.
>>     
>
> Set your regulatory domain to something that allows higher channels
> (e.g. iw reg set JP - this one unlocks channels 1-14 (14 is
> CCK/802.11b only); or iw reg set HU - channels 1-13) to test channels
> 14 and up.
>   
# iw reg set JP
[  606.879287] cfg80211: Calling CRDA for country: JP
# iw phy phy5 info
<<snip>>
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
<<snip>>

# iw dev wlan0 set channel 14
command failed: Invalid argument (-22)



> Also, test this:
>
> Create a monitor interface (iw dev wlan0 interface add mon0 type monitor)
> Up the interface (ifconfig mon0 up)
> Set channel to 1 (iwconfig mon0 channel 1 or iw dev wlan0 set channel 1)
> Run tcpdump on the interface (tcpdump -i mon0).
>   
This produces quite a lot of packages, small snippet:
08:35:31.676268 171437241us tsft 1.0 Mb/s 31 MHz (0x00a0) -82dB signal
0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
08:35:31.679047 171439995us tsft 1.0 Mb/s 31 MHz (0x00a0) -82dB signal
0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
08:35:31.691757 171454461us tsft 1.0 Mb/s 31 MHz (0x00a0) -72dB signal
0dB noise antenna 0 [0x0000000e] Data IV:8a27a7 Pad 20 KeyID 1
08:35:31.693722 171457076us tsft 2.0 Mb/s 31 MHz (0x00a0) -58dB signal
0dB noise antenna 0 [0x0000000e] Probe Request () [1.0* 2.0* 5.5* 11.0*
9.0 18.0 36.0 54.0 Mbit]
08:35:31.710293 171472955us tsft 1.0 Mb/s 31 MHz (0x00a0) -59dB signal
0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY

So channel 1 does receive packets it seems. Should I be able to see data
packets from another system thats associated and downloading from my AP
on channel 1? Protected by WPA. Or are they not shown?
I don't see any, only thin I notice is the number of pkgs/second is a
lot less when I'm downloading something on the other system.

If I cycle through the channels with iw dev mon0 set channel N, all
channels give similar output in tcpdump.

> Try for other channel values as well. (You don't need to recreate the
> interface for each channel, just use the channel-setting command to
> switch the channel.) You should see packets on all channels.
>
> Another thing to try: add a printk to b43_lpphy_op_set_channel and
> print out new_channel. This will log all channel change requests
> (including automatic ones) to dmesg, which can be helpful.
>   
Done, see further down in this mail.
> If you set your AP to channel 11, can you connect to it & use it as normal?
>   
After doing my tripple module load/recompile to switch default chan from
7->1->7,
yes, then everything seems to work on channel 11. Then all reloads with
default chan 7 still work fine,
but if I try a default chan of 1 again, it fails to bring the inteface up.

I cannot connect to my AP on channel 1, since it does not show up in the
scan results (on another system right beside it, with another type of
card, it does show up and work).


With the added printk in switch channel:

After cold boot with default chan 1:
[   70.066976] b43-phy1 debug: Switching to channel: 7
[   70.071314] b43-phy1 debug: Switching to channel: 1
[   70.071808] b43-phy1 debug: Switch to init channel failed, error = -5.
[   70.071844] b43-phy1 debug: Switching to channel: 1
[   70.072341] b43-phy1 ERROR: PHY init: Channel switch to default failed

After recompile with default chan 7:
[  226.810985] b43-phy2 debug: Switching to channel: 7
[  226.815320] b43-phy2 debug: Switching to channel: 7
[  226.815632] b43-phy2 debug: Switching to channel: 7
[  226.824062] b43-phy2 debug: Chip initialized
[  226.824274] b43-phy2 debug: 64-bit DMA initialized
[  226.845588] Registered led device: b43-phy2::tx
[  226.845610] Registered led device: b43-phy2::rx
[  226.845630] Registered led device: b43-phy2::radio
[  226.845696] b43-phy2 debug: Wireless interface started
[  226.845717] b43-phy2 debug: Adding Interface type 2
[  226.845812] b43-phy2 debug: Switching to channel: 1

And a working interface.

Another cold boot, this time starting with default chan 7:
[  100.426965] b43-phy1 debug: Switching to channel: 7
[  100.431295] b43-phy1 debug: Switching to channel: 7
[  100.431607] b43-phy1 debug: Switching to channel: 7
[  100.440061] b43-phy1 debug: Chip initialized
[  100.440259] b43-phy1 debug: 64-bit DMA initialized
[  100.461545] Registered led device: b43-phy1::tx
[  100.461567] Registered led device: b43-phy1::rx
[  100.461587] Registered led device: b43-phy1::radio
[  100.461653] b43-phy1 debug: Wireless interface started
[  100.461673] b43-phy1 debug: Adding Interface type 2
[  100.461755] b43-phy1 debug: Switching to channel: 1

Working directly after boot ! Are the printk's slowing something down
enough to make it work better?
Note: phy0 is from autoloading on boot, no interface up attempts done,
just a reload with verbose=3.

Just to be sure I did another reboot, with autoloading disabled. Also
working right away with default channel 7.
Default channel 1 still no go, and also still not seeing any AP's on
channel 1 in scan results.

Mark

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Mark Huijgen]

What I forgot to mention, is that all tests in this mail were done with
the 410 firmware version.

Mark

Mark Huijgen wrote:
> Gábor Stefanik wrote:
>   
>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>   
>>     
>>> To summarize, all cases with patches and new firmware:
>>> case 1: cold boot with default channel 7, RC calib error and 'init
>>> channel failed' error,
>>> case 2: recompile+reload b43 with default channel 1, just 'init channel
>>> failed' error,
>>> case 3: recompile+reload b43 with default channel 7, works
>>>
>>>
>>> You mean 'iw dev wlan0 set channel 1' for example?
>>>
>>> In case 2 (with default chan 1), ifconfig wlan0 gives error
>>> "SIOCSIFFLAGS: Input/output error"
>>>
>>> # iw dev wlan0 set channel 1
>>> no output generated, also nothing in dmesg
>>>
>>> # iw dev wlan0 scan trigger
>>> command failed: Network is down (-100)
>>> nothing in dmesg.
>>>
>>> Both commands do not give any output in dmesg in case 3 either.
>>>
>>> Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
>>> argument (-22)', which is expected I think.
>>>     
>>>       
>> Set your regulatory domain to something that allows higher channels
>> (e.g. iw reg set JP - this one unlocks channels 1-14 (14 is
>> CCK/802.11b only); or iw reg set HU - channels 1-13) to test channels
>> 14 and up.
>>   
>>     
> # iw reg set JP
> [  606.879287] cfg80211: Calling CRDA for country: JP
> # iw phy phy5 info
> <<snip>>
>                         * 2467 MHz [12] (disabled)
>                         * 2472 MHz [13] (disabled)
>                         * 2484 MHz [14] (disabled)
> <<snip>>
>
> # iw dev wlan0 set channel 14
> command failed: Invalid argument (-22)
>
>
>
>   
>> Also, test this:
>>
>> Create a monitor interface (iw dev wlan0 interface add mon0 type monitor)
>> Up the interface (ifconfig mon0 up)
>> Set channel to 1 (iwconfig mon0 channel 1 or iw dev wlan0 set channel 1)
>> Run tcpdump on the interface (tcpdump -i mon0).
>>   
>>     
> This produces quite a lot of packages, small snippet:
> 08:35:31.676268 171437241us tsft 1.0 Mb/s 31 MHz (0x00a0) -82dB signal
> 0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
> 08:35:31.679047 171439995us tsft 1.0 Mb/s 31 MHz (0x00a0) -82dB signal
> 0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
> 08:35:31.691757 171454461us tsft 1.0 Mb/s 31 MHz (0x00a0) -72dB signal
> 0dB noise antenna 0 [0x0000000e] Data IV:8a27a7 Pad 20 KeyID 1
> 08:35:31.693722 171457076us tsft 2.0 Mb/s 31 MHz (0x00a0) -58dB signal
> 0dB noise antenna 0 [0x0000000e] Probe Request () [1.0* 2.0* 5.5* 11.0*
> 9.0 18.0 36.0 54.0 Mbit]
> 08:35:31.710293 171472955us tsft 1.0 Mb/s 31 MHz (0x00a0) -59dB signal
> 0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
>
> So channel 1 does receive packets it seems. Should I be able to see data
> packets from another system thats associated and downloading from my AP
> on channel 1? Protected by WPA. Or are they not shown?
> I don't see any, only thin I notice is the number of pkgs/second is a
> lot less when I'm downloading something on the other system.
>
> If I cycle through the channels with iw dev mon0 set channel N, all
> channels give similar output in tcpdump.
>
>   
>> Try for other channel values as well. (You don't need to recreate the
>> interface for each channel, just use the channel-setting command to
>> switch the channel.) You should see packets on all channels.
>>
>> Another thing to try: add a printk to b43_lpphy_op_set_channel and
>> print out new_channel. This will log all channel change requests
>> (including automatic ones) to dmesg, which can be helpful.
>>   
>>     
> Done, see further down in this mail.
>   
>> If you set your AP to channel 11, can you connect to it & use it as normal?
>>   
>>     
> After doing my tripple module load/recompile to switch default chan from
> 7->1->7,
> yes, then everything seems to work on channel 11. Then all reloads with
> default chan 7 still work fine,
> but if I try a default chan of 1 again, it fails to bring the inteface up.
>
> I cannot connect to my AP on channel 1, since it does not show up in the
> scan results (on another system right beside it, with another type of
> card, it does show up and work).
>
>
> With the added printk in switch channel:
>
> After cold boot with default chan 1:
> [   70.066976] b43-phy1 debug: Switching to channel: 7
> [   70.071314] b43-phy1 debug: Switching to channel: 1
> [   70.071808] b43-phy1 debug: Switch to init channel failed, error = -5.
> [   70.071844] b43-phy1 debug: Switching to channel: 1
> [   70.072341] b43-phy1 ERROR: PHY init: Channel switch to default failed
>
> After recompile with default chan 7:
> [  226.810985] b43-phy2 debug: Switching to channel: 7
> [  226.815320] b43-phy2 debug: Switching to channel: 7
> [  226.815632] b43-phy2 debug: Switching to channel: 7
> [  226.824062] b43-phy2 debug: Chip initialized
> [  226.824274] b43-phy2 debug: 64-bit DMA initialized
> [  226.845588] Registered led device: b43-phy2::tx
> [  226.845610] Registered led device: b43-phy2::rx
> [  226.845630] Registered led device: b43-phy2::radio
> [  226.845696] b43-phy2 debug: Wireless interface started
> [  226.845717] b43-phy2 debug: Adding Interface type 2
> [  226.845812] b43-phy2 debug: Switching to channel: 1
>
> And a working interface.
>
> Another cold boot, this time starting with default chan 7:
> [  100.426965] b43-phy1 debug: Switching to channel: 7
> [  100.431295] b43-phy1 debug: Switching to channel: 7
> [  100.431607] b43-phy1 debug: Switching to channel: 7
> [  100.440061] b43-phy1 debug: Chip initialized
> [  100.440259] b43-phy1 debug: 64-bit DMA initialized
> [  100.461545] Registered led device: b43-phy1::tx
> [  100.461567] Registered led device: b43-phy1::rx
> [  100.461587] Registered led device: b43-phy1::radio
> [  100.461653] b43-phy1 debug: Wireless interface started
> [  100.461673] b43-phy1 debug: Adding Interface type 2
> [  100.461755] b43-phy1 debug: Switching to channel: 1
>
> Working directly after boot ! Are the printk's slowing something down
> enough to make it work better?
> Note: phy0 is from autoloading on boot, no interface up attempts done,
> just a reload with verbose=3.
>
> Just to be sure I did another reboot, with autoloading disabled. Also
> working right away with default channel 7.
> Default channel 1 still no go, and also still not seeing any AP's on
> channel 1 in scan results.
>
> Mark
>
>
>   

Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!

[Gábor Stefanik]

2009/8/20 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>
>>> To summarize, all cases with patches and new firmware:
>>> case 1: cold boot with default channel 7, RC calib error and 'init
>>> channel failed' error,
>>> case 2: recompile+reload b43 with default channel 1, just 'init channel
>>> failed' error,
>>> case 3: recompile+reload b43 with default channel 7, works
>>>
>>>
>>> You mean 'iw dev wlan0 set channel 1' for example?
>>>
>>> In case 2 (with default chan 1), ifconfig wlan0 gives error
>>> "SIOCSIFFLAGS: Input/output error"
>>>
>>> # iw dev wlan0 set channel 1
>>> no output generated, also nothing in dmesg
>>>
>>> # iw dev wlan0 scan trigger
>>> command failed: Network is down (-100)
>>> nothing in dmesg.
>>>
>>> Both commands do not give any output in dmesg in case 3 either.
>>>
>>> Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
>>> argument (-22)', which is expected I think.
>>>
>>
>> Set your regulatory domain to something that allows higher channels
>> (e.g. iw reg set JP - this one unlocks channels 1-14 (14 is
>> CCK/802.11b only); or iw reg set HU - channels 1-13) to test channels
>> 14 and up.
>>
> # iw reg set JP
> [  606.879287] cfg80211: Calling CRDA for country: JP
> # iw phy phy5 info
> <<snip>>
>                        * 2467 MHz [12] (disabled)
>                        * 2472 MHz [13] (disabled)
>                        * 2484 MHz [14] (disabled)
> <<snip>>
>
> # iw dev wlan0 set channel 14
> command failed: Invalid argument (-22)
>
>
>
>> Also, test this:
>>
>> Create a monitor interface (iw dev wlan0 interface add mon0 type monitor)
>> Up the interface (ifconfig mon0 up)
>> Set channel to 1 (iwconfig mon0 channel 1 or iw dev wlan0 set channel 1)
>> Run tcpdump on the interface (tcpdump -i mon0).
>>
> This produces quite a lot of packages, small snippet:
> 08:35:31.676268 171437241us tsft 1.0 Mb/s 31 MHz (0x00a0) -82dB signal
> 0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
> 08:35:31.679047 171439995us tsft 1.0 Mb/s 31 MHz (0x00a0) -82dB signal
> 0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
> 08:35:31.691757 171454461us tsft 1.0 Mb/s 31 MHz (0x00a0) -72dB signal
> 0dB noise antenna 0 [0x0000000e] Data IV:8a27a7 Pad 20 KeyID 1
> 08:35:31.693722 171457076us tsft 2.0 Mb/s 31 MHz (0x00a0) -58dB signal
> 0dB noise antenna 0 [0x0000000e] Probe Request () [1.0* 2.0* 5.5* 11.0*
> 9.0 18.0 36.0 54.0 Mbit]
> 08:35:31.710293 171472955us tsft 1.0 Mb/s 31 MHz (0x00a0) -59dB signal
> 0dB noise antenna 0 [0x0000000e] Beacon ESS, PRIVACY
>
> So channel 1 does receive packets it seems. Should I be able to see data
> packets from another system thats associated and downloading from my AP
> on channel 1? Protected by WPA. Or are they not shown?
> I don't see any, only thin I notice is the number of pkgs/second is a
> lot less when I'm downloading something on the other system.
>
> If I cycle through the channels with iw dev mon0 set channel N, all
> channels give similar output in tcpdump.
>
>> Try for other channel values as well. (You don't need to recreate the
>> interface for each channel, just use the channel-setting command to
>> switch the channel.) You should see packets on all channels.
>>
>> Another thing to try: add a printk to b43_lpphy_op_set_channel and
>> print out new_channel. This will log all channel change requests
>> (including automatic ones) to dmesg, which can be helpful.
>>
> Done, see further down in this mail.
>> If you set your AP to channel 11, can you connect to it & use it as normal?
>>
> After doing my tripple module load/recompile to switch default chan from
> 7->1->7,
> yes, then everything seems to work on channel 11. Then all reloads with
> default chan 7 still work fine,
> but if I try a default chan of 1 again, it fails to bring the inteface up.
>
> I cannot connect to my AP on channel 1, since it does not show up in the
> scan results (on another system right beside it, with another type of
> card, it does show up and work).
>
>
> With the added printk in switch channel:
>
> After cold boot with default chan 1:
> [   70.066976] b43-phy1 debug: Switching to channel: 7
> [   70.071314] b43-phy1 debug: Switching to channel: 1
> [   70.071808] b43-phy1 debug: Switch to init channel failed, error = -5.
> [   70.071844] b43-phy1 debug: Switching to channel: 1
> [   70.072341] b43-phy1 ERROR: PHY init: Channel switch to default failed
>
> After recompile with default chan 7:
> [  226.810985] b43-phy2 debug: Switching to channel: 7
> [  226.815320] b43-phy2 debug: Switching to channel: 7
> [  226.815632] b43-phy2 debug: Switching to channel: 7
> [  226.824062] b43-phy2 debug: Chip initialized
> [  226.824274] b43-phy2 debug: 64-bit DMA initialized
> [  226.845588] Registered led device: b43-phy2::tx
> [  226.845610] Registered led device: b43-phy2::rx
> [  226.845630] Registered led device: b43-phy2::radio
> [  226.845696] b43-phy2 debug: Wireless interface started
> [  226.845717] b43-phy2 debug: Adding Interface type 2
> [  226.845812] b43-phy2 debug: Switching to channel: 1
>
> And a working interface.
>
> Another cold boot, this time starting with default chan 7:
> [  100.426965] b43-phy1 debug: Switching to channel: 7
> [  100.431295] b43-phy1 debug: Switching to channel: 7
> [  100.431607] b43-phy1 debug: Switching to channel: 7
> [  100.440061] b43-phy1 debug: Chip initialized
> [  100.440259] b43-phy1 debug: 64-bit DMA initialized
> [  100.461545] Registered led device: b43-phy1::tx
> [  100.461567] Registered led device: b43-phy1::rx
> [  100.461587] Registered led device: b43-phy1::radio
> [  100.461653] b43-phy1 debug: Wireless interface started
> [  100.461673] b43-phy1 debug: Adding Interface type 2
> [  100.461755] b43-phy1 debug: Switching to channel: 1

Could you add a printk to the error path in the channel tune process
for B2062? I'm not sure at all if this channel switch succeeds or
not...

>
> Working directly after boot ! Are the printk's slowing something down
> enough to make it work better?
> Note: phy0 is from autoloading on boot, no interface up attempts done,
> just a reload with verbose=3.
>
> Just to be sure I did another reboot, with autoloading disabled. Also
> working right away with default channel 7.
> Default channel 1 still no go, and also still not seeing any AP's on
> channel 1 in scan results.
>
> Mark
>
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)