Re: [OT] Git trouble

2008-09-03 Thread Pavel Roskin
On Tue, 2008-09-02 at 20:20 -0400, Celejar wrote:
 [This is off topic, but my entire reason for struggling with git is to
 help test patches to b43, so I beg the list's pardon for asking here.]
 
 I'm trying to maintain a git repository of wireless-testing, to test
 Michael's patches to b43.  The initial git-clone went fine, and I
 tested several patches successfully. I'm currently having a great deal
 of trouble trying to update my local repository via git-pull.  I've
 spent a while with the various git manpages (git-pull, git-clean,
 git-checkout, git-reset, git-tutorial, etc.), as well as with the
 wireless.kernel.org git-guide and with google, but I just can't seem to
 grok basic git operation.
 
 All I want to do is dump any changes I've made to the code, and then
 pull in an updated version, but I just can't make git do that.  I am
 getting all kinds of errors; google turns up other instances of them,
 but no straightforward solution.

You may be better off writing to linux-wireless about it.  As far as I
know, there was some botched update made to the tree made in the recent
days, but it have been fixed.

Anyway, many trees are updated in a non-linear way.  This means that you
may need to reset the tree to the remote tip:

git-reset --hard wireless-testing/master

This will lose your uncommitted changes.  If you have your changes in a
separate branch, you should be able to rebase your branch on top on the
newly updated version.

I recommend that you use StGIT for local patches.  While not strictly
required, it's a tool that is primarily designed to working with
patchsets.  It will pop all patches before updates, so that you should
be able to do any dangerous git commands and then push your patches on
top of the result.

If you have any advanced questions about git, please ask them in the git
list.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Broadcom's own driver: firmware?

2008-08-30 Thread Pavel Roskin
On Mon, 2008-08-25 at 11:08 -0700, Adam Williamson wrote:

 The license this driver is under is not F/OSS, but it's not as
 restrictive as the license on the Windows driver.

The instructions at http://wireless.kernel.org/en/users/Drivers/b43
don't refer to any Windows drivers.  They already refer to distributable
files.

 It explicitly allows
 redistribution, in unmodified form. So it wouldn't be okay to extract
 the firmware from this driver and just package that, but distros *could*
 package the entire driver (without ever actually using it) and then
 automatically extract the firmware from it when setting up b43. This
 would finally solve the Firmware Minefield issue caused by distros not
 being able to ship firmware for b43 in any way.

That's a question to distros.  I think they have good reasons not to
ship non-free software with restrictive licenses.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: bcm4306 with 2.6.25 on Fedora

2008-07-27 Thread Pavel Roskin
On Sun, 2008-07-27 at 05:59 +, Greg Matheson wrote:

 I seem to be only able to get a bcm4306 chip to work when I power
 on, but powering on does not seem to be a sufficient condition
 for it to work. I am wondering if powering on after some time off
 is necessary and sufficient?

You mean it doesn't work after reboot?

 This is with 2.6.25-14.fc9.i686  or 2.6.25.10-86.fc9.i686.
 
 And I can only get this result with 4.150.10.5 firmware.
 With 3.130.20.0 firmware, ie b43legacy. after associating with
 the AP, it disassociates with reason=3. That is, it
 disassociates of its own accord.
 
 That is, I haven't been able to get it working with 3.130.20.0.

You should not be able to use b43 and b43legacy with the same device.
Perhaps you patched one of those drivers to support your card?  Then
please be specific.

 I wasn't able to get 4.80.53.0 working either, though I haven't
 tried as much.
 
 Actually, I think b43legacy is the track this chip should be
 working with, rather than b43, because I think it has a 'MAC core
 revision' of 2, ie less than 4.
 
 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050,
 Revision 2

What matters is the 802.11 core revision reported by the ssb driver when
SSB debugging is enabled.  b43 doesn't report it.  Perhaps ssb is too
quiet without debugging.

 b43-phy0: Broadcom 4306 WLAN found
 b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2

I have a bcm4306 card with the same PHY and radio, and it's supported by
b43 only.  b43legacy can be patched to support it.  I have no problems
with that card, even with reboots.

 The output of uname -a:
 
 Linux pl757.nas921.nara.nttpc.ne.jp 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 
 20:46:03 EDT 2008 i686 i686 i386 GNU/Linux

Fedora is known to pull some experimental stuff into its kernels.
Anyway, it's not the latest Fedora kernel, please upgrade if you can.
And all real wireless work is done on the wireless-testing kernel.

 [EMAIL PROTECTED] ~]# dhclient wlan0 -v
 Internet Systems Consortium DHCP Client 4.0.0
 Copyright 2004-2007 Internet Systems Consortium.
 All rights reserved.
 For info, please visit http://www.isc.org/sw/dhcp/
 
 Listening on LPF/wlan0/00:07:40:c4:f5:d6
 Sending on   LPF/wlan0/00:07:40:c4:f5:d6
 Sending on   Socket/fallback
 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21
 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12
 No DHCPOFFERS received.
 No working leases in persistent database - sleeping.

dhclient on Fedora brings the interface down briefly.  b43 is very
susceptible to disassociation if it happens (but sometimes the
connection survives).  A workaround it to avoid dhclient.  If you have
to use it, you'll need to set essid in another session while dhclient is
waiting, or run wpa_cli -i wlan0 reassociate

It is a known problem, but I think dhclient is entirely to blame.
Bringing the interface down goes well beyond the zone of
responsibility of dhclient, as it affects the lower layers that need to
stay connected and keep their state.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Regression (FC8 to FC9)

2008-06-25 Thread Pavel Roskin
On Wed, 2008-06-25 at 11:06 -0400, Frank Middleton wrote:

 Updated FC8 kernel that worked fine  2.6.25.6-27.fc8
 FC9 kernel (that has the regression) 2.6.25.6-55.fc9.x86_64

I would probably try to bisect it.  I realize that it's a lot of work.

The breakage is caused either by patches or by configuration changes.
Finding out is the first step.  Then look for the patch or for
configuration change that affects the problem.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: ssb-sprom application issues.

2008-06-25 Thread Pavel Roskin
On Wed, 2008-06-25 at 01:18 -0400, Dale Walsh wrote:

 As I stated, since I do not have anything concrete to work from I am  
 guessing at the expected locations and registers (bits) but after  
 close examination, I concluded the bytes are at SPROM_BOARDREV + 2  
 as seen in the html post and now this more legible post.

It overlaps with SPROM_PA0B0, so I'm not sure it's correct.  I would be
more willing to agree with you if you were restoring incorrectly changed
code, or fixing an inconsistency between reading and writing.  However,
I cannot support assertions not based on the (pre-)existing code or
reverse engineering.

 I would like to note that there should be 3 antenna entries in rev 4  
 as reported to me by Broadcom however they did not provide a decode  
 of the bytes or the sprom data.

That's a valuable piece of information.

But I think the first priority should be restructuring of ssb-eeprom to
make inconsistencies unlikely and to allow accumulating information
about new SPROM formats without having to change the code too much.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: More discrepancies in ssb-sprom

2008-06-25 Thread Pavel Roskin
On Wed, 2008-06-25 at 15:07 -0400, Dale Walsh wrote:
 
 On Jun 25, 2008, at 08:35 AM, Michael Buesch wrote:
 
  On Wednesday 25 June 2008 13:51:54 Dale Walsh wrote:
   The problem with your statement is that as far as I could locate,

   this is the only tool that allows you to modify the subsystem
   vend/ 
   prod ID's and to tweak antenna gains to improve performance of a
   card.
  
  
  You should read a good book about antenna physics.
 
 
 I can assure you I know something about antenna design, gain and
 wavelength versus overall length, loading, termination, resistance,
 balancing, corona, directional versus omni-directional, resonance,
 multi-elements, arrays, yagi's, quad's and the antenna is only as good
 as the transmitter or receiver attached to it.
 
 
 If the transmitter power is supplied at 70% of the available power
 then the distance that the transmitter is effective
 is diminished exponentially by the amount of power being generated.

I suggest that you introduce a new field in ssb-sprom, call it
antenna-shape and put yagi there.  That would greatly help with both
reception and transmission :-)

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: BCM 4325 support

2008-06-24 Thread Pavel Roskin
On Tue, 2008-06-24 at 12:36 -0700, Ram kumar wrote:

 Please guide us whether this can achieved by using BCM4325 module ? I
 have gone through the http://linuxwireless.org/en/users/Drivers/b43
 website which says that broadcomm modules can be configured to access
 point modeWe want to know whether this module BCM4325 can be
 configured to work as an access point ?

Please try and tell others whether it's working for you.  Nobody is
going to research it for you, especially if it requires buying extra
hardware.

You may get better replies if you post in plain text without HTML, don't
quote whole messages and answer the questions you are asked.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: ssb-sprom application issues.

2008-06-24 Thread Pavel Roskin
On Mon, 2008-06-23 at 20:39 -0400, Dale Walsh wrote:

 I have been trying to modify antenna and antenna gain values and it
 appears that the wrong data is being modified.

I confirm it's still a problem with the current version in git.

 SPROM(0x04, Subsytem product ID) = 0x0453

But you are not using the latest version, because I fixed that typo.

Anyway, as I understand it, the original ssb-sprom as committed to the
git repository assumed that the A gain comes first at and the BG gain is
second.

The later changes for SPROM revision 4 assumed that the BG gain is
first, and the A gain is second.  But those changes broke support for
older SPROM revisions.  Also, the use of sprom[offset + 1] meant that
the incorrect offset would be printed.  And the worst thing is that
modify_value() would modify wrong values for SPROM revision 4.

I actually don't know if the antenna gain order was changed in SPROM 4.
I just assume it from the history of the changes.

This patch should restore the original behavior for the old SPROM, and
it shouldn't break SPROM4 more than it's already broken.

