Michael Buesch wrote:
On Monday 22 March 2010 22:56:44 Larry Finger wrote:
Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule?
/dev/urandom
Yeah, there's the chance of clashes. In practice there won't be
David Montero wrote:
Hi Rafal,
I am sorry, what do you mean with *stop* using html for your mails?
I am using my gmail account from internet, could you recommend me
another way to use it?
Yes, stop using gmail. Use a real mailer (thunderbird, mutt, etc.) and
set it to use plain-text.
Larry Finger wrote:
On 11/20/2009 05:12 AM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters.
Michael Buesch wrote:
On Monday 25 August 2008 21:54:18 Michael Buesch wrote:
The patch is available here:
http://bu3sch.de/patches/wireless-testing/20080825-2146/patches/004-b43-NEW-rewrite-txpower-adjusting.patch
Here's an updated version with a major bug fixed:
Works fine here. iperf same results as prior to patch.
b43-phy0: Broadcom 4311 WLAN found
b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
2.6.27-rc2-wl on Ubuntu 8.04 (don't even ask how long it takes to build
a new
This isn't a strictly b43 thing, but since so many of the developers
regularly use iperf for testing I thought I'd get some of your expertise
on something which has been baffling me for two weeks, and which appears
to make no sense.
When testing a metropolitan-Ethernet link the following was
Dale Walsh wrote:
...
And in my opinion this comment makes you look like an idiot.
And now that you're resorting to calling list members idiots this is
your opportunity for a time-out. Go stand in the corner, post on this
list no more, and stop lowering the S/N ratio. The idiot is the one
Johannes Berg wrote:
On Fri, 2008-05-30 at 16:06 +0200, Michael Buesch wrote:
On Friday 30 May 2008 14:31:53 Johannes Berg wrote:
Since a while ago I've had trouble resuming when b43 was connected to an
AP while suspended.
I did a test today where this was the only difference,
Rafal Milecki wrote:
Really, HP-laptop dv6057ea doesn't mean much for every one. It would
be nice to post proper part of
lspci -nnv
Others have written:
Please include dmesg
Still others have said:
It doesn't help anyone when you say I have a problem without giving us
any information to allow
kala mazoo wrote:
Date: Wed, 7 May 2008 22:18:32 -0500
From: [EMAIL PROTECTED]
Apparently there's more than just these bits in the sprom controlling the
LED
behaviour? Does anyone know what that might be?
I'm not sure
Stefanik Gábor wrote:
...
Ehud Gavron: are you sure this discussion belongs to bcm43xx-dev?!
AFAIK the microcode doesn't really care about American vs. British
spellings.
Also, a good rule of thumb about which spelling to use: if you are
writing about US subjects, use US English
After the system has been up a while -- in this case 5 days -- the data
transfer rate appears slow and this is confirmed by various tools such
as ftp and speedtest.net.
Reassociating with the AP has no effect on this symptom.
modprobe -r b43 modprobe b43 corrects the symptom.
What other
back on and
works the way it's supposed to.
Ehud
Michael Buesch wrote:
On Tuesday 18 December 2007 06:42:56 Ehud Gavron wrote:
A little test code answered my own question. I don't know if this is
the best way to do it, but this patch fixes the problem.
Ehud
--- drivers/net/wireless
Michael Buesch wrote:
On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote:
Michael Buesch wrote:
On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote:
Ehud Gavron wrote:
If I manually turn the LED on (with the keyboard sequence for
KEY_WLAN
I've trimmed some of this.
Michael Buesch wrote:
I have no idea. But I don't understand why waiting a random time up to 1000ms
fails
and a random time up to 1000ms + 1ms succeeds.
The patch I submitted had a newbie-error. Right before making the patch
I removed the debug messages. As it
Michael Buesch wrote:
On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,EHUD: sleeping\n);
msleep(1);
Larry Finger wrote:
Ehud Gavron wrote:
I've trimmed some of this.
Michael Buesch wrote:
I have no idea. But I don't understand why waiting a random time up
to 1000ms fails
and a random time up to 1000ms + 1ms succeeds.
The patch I submitted had a newbie-error
Submitted.
E
Michael Buesch wrote:
On Tuesday 18 December 2007 22:09:24 Ehud Gavron wrote:
I did just check and you are right! It is a compiler bug despite the
version being supposedly safe.
two msleep(0); 's got inlined out of the way and the KEY_WLAN code ran
as it's supposed
Larry Finger wrote:
Ehud Gavron wrote:
...
If I use the kill-switch both the WiFi and the BT LEDs go off.
When I switch back on the BT LED lights but the WiFi does not.
As long as you are using the latest everything branch wireless-2.6, and
rfkill-input is built for
your system
We worked out the SPROM is the same... but here are some interesting twists.
When switched off
1. The LED is switched off by hardware, not b43
2. B43 does send the event as expected but the LED is already off
When switch on
1. The LED is not switched on by hardware
2. B43 does send the event as
the LED */
input_report_key(poll_dev-input, KEY_WLAN, 1);
input_report_key(poll_dev-input, KEY_WLAN, 0);
}
Ehud Gavron wrote:
We worked out the SPROM is the same... but here are some interesting twists.
When switched off
1. The LED is switched off
First, thanks for making the LED light up again, Larry and Michael.
If I use the kill-switch both the WiFi and the BT LEDs go off.
When I switch back on the BT LED lights but the WiFi does not.
Dmesg shows:
Dec 16 17:43:30 egdell kernel: input: b43-phy0 as /class/input/input11
Dec 16 17:43:31
Larry Finger wrote:
Ehud Gavron wrote:
First, thanks for making the LED light up again, Larry and Michael.
If I use the kill-switch both the WiFi and the BT LEDs go off.
When I switch back on the BT LED lights but the WiFi does not.
Dmesg shows:
Dec 16 17:43:30 egdell kernel: input
This does not correct the LED issue in my Dell Latitude 620.
Let me know how I can help debug this. I'm available all night and I
can build a new kernel in about 5 minutes...
Ehud
[EMAIL PROTECTED] leds]# ls
b43-phy0:radio b43-phy0:rx b43-phy0:tx
[EMAIL PROTECTED] leds]# cat */uevent
changed to ENABLED
Larry Finger wrote:
Ehud Gavron wrote:
This does not correct the LED issue in my Dell Latitude 620.
Let me know how I can help debug this. I'm available all night and I
can build a new kernel in about 5 minutes...
When you turn the radio off/on, do you see
1A000E921F40
36303D15A0FA79FEFF834AFF3EFF494A02FF
0CFF021F
Larry Finger wrote:
Ehud Gavron wrote:
Yes. See below. The USB device is the BT radio.
Ehud
usb 1-2.4: USB disconnect, address 4
b43-phy0: Radio hardware status
Just as a reminder in the hopes it triggers some thought, Fedora
2.6.23.1-42.fc8 worked... but 1-49.fc9 didn't, and none of everything or
wireless-2.6 worked.
If you think of anything I can test... let me know. It's early. :)
Ehud
Larry Finger wrote:
Ehud Gavron wrote:
[EMAIL PROTECTED
Michael Buesch wrote:
On Tuesday 27 November 2007 17:28:33 Larry Finger wrote:
Michael Buesch wrote:
On Tuesday 27 November 2007 17:03:57 Larry Finger wrote:
This is not how led triggers work.
You are shortcutting the whole thing here. So you could as well
remove the whole rfkill
LEDs work with Fedora Kernel 2.6.23.1-42.fc8.
LEDs NOT with Fedora Kernel 2.6.23.1-49.fc8
LEDs NOT with everything/2.6.24-rc2
LEDs NOT with wireless-2.6/2.6.24-rc3
I have the same settings in dot config as Larry does below and I have
the same info except for ...uevent has a power button but
Excellent suggestion. I'll test that upon my return home and get back here.
Thanks!
E
Holger Schurig wrote:
Do you have any logs of the APs, e.g. do they log that somebody
tried to associate and failed?
Did you try a workaround to put all 3 APs to the same frequency?
If you then observe
Based on your problem description...
there isn't one.
Based on your uname -a ...
there isn't one.
Based on your dmesg...
there isn't one.
This is like a locked room mystery, right, you want us to solve the
problem without the problem being
a. mentioned
b. described
c. error messages
$ su -
and don't forget to ifconfig the interface up (in addition to all the
iwconfigs, MUST ifconfig it up)
Ehud
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
As the son of a physicist and someone who appreciates GOOD DOCUMENTATION
OF A PROBLEM AND SOLUTION I have to echo Larry's kudos. This was a
well-documented analytical approach to solving the problem. Undoubtedly
since the world is not perfect and we must deal with $40 APs we'll all
see this
Here's the script that used to work:
#!/bin/sh
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
everything
cd everything
git checkout -b everything origin/everything
Here's what the first git buys me yesterday and today:
Initialized empty Git repository in
Thank you. I must have missed that note. The new tree works great.
RIP wireless-dev. Long Live Everything.
Ehud
Johannes Berg wrote:
wireless-dev is dead, see
http://marc.info/?l=linux-wirelessm=119152616425736w=2
johannes
There are two drivers that support the hardware. The new one (the one
you want) that works with mac80211 is b43. It uses v4 firmware.
The older one (the one you don't want) works with ieee80211softmac is
b43legacy. It uses v3 firmware.
I would download the latest wireless-dev kernel
Ehud Gavron wrote:
There are two drivers that support the hardware. The new one (the one
you want) that works with mac80211 is b43. It uses v4 firmware.
The older one (the one you don't want) works with ieee80211softmac is
b43legacy. It uses v3 firmware.
Disregard the rest of my answer
Perhaps a couple of changes to the driver messages would help eliminate
confusion and support repetition?
Larry Finger wrote:
bcm43xx: Radio turned off
Perhaps: bcm43xx: Radio turned off. Interface must be enabled
(ifconfig up)
...
bcm43xx: Microcode rev 0xf5, p1 ox5a (2003-12-22
I have had this problem after moving from AP1 to AP2 (same ESSID,
different channels, same WEP key).
Try this:
1) Kill the network manager :)
2) sudo iwevent
3)
sudo modprobe -r b43
sudo moprobe b43
If it doesn't bring the interface up automatically:
4) sudo ifup [interface-name-here, like
iwconfig shows the last AP associated, even if there is no association.
You can easily test this... associate, ping, then
iwconfig INTFCNAME essid this does not exist
iwconfig
You'll see the AP MAC address is still there.
What looks like is your power mode is set to suspend on lid close. If
FYI Suspend/Resume is iffy. Sometimes it works, sometimes it does not.
When it does not, sometimes it unloads fine, sometimes it says it's
waiting for a reference (or 3) to be cleared before unloading. Only a
reboot will cure that one... as the message repeats but the reference
count never
Synopsis:
With everything tree and b43, loses AP association but then
reassociates, usually on ARP request.
I realize there's a tcpdump in there and that doesn't really provide any
useful info... the key is the iwevent and generating traffic.
Duplicating:
1. Use a 4311
2. Load b43
ifconfig eth1 up
E
Andrew McGuinness wrote:
I'm not able to detect my AP with a Dell 1390 mini-pci using bcm43xx
I appreciate that the driver is under very heavy development at the
moment, and I'm willing to try the bcm43 if that will help.
Details follow:
The Acer Aspire 3680 contains the
I have a Linksys PCMCIA N card which IDs as a BCM43XG, but unfortunately
is model 0x4329 rev 01, which is not on the hardware list as a supported
device.
Is this something that requires RE effort... and am I tainted because
I've looked at the Linux driver (reverse tainted) or am I clear... but
I've git clone'd the wireless-dev tree, and the test tree, and there
ain't* not bcm43xx_mac80211 or b43 or b44 or anything similar in the
.config.
1) How can I get access to update the berlios.de wiki? I'd like to
contribute, and I think I can help other newbies because I can relate
(being
Off list... but your eventual reply may want to be there.
When John gets his tree so we [those of us who use this code] can test
it, let us [same group] know.
Best regards,
Ehud
Tucson
Larry Finger wrote:
Ehud Gavron wrote:
I've git clone'd the wireless-dev tree, and the test tree
Jory, thank you for helping convince Michael I was not hallucinating!
Larry, thank you for finding the difference in the kernel output!
Michael, thank you for finding the part of the code affected by the
underlying changes caused by the patch but not changed by the patch!
It works.
I've got
That change is already built on my kernel (now wireless-dev with two
patches). I'm assuming it's correct, but if you'd like to confirm it,
please let me know which packet(s) to craft in order to test it.
Thanks again,
Ehud
Larry Finger wrote:
Michael Buesch wrote:
On Friday 10 August
I had hoped this would be the cure so I don't have to undo the 85a83d26
commit patch by patch.
However, while this did not solve the problem it DID show a new error:
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) ==
BCM43xx_STAT_STARTED) at:
[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
# (use git add file... to include in what will be committed)
#
# arch/x86_64/vdso/vdso.lds
nothing added to commit but untracked files present (use git add to track)
[EMAIL PROTECTED] test]# git diff
[EMAIL
The corrected patch shows the same results. I have a 2.6.23-rc2 kernel
where bcm43xx_mac80211 receives garbage.
Ehud
Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files
.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej
I can do this all day long. It's much more fun than dissecting the
original commit and doing it step by step.
Ehud
Larry Finger wrote:
Ehud Gavron wrote:
The corrected patch shows
, and it is now building. Should have results in 35m.
Thanks
Ehud
Larry Finger wrote:
Ehud Gavron wrote:
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm -rf'd both and re git clone'd them)
[EMAIL
It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
Ehud
Michael Buesch wrote:
On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote:
Patch with debug on or off both fail.
I'm unable to apply Michael's patch to either a virgin test or virgin
wireless-dev tree (I rm
. All work fine
with bcm43xx ndiswrapper with bcmwl5.
See attached.
Ehud
Larry Finger wrote:
Ehud Gavron wrote:
good: rc1 git test tree with the commit in question reversed. Works fine.
bad: rc2 git wireless-dev tree with Michael's latest patch. Does not
work.
full dmesg, iwconfig
time nice make install
1079 history
1080 history ~root/build_history.txt
(and here you have it)
Larry Finger wrote:
Ehud Gavron wrote:
The bcm43xx_mac80211 code associates fine and has good signal strength.
However, the stuff coming out of it on eth1 is not Ethernet...
The same setup
I'm bored, and I don't leave for the Champ Car Grand Prix of San Jose
until Thursday. Developers - if there's something you need from my
system, ask away.
Ehud
bcm43xx_mac80211: Adding Interface type 2
ssb: Switching to PCI-E core, index 3
ssb: Switching to IEEE 802.11 core, index 1
Not a developer, just a tester, and not a very good one... but I am a
_USER_ so here's my take.
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
Interestingly neither bcm43xx nor bcm43xx_mac80211 automatically load.
However, when I modprobe bcm43xx_mac80211 the following happens. I
would love to know how to fix the module won't load automatically
issue. However, here ya go:
bcm43xx_mac80211: Adding Interface type 2
interface is called)
I hope this information has helped rather than hurt,
Kind regards,
Ehud Gavron
Tucson AZ USA
Toronto: Paul Tracy. Silverstone: Lewis Hamilton: Lime Rock:
McNish/Capello or Pirro/Werner Daytone: JPM IndyOvalDoodle: WTFC
Andreas Peer wrote:
I don't know if this matters
regards,
Ehud Gavron
Tucson AZ USA
Toronto: Paul Tracy. Silverstone: Lewis Hamilton: Lime Rock:
McNish/Capello or Pirro/Werner Daytone: JPM IndyOvalDoodle: WTFC
Andreas Peer wrote:
I don't know if this matters, but I have a Acer Ferrari 3400
notebook, and according to the device list
You know, people read this list TO HELP PEOPLE. That's right. I'm up
at 2307 my time hoping that I can provide some information that will
help you get your bcm43xx device functional, or that failing that I can
help you provide information so the folks that work between the
firmware, the
Right.
E
Florian Erfurth wrote:
Von: Ehud Gavron [EMAIL PROTECTED]
One of the things I did is put the v3 firmware in /lib/firmware only I
renamed the files from *.fw to *.fw3.fw
I then can do modprobe bcm43xx fwpostfix=.fw3 to load the bcm43xx
module with the old firmware.
If I
I use F7, and having had the same disappointing results upgraded my kernel.
IF YOU USE NVIDIA VIDEO DRIVERS DO THIS ONLY AFTER FOLLOWING THE
PROCEDURE BELOW MY SIGNATURE
Building the latest Larry Linville kernel on F7 systems:
# cd /usr/src
# git clone
One of the things I did is put the v3 firmware in /lib/firmware only I
renamed the files from *.fw to *.fw3.fw
I then can do modprobe bcm43xx fwpostfix=.fw3 to load the bcm43xx
module with the old firmware.
put all v3 firmware files in /lib/firmware/v3
# cd /lib/firmware/v3
# ls -C1 *.fw |
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.
I've been alternately switching between bcm43xx and bcm43xx_mac80211,
henceforth soft and hard respectively.
About the only thing I've
source and ready for changes if need be.
Pavel Roskin wrote:
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
Is it possible your update killed fwcutter? I would try this
1. download a known good fwcutter
2. download a known good firmware
3. modprobe -r bcm43xx
4. modprobe -r bcm43xx_mac80211
5. modproble bcm43xx
6. dmesg and make sure it loaded the firmware, saw the cores, activated,
etc.
7. resume
Ndiswrapper works fine, ignore the 4k stacks warning.
Your firmware seems fine. Here's my 4311 (Dell 1390): bcm43xx_mac80211:
Loading firmware version 371.1061 (2006-10-04 21:02:04)
The fact that you see APs in the scan means it works.
You didn't include the iwlist, so we can't tell if it's
In your private reply you show great progress (but you didn't CC the
list on that one so make reference to it only).
Since I didn't know where you were going (ndiswrapper or bcm43xx) I also
didn't mention that you are running the F7 2.6.21 kernel... and that
kernel needs patching from Larry's
Ok, so I was bored... and installed the 2.6.21 kernel.
I then patch -p1 combined_2.6.21.patch
make
make modules_install
make install
sync reboot -f
The bcm43xx modules reports associated... scanning... associated... with
another message in the middle, about once every half second without
Finger wrote:
Ehud Gavron wrote:
Ok, so I was bored... and installed the 2.6.21 kernel.
I then patch -p1 combined_2.6.21.patch
make
make modules_install
make install
sync reboot -f
The bcm43xx modules reports associated... scanning... associated... with
another message in the middle, about
Ehud Gavron wrote:
Just to be precise, I repeated everything. Here it is in gory detail,
except that I don't know how to capture the panic attack info because
the system is stuck and I think a camera screenshot would be lame ;)
tar -zxvf linux-2.6.21.tar.gz
mv linux-2.6.21 /usr/src
ln -s
You can't used bridged networking on wireless.
Use NAT.
Ehud
Gary Radford wrote:
New install on Athlonx64 Emachines M6809 with Mandriva x86-32 2007.0
with all current updates. I had my wireless bcm43 working for a couple
of hours and a few reboots (x86-64 2007, the wireless is not working).
way this is NOT a BCM43xx issue.
Ehud
Igor Korot wrote:
Hi,
-Original Message-
From: Ehud Gavron [EMAIL PROTECTED]
...
Subject: Re: Vmware install on Mandriva 2007.0 kills bcm43 wireless
You can't used bridged networking on wireless.
Use NAT.
On Windows, I run VMware
diagnostics/tests I can run... I just got back
from five days in Vegas, so I need a drink and some debugging to unwind ;)
Ehud
Larry Finger wrote:
Ehud Gavron wrote:
Feedback: the make files work.
However... this version of the driver is unusable. It's worse than the
one I downloaded
Removed module.symvers. Make; make install. rmmod bcm43xx hung (yes I
forgot to ifconfig down ;) reboot... module now works perfectly.
I am unable to see the behavior I saw before: namely ifconfig rxcount
goes to 0, txcount goes low, radio off, radio on, rxcount+, txcount+++,
dhcp works,
, Ehud Gavron wrote:
Removed module.symvers. Make; make install. rmmod bcm43xx hung (yes I
forgot to ifconfig down ;) reboot... module now works perfectly.
This means that you already have CONFIG_BCM43XX_DEBUG defined
in .config, right? I guess you had to recompile the kernel anyway
I am also unable to get bcm43xx to connect to my WRT54G (which I pulled
out of the network kit to do this test). It connects just fine to the
Buffalo WBR54Gs. (The case does not have any ID other than WRT54G... no
version number or anything.)
Ehud
Larry Finger wrote:
Do you think that
Since those changes are in the fedora-netdev repo, I downloaded that
kernel* and performance jumped to over 7Mbps to outside testing places.
Wow! Nice job guys!
Thanks for the advice, Larry, and thanks for the hard work from the
development and spec teams!
Ehud
*ok, it wasn't quite that
80 matches
Mail list logo
