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
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
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
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
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
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
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
= 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
= 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
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
.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
.
*/
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
, 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
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
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
to the particular driver.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
in that direction.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
. 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
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
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
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
, 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
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
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
-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
,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
to start a flamewar :-)
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
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
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
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
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
,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
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
,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
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
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
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
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
.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
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
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
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
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
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
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
(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
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
, 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
--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
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
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
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
. 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
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
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
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
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
'(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
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
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
, 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
, 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
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
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
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
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
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
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
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
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
for development.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
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
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
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
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
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
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
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
,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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
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
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
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
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
, 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
.
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
, the console is designed to
be more survivable than the storage devices in case of a panic, so using
the console is preferred.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo
support to the hardware not
supported otherwise.
We'll find out very soon, when Linux 2.6.22-rc1 is released.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
association code in mac80211 was another pleasant surprise.
Perhaps I'll use bcm43xx_mac80211 by default - it seems quite stable
now.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman
the iwlist
output a bit longer, but kernel drivers shouldn't be written to make userspace
program generate pretty output.
--
Regards,
Pavel Roskin
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
1 - 100 of 152 matches
Mail list logo