diff --git a/ssb_sprom/ssb_sprom.c b/ssb_sprom/ssb_sprom.c
index ee56d38..9f182ef 100644
--- a/ssb_sprom/ssb_sprom.c
+++ b/ssb_sprom/ssb_sprom.c
@@ -293,10 +293,16 @@ static int modify_value(uint8_t *sprom,
sprom[SPROM_BOARDREV + 1] |= (1  5);
break;
case VALUE_ANTGA:
-   sprom[SPROM_ANTENNA_GAIN + 0] = (v  0xFF);
+   if (sprom_rev == 4)
+   sprom[SPROM4_ANTENNA_GAIN + 1] = (v  0xFF);
+   else
+   sprom[SPROM_ANTENNA_GAIN] = (v  0xFF);
break;
case VALUE_ANTGBG:
-   sprom[SPROM_ANTENNA_GAIN + 1] = (v  0xFF);
+   if (sprom_rev == 4)
+   sprom[SPROM4_ANTENNA_GAIN] = (v  0xFF);
+   else
+   sprom[SPROM_ANTENNA_GAIN + 1] = (v  0xFF);
break;
case VALUE_PA0B0:
sprom[SPROM_PA0B0 + 0] = (v  0x00FF);
@@ -577,14 +583,14 @@ static void display_value(const uint8_t *sprom,
offset = SPROM_ANTENNA_GAIN;
} else {
desc = Antenna 1 Gain;
-   offset = SPROM4_ANTENNA_GAIN;
+   offset = SPROM4_ANTENNA_GAIN + 1;
}
-   value = sprom[offset + 1];
+   value = sprom[offset];
break;
case VALUE_ANTGBG:
if (sprom_rev != 4) {
desc = B/G PHY antenna gain;
-   offset = SPROM_ANTENNA_GAIN;
+   offset = SPROM_ANTENNA_GAIN + 1;
} else {
desc = Antenna 0 Gain;
offset = SPROM4_ANTENNA_GAIN;


-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: ssb-sprom application issues.

2008-06-24 Thread Pavel Roskin
Hello, Dale!

It would be great if you write in plain text without HTML.  It would
make it easier to quote your message.

On Tue, 2008-06-24 at 17:14 -0400, Dale Walsh wrote:

 Since I can't be sure which version I actually have I started with
 what I had with the fix for the subsystem product code and moved
 forward from there.

Please don't do it this way.  In general case, it would be dangerous to
integrate your changes in nobody, even you, knows what was changed by
you and what was present in the base code.  That's why patches are used
to send code  changes.

 Other than adding some checking that seemed to be going on with the
 sprom_rev 4, (I added similar checking in a couple of places) the
 sprom_rev 4 is still broken but sprom_rev 2 appears to now works
 properly.

I understand you are talking about your code, not about my patch?

 case VALUE_ANTGA:
 if (sprom_rev == 4)
 sprom[SPROM4_ANTENNA_GAIN + 2] = (v  0xFF);
 else
 sprom[SPROM_ANTENNA_GAIN + 2] = (v  0xFF);
 break;

Do you have any reason to believe that antenna gain for 802.11a is
located there?  That's a separate 16-bit register.

 case VALUE_ANTGBG:
 if (sprom_rev == 4)
 sprom[SPROM4_ANTENNA_GAIN + 0] = (v  0xFF);
 else
 sprom[SPROM_ANTENNA_GAIN + 0] = (v  0xFF);
 break;

The same question about 802.11bg.  Do you actually see any changes if
you modify SPROM?

 case VALUE_ANTGA:
 if (sprom_rev != 4) {
 desc = A PHY antenna gain;
 offset = SPROM_ANTENNA_GAIN + 1;
 } else {
 desc = Antenna 1 Gain;
 offset = SPROM4_ANTENNA_GAIN;
 }
 value = sprom[offset + 1];

That's misleading.  You are telling users that the data is at offset
0x75, but you are reading it at 0x76.

Your code is consistent, but I don't see any evidence that it's correct.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


More discrepancies in ssb-sprom

2008-06-24 Thread Pavel Roskin
Hello!

VALUE_ANTA0, VALUE_ANTA1, VALUE_ANTBG0 and VALUE_ANTBG1 are all read at
SPROM_BOARDREV + 2 for non-rev4 SPROM.  SPROM_BOARDREV + 2 is equal
SPROM_PA0B0, which means that the same data is displayed twice.

The same values are written to SPROM_BOARDREV + 1.  For VALUE_ANTA1,
VALUE_ANTBG0 and VALUE_ANTBG1 there is no special handling for rev4
SPROM, which must be wrong.

Likewise, there is no special treatment for rev4 for VALUE_MAXPA and
VALUE_MAXPBG in modify_value(), but display_value() treats them
separately.

It seems to me that ssb-sprom should be rewritten.  I think the SPROM
structure should be described as a table for every SPROM revision in a
format like this:

ID, name, byte offset, bit offset, bit size

That should solve the problem of synchronization between read and write
functions. 

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: More discrepancies in ssb-sprom

2008-06-24 Thread Pavel Roskin
On Tue, 2008-06-24 at 22:07 -0500, Larry Finger wrote:

 I agree that ssb-sprom should be rewritten; however, before that is 
 done, we need to think carefully as to what variables should be 
 exposed for a user. For instance, should antenna gains be brought
 out? 
 What about antenna enable variables? Is there any reason for a user
 to 
 change these?

The reason would be to fix wrong values.  I believe everything should be
available.  If there are any specific concerns about specific fields,
there should be warnings.  If there are chances to brick the device,
there should be big warnings, or perhaps the entries should have a
read-only flag.  Anyway, ssb-sprom is not for casual users.

 In addition, it might be useful to know about new revisions. We now 
 have an instance of revision 8, where the only locations that have 
 been identified are the usual ID stuff at the start and the MAC 
 address. Everything else is unknown. What about revs 5, 6 and 7?

That's where having a table with entry descriptions would be helpful.
Tables for unknown revisions could start with just a few entries and get
populated with entries from other revisions.  If there is anything
unusual about the unknown fields (e.g. they are big endian or
read-only), it could be represented as additional flags.

If the firmware was described as a C structure covering the whole
firmware, copying entries could shift everything.  And the current
approach would lead to unmaintainable growth of the code.
 
-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43legacy kernel warning

2008-06-17 Thread Pavel Roskin
On Tue, 2008-06-17 at 16:59 -0400, David Ellingsworth wrote:
 I ran into this error today from a kernel I built last night based on
 the latest wireless-testing branch. Correct me if I'm wrong, but it
 looks to be b43legacy related. I'm a bit new to kernel debugging but
 can try to provide additional information if instructions on how to do
 so are provided.
...
 WARNING: at kernel/softirq.c:141 local_bh_enable+0x1f/0x59()
...
  [c0117477] local_bh_enable+0x1f/0x59
  [dcf44045] __sta_info_unlink+0xa9/0x134 [mac80211]
  [dcf4453f] sta_info_unlink+0x9/0xd [mac80211]

It looks like __sta_info_unlink() from net/mac80211/sta_info.c tries to
enable softirqs while hardirqs are disabled.  That doesn't appear to be
specific to the driver.  Perhaps it should be reported to
linux-wireless.

 b43legacy-phy0 warning: Unexpected value for chanstat (0x7C00)

That is b43legacy related.  The driver only expects B43legacy_PHYTYPE_B
(1) or B43legacy_PHYTYPE_G (2) in the lower two bytes of chanstat, but
it's 0.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[PATCH] b43-tools typos

2008-06-13 Thread Pavel Roskin
diff --git a/ssb_sprom/ssb_sprom.c b/ssb_sprom/ssb_sprom.c
index 2b05e9f..facacab 100644
--- a/ssb_sprom/ssb_sprom.c
+++ b/ssb_sprom/ssb_sprom.c
@@ -16,7 +16,7 @@
 
   You should have received a copy of the GNU General Public License
   along with this program; see the file COPYING.  If not, write to
-  the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor,
+  the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
   Boston, MA 02110-1301, USA.
 
 */
@@ -398,7 +398,7 @@ static void display_value(const uint8_t *sprom,
value = sprom[offset];
break;
case VALUE_SUBP:
-   desc = Subsytem product ID;
+   desc = Subsystem product ID;
if (sprom_rev == 4)
offset = SPROM4_SUBP;
else
@@ -937,7 +937,7 @@ static void print_usage(int argc, char *argv[])
prdata(  -g|--rawget OFF   Get a value at a byte-OFFset\n);
prdata(\n);
prdata(Predefined values (for displaying (GET) or modification):\n);
-   prdata(  --subp [0x]   Subsytem product ID for PCI\n);
+   prdata(  --subp [0x]   Subsystem product ID for PCI\n);
prdata(  --subv [0x]   Subsystem vendor ID for PCI\n);
prdata(  --ppid [0x]   Product ID for PCI\n);
prdata(  --bflhi [0x]  High 16 bits of boardflags (only if 
spromversion  1)\n);
diff --git a/ssb_sprom/ssb_sprom.h b/ssb_sprom/ssb_sprom.h
index 4b44e95..68d690f 100644
--- a/ssb_sprom/ssb_sprom.h
+++ b/ssb_sprom/ssb_sprom.h
@@ -16,7 +16,7 @@
 
   You should have received a copy of the GNU General Public License
   along with this program; see the file COPYING.  If not, write to
-  the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor,
+  the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
   Boston, MA 02110-1301, USA.
 
 */
diff --git a/ssb_sprom/utils.c b/ssb_sprom/utils.c
index 5d3189e..b57b415 100644
--- a/ssb_sprom/utils.c
+++ b/ssb_sprom/utils.c
@@ -16,7 +16,7 @@
 
   You should have received a copy of the GNU General Public License
   along with this program; see the file COPYING.  If not, write to
-  the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor,
+  the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
   Boston, MA 02110-1301, USA.
 
 */

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: hybrid-wl compilation

2008-06-12 Thread Pavel Roskin
On Thu, 2008-06-12 at 16:39 -0400, Felipe Maya wrote:
 Hi, it was my results of the compilation of
 http://www.broadcom.com/support/802.11/linux_sta.php on openwrt
...
 /opt/openwrt-2.6.25/build_dir/linux-brcm47xx/compat-wireless-2008-06-10/hybrid-wl/lib/wlc_hybrid.o_shipped:
  could not read symbols: File in wrong format

I guess you are trying to link an i386 object file into a mips kernel.

Binaries are for one architecture only.  Welcome to the closed source
world.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 opensource firmware for monitor mode

2008-06-12 Thread Pavel Roskin
On Mon, 2008-06-09 at 14:08 +0200, Michael Buesch wrote:

 You can try the latest firmware from git, btw. It should be (partially) fixed 
 there.

I've tried the today's version.  It's working in monitor mode.
Moreover, it scans in managed mode!  The only problem is that it fails
to associate, even to an AP with no security.  But there are no hangs
whatsoever.  That's core rev5 (bcm4306).

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 opensource firmware for monitor mode

2008-06-12 Thread Pavel Roskin
On Fri, 2008-06-13 at 01:20 +0200, Michael Buesch wrote: 
 On Friday 13 June 2008 00:22:39 Pavel Roskin wrote:
  On Mon, 2008-06-09 at 14:08 +0200, Michael Buesch wrote:
  
   You can try the latest firmware from git, btw. It should be (partially) 
   fixed there.
  
  I've tried the today's version.  It's working in monitor mode.
  Moreover, it scans in managed mode!  The only problem is that it fails
  to associate, even to an AP with no security.  But there are no hangs
  whatsoever.  That's core rev5 (bcm4306).
 
 Thanks for testing. TX is not implemented. No wonder it fails to assoc ;)

No wonder even the big 7 dBi antenna didn't help :)

Anyway, it's great news.  It turns out bcm4318 with rev9 code is working
in monitor mode too!

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 and card recognition.

2008-06-08 Thread Pavel Roskin
On Sun, 2008-06-08 at 20:56 +0200, Michael Buesch wrote:

  Would donating a card speed up the process???
 
 No. Donating a Reverse Engineer would help.

:-)

I suggest that you write to [EMAIL PROTECTED]

Reverse engineering could be a fun project for somebody, especially
since bcm4328 is modern hardware with many potential users.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


RE: b43legacy: Problems with dhclient

2008-06-04 Thread Pavel Roskin
On Wed, 2008-06-04 at 15:49 -0400, David Ellingsworth wrote:

 For a while now, I've been experiencing connection stability issues which from
 what I can tell seem to stem from the use of dhclient.
 
 After upgrading to the latest wireless-testing kernel, I noticed the output 
 from
 wpa_supplicant and iwconfig regarding association status differed as well as 
 an
 inability to use dhclient to receive an ip address. In an attempt to resolve 
 the
 issue, I first eliminated the use of dhclient by issuing a static ip address 
 for
 the interface after it was associated with the AP. Doing so resulted in a very
 stable and reliable connection. This led me to believe the issues were a 
 result
 of using dhclient. To verify, I tried dhcpcd in place of dhclient, which once
 again resulted in a stable and reliable connection. Thus confirming my 
 suspicion.

The problem with dhclient is that it brings the interface down
temporarily, thus breaking the WPA connection.  You can see hostap
archives for a recent discussion about it:
http://lists.shmoo.com/pipermail/hostap/

It's a complicated problem, involving a lot of software, including
distribution specific scripts.  It's entirely possible that simply
different timing can break the behavior.  Jouni Malinen mentioned that
the driver is supposed to tell wpa_supplicant to renegotiate the
connection after the interface goes down and up.  It's possible that the
kernel is not doing it right, but the code is not in b43legacy, it's in
mac80211.

My solution is either to use static addresses with WPA or use a dhclient
script that brings the interface up and tell wpa_supplicant to
renegotiate the connection.

In any case, I'm quite sure that discussing the problem here is not
going to be useful because it's not specific to the particular driver.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 opensource firmware for monitor mode

2008-06-04 Thread Pavel Roskin
On Wed, 2008-06-04 at 17:16 +0200, Michael Buesch wrote:
 Release early, release often.
 Here's the first testing release of the b43 opensource firmware.
 http://bu3sch.de/misc/b43-openfw-20080604.tar.bz2
 
 Currently only the receive path is partially implemented. So that
 means we can only run it in monitor mode for now. This firmware is
 able to receive packets and push them without special handling (like
 decrypting) to the driver.
 There are lots of bugs, of course. Sometimes the PLCP header is corrupted.
 That will result in a kernel driver warning in xmit.c.
 
 This firmware does _only_ work on wireless core revisions 5, 6, 7, 8 or 10.

That's great news!  Having distributable firmware would simplify
installation, placing b43 to the same league as Intel devices.  But
having free firmware would be unique to Broadcom card and extremely
attractive for research in wireless communications and development of
novel devices using non-standard protocol extensions.

As a short term goal, maybe bcm4328 could be dumbed down to work with
b43?

I've tried it with bcm4318 first, and it hung hard on module load.  Even
Alt-SysRq would not work.  It turns out it was revision 9 missing in
your list.

Then I tries a bcm4306 device with rev 5 core.  The module loaded.  I
brought it up in managed mode first.  Scanning didn't work.  I brought
the device down and set monitor mode.  But the system hung when I tried
to bring the interface back up.

Anyway, I'm glad to see progress in that direction.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[PATCH] mac80211: fix panic when using hardware WEP

2008-06-02 Thread Pavel Roskin
57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99 misplaced code for setting
hardware WEP keys.  Move it back.  This fixes kernel panic in b43 if WEP
is used and hardware encryption is enabled.

Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---

 net/mac80211/wep.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index c9fd129..e7b6344 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -335,10 +335,10 @@ static int wep_encrypt_skb(struct ieee80211_tx_data *tx, 
struct sk_buff *skb)
info-control.icv_len = WEP_ICV_LEN;
 
if (!(tx-key-flags  KEY_FLAG_UPLOADED_TO_HARDWARE)) {
-   info-control.hw_key = tx-key-conf;
if (ieee80211_wep_encrypt(tx-local, skb, tx-key))
return -1;
} else {
+   info-control.hw_key = tx-key-conf;
if (tx-key-conf.flags  IEEE80211_KEY_FLAG_GENERATE_IV) {
if (!ieee80211_wep_add_iv(tx-local, skb, tx-key))
return -1;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit

2008-06-01 Thread Pavel Roskin
Quoting Johannes Berg [EMAIL PROTECTED]:

  info-control.hw_key is NULL.

 Is a NULL pointer supposed to tell do not encrypt, or is this a   
 mac80211 bug?

 It's probably a bug.

I've bisected it to commit 57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99:
mac80211: move TX info into skb-cb

It turns out that commit introduces two sparse warnings in net/mac80211/wpa.c:

net/mac80211/wpa.c:202:10: warning: incorrect type in return  
expression (different base types)
net/mac80211/wpa.c:202:10:expected int
net/mac80211/wpa.c:202:10:got restricted ieee80211_tx_result  
[usertype] noident
net/mac80211/wpa.c:448:10: warning: incorrect type in return  
expression (different base types)
net/mac80211/wpa.c:448:10:expected int
net/mac80211/wpa.c:448:10:got restricted ieee80211_tx_result  
[usertype] noident

That's returning TX_CONTINUE from tkip_encrypt_skb() and  
ccmp_encrypt_skb(), where an integer should be returned.  Both times  
it happens after info-control.hw_key is set.  The callers of those  
functions check for negative numbers only, but TX_CONTINUE is 0, and  
TX_DROP is 1.  Something must be wrong there.

wep_encrypt_skb() in wep.c would not return TX_CONTINUE.  But most  
importantly, there is a suspicious change in wep_encrypt_skb() - the  
key is set in the other branch of the condition.

I'll try to restore the original logic in wep.c.  I'll post a patch if  
it works.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit

2008-06-01 Thread Pavel Roskin
On Mon, 2008-06-02 at 00:08 -0400, Pavel Roskin wrote:

 wep_encrypt_skb() in wep.c would not return TX_CONTINUE.  But most  
 importantly, there is a suspicious change in wep_encrypt_skb() - the  
 key is set in the other branch of the condition.
 
 I'll try to restore the original logic in wep.c.  I'll post a patch if  
 it works.

That was it!  Here's the patch (I'll submit it to John tomorrow if nobody 
objects).


mac80211: fix hardware WEP support

Setting hardware WEP key was accidentally moved to a wrong place in
57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99.  Move it back.  This fixes
kernel panic in b43 if WEP is used.

Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---

 net/mac80211/wep.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index c9fd129..e7b6344 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -335,10 +335,10 @@ static int wep_encrypt_skb(struct ieee80211_tx_data *tx, 
struct sk_buff *skb)
info-control.icv_len = WEP_ICV_LEN;
 
if (!(tx-key-flags  KEY_FLAG_UPLOADED_TO_HARDWARE)) {
-   info-control.hw_key = tx-key-conf;
if (ieee80211_wep_encrypt(tx-local, skb, tx-key))
return -1;
} else {
+   info-control.hw_key = tx-key-conf;
if (tx-key-conf.flags  IEEE80211_KEY_FLAG_GENERATE_IV) {
if (!ieee80211_wep_add_iv(tx-local, skb, tx-key))
return -1;


-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit

2008-05-31 Thread Pavel Roskin
Hello!

You beat me at reporting it.  I was about to report the same thing.
Basically, my laptop with bcm4311 started crashing when using WEP in the
last weeks.  Its runs the current wireless-testing.

On Sat, 2008-05-31 at 16:23 +0200, Stefanik Gábor wrote:
  #4 [c04619c8] b43_generate_txhdr at f8dd3a99

Yes, that's where it happens.  This patch prevents the panic, but it's
almost certainly not the right fix.

diff --git a/drivers/net/wireless/b43/xmit.c
b/drivers/net/wireless/b43/xmit.c
index f9e1cff..5ec8d86 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -234,11 +234,14 @@ int b43_generate_txhdr(struct b43_wldev *dev,
 
plcp_fragment_len = fragment_len + FCS_LEN;
if (use_encryption) {
-   u8 key_idx = info-control.hw_key-hw_key_idx;
+   u8 key_idx;
struct b43_key *key;
int wlhdr_len;
size_t iv_len;
 
+   if (!info-control.hw_key)
+   return -ENOKEY;
+   key_idx = info-control.hw_key-hw_key_idx;
B43_WARN_ON(key_idx = dev-max_nr_keys);
key = (dev-key[key_idx]);
 
Another workaround is to use nohwcrypt=1 in the module options.

It's strange that other drivers (b43legacy, ath5k) use
info-control.hw_key-hw_key_idx under the same conditions (see how
use_encryption is calculated), but don't have any problems on the same
network (but I need to recheck).

I'm using 40-bit WEP with wpa_supplicant (because it's configured to
recognize many networks, some of which are with WPA).  I don't know if
it's relevant.  It's Fedora 9 for x86_64, but NetworkManager is
disabled.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit

2008-05-31 Thread Pavel Roskin
On Sat, 2008-05-31 at 18:54 +0200, Stefanik Gábor wrote:
 On Sat, May 31, 2008 at 6:48 PM, Pavel Roskin [EMAIL PROTECTED] wrote:
  It's strange that other drivers (b43legacy, ath5k) use
  info-control.hw_key-hw_key_idx under the same conditions (see how
  use_encryption is calculated), but don't have any problems on the same
  network (but I need to recheck).
 
 Hmm... does ath5k use hardware crypto?

No, it doesn't, at least with WEP, if I understand ath5k_set_key()
correctly.

 B43 does (but not with
 nohwcrypt - and that appears to be a valid workaround), b43legacy
 doesn't AFAIK.

Although the code with use_encryption is present in b43legacy, it don't
see any references to set_key, so I guess you are right.

Well, that explains something.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: cancel_work_sync() question

2008-05-31 Thread Pavel Roskin
On Sat, 2008-05-31 at 16:05 -0400, Clyde McPherson wrote:
 I am trying to port the Broadcom drivers to an ARM archicture  (Linux 
 version 2.6.21) and it appears that cancel_work_sync() is missing from 
 its kernel. Is there any other function that I can replace it with?

It's present in newer kernels, and you can look at the implementation
and reimplement it.  Better yet, switch to a newer kernel.  In any case,
I don't think you should be asking b43 developers about backporting a
standard kernel function to an older kernel.  There should be places
more suitable for such questions.

Also, compat-wireless aims to bring newer wireless drivers to older
kernels.  It may work for you.  If it doesn't, and if compat-wireless
still aims to support Linux 2.6.21, you can report the failure as a bug
in compat-wireless.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH] b43legacy: Fix controller restart crash

2008-05-30 Thread Pavel Roskin
On Wed, 2008-05-28 at 15:12 -0400, John W. Linville wrote:

  Stefano, this is untested. Please test by doing
  echo -n 1 /debug/b43legacy/phy*/restart
  rmmod b43legacy
  It should not crash anymore at the rmmod (actually the restart should
  also hang in b43legacy, as it has a deadlock, which this patch also fixes).
 
 Anyone get a chance to test this one?

Yes, the patch is fine.

Unloading b43legacy hangs without the patch and works properly with the
patch.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: no scan results BCM94311MCG

2008-05-21 Thread Pavel Roskin
On Wed, 2008-05-21 at 20:11 +0200, Sandro Hannemann wrote:
 Dear list members,
 
 yesterday I wasted quite some time trying to get the wireless to work
 without success.
 The situation is:
 
 linux-2.6.24-gentoo-r7  (gentoo flavoured linux kernel).
 lspci gives:
  0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
 mini-PCI (rev 01)
 I used b43-fwcutter-011 to install firmware version
 broadcom-wl-4.80.53.0 into /lib/firmware.
 
 iwlist wlan0 scan yields only wlan0 No scan results.

As far as I can tell, you installed the firmware correctly.  But it's
possible that the driver you are using doesn't have some fixes needed
for your hardware.  I suggest that you try the driver from
compat-wireless, which is the latest driver backported to the recent
kernels: http://linuxwireless.org/en/users/Download

If it doesn't help, check the antenna connectors on the card if they are
accessible.  Also try ndiswrapper to rule out problems unrelated to the
b43 driver.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: no scan results BCM94311MCG

2008-05-21 Thread Pavel Roskin
On Thu, 2008-05-22 at 01:25 +0200, Sandro Hannemann wrote:
 First, thanks for your reply.
 
  I suggest that you try the driver from
  compat-wireless, which is the latest driver backported to the recent
  kernels: http://linuxwireless.org/en/users/Download
 
 I did that. The thing is only, I get compile issues, which wouldn't
 bother me too much, as long as b43 would be working fine...

Still, you may want to report it to [EMAIL PROTECTED]

 The reaction on modprobe:
 # modprobe -f b43
 WARNING: Error inserting ssb
 (/lib/modules/2.6.24-gentoo-r7/kernel/drivers/ssb/ssb.ko): Invalid
 module format

It means the replacement ssb module failed to install.  It would be
under updates instead of kernel.

 Well, I don't have pcmcia in my kernel config, because I don't need it.
 Is there a certain kernel setting requirement that I miss?

I believe there is no such requirement (although I haven't tried that).
If such requirement exists, the build system should report it.

I only see one reference to PCMCIA on the download page:

Additionally, the kernel you're building for needs a valid .config
file, if it isn't present compat will assume you have PCI, USB and
PCMCIA built into your kernel and if not, fail building.

So, maybe your .config file wasn't found.

 Then I found a command b43load somewhere in the wireless-compat tree, but
 b43load complains about the same error as above and eventually loads
 the module b43legacy... well... which doesn't work...

It confirms that the installation was incomplete.

  If it doesn't help, check the antenna connectors on the card if they are
  accessible.
 It's a laptop from my work. I am not planning to open it and fiddle
 around with any connectors. Let's say, it is built-in and just not
 accessable.

OK, chances are it's OK if you didn't touch it.

   Also try ndiswrapper to rule out problems unrelated to the
  b43 driver.
 
 ndiswrapper acts weired as well. I installed version 1.52.
 I did blacklist these guys: b43, b43legacy, ccb.
 I downloaded the windows driver and installed it. ndiswrapper seems to be 
 happy:
 # ndiswrapper -l
 bcmwl5 : driver installed
device (14E4:4311) present (alternate driver: ssb)
 
 however, iwconfig says:
 # iwconfig
 lono wireless extensions.
 eth0  no wireless extensions.
 
 basically, no wireless device showing up here (also the LED stays off).

modprobe ndiswrapper

 Summary:
 The wifi here did work some time ago. It is only recently that it
 rendered that broken. I used to use ndiswrapper one year ago, at some
 point I switched to b43.

So, I guess b43 stopped working one day?

 Just one restriction: I'd like to stick to 2.6.24 for the time being,
 as the vmware-modules don't compile against 2.6.25 kernels yet.

compat-wireless supports 2.6.22 and newer.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH] b43: Upload both beacon templates on initial load

2008-05-20 Thread Pavel Roskin
On Tue, 2008-05-20 at 12:16 +0200, Michael Buesch wrote:
 This updates the beacon template code to upload both templates,
 if we never uploaded one before.
...
 + bool beacon_templates_virgin; /* Never wrote the templates? */
...
 @@ -4164,12 +4191,15 @@ static int b43_op_start(struct ieee80211
* and mac80211 reconfiguring it. */
   memset(wl-bssid, 0, ETH_ALEN);
   memset(wl-mac_addr, 0, ETH_ALEN);
   wl-filter_flags = 0;
   wl-radiotap_enabled = 0;
   b43_qos_clear(wl);
 + wl-beacon0_uploaded = 0;
 + wl-beacon1_uploaded = 0;
 + wl-beacon_templates_virgin = 1;

Just a hint.  You may want to revert the logic, so that you start with
0 and set the variable to 1 as something substantial happens.  You can
introduce more states later if required, or count the upload events.

This way, it would be beacon_templates_loaded or
beacon_templates_touched.

The human brain is better at understanding positive meanings.  virgin
means that something did _not_ happen, and it's not like it's very
valuable per se, at least for beacon templates :-)

I worked on code full of things like HAVE_NO_CURSES_H and DISABLE_COLOR,
and it wasn't fun.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH] b43: Fix typo in firmware file name for 802.11 cores with rev 13

2008-05-15 Thread Pavel Roskin
On Thu, 2008-05-15 at 21:39 +0200, Michael Buesch wrote:

  This is 2.6.27 material. Although it is a bug in 2.6.25 and .26, it
  seems to have zero effect on the performance of the device and can
  be delayed.
 
 Exactly. That's why I decided to delay it :P

Actually, it it's a bug and there is a simple fix unlikely to break
anything, it should go to 2.6.26.  The whole point of having release
candidates is fixing bugs.  If nothing else, the fix should be applied
out of respect to the users of 2.6.26 who will be wondering where to get
lp0initvals13.

It's just a suggestion, I'm not trying to start a flamewar :-)

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 4311 v2 Bail - 2.6.26-rc2

2008-05-13 Thread Pavel Roskin
On Tue, 2008-05-13 at 09:19 +0100, Daniel wrote:

 buffer size7wlan0: wrong buffer size

The missing newlines are fixed in today's wireless-testing repository.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 4311 v2 Bail - 2.6.26-rc2

2008-05-13 Thread Pavel Roskin
On Wed, 2008-05-14 at 01:27 +0200, Michael Buesch wrote:

 Where does this wrong buffer size message come from, and what does it mean?

net/mac80211/rx.c

There are two instances of that message, both in ieee80211_rx_h_amsdu(),
and both in the code path that returns RX_DROP_UNUSABLE.

I guess the code complains about some invalid frames and drops them.
Somebody with a better knowledge of the code should write better
descriptions and make the messages different.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: sucess with HP-laptop dv6057ea

2008-05-12 Thread Pavel Roskin
On Mon, 2008-05-12 at 09:44 -0700, Alan wrote:

 I have a HP dv6000 that was custom built.  It has a Broadcom Corporation
 BCM4328 802.11a/b/g/n (rev 03).  This is a b43xx chipset, but does not
 work correctly with the b43 driver (as far as I know).  To get it to work
 I had to use the ndiswrapper hack.

bcm4328 is not supported and is not expected to be supported soon unless
more people help with reverse engineering efforts.

The driver page mentions that bcm4328 is not supported:
http://linuxwireless.org/en/users/Drivers/b43

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Ubuntu systems

2008-05-10 Thread Pavel Roskin
On Sat, 2008-05-10 at 21:38 -0500, Larry Finger wrote:

 The short version of my results is that patches have been submitted and 
 accepted to fix all known problems with b43legacy when using 802.11b devices. 
 I also submitted the patches needed for implementation of 4311/2 and 4312/2 
 cards including the disabling of A-PHY's on 802.11a/b/g units. The 4311/2 
 patch had been in trial versions of the Hardy kernel and reportedly caused a 
 regression for a 4312/1 user. I don't understand that problem. If anyone 
 reading this list knows of a similar problem, please let me know. Because of 
 this history, they are being careful with the 4311/2 changes.

Sorry for getting this thread in a slightly different direction, but it
seems to me that 4311/4312 don't get as much testing as 4306/4318 among
the core developers, which is unfortunate, as the former are used in
more modern systems.

I think we need to get developers a laptop with PCI Express Mini Card
support.  A modern Dell Inspiron would be fine.  I know that it can be
opened relatively easy to replace the card.  I did it twice - first to
change bcm4328 to iwl4965, and then to bcm4311 (without 802.11a support,
so I cannot test this case).  In fact, there is another empty slot in my
Dell Inspiron 1420, reserved for WAN, so it should be possible to put
the second card there.  I'm actually going to try it.  Dell Vostro
shouldn't be much different.

I contributed my part to the funds (no idea why it's not shown, I
forwarded my receipt to Stefano), and there is more than enough for a
minimal Dell Inspiron or Vostro.

Vostro 1000 with 64-bit AMD CPU and bcm4312 (1490) is $434 now in the US
(plus shipping and tax).

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Ubuntu systems

2008-05-10 Thread Pavel Roskin
On Sat, 2008-05-10 at 23:58 -0500, Larry Finger wrote:

 At present, I have a BCM4311 rev 2 in my laptop so that device gets lots of 
 testing. I used to have a 4311/1, but that laptop was recalled and replaced. 
 To help debug this particular issue, I just bought a D1490 on E-bay. I also 
 have a BCM4310, which has an LP-PHY and is the reason I'm working on the RE 
 for that device.
 
 If the developers feel that a new laptop would be desirable, I certainly 
 would not object; however, we do have coverage for these devices.

I see, good to know.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: BCM4308 rev 3 owner, willing to help (want to make an access point)

2008-04-28 Thread Pavel Roskin
On Mon, 2008-04-28 at 11:50 +0200, Francis Galiegue wrote:
 Hello everyone,
 
 Here is my setup:
 
 - Gentoo 2007.0, x86;
 - a Broadcom BCM4308 rev 3 chipset (PCI card), PCI ID 14e4:4320;

Actually, according my /usr/share/hwdata/pci.ids file, which came with
Fedora development, and should be recent, 14e4:4320 is BCM4306
802.11b/g Wireless LAN Controller.  Is BCM4308 written on the chip?

 - making this card an AP, using hostapd (with the nl80211 driver, I guess);
 - including the Ethernet card and the BCM in a bridge setup (it works
 already, but no access point yet).
 
 My main gripe right now is that I cannot iwconfig wlan0 mode master.
 The b43 page says it doesn't work, lacking proper support in mac80211
 and hostapd.
 
 I'm quite a rookie with AP setups. This card otherwise works fine in
 managed and ad-hoc mode.

The AP functionality is still experimental.  Please check archives of
[EMAIL PROTECTED] for messages from Johannes Berg with
hostap in the subject.  You'll find the description of what is
missing.

There are some patches to enable AP functionality at
http://johannes.sipsolutions.net/patches/

I haven't tried it myself and I don't know any details.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Tons of interrupts on driver load

2008-04-28 Thread Pavel Roskin
On Sun, 2008-04-27 at 18:07 +0200, Michael Buesch wrote:

 I'm interested in buying multi-PHY cards (dual-PHY and multi-core).
 Do you know a source for such cards?

Look for Dell 1450.  There are some on ebay.de.  It's miniPCI (at least
some of them).

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Tons of interrupts on driver load

2008-04-24 Thread Pavel Roskin
On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote:
 Hello,
 
 First some background:
 I am currently running latest mainline from git. This kernel suffers 
 from a scheduler?

I think this question is more suited for LKML.

 While trying to find what these hickups come from I ran watch --interval 
 .1 cat /proc/interrupts. I can see there that the b43 disappears, gets 
 unloaded probably, and then reappears.

You should probably show the exact contents of /proc/interrupts and
provide some details about the systems (architecture, CPU speed,
contents of /proc/sched_debug, lspci output, dmesg output).

 When b43 reappears in the interrupt listing, that line generates some 
 25000 irq's within a fraction of a second. Is this a bug somewhere or by 
 design?

It's possible that the interrupt count is not shown when the driver
disappears, but is not reset to 0.  Once the interrupt has a handler,
the original count is shown.

 Note that I wouldn't ever see this if the kernel was behaving as normal. 
 I have no idea if the b43 driver has always behaved like this. I could 
 of course test an older kernel on request.

That's probably a good idea, as the LKML folks would suspect something
they know least about, i.e. the hardware.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Success with bcm4311 and rewrite-lo-calibration

2008-04-20 Thread Pavel Roskin
Quoting Michael Buesch [EMAIL PROTECTED]:

 On Sunday 20 April 2008 05:43:18 Pavel Roskin wrote:
 Hello!

 It looks like all tests with the experimental LO calibration code were
 for bcm4306 and bcm4318.  So I downgraded my Dell laptop from bcm4328
 to bcm4311 (PCIe Mini Card), so that I can cover this gap and finally
 switch to a free driver.

 Everything seems to be OK.  I'm using the current linux-wireless
 repository plus mm-only-b43-rewrite-lo-calibration.patch from
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/broken-out/

 Can you also give this a try?
 http://bu3sch.de/patches/wireless-testing/20080419-1646/patches/005-b43-calibrate-lo-on-demand.patch

Just fine.  Downloads, uploads, flood ping - everything is OK on 4311.  
  Very little packet loss (through a wall with real live conditions):

231827 packets transmitted, 231210 received, 0% packet loss, time 358086ms
rtt min/avg/max/mdev = 1.167/1.395/81.565/0.571 ms, pipe 5, ipg/ewma  
1.544/1.214 ms

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Success with bcm4311 and rewrite-lo-calibration

2008-04-19 Thread Pavel Roskin
Hello!

It looks like all tests with the experimental LO calibration code were  
for bcm4306 and bcm4318.  So I downgraded my Dell laptop from bcm4328  
to bcm4311 (PCIe Mini Card), so that I can cover this gap and finally  
switch to a free driver.

Everything seems to be OK.  I'm using the current linux-wireless  
repository plus mm-only-b43-rewrite-lo-calibration.patch from  
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/broken-out/

# lspci -nnv -s 0c:00.0
0c:00.0 Network controller [0280]: Broadcom Corporation BCM94311MCG  
wlan mini-PCI [14e4:4311] (rev 01)
 Subsystem: Dell Unknown device [1028:0007]
 Flags: bus master, fast devsel, latency 0, IRQ 17
 Memory at fe8fc000 (32-bit, non-prefetchable) [size=16K]
 Capabilities: [40] Power Management version 2
 Capabilities: [58] Message Signalled Interrupts: Mask- 64bit-  
Queue=0/0 Enable-
 Capabilities: [d0] Express Legacy Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting ?
 Capabilities: [13c] Virtual Channel ?
 Kernel driver in use: b43-pci-bridge
 Kernel modules: ssb

ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
b43-phy0: Broadcom 4311 WLAN found
phy0: Selected rate control algorithm 'pid'
Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ]
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)

