[PATCH] b43: fix b43_plcp_get_bitrate_idx_ofdm return type
This patch fixes the return type of b43_plcp_get_bitrate_idx_ofdm. If
the plcp contains an error, the function return value is 255 instead
of -1, and the packet was not dropped. This causes a warning in
__ieee80211_rx function because rate idx is out of range.
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/xmit.c 2009-03-22
17:25:19.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/xmit.c2009-03-22
17:25:40.0 +0100
@@ -50,7 +50,7 @@
}
/* Extract the bitrate index out of an OFDM PLCP header. */
-static u8 b43_plcp_get_bitrate_idx_ofdm(struct b43_plcp_hdr6 *plcp,
bool aphy)
+static int b43_plcp_get_bitrate_idx_ofdm(struct b43_plcp_hdr6 *plcp,
bool aphy)
{
int base = aphy ? 0 : 4;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: fix b43_plcp_get_bitrate_idx_ofdm return type
I hope it is ok.
Reported-by: Lorenzo Nava
Signed-off-by: Lorenzo Nava navalor...@gmail.com
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/xmit.c 2009-03-22
17:25:19.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/xmit.c2009-03-22
17:25:40.0 +0100
@@ -50,7 +50,7 @@
}
/* Extract the bitrate index out of an OFDM PLCP header. */
-static u8 b43_plcp_get_bitrate_idx_ofdm(struct b43_plcp_hdr6 *plcp,
bool aphy)
+static int b43_plcp_get_bitrate_idx_ofdm(struct b43_plcp_hdr6 *plcp,
bool aphy)
{
int base = aphy ? 0 : 4;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
Hmmm, I think the cookies should actually be more or less sequential, if QoS and PIO are not used. That's rather strange. Can you try with original fw and see what the cookies look like? Yes Michael, you're right... I tried with my 4318 and openfwwf-5.1 and cookie value goes from 00 to 7E and then restarts from 00. Here is a portion of what cookie header field looks like during a 1 ping/s transmission... ... |6420| |6620| |6820| |6A20| |6C20| |6E20| |7020| |7220| |7420| |7620| |7820| |7A20| |7C20| |7E20| |0020| |0220| |0420| |0620| |0820| |0C20| |0E20| |1020| ... Any idea on the reason why Larry has 2 cookie sequences mixed togheter? cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 31, 2009, at 12:23 PM, Michael Buesch wrote: On Saturday 31 January 2009 12:20:18 Lorenzo Nava wrote: Hmmm, I think the cookies should actually be more or less sequential, if QoS and PIO are not used. That's rather strange. Can you try with original fw and see what the cookies look like? Yes Michael, you're right... I tried with my 4318 and openfwwf-5.1 and cookie value goes from 00 to 7E and then restarts from 00. Here is a portion of what cookie header field looks like during a 1 ping/s transmission... ... |6420| |6620| |6820| |6A20| |6C20| |6E20| |7020| |7220| |7420| |7620| |7820| |7A20| |7C20| |7E20| |0020| |0220| |0420| |0620| |0820| |0C20| |0E20| |1020| ... Any idea on the reason why Larry has 2 cookie sequences mixed togheter? Why are your cookies endianness swapped? I forgot to say that these numbers are related to tx header, so I now need to check what report_tx_status send back... -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
Opensource firmware 5.1 works with my BCM4318; however, under heavy load with a ping running in one window and 10 second bursts of tcpperf transmissions in another, the kernel (2.6.29-rc2-wl) panicked by hitting the BUG at drivers/.../b43/dma.c:1386, which is in routine b43_dma_handle_txstatus. The specific condition is !meta-skb. I had similar problem while I was updating from version 351 to 410: the problem was related to some tx_header fields that had different offsets. Once shared memory definitions were updated I had no problem. I did a lot of tests and everything seems to be ok. Did you use encryption while doing your tests? cheers Lorenzo Nava ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Pardon me, but those filenames are identical and contain no numbers. Did those get stripped off somewhere? I did a mistake. The correct name are b0g0bsinitvals5.fw and b0g0initvals5.fw for revision 5. Sorry Cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[b43] opensource firmware
Hello everybody, we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf . Currently only binary version is available: don't worry, we will publish source code as soon as possible!! This first version is a test version: please try it and let us know if everythink is ok... Today we have also tested a new firmware version that works with WPA2- personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested on 4306 and 4318 PCI device). If anybody was interested please try new firmware with encryption and let us know if it works correctly, thanks! Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf Cheers Lorenzo Nava Francesco Gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Great! Thank you very much for the help... qos=0 parameter was still needed, so it is correct. cheers Lorenzo Nava. On Jan 14, 2009, at 4:57 PM, Buran Ayuthia wrote: My 4311 rev 01 card still works with the new initvals and firmware using WPA2-personal (both TKIP and CCMP) and without encyrption. I am still loading the module using modprobe b43 qos=0. Buran Ayuthia On Wed, Jan 14, 2009 at 9:30 AM, Lorenzo Nava navalor...@gmail.com wrote: Hello everybody, we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf . Currently only binary version is available: don't worry, we will publish source code as soon as possible!! This first version is a test version: please try it and let us know if everythink is ok... Today we have also tested a new firmware version that works with WPA2- personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested on 4306 and 4318 PCI device). If anybody was interested please try new firmware with encryption and let us know if it works correctly, thanks! Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf Cheers Lorenzo Nava Francesco Gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Hello everybody, today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with Broadcom 4306 chipset: BCM94306 802.11g (rev 03) PHY: Analog 2, Type 2, Revision 2 Radio: Manuf 0x17F, Version 0x2050, Revision 2 I did some tests and everything seems to work fine. I remember, once again, that OpenFWWF needs v480 initvals to work properly, and was tested on 2.6.27-rc5 kernel. During firmware development we used these devices Belkin PCMCIA 4306 card, Siemens PCI 4306 card. Belkin PCI 4306 card. ASUSTeK PCI 4318 card. and firmware seems to work fine. Everyone that is interested in testing OpenFWWF is welcome: please let us know if the firmware works correctly, and, if it doesn't, please report which kind of problems you had. Michael please let us know which kind of problem you had with your device. cheers Lorenzo Nava. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: fix QoS parameters initialization
This fixes the initialization of QoS parameters.
Reported-by: Lorenzo Nava, Francesco Gringoli
Signed-off-by: Francesco Gringoli [EMAIL PROTECTED]
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -569,7 +569,7 @@
#define B43_QOS_VOICE B43_QOS_PARAMS(3)
/* QOS parameter hardware data structure offsets. */
-#define B43_NR_QOSPARAMS 22
+#define B43_NR_QOSPARAMS 16
enum {
B43_QOSPARAM_TXOP = 0,
B43_QOSPARAM_CWMIN,
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
I'm not a reverse engineer, so I have no chance to check the original code to agree (or not) with you. Ok, the mail has Johannes in Cc. I hope that he can tell me if me and Francesco are right or not. Johannes please check it (I mean specs at http://bcm-v4.sipsolutions.net/802.11/QoS) , thank you. regards Lorenzo -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Hi everybody, I worked with the QoS parameters trying to understand why, checking them within the firmware, they don't seems to have the correct values even if they were set correctly by the driver. I think that there could be an error in the b43.h file: /* SHM offsets to the QOS data structures for the 4 different queues. */ #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ (B43_NR_QOSPARAMS * sizeof(u16) * (queue))) #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) #define B43_QOS_VIDEO B43_QOS_PARAMS(2) #define B43_QOS_VOICE B43_QOS_PARAMS(3) /* QOS parameter hardware data structure offsets. */ #define B43_NR_QOSPARAMS22 Each EDCF parameters set take up 32 byte (in the firmware the offset between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was expressed in byte). This means that the B43_NR_QOSPARAMS must be set to 16. With the value equal to 16 I can access correctly the aifs, cwcur, cwmax, etc within the firmware. What do you think about that? regards. Lorenzo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 firmware on 2 different card
Hello, I have a PC with 2 broadcom card installed on it. Here is the details of the cards: BCM4306 PCI card: [ 16.748857] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) [ 16.748866] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) [ 16.748874] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) [ 16.748882] ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) [ 16.748890] ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) BCM4318 PCI card: [ 16.823994] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) [ 16.824011] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243) [ 16.824042] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) [ 16.824050] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) Is it possible to make the cards work with different firmware? I'd like to use b43-open-firmware on the 4306 card and the normal firmware on the 4318 one. Thank you regards ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Problem with BCM4306 and hostapd
Hello, here is my problem: I have a BCM4306 (b43 driver) with kernel 2.6.25-rc9 and hostapd-0.6.3 installed. I tested the card performance with a simple test. The configuration of the network for the test was: an access point (my computer with BCM4306) and 2 clients (both using b43 driver). I used no encryption and work with 11M rate. I sent a CBR traffic (11M) from the 2 clients to the access point. When I started transmit packets from clients they disconnected from the AP until I didn't stop the transmission. Hostapd print this message that I've never seen before: _Failed to set beacon head/tail_ The problem is related to hostapd? Maybe when the AP processes a lot of traffic it was unable to generate beacons correctly? As the final goal of the experiment was to try 80211e performance, I tried the ad-hoc network mode, but I saw that the stations don't use qos support. Can I use qos with ad-hoc network? Thank you regards ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