I'm using WEP to an AP on another floor.  The connection is reliable.   
I don't see any disconnects at all.  I downloaded several videos,  
uploaded a lot of pictures, talked on Skype (for more than 120 seconds  
:)), ran an X application over ssh, and now writing this e-mail - all  
things that an ordinary user would do.  Everything is fine.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: HP Pavillion Woes

2008-04-17 Thread Pavel Roskin
Quoting Robert Williams [EMAIL PROTECTED]:

 Hi All! Been trolling for couple months trying to
 learn...just when I think I know what to do  in what
 sequence you guys change everything!
 I've an HP Pavilion dv9310us w/bcm4311 rev 2 mini-pci.
 temp dual-boot xp(sp2)/opensuse 10.3. works on
 xp(ugh!) did work on suse for 2 weeks, added security
  other patches, hasn't worked since. kernel:
 2.6.22.17-0.1-default
 Prefer operate linux exclusively, but many probs
 w/ndiswrapper, if-iw/config and other stuff. really
 need wireless access so I can learn remote admin of
 tux servers, config, etc.  course is avail  free, but
 i'm not up to recomp of kernel and/or reverse eng.
 just yet. Anybody got a step-by-step for a n00b that
 isn't convoluted?? Maybe now there is a pkg or util
 which auto-magics??

Please read this document:
http://catb.org/~esr/faqs/smart-questions.html

Please pay special attention to the following parts:
http://catb.org/~esr/faqs/smart-questions.html#forum
http://catb.org/~esr/faqs/smart-questions.html#beprecise
http://catb.org/~esr/faqs/smart-questions.html#id306968
http://catb.org/~esr/faqs/smart-questions.html#writewell

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: mac80211 sysfs interface

2008-04-15 Thread Pavel Roskin
On Mon, 2008-04-14 at 09:52 -0400, Celejar wrote:
 Hi,
 
 I'm playing with b43 with my BCM4318 (rev 02).  It seems to be working
 fine in station and monitor modes (currently 2.6.24 self compiled from
 Debian Sid packaged source), but I'm baffled by instructions I've seen
 (e.g. in the Packetspammer docs) that discuss adding monitor mode to my
 interface via something like echo -n mon0
  /sys/class/ieee80211/phy0/add_iface.  That directory on my system doesn't
 contain 'add_iface':
 
 $ ls /sys/class/ieee80211/phy0/ 
 device  index  macaddress  power  subsystem  uevent

Same thing here with wireless-testing.  I don't see any add_iface in
the kernel sources.  Perhaps your documentation is obsolete.

I guess you need iw:
git-clone http://git.sipsolutions.net/iw.git

And then run something like this:
iw type station dev wmaster0 interface add

Sorry, iw is undocumented, so that's what I could figure out by reading
the code.  If it doesn't work, please ask in
[EMAIL PROTECTED]

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Problems with PCI (not Cardbus) BCM43xx

2008-04-13 Thread Pavel Roskin
On Sun, 2008-04-13 at 19:36 -0500, Larry Finger wrote:

 Do you have any PCI (not Cardbus) devices that work with b43? Do you 
 know of anyone that does?

I have MiniPCI cards with bcm4306 and bcm4318, and both are working fine
with the latest b43.  I tired them in a PCI adapter and in a Thinkpad
T30 laptop, which has a MiniPCI slot.  No problems whatsoever.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43: 1 second freeze every 2 minutes - works with bcm43xx

2008-04-06 Thread Pavel Roskin
On Sun, 2008-04-06 at 15:51 +0200, Julien Muchembled wrote:
 Pavel Roskin a écrit :
  If you don't see in in the kernel log, then it's the ssb module that
  doesn't want to work with your PCI card.
 
 Indeed the problem is in ssb: no alias at all.
 There is a missing option in config.mk
 I've added the following line and it works:
 CONFIG_SSB_B43_PCI_BRIDGE=y

Thanks!  Patch forwarded to Luis Rodriguez.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43: 1 second freeze every 2 minutes - works with bcm43xx

2008-04-05 Thread Pavel Roskin
On Sun, 2008-04-06 at 01:27 +0200, [EMAIL PROTECTED] wrote:
 Pavel Roskin a écrit :
  You may want to use compat-wireless then:
  http://linuxwireless.org/en/users/Download
  
  It's a backport of the current wireless drivers for the older kernels.
  The patch Michael asked us to test applies to it cleanly.
 
 Thank you. I didn't know compat-wireless.
 Unfortunately I haven't been able to make it work: b43 doesn't recognize
 my wifi card.
 I tried compat-wireless-2008-04-05 without the b43 patch.
 
 On boot, b43 isn't loaded automatically (by udev) as usual. If I load it
 with modprobe, I just get the following message:
 
  Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ]
 
 No card appears.

I've never been that.  I suggest that you unload b43 and ssb modules,
then load ssb and look for messages.  There should be a message like:

ssb: Sonics Silicon Backplane found on PCI device :02:02.0

If you don't see in in the kernel log, then it's the ssb module that
doesn't want to work with your PCI card.  If you see that message but
loading b43 doesn't result in recognizing your card, then we should be
looking why the wi-fi device one the ssb bus doesn't match any entry in
b43.

 # With compat-wireless:
 $ grep b43 modules.*
 modules.alias:alias ssb:v4243id0812rev0D* b43

It's better to use modinfo:

modinfo ssb
modinfo b43

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH RFT] b43: We need lots of regression testing

2008-04-05 Thread Pavel Roskin
On Sat, 2008-04-05 at 11:09 +0200, Johannes Berg wrote:
  Another unrelated bug (sorry, testing often finds unrelated bugs) is
  that scanning with specific ESSID was returning non-matching APs.  I
  mean iwlist wlan0 scan my_essid, which would still report many
  different ESSIDs.  It's inconvenient when the driver can sense 22 APs at
  once :)
 
 Heh. I'm not sure what the desired behaviour is, if you do that scan
 we'll give you everything we found but will scan actively for that
 particular SSID. The man page (sigh) only says:
 
   This command take optional arguments, however most drivers  
 will
   ignore  those.  The  option essid is used to specify a scan on a
   specific ESSID. The option last do not trigger a scan  and  read
   left-over scan results.
 
 Which isn't quite clear, but seems to match what we do. Maybe iwlist
 should filter it?

I tried scanning for ESSID that no AP has.  Most time I only get
response from one AP, which is an old Linksys BEFW11S4 v4 (802.11b
only).  Sometimes one or two other APs appear.  But it some cases, all
22 or 23 APs in range appear in the list.

The easiest way to reproduce it is to scan without ESSID and then with
ESSID.  Then the second scan will return all APs found in the first
scan.  But run the scan with the ESSID several times, and at some point
the list goes down to that dumb Linksys.

I'm fine with scanning without filtering.  It's more important that we
let users control what probe requests are being sent.  But I think we
should be consistent and avoid returning results of scans with different
parameters.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH RFT] b43: We need lots of regression testing

2008-04-05 Thread Pavel Roskin
On Fri, 2008-04-04 at 23:06 -0400, Pavel Roskin wrote:

 I'll try to get 4318 tested over the weekend.

It's just as good as bcm4306.

b43-phy0: Broadcom 4318 WLAN found
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8

It was the same laptop in the same place, and I could even go a couple
of steps further than with bcm4306.  It's a place with 22 APs in range,
and the AP I was connecting to is installed in a brick building away
from any windows.  Yet I could maintain connection at the far end of the
paring lot nearby.

I realize that the unpatched drive could probably perform as well.  But
I wanted to use this opportunity to test the driver and the patch at
once in some real life conditions, and the results are great!

Another thing I noticed today is that the quality next to the AP is
normally from 65/100 to 75/100.  But sometimes it jumps to a higher
number momentarily, up to 130/100.  Yet I don't see corresponding
changes in the signal and noise when it happens.  Signal level is
jumping randomly from -55 dBm to -15 dBm, and noise level is always -72
dBm (rarely -71 dBm).

When at the place when the connection breaks, the quality is 30/100,
the signal level is -84 dBm and the noise level is still -72 dBm.

Perhaps the quality could be calibrated so that 30 becomes 0 and 70
becomes 100 (and we should never get quality over 100).  The noise level
is probably too high.  And the signal jumping 40 dBm without me even
touching anything may indicate that the driver probably fails to make
some adjustments in the signal value.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43: 1 second freeze every 2 minutes - works with bcm43xx

2008-04-04 Thread Pavel Roskin
On Sat, 2008-04-05 at 00:45 +0200, Julien Muchembled wrote:
 Hmm... There's a misunderstanding somewhere.
 
 My laptop appears to be a real nightmare. I've spent too much time
 hacking the DSDT, having TuxOnIce work (yes, I would also like to test
 Nigel's git tree if I had time), getting around various hardware and
 BIOS bugs, etc.
 I'm tired of updating the kernel so often.

You may want to use compat-wireless then:
http://linuxwireless.org/en/users/Download

It's a backport of the current wireless drivers for the older kernels.
The patch Michael asked us to test applies to it cleanly.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH RFT] b43: We need lots of regression testing

2008-04-04 Thread Pavel Roskin
On Fri, 2008-04-04 at 16:12 +0200, Michael Buesch wrote:
 Hi b43 users,
 
 Please be so kind to run lots of regression tests on the following
 patch. This patch is supposed to make the LO calibration a _lot_ more
 lightweight and avoid a long MAC-disable period every 120 seconds.
 
 We need a lot of regression testing with this patch on lots of different
 devices to make sure we don't introduce regressions.
 
 I tested this on a 4306 and a 4318 card. So far it seems to work great
 on these cards.

Tested on this:

b43-phy0: Broadcom 4306 WLAN found
b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
phy0: Selected rate control algorithm 'pid'
Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]

It's actually Fedora development kernel 2.6.25-0.195.rc8.git1.fc9.i686
with patched compat-wireless installed.

It's working better than I could possibly expect.  The range is on the
par with another laptop with ipw3945 running Linux or Windows XP.  It's
working through 4 walls and 30 meters on top of that.  I understand that
there are many random factors involved, but my impression is very
positive.  Basically, it's good enough to go outside with the laptop
without having an AP installed near a window.  I haven't seen any
significant interruptions in the connection.

Unfortunately, I hit that nasty circular lock dependency bug (already
discussed in another thread) when I killed wpa_supplicant to try another
AP.  The CPU utilization went to 100%, but the driver kept working.

Another unrelated bug (sorry, testing often finds unrelated bugs) is
that scanning with specific ESSID was returning non-matching APs.  I
mean iwlist wlan0 scan my_essid, which would still report many
different ESSIDs.  It's inconvenient when the driver can sense 22 APs at
once :)

I'll try to get 4318 tested over the weekend.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Urgent help needed: Broadcom 4318 SPROM corruption

2008-03-31 Thread Pavel Roskin
On Mon, 2008-03-31 at 17:39 +0200, Stefanik Gábor wrote:
 I have a weird problem with my 4318: its SPROM got corrupted (power
 outage, whatever, I don't know, as I haven't messed with it), and now
 it appears in my LSPCI output as a Broadcom 4218 (device ID changed
 to 0x4218 from 0x4318). I can't even flash my SPROM back to the right
 values, because the SSB driver doesn't pick up my card, and thus no
 ssb_sprom file appears. My question is: what do I have to modify in
 the kernel to make SSB threat my BCM4218 as a proper BCM4318, or at
 least to pick it up to the point where ssb_sprom shows up and I can
 flash it back to the proper BCM4318?

Look for 4318 in drivers/ssb/b43_pci_bridge.c and add a similar value
for 4218.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: BCM4328 latest GIT driver.

2008-03-31 Thread Pavel Roskin
On Mon, 2008-03-31 at 16:09 +0200, Michael Buesch wrote:
 On Monday 31 March 2008 15:15:03 Subodh Shrivastava wrote:
   [ 2056.834017] b43-phy1 ERROR: FOUND UNSUPPORTED PHY (Analog 5, Type
   4, Revision 1)
 
   I am aware that support for this chipset is work in progress, I would
   be happy to help in testing.
 
 Help in reverse engineering is needed ;)

I prefer to stay on the software part of things, but I have a BCM4328 in
my laptop.  I just ordered an Intel card (iwl4965), so once I get it, I
can offer that BCM4328 for free (plus free shipping and handling :)) to
whoever is going to reverse engineer it.

Last time I did it with an Atheros card, and the result exceeded all my
expectations - we have functional ath5k now :)

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Problems with a bcm4306 (03) and b43/b43legacy

2008-03-26 Thread Pavel Roskin
On Wed, 2008-03-26 at 13:46 +0100, Stefanik Gábor wrote:
 An idea: Are you using a kernel with SMP and/or PAE enabled? I suspect
 an SMP-related issue (I got this problem with OpenSUSE kernels, which
 are all SMP-enabled), or maybe HPET/high-resolution timer/tickless
 system related.

I'm not sure why you are asking me, since I'm not experiencing any major
problems now.

bcm4318 is working for me with or without SMP.  PAE is not enabled.
That's the latest wireless-testing kernel.  Both the old and the new 4.x
firmware is working fine.  I tried removing the antenna, but it's still
working (the link quality is lower, of course).

If you have kernels that work and those that don't work, it's a good
starting point.

I would try to capture packets going in both directions on a separate
machine, note the signal strength, then load ndiswrapper with Windows
drivers, capture the packets and compare the results.  It's very
important that you don't even touch any antenna between measurements or
reorient anything.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Problems with a bcm4306 (03) and b43/b43legacy

2008-03-25 Thread Pavel Roskin

On Mon, 2008-03-24 at 19:49 -0700, Larry Finger wrote:

 The problem is with authentication. The interface is actively 
 scanning, thus transmit is working.

How do you know that?  Receiving beacons doesn't require transmission.
Just trying to understand your logic.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: No Access to https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

2008-02-26 Thread Pavel Roskin
On Tue, 2008-02-26 at 20:44 +0100, Guillaume wrote:
 Hi every one.
 
 https://lists.berlios.de/mailman/listinfo/bcm43xx-dev return me a Secure 
 Connection Failed...
 
 How can i do to unsuscribe ?

Firefox says Your certificate contains the same serial number as
another certificate issued by the certificate authority.

One solution would be to remove the certificates for berlios.de.  In
Firefox, go to Edit-Preferences-Advanced-Encryption-View
Certificates-Web Sites.  Remove all certificates issued by berlios.de.

Alternatively, you can use another browser that doesn't know of a
certificate with the same number.  Konqueror, lynx or links should work
fine.

If everything fails, you can write a message to
[EMAIL PROTECTED] with unsubscribe in the subject.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Cannot associate (4318 on HP laptop)

2008-02-22 Thread Pavel Roskin
On Fri, 2008-02-22 at 14:45 +0200, Alberto Mardegan wrote:
 ext Alberto Mardegan wrote:
  wlan0: Initial auth_alg=0
  wlan0: authenticate with AP 00:13:49:68:98:85
  wlan0: authenticate with AP 00:13:49:68:98:85
  wlan0: authenticate with AP 00:13:49:68:98:85
  wlan0: authentication with AP 00:13:49:68:98:85 timed out
 
 A short follow-up: a user suggested me to move closer to the AP. That 
 made it to work (and NetworkManager reported full signal power, which is 
 hard to believe since I moved only one metre aside).

The problem is, this driver is written only from reverse engineered
data, but the device needs a lot of attention from the host software.
Many things just cannot be implemented without a good understanding of
the hardware registers.  The driver is getting better, but it not
perfect.

I do appreciate that you have tested it and that we know that the
physical layer is likely suspect.

 But unfortunately that's not a feasible setup for me, and I had to 
 switch back to ndiswrapper. It's kind of strange to me though, since I'm 
 only 4 metres away from the AP!

You may want to try a different channel or bigger antennas.  And if you
go to ndiswrapper, it would be great to see you back once the driver
handles your setup better.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Cannot associate (4318 on HP laptop)

2008-02-18 Thread Pavel Roskin
On Mon, 2008-02-18 at 09:52 +0200, Alberto Mardegan wrote:
 Hi, yesterday I installed the kernel version 2.6.24, and tried to get 
 rid of ndiswrapper. But I could get the wlan to work.
 wlan0: Initial auth_alg=0
 wlan0: authenticate with AP 00:13:49:68:98:85
 wlan0: authenticate with AP 00:13:49:68:98:85
 wlan0: authenticate with AP 00:13:49:68:98:85
 wlan0: authentication with AP 00:13:49:68:98:85 timed out

From my experience with bcm4318, you need a bigger antenna, and the
range will be shorter than with ndiswrapper.  I realize that you may not
be able to change the antenna, but try getting close to the AP to see if
that's the case.

 iwconfig reports that we are associated with the AP, but if I manually 
 assign an IP to wlan0 with ifconfig and try to ping the AP, I get 
 destination unreachable.

If the link quality is shown as 0, you are not associated.  Yes, it's
misleading to the see AP if the association didn't complete.  You can
try setting the ESSID again.  That should retry the association.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Help with bcm4328 revision 5

2008-02-12 Thread Pavel Roskin
On Tue, 2008-02-12 at 14:38 -0200, Alan Carvalho de Assis wrote:
 Hi,
 I am testing kernel 2.6.25-rc1 to get my Broadcom Corporation BCM4328
 802.11a/b/g/n (rev 03) working.

You probably want to be on the everything branch of the wireless-2.6
repository to help with this.  Not all patches go into 2.6.25-rc1.

 ssb: SPROM revision 5 detected. -

From what I see in drivers/ssb/pci.c, even though 5 is printed, it is
later set to 4 for BCM4328:

   } else if (bus-chip_id == 0x4321) {
   /* the BCM4328 has a chipid == 0x4321 and a rev 4 SPROM */
   out-revision = 4;
   sprom_extract_r4(out, in);

Otherwise, you would also see Unsupported SPROM revision in the kernel
log.

 ssb: Sonics Silicon Backplane found on PCI device :03:00.0
 
 Although ssb module is loaded automatically and correctly, the module
 b43 is not loaded automatically, even if I create a
 /etc/modprobe.d/b43 (alias wlan0 b43).
 
 Issuing modprobe b43 loads the module but don't raises wlan0 and
 don't show any log info.

Try adding revision 12 to the device table.

diff --git a/drivers/net/wireless/b43/main.c
b/drivers/net/wireless/b43/main.c
index afb1094..aa174da 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -82,6 +82,7 @@ static const struct ssb_device_id b43_ssb_tbl[] = {
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 9),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 10),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 11),
+   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 12),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 13),
SSB_DEVTABLE_END
 };

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Problems b43 driver and bcm4318

2008-02-11 Thread Pavel Roskin
Quoting [EMAIL PROTECTED]:

 Hi,
 I tried the new b43 driver from kernel 2.6.24 hoping I could get rid of
 ndiswrapper, but something is wrong. Can you please give me advice as
 how to troubleshoot this? Below follows the output from dmesg after I
 modprobe'd the b43 driver. I can't connect to the access point (WEP),
 but iwlist wlan0 scan  actually works.

I'm quite sure your case is described in the mail archives:
https://lists.berlios.de/pipermail/bcm43xx-dev/2008-February/006779.html

It looks like you are using firmware for the git version of the  
driver, not for Linux 2.6.24.x and older.

And by the way, Linux 2.6.24.1 would give you are better message about  
firmware compatibility.  And you probably want to go to the latest  
2.6.24.x anyway to avoid a major security issue with the kernel.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Possible problem on b43 driver's init

2008-02-10 Thread Pavel Roskin
On Sun, 2008-02-10 at 17:28 -0400, David Cohen wrote:
 Hi all,
 
 I'm here again reporting another possible problem with my wireless
 card and b43 driver. Please don't bite me this time, I promise I'm
 sending all useful inputs :D
 Well, the problem is:
  - After boot my laptop, the wireless card is not connected to my wifi
 network. But if I just type sudo iwlist scan, then it connects.
  - The same problem does not occur if I use ndiswrapper or another laptops.

I believe it's a feature of mac80211.  It only scans for APs under some
circumstances.  Setting ESSID triggers scanning.  I suggest that you do
it in this order:

bring the interface up
set the WEP key
set the ESSID

By the way, your AP is set for shared key authentication.  It delays
authentication because mac80211 tries open system first and fails.
Even without that step, shared key authentication needs 4 packets to be
sent, rather than 2 for open system authentication.  It's believed that
shared key is even less secure than open system.  See e.g.
http://www.networkworld.com/research/2002/0909wepprimer.html

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH] b43: Add support for new firmware

2008-01-15 Thread Pavel Roskin

On Sun, 2008-01-13 at 14:20 +0100, Michael Buesch wrote:
 This patch adds support for new firmware.
 Old firmware is still supported until July 2008.
 
 To get new firmware, go to
 ftp://ftp.linksys.com/opensourcecode/wrt150nv11/1.51.3/
 and download the tarball. We don't have a smaller tarball, yet.
 That will be fixed later.

I have finally found some time and hardware to test it, but the tarball
is overwhelming at its 186M.  And the worst thing, the server
disconnected after 30M and appears to be down right now.  P.S. It's up,
ETA is 48 minutes.

There were two files there.  I hope either is fine.  I'm trying to
download WRT150NV11_v1.51.3_ETSI.tgz

Cannot we petition Linksys to put wl_ap.o outside the tarball?  Or maybe
Broadcom could do it?

Even a zip file would be better.  It's possible to cut a part of the zip
file and uncompress it with gzip.

It's really a travesty of open source.  The file is available, but you
have do download 186M of useless (for me at least) mips compilers and
other stuff.  And I have a relatively good connection.

 You can extract firmware out of the wl_ap.o file contained
 in this tarball using latest fwcutter. You must pass the option
 --unsupported to fwcutter.
 Fwcutter-010 with official support for a new firmware image will
 be released soon.

Do you know that the Subversion repository of fwcutter has no files at
all?  I mean svn://svn.berlios.de/bcm43xx/trunk

Yes, I will try --unsupported, with version 009.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 will need a firmware upgrade soon

2008-01-06 Thread Pavel Roskin
Quoting Michael Buesch [EMAIL PROTECTED]:

 see fwpostfix module parameter

Can we please avoid this annoyance this time?

It was bad at the bcm43xx/bcm43xx_mac80211 time, but it's going to be  
a bigger annoyance this time, because the driver with the same name  
b43 will need a different fwprefix for different kernel versions.

I don't think modprobe.conf can be written to use different options  
for different kernel versions.  And if it can, I don't want to force  
everyone to figure it out.

The driver knows which firmware is needs.  It's the driver's  
responsibility to express its requirements, rather that the users'  
responsibility to figure out which firmware this particular version of  
the driver wants.

iwlwifi changed the firmware name when a different firmware was  
needed.  And that's a good example, in my opinion.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 will need a firmware upgrade soon

2008-01-06 Thread Pavel Roskin
Quoting Michael Buesch [EMAIL PROTECTED]:

 On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote:
 Quoting Michael Buesch [EMAIL PROTECTED]:

  see fwpostfix module parameter

 Can we please avoid this annoyance this time?

 Go and complain at Broadcom please.

Mind you, there is nothing fundamentally wrong with changing firmware  
or changing its API.

Sure, Broadcom firmware is not under GPL, so we have to keep it in  
separate files rather than link it into the kernel.  But the same  
situation exists for many other drivers, even those where the vendors  
are much more cooperative, such as Intel.

If the firmware is kept outside the kernel, we have a problem of  
synchronization between the driver and the firmware.  It can be  
addressed gracefully, or not so gracefully.  The choice is entirely  
ours, and Broadcom is not to blame for our choice.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43 will need a firmware upgrade soon

2008-01-06 Thread Pavel Roskin
Quoting Rafael J. Wysocki [EMAIL PROTECTED]:

 People don't want N-PHY support?

 Well, as it sometimes is said the better is an enemy of the good.  If they
 feel comfortable without the N-PHY, why would they want it?

 Still, if you can add the support for it as a feature that doesn't affect the
 people's working configurations, no one will complain.

I really want N-PHY and I have hardware to test it on.  It's just the  
word fwprefix that makes me allergic.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH RFT] b43: Fix for broken transmission

2007-12-12 Thread Pavel Roskin
Quoting Larry Finger [EMAIL PROTECTED]:

 Michael Buesch wrote:
 Here's an updated version that should fix even more bugs:
 http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/005-b43-fix-init-rewrite-breakage.patch

I had to omit the last part (for tables.c) - it's unrelated, cosmetic  
and doesn't apply to wireless-2.6/everything.

 This patch (and its predecessor) seem to make transmission at the   
 OFDM rates a bit more reliable on
 my BCM4311/2 card.

It's working fine on BCM4318 on PowerPC.  I haven't done any specific  
comparisons, but it used to disconnect a lot (at least one an hour)  
with a small antenna, so I installed a bigger antenna, but then gave  
up and switched to using another wireless device (rtl8185).

Right now, it's been working for over 2 hours with a small antenna  
(although it's a different antenna borrowed from rtl8185) and no  
disconnects.  Scanning finds 5 APs, which is the most I have seen here.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Off-line for now

2007-11-29 Thread Pavel Roskin

On Thu, 2007-11-29 at 07:44 -0600, Larry Finger wrote:
 Today is the day I start my winter migration to a warmer clime. Until April, 
 my full-time access to 
 a broadband line is limited, which is the reason I resigned as maintainer for 
 bcm43xx and b43legacy.
 
 I will not be leaving the bcm43xx community completely as I have joined the 
 reverse engineering 
 group.

Larry, I think it's a very good decision after you put the driver on the
firm foundation of mac80211.  Better understanding of the hardware is
essential for further improvements.  Good luck with your migration and
with reverse engineering!

 In fact, my BCM4311 has higher throughput with the b43 driver than it 
 does when I'm running Windows (Yes, my machine does dual-boot, but
 that is mainly for testing!).

That's impressive indeed.  I hope it would be true for 4318, and
eventually for 4328.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: mac80211 regression: doesn't associate automatically

2007-11-22 Thread Pavel Roskin
On Thu, 2007-11-22 at 08:26 -0500, John W. Linville wrote:

 As it stands, setting the SSID is the closest thing we have to an
 associate now trigger.  I would have to advise distros and users to
 always set it last in the wireless init, just before running dhclient
 or whatever.

Maybe mac80211 should have a grace period of 0.5 seconds or so to
allow other settings to be set before the scanning starts?  The same
applies to other events causing scanning, such as bringing up the
interface.  It's too short to be noticeable, yet long enough for the
next command to run even on slow systems.

I think setting the key should not cause reassociation if there is an
association.  It can break some schemes where the WEP key changes
periodically on both sides.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: mac80211 regression: doesn't associate automatically

2007-11-22 Thread Pavel Roskin
On Thu, 2007-11-22 at 18:18 -0700, Ehud Gavron wrote:

 2. dmesg repeats: wlan0: authentication with AP 00:50:bf:b1:da:64 timed out

I think it's an unrelated hardware specific issue.  mac80211 tried to
associate but failed.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: BCM94311MCG

2007-11-08 Thread Pavel Roskin

On Thu, 2007-11-08 at 17:36 +0100, Ruggiero wrote:
 i just installed fedora7 and the firmware 4 by bcm43xx_fwcutter,it's a bit 
 different by ubuntu because i don't have the command iwconfig and iwlist 
 scan,how can i verify the card is working properly?here there is some 
 informations:
 i have a b44ethernet card in the laptop
 
 [EMAIL PROTECTED] ~]$ dmesg|grep bcm
 bcm43xx_mac80211: Broadcom 4311 WLAN found

You should upgrade your system with yum upgrade.  The current Fedora 7
kernel is 2.6.23.1 with b43 and b43legacy drivers, which work much
better.

You'll need b43-fwcutter to prepare firmware for the updated drivers.
It creates firmware files in subdirectories and avoids conflict between
v23 and v4 firmware.

Just in case, today may not be the best day to upgrade Fedora, and
Fedora 8 was released, and the pipes are likely saturated.  Try
upgrading just the kernel: yum upgrade kernel

On the other hand, Fedora updates are so massive, that you may prefer to
join the torrent and download Fedora 8.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Kubuntu on an Acer

2007-10-28 Thread Pavel Roskin

On Sun, 2007-10-28 at 19:23 -0500, Robert Easter wrote:
 Here's one for the scrapbook, though hopefully not for the scrap yard-
 
 New install of Kubuntu 7.10- has a gui install set up for the Broadcom 
 drivers, etc.  Very nice, if it worked.  Any suggestions on how to find 
 the glitch, or best ways to totally replace the dead code with some that 
 works?  Details:

Most likely you don't have the firmware.  Please try:

aptitude install bcm43xx-fwcutter

That should download and install the firmware upon install.  If you
cannot get that system online at all, you can get bcm43xx-fwcutter from
http://linuxwireless.org/en/users/Drivers/b43 and follow the
instructions how to extract the firmware.  Then transfer it to the
laptop.

If the problems persist, please check the kernel messages with dmesg.
You may also want to find out which driver you are using by running:

lsmod |grep -E '(b43|bcm43)'

If you are using b43 or b43legacy, you'll need b43-fwcutter, which
creates slightly different firmware files.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Machine Check on Fedora rawhide kernel.

2007-09-14 Thread Pavel Roskin
On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote:

 -   macstat = le32_to_cpu(rxhdr-mac_status);
 +   macstat = le16_to_cpu(rxhdr-mac_status);
 mactime = le16_to_cpu(rxhdr-mac_time);
 chanstat = le16_to_cpu(rxhdr-channel);
 
 But I think in this case this also didn't change the actual
 result in macstat.

I don't think so.  Suppose rxhdr-mac_status is 1.  le32_to_cpu() will
return 0x100, which would turn into 0 on conversion to u16.
le16_to_cpu() will return 0x100.  Since rxhdr-mac_status is accessed by
value (not by pointer), it will be 1 whether it's treated as 32-bit or
16-bit.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Machine Check on Fedora rawhide kernel.

2007-09-14 Thread Pavel Roskin
Quoting Michael Buesch [EMAIL PROTECTED]:

  I don't think so.  Suppose rxhdr-mac_status is 1.  le32_to_cpu() will
  return 0x100,

 How would it return 0x100?
 if mac_status is 1 in the lowest byte, le32_to_cpu would not put that 1 into
 the highest byte of the result.

Actually, it would.  On big-endian systems, conversion from  
little-endian to CPU order swaps bytes.

Please note that referring to the lowest byte can be confusing.  The  
least significant byte and the byte with the least address are not the  
same on big-endian systems.  Besides, mac_status has a meaning for the  
CPU that is different from its meaning for the hardware in the  
hardware is little-endian but the CPU is not.  What the hardware sees  
as 0x100, the CPU sees as 1 before the conversion.  What is least  
significant for one is most significant for another, until the  
conversion is done.

  which would turn into 0 on conversion to u16.
  le16_to_cpu() will return 0x100.  Since rxhdr-mac_status is accessed by
  value (not by pointer), it will be 1 whether it's treated as 32-bit or
  16-bit.

 Ok, I didn't know it's passed by value.
 I thought it was casted to pointer inline.
 If it's passed to leX_to_cpu by value, of course it's a different story.

OK.  I'll leave my explanation anyway for benefit of other readers.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH, fwcutter] add support for DragonFlyBSD

2007-09-08 Thread Pavel Roskin
Hello!

On Sat, 2007-09-08 at 15:08 +0800, Sepherosa Ziehau wrote:

 Following patch make b43-fwcutter work on DragonFlyBSD:
 http://leaf.dragonflybsd.org/~sephe/fwcutter.diff
 
 Please review it.  If you folks think it is OK, please commit it to
 your svn repos.
 It was reviewed by johill and mb on #bcm-specs

I suggest that you remove all references to DragonFlyBSD and use some
symbol that is defined on all BSD systems.

This way, the program will compile and work with no changes on all BSD
systems as long as the headers are compatible.  And if there are any
incompatibilities, they would likely be minor and fixable without adding
too many ifdefs.

The patch as it is just encourages adding more preprocessor conditionals
if the program is ported to more OSes.

Also, I suggest that you reconsider calling the firmware directories
v3 and v4.  Such names are too generic and don't provide information
about the hardware, unlike b43 and b43legacy.  It would be easier if
b43-fwcutter just worked the same way on any OS.  You may prefer to do
renaming in a wrapper that installs the firmware.

I would put definitions for bswap_16 and bswap_32 immediately below
#include sys/endian.h, but it's a mater of taste.  Also, I would use
definitions with arguments, as they are more robust and would indicate
use with a wrong number of arguments.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Thanks...!

2007-09-07 Thread Pavel Roskin
Hello!

Please don't start new threads for the same topic.  Next time please use
reply on the appropriate message in the thread.  It's just easier to
read this way.

On Fri, 2007-09-07 at 13:24 -0700, Arne Chr. Jorgensen wrote:

  (3) For Broadcom wireless, look for BCM4311 or BCM4312 cards. Stay
 away
   from pre-N stuff.

 pre..802.11n - is that what you meant ?

Just to avoid possible confusion, this refers only to the devices
implementing any preliminary 802.11n specifications (whether it's
pre-N or draft N), not to the devices implementing standard
protocols that predate 802.11n, such as 802.11g and 802.11b.

Basically, support for bcm4306 and bcm4311 are quite good, bcm4318 is
getting there, support for anything newer is not even under development.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


An idea about Kconfig issue

2007-08-12 Thread Pavel Roskin
Hello!

[I'm sorry I'm on vacation on a very slow connection, so I may not be  
able to reply soon, but I'll post anyway]

I think we could rename CONFIG_SSB to CONFIG_BROADCOM_SSB.  This way,  
everybody running make oldconfig will be asked whether to enable  
this option.  The help text could explain which devices need it.

I believe it's at least as good as the hacks that have been suggested so far.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: bcm4301 - bcm43xx-legacy

2007-08-09 Thread Pavel Roskin
On Thu, 2007-08-09 at 15:41 +0200, Michael Buesch wrote:

 So, that said, I want to rename all the drivers.
 My plan was to rename bcm43xx-mac80211 to b43, so
 you could probably rename bcm4301 to b43-legacy or something
 shorter like b43-leg or maybe even b43-old.

I think if bcm43xx will be replaced with its mac80211 port, it should
stay bcm43xx to preserve users' .config and fwpostfix settings.

If the softmac and the mac80211 drivers are going to coexist at least in
one released kernel, then b43old seems to be a good name for the new
driver.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: bcm4301 - bcm43xx-legacy

2007-08-09 Thread Pavel Roskin
On Thu, 2007-08-09 at 16:07 +0200, Michael Buesch wrote:
 On Thursday 09 August 2007 16:00:47 Pavel Roskin wrote:
  On Thu, 2007-08-09 at 15:41 +0200, Michael Buesch wrote:
  
   So, that said, I want to rename all the drivers.
   My plan was to rename bcm43xx-mac80211 to b43, so
   you could probably rename bcm4301 to b43-legacy or something
   shorter like b43-leg or maybe even b43-old.
  
  I think if bcm43xx will be replaced with its mac80211 port, it should
  stay bcm43xx to preserve users' .config and fwpostfix settings.
 
 No it should not. bcm43xx-mac80211 requires different firmware.

I think you misread me.  its mac80211 port refers to bcm4301.  I just
tried to avoid the bcm4301 name because it wasn't exposed in Linux
releases yet.

Anyway, it's up to Larry, and he doesn't seem to dislike legacy.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Pavel Roskin
On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote:

 The spec is telling us to lookup an invalid index in the LO table.

I see.  Thanks for your explanation!

I think the way to solve it would be to see how the table is used in the
proprietary driver.  Either the data from the extra entries is used, and
we need to find out where it comes from, or there is an algorithm to
limit the index to only access valid entries.

I hope the reverse engineering team knows that.  I wish them good luck.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Dell Inspirson 9400 with Dell 1390 wireless card

2007-08-07 Thread Pavel Roskin
Hello!

On Tue, 2007-08-07 at 08:25 -0400, Rob Lewis wrote:

 I apologize if this has been covered already, but i have a few
 questions, as i am lost as where to begin to get this driver to work.
  
 I have a Dell 1390 Wireless card with bcm4311 chipset. I believe it is
 v4 firmware. I have been reading the lists and Larry mentioned that
 this driver only works with v3.

As far as I know, the firmware is never stored in the device
permanently.  It is loaded by the driver into device RAM.  The firmware
has to be extracted by bcm43xx-fwcutter, which can process both v3 and
v4 firmware.
 
 How do i find out my firmware revision?

It will be reported by bcm43xx-fwcutter

 Will there be support for v4?

It is is a separate driver, bcm43xx_mac80211.  It's already supported.

 Can i flash the rom to v3 to get support for this driver, and in doing
 so, will it affect the hardware functionality at all?

As far as I know, you cannot flash ROM.

 I did not see a bcm4311 driver in the kernel (.22 and .23rc1), do i
 need to patch to get it?

If you mean bcm4301, yes, you need to patch the kernel.  But bcm43xx is
already in the driver, and it works with v3 firmware.
 
-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Dell Inspirson 9400 with Dell 1390 wireless card

2007-08-07 Thread Pavel Roskin
On Tue, 2007-08-07 at 10:41 -0400, Rob Lewis wrote:

 1) Use fwcutter to find out firmware revision, if v4 patch kernel
 enable 4301, if v3 enable bcm4311 driver.
 2) Use normally?

You can use fwcutter to extract any firmware.  bcm43xx and bcm4301 use
v3 firmware.  bcm43xx_mac80211 uses v4 firmware.  There is no such thing
as bcm4311 driver.

When the interface is brought up, the driver will load the firmware.  If
the firmware version is wrong, there will be a message in the kernel
log, which can be seen with the dmesg command.
 
 I will be looking for 'tutorials online' as to how to do this, though
 if you can point me to something you can recommend, that would be
 great. 

I'm not aware of any tutorials.  bcm43xx-fwcutter can be found here:
http://developer.berlios.de/project/showfiles.php?group_id=4547
 
-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Dell Inspirson 9400 with Dell 1390 wireless card

2007-08-07 Thread Pavel Roskin
On Tue, 2007-08-07 at 11:34 -0400, Rob Lewis wrote:

 Without broadcom releasing drivers or source, will we always have to
 use fwcutter?

All that's needed is to make it legal to copy the firmware, and most
distributions will be able to package it.  That's what Atmel and Intel
did.  They didn't release sources of the firmware.

The best thing Broadcom could do would be to release the detailed
specifications, but releasing the firmware under a free-to-copy license
would be helpful too, as it would allow using the existing Linux drivers
out-of-box.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[PATCH] Fix handling of failure to create debugfs directory

2007-08-07 Thread Pavel Roskin
This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.

Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
---

 .../wireless/bcm43xx-mac80211/bcm43xx_debugfs.c|8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c 
b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
index 9ca4625..aded2b3 100644
--- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
@@ -408,7 +408,7 @@ static struct file_operations restart_fops = {
 
 int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
 {
-   return !!(dev-dfsentry-dyn_debug[feature]);
+   return !!(dev-dfsentry  dev-dfsentry-dyn_debug[feature]);
 }
 
 static void bcm43xx_remove_dynamic_debug(struct bcm43xx_wldev *dev)
@@ -472,7 +472,9 @@ void bcm43xx_debugfs_add_device(struct bcm43xx_wldev *dev)
snprintf(devdir, sizeof(devdir), %s, wiphy_name(dev-wl-hw-wiphy));
e-subdir = debugfs_create_dir(devdir, fs.root);
if (!e-subdir || IS_ERR(e-subdir)) {
-   e-subdir = NULL;
+   bcmerr(dev-wl, debugfs: cannot create %s directory\n,
+  devdir);
+   dev-dfsentry = NULL;
kfree(log-log);
kfree(e);
return;
@@ -525,6 +527,8 @@ void bcm43xx_debugfs_log_txstat(struct bcm43xx_wldev *dev,
struct bcm43xx_txstatus *cur;
int i;
 
+   if (!e)
+   return;
log = e-txstatlog;
assert(irqs_disabled());
spin_lock(log-lock);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-06 Thread Pavel Roskin
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:

 Well, it's not that easy. Current code just doesn't make any sense.
 I do not understand how hardware power control works exactly, so I
 can't write some detailed message or something.
 That's probably a chicken and egg problem ;)

OK, the existing code complains that one number is larger than another.
You don't want to hide that message, but when I ask you to explain, you
say that the code makes no sense to you.

Somehow, it doesn't sound right.  Nobody knows the code better than you.
I think communication is essential for development.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-06 Thread Pavel Roskin
On Mon, 2007-08-06 at 08:42 -0400, Joseph Jezak wrote:

 The problem is that the reverse engineering team (myself and 
 Johannes) don't understand the code in the original driver well 
 enough. The power control code is certainly the most confusing and 
 incomplete part of our specs.  While I'd love to spend the time 
 figuring it out, I just can't spend that time right now.

Well, this reminds me The Mad Hatter's Tea Party with me being
Alice :)

Anyway, good luck with the driver work!

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-04 Thread Pavel Roskin
On Sat, 2007-08-04 at 18:47 +0200, Michael Buesch wrote:

 Yeah, I'd like to get rid of this message, too. But by fixing the
 bug and not by hiding it.
 
 So any suggestions on how to fix this?

I think you could try to write a detailed explanation of the problem, in
particular, what those tables do, where the numbers come from, what
hardware is affected, what the driver does now, what it should do, and
how to find out the right solution from reverse engineering data.

After all, there are working drivers for the chipset, and they can be
reverse engineered.  It cannot be a problem with no solution.

Chances are that you will have some ideas before you finish writing the
message.  It happened to me many times.  But even if it doesn't happen,
you will make it easy for others to suggest solutions.  And you will
give the reverse engineering team some ideas what to look for.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: I will switch to quilt based development

2007-08-03 Thread Pavel Roskin
On Fri, 2007-08-03 at 09:36 +0200, Holger Schurig wrote:
  I see.  One thing I didn't like in quilt is that I have to
  decide what I'm going to do before actually changing the
  sources.
 
 All I have to decide beforehand is the name of patch. In stgit 
 this is the same. However, stg is worse, because there I even 
 have to enter a description of what I'm about to do beforehand. 
 *)

But unlike quilt, you don't have to do anything before editing the
sources.  You can create a patch after the changes are done.  Or you can
revert the changes.

Having to do anything before editing reeks of version control systems
predating CVS, where files had to be checked out for editing.

My complaint about stgit is that I have to write the description without
seeing the changes.  I just noticed stg new -s, but it's broken.
Generally, stgit follows quilt too closely here.  stg new and stg
refresh should be merged, or one of them should be optional.

 Sometimes, I just make patches in quilt, then I do quilt 
 refresh, quilt pop -a, cd patches and modify the patches 
 and series file manually, e.g. by moving one patch from one file 
 into the other. The cd .., quilt push -a and off I am. That 
 the database of quilt is in a known format and I can hack on 
 it with an editor is a plus for me :-)

That's a very cool feature that stgit should learn.

 That said: once I'm finished with quilt-things, I'm using stg 
 import to import this into git and use git to send it off to the 
 mailing list. I'm not working with stg on the first place, 
 because quilt is noticably faster than stg.

Perhaps periodic repacking with git-gc could speed up things a bit.  But
the search for changed files is actually for your protection, and should
be appreciated IMHO.

 *) in stgit I can do stg refresh -e to edit the description 
 afterwards

stg refresh -es and stg export -np are my favorite commands.

I'm going to post all my ideas to the git list right now.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-03 Thread Pavel Roskin
On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote:

 The size of LO array message is not fatal.

I'll really appreciate if it's removed or at least the stack dump is
suppressed.  We know already that it's a problem, so why scare users
more than they need to?  We know where it happens, why show the stack?

I don't think we want to make users ignore stack traces in the kernel
logs, because we may not hear about unknown problems.

IMHO there are better places for TODO notes than innocent users' kernel
logs.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: I will switch to quilt based development

2007-08-02 Thread Pavel Roskin
Hello, Michael!

On Thu, 2007-08-02 at 22:47 +0200, Michael Buesch wrote:
 Hey guys,
 
 I will drop my git tree and switch to much more
 lightweight quilt based workflow.
 My latest patchsets will be published at
 
 http://bu3sch.de/patches/wireless-dev/
 
 My scripts do upload the plain patchfiles (plus quilt series file)
 and additionally a .tar.bz2 file.

Please consider StGIT (http://www.procode.org/stgit/), which works on
top of git.

I really like that StGIT makes it possible to go back to old patches and
adjust them.  And it works with qgit.  Patches can be exported and
published.

It should be possible to make a build system that would compile SSB and
bcm43xx_mac80211 outside the kernel tree.  The lightweight tree could
still use the usual path under drivers/ssb and drivers/net/wireless for
the drivers, so that the patches won't need to be adjusted.

If you have any specific problems with git, it would be great if you
report them to the git mailing list.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: I will switch to quilt based development

2007-08-02 Thread Pavel Roskin
On Fri, 2007-08-03 at 00:22 +0200, Michael Buesch wrote:

 No, I don't want git.
 It's too heavy. And it has major problems when John rebases his
 tree upstream.

I'm sure you can help git development if you post your observations to
the git list.

 With quilt and my scripts I can easily push them upstream to linville,
 easily publish them on my server. All a matter of typing one command.

stg export -np
stg mail --all

 Going back to old patches works perfect with quilt.

I see.  One thing I didn't like in quilt is that I have to decide what
I'm going to do before actually changing the sources.  And it's
impossible to revert changes made before the patch is created.

But I understand it's a question of habits, and everybody has different
preferences when it comes to the tools.

 And I am not going to maintain out of tree stuff anyway.
 :)

That's why I suggested the lightweight tree:

Makefile
drivers/
  ssb/
ssb sources
  net/
wireless/
  bcm43xx_mac80211/
bcm43xx_mac80211 sources

The top-level Makefile finds the kernel sources and compiles against
them.  It can also have maintenance targets, such as indent.

 Yes, I looked at stgit before writing my own set of scripts on top
 of quilt. And I found out that it doesn't quite fit my needs.

OK, it's getting off-topic, but if you need help with stgit, please feel
free to ask.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: bcm4301: A mac80211 driver using V3 firmware

2007-07-20 Thread Pavel Roskin
On Fri, 2007-07-20 at 09:44 -0400, John W. Linville wrote:
 On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote:
  Actually, the common practice is that the new driver that doesn't
  supplant the old driver immediately and for the whole range of hardware
  gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.
  
 Yes, this preserves stability for happy bcm43xx users.  Still taking
 suggestions for the new name for bcm43xx-mac80211... :-)

b43
bcm43
bcm4k3
bcmwifi
bcmwlan
bcm80211
brcm43xx
broadcom

I really like the minimalism of b43, which plays well with b44 and
p54 :)

  Also, we could introduce a kernel option to enable support for new
  devices in your driver.
  
 Yes, this is probably worthwhile for those wishing to avoid PCI ID
 conflicts between the drivers.  I have also been speculating that
 perhaps we need an option for a secondary PCI ID table, so that a
 driver could support a large range of PCI IDs but then gracefully
 bow-out if another driver had a certain ID in its primary table.
 Does that make any sense?  It would seem to be applicable to a number
 of drivers in the kernel.

Yes, I used to hearing complains that orinoco steals IDs from hostap.
Then it became popular to blacklist orinoco modules.  Quite a disgrace
for the driver!  Having weak IDs for Prism based cards would have
avoided it.

But please realize that the problem goes far beyond PCI.  Perhaps you
have heard of CONFIG_USB_LIBUSUAL, which selects the best driver for USB
storage devices, either the slow but reliable ub, or the SCSI based
usb-storage, which it too fast for some cheap sticks.

It even has a parameter called bias, which allows to control how
conservative the algorithm should be.  That would be hard to emulate
with weak entries, but I hope that bias is an overkill.

 Yes, we should probably start using a default value for fwpostfix.
 As dwmw2 suggested, it would also be nice to fall back to an empty
 fwpostfix if the firmware is not found w/ the default extension.

Yes, that sounds good.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: bcm4301: A mac80211 driver using V3 firmware

2007-07-20 Thread Pavel Roskin
Hello, Ehud!

On Fri, 2007-07-20 at 09:33 -0700, Ehud Gavron wrote:

 The USERs don't want to know what card they have or what driver they 
 need or PCI IDs.  That's all stuff that makes them say Linux Bad, 
 *s good. (Yeah I know, there's the whole driver moreass there and 
 PCI VENs too) but anyway...

Agreed.

 The driver should have a name that reflects its use and capabilities.

Not necessarily.  End users should be shielded from such details by
distributions.  Do you know the name of the Windows driver for your
network card?  Does it reflect its use and capabilities?

Now, if we are talking about power users, who can occasionally recompile
the kernel or install a program not from the distribution, they would be
helped by reasonable names of the drivers.

Also, distribution maintainers would feel better if the drivers are not
renamed, so that /etc/modprobe.d/ doesn't need to be scanned for the old
names on kernel upgrade.

 For example, bcm43xx is a reasonable name.  I don't like it personally 
 because the google links to the site (berlios.de) that tell me that's 
 why I need took a while to find but that's just semantics.

That's not a problem with the name.  If the first hit on Google was some
vomit inducing picture, then maybe.

 bcm43xx_mac80211 is a less reasonable name.  With respect to the coders 
 who have put time into making this usable on by 4306 and almost usable 
 on my 4311 I can say that I appreciate the effort... but the name needs 
 work.
 
 If I was king of driver package naming, the driver that works with v3 
 and v4 firmware and supports crypto functions would be... 
 broadcom80211bg or bcm80211g
 The driver that only works with v3 (aka bcm43xx) broadcomv3
 The driver that only works with v4 (aka bcm43xx_mac80211) broadcomv4

You take just one aspect (firmware version) and put it into the name.
The original name was also taking just one aspect (802.11 stack).  I
fail to see why your approach it better.  I don't know any other Linux
(or _any_) driver that puts the firmware version into its name.

I believe you are implying that the firmware selection will be a
problem, so you prefer a name that would make it easy to solve that
problem.  But then you are not writing as a user, you are writing as
somebody who has been exposed to some internals.  Ask a random user if
the firmware version should be part of the driver name, and you'll get a
blank stare.

By the way, more information could be put into the module description,
which is shown by modinfo.

 As time advances and bcb43xx_mac80211/broadcomv4 is brought to spec so 
 it works great... its code would be integrated into 
 broadcom80211g/bcm80211g.

Now you put the name of the protocol into the driver, which is again
inconsistent with the existing naming and doesn't scale.  Suppose
802.11a support is fixed, would we need to rename the driver again?  And
that if the driver supports only 802.11b on some card?  Would not the
80211g part be misleading?

 That's my thinking.  As a USER.  As a linux advocate and zealot.

See above.  Users should not care about driver names.  If they do, we
have a bigger problem.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: bcm4301: A mac80211 driver using V3 firmware

2007-07-19 Thread Pavel Roskin
Hello, Larry!

First of all, many thanks for porting the v3 driver to mac80211!

On Thu, 2007-07-19 at 20:38 -0500, Larry Finger wrote:

 1. For more general testing, I'll distribute my driver as a patch to
 be applied to wireless-dev as 
 it needs ssb, which is not yet in mainline. If we are still in testing when 
 ssb is merged, I'll 
 change to making patches against mainline.

Sounds good.

 2. Once the problems have been cleared and ssb is in -mm, it gets sent there 
 as a port from softmac 
 to mac80211 for the current bcm43xx. An additional consideration is that a 
 port from softmac to 
 mac80211 will be more easily merged than if it looks like a new driver.

I would prefer if the name stayed the same, but it shouldn't be a big
deal.

 3. If the port of softmac to mac80211 is merged before Michael's driver, it 
 will be known as bcm43xx 
 with bcm43xx-mac80211 remaining in wireless-dev.

Yes, that's what I mean, keep it bcm43xx unless renaming it is the
condition for acceptance.

 4. Once bcm43xx-mac80211 gets merged to mainline, then Michael's driver 
 should become bcm43xx and my 
 driver gets its PCI IDs stripped to the 802.11b-only devices and once again 
 becomes bcm4301. This 
 name change for Michael's driver would cause some disruption for current 
 users as their firmware 
 would have the wrong name/version. That might be too much of a problem.

Actually, the common practice is that the new driver that doesn't
supplant the old driver immediately and for the whole range of hardware
gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.

Also, we could introduce a kernel option to enable support for new
devices in your driver.

 I think this is a path that always has a stable driver with at least moderate 
 performance in 
 mainline throughout the entire transformation.

That's a very good goal.

I would also consider the option to use different names for v3 and v4
firmware.  I have a file /etc/modprobe.d/bcm43xx that reads

options bcm43xx fwpostfix=.3
options bcm43xx_mac80211 fwpostfix=.4

but we cannot expect every distro (let alone every user) to take care of
the naming conflict.  Users don't expect the need to rename firmware,
and we shouldn't create a problem for them.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: dell e1505 bcm43xx driver, bcm4311 chipset?

2007-07-06 Thread Pavel Roskin
On Fri, 2007-07-06 at 13:00 -0500, Larry Finger wrote:
 John H. wrote:
  I was wondering if, on fedora 7 now with 2.6.21 kernel, it is possible
  to use bcm43xx driver with this device and get 54mb/s and wpa support?
  
  I have the firmware installed, etc.
  
  I just had many problems last time, as it wouldn't get 54mb/s, etc.
 
 With 2.6.21 or later kernels, the bcm43xx driver works quite well without any 
 patching. It still 
 doesn't do 54 Mbs, but my 4311 gets an Iperf throughput of over 15 Mbs. FYI, 
 Windows using exactly 
 the same configuration and hardware gets 19 Mbs, thus we are close.

Actually, bcm43xx seems to be patched in the stock Fedora kernel to only
support 4301.  At least it fails to pick 4318 on my desktop machine.
See alias below:

$ modinfo bcm43xx
filename:   
/lib/modules/2.6.21-1.3228.fc7/kernel/drivers/net/wireless/bcm43xx/bcm43xx.ko
license:GPL
author: Michael Buesch
author: Stefano Brivio
author: Martin Langer
description:Broadcom BCM43xx wireless driver
srcversion: F29014CCD786A001B1A577A
alias:  pci:v14E4d4301sv*sd*bc*sc*i*
depends:ieee80211,ieee80211softmac
...

The standalone version from ftp://lwfinger.dynalias.org/patches compiles
fine though and has a whole bunch of aliases.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Unauthorized Network card (ERROR 104)

2007-07-04 Thread Pavel Roskin
On Wed, 2007-07-04 at 16:49 -0700, Jhonie Walker wrote:

 Whathever I tried it didn't gave any results. no
 value, etc.
[skip]
 I hope someone can help me. Maybe I am using the tool
 in a wrong way.

Then maybe you should give the exact command line and the exact error
messages?

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.22-rc6, dhcp, promiscuous mode, and other things

2007-06-26 Thread Pavel Roskin
Hello!

On Tue, 2007-06-26 at 18:58 -0700, Ehud Gavron wrote: 
 I've been alternately switching between 2.6.22-rc3 (Linville git tree) 
 and 2.5.22-rc6 (Linville git tree as of today), henceforth rc3 and rc6 
 respectively.

There have been significant changes in bcm43xx_mac80211 in its own git
repository (http://bu3sch.de/git/wireless-dev.git), which improved
things a lot.  As far as I know, the changes are not in 2.6.22-rc6 yet,
or you would have seen a backtrace.

 I've been alternately switching between bcm43xx and bcm43xx_mac80211, 
 henceforth soft and hard respectively.

There is nothing specifically hard in mac80211.  You may need to use
another convention.

 About the only thing I've found strange that I hope someone else can 
 confirm, is that running a tcpdump simultaneously with the DHCP client 
 causes more success than failure.

I understand you mean tcpdump on the same machine as the driver.  I
think I may have seen it.  Perhaps the promiscuous mode would speed up
recalibration, or something like that.  Anyway, the current git version
of bcm43xx_mac80211 is working much better and should not need such
tricks.

 If I had to do a matrix it would look like this:
 rc6 hard - works but stuck at 1Mbps
 rc6 soft - works
 rc6 hard - unable to communicate, but associates fine
 rc6 soft - works

You may want to use another convention for kernel versions as well.
They look too similar to me.

   Encryption key:896A-0055-AE77-5E80-ED86-4E38-3A

I hope you understand you cannot reuse this key after having exposed it
in a public forum.  On the other hand, WEP is considered generally
unsafe these days, so it's more an polite request to leave your network
alone than actual security.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [bcm43xx-users] 4311 still not receiving

2007-06-22 Thread Pavel Roskin
On Fri, 2007-06-22 at 00:54 -0400, Chuckk Hubbard wrote:

 I worked through some things with Ehud, but it was inconclusive.  I
 just recompiled using the advice at
 http://forums.gentoo.org/viewtopic-t-547687.html as far as kernel
 options, and I did this with the 2.6.22-rc4 patched kernel, and uname
 -r indeed tells me 2.6.22-rc4_etc.
 eth1 will scan, picking up several APs, and the command iwconfig eth1
 essid frank key blahblahbl, after doing it twice, does cause a
 valid access point in the output of ifconfig eth1.  The network GUI
 dialog shows the available ap's, several of them, and shows eth1 as
 being active and the WEP key is in and everything.  Yet the command
 'dhclient eth1' still tells me the network is down, and I still cannot
 access the internet. 

I remember that I had to specify open when setting the WEP key to
force open system authentication.  Even though the algorithm was already
shown as open, setting it would probably fix something in softmac.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [bcm43xx-users] 4311 still not receiving

2007-06-22 Thread Pavel Roskin
On Fri, 2007-06-22 at 04:06 -0400, Chuckk Hubbard wrote:
 Thanks for the suggestion; I tried several times in a row, it didn't
 change anything.
 
 I went ahead and copied a bunch of commands, the dmesg output
 afterwards, and the results of ifconfig and iwconfig... Did I miss
 something (also plz tell me if I just published all someone needs to
 hack into my comp!): 
 
 
 #: ifconfig eth1 down
 #: ifconfig eth1 up
 #: iwconfig eth1 essid frank
 #: iwconfig eth1 key open
 #: iwconfig eth1 key 74b571f1c9

My situation is that I don't use iwconfig eth1 key open initially.
The interface goes up and works enough time for dhclinet to get an
address.  Then it's stops working, although iwconfig still shows the
association.  And then iwconfig eth1 key open restores the connection
permanently.

It's one of those little irritating bugs in softmac.  Other little bugs
are incorrect display of ESSID when the interface is down and duplicate
packets when pinging another station connected to the same AP.

Oh, another one is that the code becomes confused when it re-associates.
It sends packets to the new AP through the old AP.  Maybe you have an
open AP around?  Then I suggest that you set ESSID before bringing the
interface up to avoid reassociation.  And please don't be surprised if
ESSID looks a bit too short before the interface is up.

Anyway. maybe you have something different.

It's quite frustrating to have two drivers for the hardware, one of
which is pretty bad with the 802.11 implementation, and the other cannot
setup the hardware (although I need to give bcm43xx_mac80211 another
try).  Both should be fixable.  I just need to get some other stuff off
my plate first.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [bcm43xx-users] 4311 still not receiving

2007-06-22 Thread Pavel Roskin
On Fri, 2007-06-22 at 14:53 -0500, Larry Finger wrote:
 Pavel Roskin wrote:
  
  It's quite frustrating to have two drivers for the hardware, one of
  which is pretty bad with the 802.11 implementation, and the other cannot
  setup the hardware (although I need to give bcm43xx_mac80211 another
  try).  Both should be fixable.  I just need to get some other stuff off
  my plate first.
 
 It is also frustrating to have put as much effort into a project as we have 
 and then get the kind of 
 backbiting that you are exhibiting!!

Larry, it must be a misunderstanding.  I realize that softmac is not
your code.  You are doing a great job.  I only regret that I don't have
time to make patches for softmac, so that your driver can work better.

 The only two fixes that will have any future are (1) get bcm43xx-softmac 
 switched over to mac80211 
 (which I am working on) or (2) fix bcm43xx-mac80211. We are not spending any 
 time on SoftMAC. It is 
 gone as soon as either of the steps above are working well enough.

That's all great, and I don't want to discourage you from that.  I was
just trying to help somebody who is using the driver with softmac now.
Maybe it was just a coincidence that I started hitting various softmac
bugs as I saw that e-mail.

 Don't give me that SH*T about how much you have on your plate. In the past, I 
 have dropped 
 everything to help you get bcm43xx working. Obviously, that was a bad 
 decision on my part. I should 
 have just let you use ndiswrapper!!!

I only mean I regret that I cannot accompany my complains with patches
right now.  Although I think I should.

I do appreciate your help.  I absolutely didn't mean anything bad
towards you or the approach you are taking.

Perhaps I should keep my frustrations to myself.  Sorry if I offended
you.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: TX power stuff confusion

2007-06-11 Thread Pavel Roskin
Hello Brennan,

Brennan Ashton wrote:
 I have the same card (on fedora), it is working great now that i used the
 new kernel and firmware code. kernel 2.6.22-rc4, dont use the
 2.6.21.4kernel.

It's the version from git, which should be newer than 2.6.22-rc4 and 
should include the new TX power adjustment code.

 When you update, make shure you go in menuconfig and
 select to
 install as a module, it's placement has changed and will not load with your
 old config file (third time compiling tonight).

It is a module.  And it's bcm43xx_mac80211, it case I was unclear.

 Hope you get that card
 working.

It is working with bcm43xx.  It was also working with bcm43xx_mac80211 
is older kernels, but only with some APs and only with patches limiting 
the Tx rate.

 On 6/10/07, Pavel Roskin [EMAIL PROTECTED] wrote:

 On Sun, 2007-06-10 at 19:13 +0200, Michael Buesch wrote:
  I implemented the new stuff for the TX power adjustment and
  it seems to work fine. Good work on the specs! :)

Please don't top post.  If you put the original message to the bottom, 
it makes you miss important points.  I was testing the new TX power 
adjustment, and my point was that the new code was emitting some messages.

-- 
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: TX power stuff confusion

2007-06-10 Thread Pavel Roskin
On Sun, 2007-06-10 at 19:13 +0200, Michael Buesch wrote:
 I implemented the new stuff for the TX power adjustment and
 it seems to work fine. Good work on the specs! :)

I'm very glad about it!

I checked out the current code http://bu3sch.de/git/wireless-dev.git and
compiled it.  First time the kernel would not even boot (Fedora is too
smart to load all modules on startup), but I saw debugfs in the stck
track.  CONFIG_DEBUG_FS was disabled, so I enabled it.

This time I could boot, but I saw some stack traces and messages you may
want to see.  This is the part of the kernel log starting with wireless
initialization.

It's going to be a busy week for me, so I don't expect to participate in
debugging much, but I'm ready to send more information if needed.

This is Fedora 7 x86_64 on Dell D-520 laptop with PCIe BCM4311.

Thanks to everybody involved!  Even if it's not working for me now, I'm
sure it will work really soon.

-- 
Regards,
Pavel Roskin
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED]
ieee80211_crypt: registered algorithm 'NULL'
ieee80211_crypt: registered algorithm 'WEP'
ieee80211_crypt: registered algorithm 'CCMP'
ieee80211_crypt: registered algorithm 'TKIP'
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 244k freed
Write protecting the kernel read-only data: 4124k
ACPI: PCI Interrupt :0c:00.0[A] - GSI 17 (level, low) - IRQ 17
PCI: Setting latency timer of device :0c:00.0 to 64
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243)
ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243)
ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243)
ssb: Switching to ChipCommon core, index 0
ssb: Switching to PCI-E core, index 3
ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
bcm43xx_mac80211: Broadcom 4311 WLAN found
ssb: Switching to IEEE 802.11 core, index 1
bcm43xx_mac80211: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx_mac80211: Radio turned off
wmaster0: Selected rate control algorithm 'simple'
bcm43xx driver
EXT3 FS on sda3, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
NTFS volume version 3.1.
NTFS-fs warning (device sda2): load_system_files(): Unsupported volume flags 0x4000 encountered.
NTFS-fs warning (device sda2): load_system_files(): Volume has unsupported flags set.  Will not be able to remount read-write.  Run chkdsk and mount in Windows.
Adding 1020088k swap on /dev/sda5.  Priority:-1 extents:1 across:1020088k
bcm43xx_mac80211: Adding Interface type 2
ssb: Switching to PCI-E core, index 3
ssb: Switching to IEEE 802.11 core, index 1
bcm43xx_mac80211: Loading firmware version 371.1122 (2006-11-08 22:02:13)
ssb: Switching to ChipCommon core, index 0
ssb: Switching to IEEE 802.11 core, index 1
bcm43xx_mac80211: Radio turned on
bcm43xx_mac80211: Radio enabled by hardware
bcm43xx_mac80211: ERROR: invalid bband_att: 11

Call Trace:
 [8020a13c] restore_args+0x0/0x30
 [88050b2d] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x4d/0xd0
 [88050bef] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x3f/0x50
 [88050d01] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x11/0x30
 [88049f48] :bcm43xx_mac80211:bcm43xx_set_txpower_g+0x1c8/0x200
 [8804a50a] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x10a/0x730
 [88044aef] :bcm43xx_mac80211:bcm43xx_phy_write+0x6f/0x80
 [8804ddfe] :bcm43xx_mac80211:bcm43xx_phy_initg+0xbfe/0xe70
 [8804e5e1] :bcm43xx_mac80211:bcm43xx_phy_init+0x2a1/0x620
 [8803f2b8] :bcm43xx_mac80211:bcm43xx_chip_init+0x448/0xa70
 [8804e0e3] :bcm43xx_mac80211:bcm43xx_phy_early_init+0x73/0x2d0
 [8804114f] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x26f/0x900
 [8800c0a8] :mac80211:ieee80211_open+0x48/0x450
 [880430a8] :bcm43xx_mac80211:bcm43xx_add_interface+0x108/0x140
 [8800c23a] :mac80211:ieee80211_open+0x1da/0x450
 [804861a0] dev_open+0x40/0x90
 [8048406d] dev_change_flags+0x6d/0x160
 [804c53d7] devinet_ioctl+0x587/0x750
 [80485f39] dev_ioctl+0x2b9/0x390
 [804c5a1d] inet_ioctl+0x5d/0x80
 [80477dbf] sock_ioctl+0xbf/0x240
 [8029b9c8] do_ioctl+0x38/0xe0
 [8029bae3] vfs_ioctl+0x73/0x2c0
 [8029bd7a] sys_ioctl+0x4a/0x80
 [80209b9e] system_call+0x7e/0x83

bcm43xx_mac80211: Chip initialized
bcm43xx_mac80211: 32-bit DMA initialized
bcm43xx_mac80211: Wireless interface started
bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:0f:66:2f:ef

Re: Belkin Wireless PCMCIA F5D7010.

2007-05-29 Thread Pavel Roskin
On Tue, 2007-05-29 at 21:42 +0200, Vincent Blondel wrote:
 Hello all,
 
 I am trying to make my brand new Belkin Wireless PCMCIA F5D7010
 (Ver.7000df) working on a Debian/Etch distro with my laptop HP Omnibook
 6000 but this goes wrong.

There is a Windows driver on the Belkin site for this device, called
F5D7010v7000.exe.  In can be unpacked with unzip.  The actual driver,
called BLKWGNv7.sys has this string inside:

Realtek RTL8185 driver

 I already tried lots of modules like rt2500, ndiswrapper, bcm43xx but it
 seems my card is not recognized.

I think next stop should be http://rtl8180-sa2400.sourceforge.net/
There are also Linux hardware compatibility database(s).  There are also
mailing lists for all Linux wireless issues.  Please avoid asking for
help with identification in a mailing list for one specific driver
without a good reason to assume that it's the driver you need.

 Can somebody help troubleshoot this problem, say me if this problem is
 solved by a new version ???

Not me.  And not in this list.

-- 
Regards,
Pavel Roskin

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


  1   2   >