Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On Tuesday 23 March 2010 00:45:28 Larry Finger wrote: (2) In drivers/ssb/pci.c, the firmware loading process reads the file, then modifies it using the bus address. No. You don't need firmware loading at all. udev can just set the mac address through the standard ioctl calls. Just like how ifconfig and ip can do. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On Tuesday 23 March 2010 09:55:39 Florian Fainelli wrote: Why not use random_ether_addr and only use the digits that you are interested in? Because it's not constant across reboots. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On 03/23/2010 03:52 AM, Michael Buesch wrote: On Tuesday 23 March 2010 00:45:28 Larry Finger wrote: (2) In drivers/ssb/pci.c, the firmware loading process reads the file, then modifies it using the bus address. No. You don't need firmware loading at all. udev can just set the mac address through the standard ioctl calls. Just like how ifconfig and ip can do. Will someone please write me udev rule(s) that do the following: 1. Detect a MAC address of FF:FF:FF:FF:FF:FF 2. If this is the first time for this bus address, then generate a random MAC address with the bus address encoded in it. 3. Preserve the address for future reloads 4. Load the saved address into the device. 5. Do the above with only standard external commands - no new programs My skills with udev are not up to the task. I now have code running that uses the firmware load facility to read a file created by /bin/dbus-uuidgen to create a MAC address that will satisfy the requirements. If the file is needed but not available, then the user is prompted with the commands needed to create it. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V3] ssb: Implement virtual SPROM
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution is to use a file in /lib/firmware/ssb, which has some random
information generated by /bin/dbus-uuidgen. This file is loaded using the
asynchronous firmware facility and a MAC address is generated from those
data. To prevent multiple devices in a single box from having the same
MAC address, the last two digits are replaced by the bus numbers of the
device.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
Unless someone comes up with a unique way to generate a MAC address using
only udev rules, I think this is ready.
I suspect it is a little to invasive for 2.6.34. In addition, it fixes
a bug, but not a regression.
Larry
---
V2 - make virtual SPROM loading asynchronous.
V3 - eliminate the need for a special external utility
- set for unique MAC address even if a box has more than one of these
devices
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
#include linux/ssb/ssb_regs.h
#include linux/pci.h
#include linux/delay.h
+#include linux/firmware.h
#include ssb_private.h
@@ -613,6 +614,120 @@ static int sprom_extract(struct ssb_bus
return 0;
}
+static void ssb_vsprom_load_failed(void)
+{
+ printk(KERN_ERR ssb: The BCM43XX device does not have an
+ SPROM built in. Use the command\n);
+ printk(KERN_ERR 'mkdir -p /lib/firmware/ssb ; /bin/dbus-uuidgen
+ /lib/firmware/ssb/mac_addr'\n);
+ printk(KERN_ERR to generate the required file.\n);
+}
+
+static inline u8 ascii_to_bin(u8 input)
+{
+ /* return the binary value of the ASCII char in the low nibble */
+ return (input = 0x39) ? input 0xF : (input - 0x27) 0xF;
+}
+
+static void ssb_get_vsprom(const struct firmware *fw, void *context)
+{
+ /* Second part of asynchronous firmware load */
+ int i;
+ struct ssb_bus *bus = context;
+ struct ssb_sprom *sprom = bus-sprom;
+ u8 buf2[8];
+ char *name;
+
+ if (!fw) {
+ ssb_vsprom_load_failed();
+ return;
+ }
+ /* Get values extracted from SPROM. If sprom_extract_r8() is changed,
+* this section must be changed as well. For any device with 5GHz
+* capability, some variables will have to be changed.
+*/
+ sprom-revision = 8;
+ sprom-boardflags_lo = 0x0A01;
+ sprom-boardflags_hi = 0x0006;
+ sprom-boardflags2_lo = 0x;
+ sprom-boardflags2_hi = 0x;
+ sprom-ant_available_a = 0x00;
+ sprom-ant_available_bg = 0x03;
+ sprom-maxpwr_bg = 0x4A;
+ sprom-itssi_bg = 0x3E;
+ sprom-maxpwr_a = 0xFF;
+ sprom-itssi_a = 0xFF;
+ sprom-maxpwr_ah = 0xFF;
+ sprom-maxpwr_al = 0xFF;
+ sprom-gpio0 = 0x83;
+ sprom-gpio1 = 0xFF;
+ sprom-gpio2 = 0xFF;
+ sprom-gpio3 = 0xFF;
+ sprom-tri2g = 0x6C;
+ sprom-tri5g = 0x00;
+ sprom-tri5gl = 0xFF;
+ sprom-tri5gh = 0xFF;
+ sprom-rxpo2g = 0xFA;
+ sprom-rxpo5g = 0xFF;
+ sprom-rssismf2g = 0x0F;
+ sprom-rssismc2g = 0x00;
+ sprom-rssisav2g = 0x00;
+ sprom-bxa2g = 0x00;
+ sprom-rssismf5g = 0x0F;
+ sprom-rssismc5g = 0x0F;
+ sprom-rssisav5g = 0x07;
+ sprom-bxa5g = 0x03;
+ sprom-pa0b0 = 0x1a57;
+ sprom-pa0b1 = 0xF98A;
+ sprom-pa0b2 = 0xFE91;
+ sprom-pa1b0 = 0x;
+ sprom-pa1b1 = 0x;
+ sprom-pa1b2 = 0x;
+ sprom-pa1lob0 = 0x;
+ sprom-pa1lob1 = 0x;
+ sprom-pa1lob2 = 0x;
+ sprom-pa1hib0 = 0x;
+ sprom-pa1hib1 = 0x;
+ sprom-pa1hib2 = 0x;
+ sprom-cck2gpo = 0x;
+ sprom-ofdm2gpo = 0x0002;
+ sprom-ofdm5glpo = 0x;
+ sprom-ofdm5gpo = 0x;
+ sprom-ofdm5ghpo = 0x;
+ memset(sprom-et0mac, 0xFF, 6);
+ memset(sprom-et1mac, 0xFF, 6);
+
+ if (fw-size != 33) {
+ printk(KERN_ERR ssb: The MAC address file has the wrong
+ size\n);
+ goto out;
+ }
+ /* Input MAC address data in ASCII - get low nibble in binary */
+ for (i = 0 ; i 8; i++) {
+ u8 tmp = ascii_to_bin(fw-data[2 * i]);
+ u8 tmp1 = ascii_to_bin(fw-data[2 * i + 1]);
+ buf2[i] = tmp 4 | tmp1;
+ }
+ /* make sure 2 least significant bits of first byte are clear
+* These bits are multicast address and LAA bit, and
+* copy the randomized MAC address to the sprom variables
+*/
+ buf2[0] = ~(3);
+ memcpy(sprom-il0mac, buf2, 4);
+
+ /* As there may be
Re: Works wonderfully except at Barnes and Nobles.
On 03/22/2010 09:57 PM, Frank Middleton wrote: Had some really great experiences with your software recently, especially using a public Wifi system with really weak/out of range signals. I could still get emails even when Windows couldn't find any unencrypted APs, and it worked like a champ even at one site where there were 14 APs. FWIW it kept working flawlessly through dozens of suspend/resumes, something the eth0 driver couldn't do. Thanks for a robust and useful product! Good to hear. I did notice that the system log had a very large number of entries like the following that coincided with the out of range usage. This isn't a question, just an observation that might perhaps be useful. It didn't seem to be a problem (this on a very recent Fedora C10). Mar 2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error Mar 2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error Mar 2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error We don't know why the firmware is generating these errors. In general, they are harmless. However, I do have a question - maybe this isn't the right list to ask, but not sure which one would be. We tried a Barnes and Noble store which had free WiFi access, but I couldn't get it to associate with the AP at all. This is one of those setups where it forces your initial browser access to an agreement page. I suppose this might have worked with Windows and subsequently the B43 device might have been able to associate. Can anyone explain why this didn't work, or a way to make it work? You don't say what distro you are using, nor what kernel. It has been a while since I connected to an AP using that method, but it worked with openSUSE 11.2 and what was probably a 2.6.32 kernel. With the KDE flavor of NetworkManager's applet, I created a connection to the AP, then used the applet to connect to it. Once associated and an IP was obtained with DHCP, I launched the browser, and up came the sign-in page. This was at a Starbucks where the service was not free, so I did go any further. Internet access was not that important at the time. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
Hi, I had a perfectly working Dell system running Windows Vista and using version 5.60.188.1 of the Broadcom windows driver (distributed by Dell) for what Windows calls the Dell Wireless 1397 WLAN Mini-Card, which is actually 14e4:4315. I booted Parted Magic 4.9 from a USB flash drive, which uses the 2.6.32 linux kernel. I started up networking in Parted Magic and asked it to configure the wireless driver. At first it found my normal SSID and I asked it to try to connect, but it failed. I thought this was just a transient issue specific to Parted Magic and/or linux. So I booted bank into Vista, only to see that although Vista reports everything as being fine with the card, no wireless networks are ever detected. I have verified that the wireless networks that I expect indeed exist and are in range (the machine has not moved). Is it possible that the b43 driver somehow corrupted the firmware/ROM of my card such that it does not function correctly? Can I fix this? There is a DMA error (also shown below in context): b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x Please help I booted back into Parted Magic and got this info from uname, dmesg, and lspci: uname: Linux PartedMagic 2.6.32.9-pmagic #3 SMP Fri Mar 12 15:53:22 CST 2010 i686 GNU/Linux lspci: 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4 :4315] (rev 01) Subsystem: Dell Wireless 1397 WLAN Mini-Card [1028:000c] Flags: bus master, fast devsel, latency 0, IRQ 7 Memory at f1ffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information: Len=78 ? Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number 83-42-5f-ff-ff-53-00-22 Capabilities: [16c] Power Budgeting ? Kernel driver in use: b43-pci-bridge Kernel modules: ssb dmesg: b43-pci-bridge :0c:00.0: PCI INT A - Link[LNKB] - GSI 7 (level, low) - IRQ 7 b43-pci-bridge :0c:00.0: setting latency timer to 64 b43-phy0: Broadcom 4312 WLAN found (core revision 15) Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio b43 ssb0:0: firmware: requesting b43/ucode15.fw b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) b43-phy0: Controller restarted (followed by repeated errors with the same messages) Thanks ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On 03/23/2010 02:30 PM, Chris Lopes wrote: Hi, I had a perfectly working Dell system running Windows Vista and using version 5.60.188.1 of the Broadcom windows driver (distributed by Dell) for what Windows calls the Dell Wireless 1397 WLAN Mini-Card, which is actually 14e4:4315. I booted Parted Magic 4.9 from a USB flash drive, which uses the 2.6.32 linux kernel. I started up networking in Parted Magic and asked it to configure the wireless driver. At first it found my normal SSID and I asked it to try to connect, but it failed. I thought this was just a transient issue specific to Parted Magic and/or linux. So I booted bank into Vista, only to see that although Vista reports everything as being fine with the card, no wireless networks are ever detected. I have verified that the wireless networks that I expect indeed exist and are in range (the machine has not moved). Is it possible that the b43 driver somehow corrupted the firmware/ROM of my card such that it does not function correctly? Can I fix this? There is a DMA error (also shown below in context): b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x No, b43 did not corrupt your firmware. The firmware is not contained in non-volatile memory. With a power-down, it goes away. There is an EEPROM containing some initial values, but changing that requires specific actions through the sysfs, and does not happen accidentally. The wl and Windows drivers have the firmware embedded in the driver. For copyright reasons, we cannot do that, which is why there is external firmware. Your DMA error is a known problem with 14e4:4315 devices with Netbooks and some other systems with Intel processors and a Phoenix BIOS. Again, we have no fix. With a 2.6.33 kernel, the system will seamlessly switch to PIO mode when the fatal DMA error occurs. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On 03/23/2010 02:53 PM, Chris Lopes wrote: Thanks for the quick reply. So are you saying that it is impossible that the b43 driver could have somehow made my wireless card unable to detect any networks after a reboot (in either Windows or Linux)? I don't know of any way that b43 could have done that. A power-down including removal of the battery should completely put the device in the original condition. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? This laptop is a Dell Latitude E6400 On Wed, Mar 24, 2010 at 3:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/23/2010 02:53 PM, Chris Lopes wrote: Thanks for the quick reply. So are you saying that it is impossible that the b43 driver could have somehow made my wireless card unable to detect any networks after a reboot (in either Windows or Linux)? I don't know of any way that b43 could have done that. A power-down including removal of the battery should completely put the device in the original condition. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On 03/23/2010 03:31 PM, Chris Lopes wrote: Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? You should never hibernate one OS and run a different one. That is a prescription for disaster. Although there is nothing in the BCM4312 that can be changed, Vista could set a given state in the BIOS that is destroyed by booting Linux. Fortunately, this info seems to be in volatile memory, thus the power off and battery removal fixes it. You might look at the BIOS settings to see if there is a Wake On LAN option for the wireless. It should be off. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
What does (or might) Wake On LAN have to do with this problem, exactly? 2010/3/24 Larry Finger larry.fin...@lwfinger.net: On 03/23/2010 03:31 PM, Chris Lopes wrote: Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? You should never hibernate one OS and run a different one. That is a prescription for disaster. Although there is nothing in the BCM4312 that can be changed, Vista could set a given state in the BIOS that is destroyed by booting Linux. Fortunately, this info seems to be in volatile memory, thus the power off and battery removal fixes it. You might look at the BIOS settings to see if there is a Wake On LAN option for the wireless. It should be off. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
The wireless access point (AP), also sometimes called a router, is not relevant to my problem. It was not the cause and it did not need to be rebooted. My problem was not one of connectivity, per se. My wireless card was unable to see any SSID's (networks), including ones that are always present but to which I have never connected. Upon taking the steps I described, this situation was remedied. 2010/3/24 ikorot iko...@earthlink.net: Hi, Chris, -Original Message- From: Chris Lopes clo...@gmail.com Sent: Mar 23, 2010 4:31 PM To: Larry Finger larry.fin...@lwfinger.net Cc: bcm43xx-dev@lists.berlios.de Subject: Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? Unfortunately, that's how it works. I had the same problem myself. WHen you either hibernate or shutdown Windows you need to reset the power on you AP in order to successfully connect in Linux. The same goes to Linux - Windows scheme. My guess is that this is how the AP/DHCP/router or whatever protocol is used in the router works. It connects the MAC address of the hardware to the leased IP address, and until you reboot the router this connection stays. Unfortunately this is far beyond the control of any wireless driver in WiFi network card... ;-) Thank you. P.S.: Please someone correct me if I'm wrong. This laptop is a Dell Latitude E6400 On Wed, Mar 24, 2010 at 3:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/23/2010 02:53 PM, Chris Lopes wrote: Thanks for the quick reply. So are you saying that it is impossible that the b43 driver could have somehow made my wireless card unable to detect any networks after a reboot (in either Windows or Linux)? I don't know of any way that b43 could have done that. A power-down including removal of the battery should completely put the device in the original condition. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On Tuesday 23 March 2010 21:58:22 Calvin Walton wrote:
On Tue, 2010-03-23 at 09:25 -0500, Larry Finger wrote:
Will someone please write me udev rule(s) that do the following:
1. Detect a MAC address of FF:FF:FF:FF:FF:FF
2. If this is the first time for this bus address, then generate a random
MAC
address with the bus address encoded in it.
3. Preserve the address for future reloads
4. Load the saved address into the device.
5. Do the above with only standard external commands - no new programs
My skills with udev are not up to the task.
I will warn you that the following is rather untested, as I don't have
any of the affected hardware (or any b43 devices at all, actually), but
something along these lines should work. There's no syntax errors, at
least :)
--- /lib/udev/rules.d/65-persistent-b43-mac-generator.rules
ACTION!=add GOTO=persistent_b43_mac_generator_end
SUBSYSTEM==net, DRIVERS==b43, ATTR{address}==ff:ff:ff:ff:ff:ff,
IMPORT{program}=write_persistent_b43_mac
SUBSYSTEM==net, ENV{MACADDRESS_NEW}==?*, RUN+=ifconfig $env{INTERFACE}
hw ether $env{MACADDRESS_NEW}
LABEL=persistent_b43_mac_generator_end
--- /lib/udev/write_persistent_b43_mac (chmod +x)
#!/bin/bash
# This mac address generation function could be replaced with something better
MACADDRESS=$(dd if=/dev/urandom bs=1 count=6 2/dev/null | od -tx1 | head -1
| cut -d' ' -f2- | awk '{ print $1:$2:$3:$4:$5:$6 }')
RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'
. /lib64/udev/rule_generator.functions
lock_rules_file
choose_rules_file
echo DEVPATH==\$DEVPATH\, DRIVERS==\b43\,
ATTR{address}==\ff:ff:ff:ff:ff:ff\, RUN+=\ifconfig $INTERFACE hw ether
$MACADDRESS\ $RULES_FILE
echo MACADDRESS_NEW=$MACADDRESS
unlock_rules_file
---
A new file /etc/udev/rules.d/60-persistent-b43-mac.rules will be
created, which will contain the the saved mac address and bypass the
generating script on future boots.
This should probably be run by the udev maintainers, but is a start,
anyways.
Thanks a lot for this proof of concept. This looks very nice.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On Wed, 24 Mar 2010 03:31:42 +0700 Chris Lopes clo...@gmail.com wrote: Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? I have never had to do anything with my netbook to recover the wireless with the 2.6.32 kernel other than to shutdown the netbook down and then switch the netbook on again. It has never been necessary to disconnect the battery. A warm reboot however has never been sufficient to recover the wireless. I am not saying that your laptop might not be different, but if you do a proper shutdown which actually switches the laptop off followed by a switch on (cold boot), rather than a restart (warm boot), then if it follows my experience then it should be OK. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
I didn't try a cold reboot that did not involve the removal of battery and power supply, so maybe it would work. Honestly I am still perplexed (given modern hardware and software), as to why/how: 1) Hibernate and un-hibernate, regardless of what happens in between with the wireless card, could somehow result in it stopping working 2) Rebooting (warm), regardless of how the wireless card is messed up in my situation does not fix the problem 3) Cold rebooting and warm rebooting are different in any way whatsoever (all of the above involve zero changes on the hard disk during the time when the OS is not running) Is this behavior some sort of feature with unintuitive results, or is it a bug? And what is the buggy component, exactly? It seems like something that would happen with early 1990's technology. Also, are you saying that there is some sort of known problem that results in you having to recover the wireless via a cold-reboot? What is this problem and is it similar to my situation? On Wed, Mar 24, 2010 at 5:03 AM, Chris Vine ch...@cvine.freeserve.co.uk wrote: On Wed, 24 Mar 2010 03:31:42 +0700 Chris Lopes clo...@gmail.com wrote: Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? I have never had to do anything with my netbook to recover the wireless with the 2.6.32 kernel other than to shutdown the netbook down and then switch the netbook on again. It has never been necessary to disconnect the battery. A warm reboot however has never been sufficient to recover the wireless. I am not saying that your laptop might not be different, but if you do a proper shutdown which actually switches the laptop off followed by a switch on (cold boot), rather than a restart (warm boot), then if it follows my experience then it should be OK. Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On Tue, Mar 23, 2010 at 11:23 PM, Chris Lopes clo...@gmail.com wrote: I didn't try a cold reboot that did not involve the removal of battery and power supply, so maybe it would work. Honestly I am still perplexed (given modern hardware and software), as to why/how: 1) Hibernate and un-hibernate, regardless of what happens in between with the wireless card, could somehow result in it stopping working 2) Rebooting (warm), regardless of how the wireless card is messed up in my situation does not fix the problem 3) Cold rebooting and warm rebooting are different in any way whatsoever (all of the above involve zero changes on the hard disk during the time when the OS is not running) Is this behavior some sort of feature with unintuitive results, or is it a bug? And what is the buggy component, exactly? It seems like something that would happen with early 1990's technology. Also, are you saying that there is some sort of known problem that results in you having to recover the wireless via a cold-reboot? What is this problem and is it similar to my situation? Well, the following sequence can easily happen: 1. You boot Vista. The Broadcom official driver initializes the card (writing a complete register setup) with the embedded firmware. 2. You hibernate Vista. The card is un-initialized and prepared for restore upon return from hibernation. Some registers are left in the state they were originally, to aid in quicker restore. 3. You boot Linux. b43 finds the Broadcom card, and, seeing that it is un-initialized, quickly initializes it (again, overwriting all registers, including the ones left intact by hibernation) with your installed firmware. Due to a known bug, the driver misses some part of the initialization routine; we are working on fixing this,. 4. With the card only partially initialized, DMA TX is broken. (On 2.6.33, b43 works around this by falling back to PIO.) 5. You leave Linux. b43 either doesn't uninitialize the card at all, or does a full uninit, in preparation for a shutdown (as opposed to hibernate) 6. You restore Vista. The Broadcom driver expects the card to be in the state it left it during hibernation; but it is really either in the (broken) init state produced by Linux, or completely uninitialized. The driver does a resume routine, assuming the card is prepared for it. The result of this operation is completely undefined; as my college programming professor once said: even if it becomes self-aware and nukes the world, it is still operating correctly. 7. You scan for wireless networks. The card is in an undefined state, so this obviously doesn't work! -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On Tue, 23 Mar 2010 23:37:45 +0100 Gábor Stefanik netrolller...@gmail.com wrote: (On 2.6.33, b43 works around this by falling back to PIO.) I think it requires 2.6.34 for this (currently 2.6.34-rc2). Chris ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Failure with monitor mode
On Mon, 22 Mar 2010 20:54:14 -0400 Celejar cele...@gmail.com wrote: Hi, I have been using my 4318 successfully with b43 (thanks, Michael and all devs / reverse engineers!) for many kernel revisions now, both as a client, as well as in monitor mode (kismet, airodump). With 2.6.34-rc1, I can't get monitor mode to work successfully - I get errors like this: setsockopt(PACKET_MR_PROMISC) failed: Invalid argument [Replying to my own mail.] I rebuilt my kernel (using -rc2 sources), and while configuring, I noticed that LIB80211 wasn't being built. I enabled it, and monitor mode now works. Question: is this 'library of common routines used by IEEEU802.11 wireless LAN drivers' indeed necessary for monitor mode to function properly? If so, shouldn't b43 select it by default, as per the documentation that 'Drivers should select this themselves if needed'? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
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 any clashes, however. If you think there's a real risk, you should start playing the lottery tomorrow. You'll immediately win a million dollars so you don't have to worry about those questions anymore. ;) In fact, I think the risk for mac clashes is not really reduced by generating the mac address from serial numbers, whatever, etc... DEC used the L3 address to encode a new MAC at the time the [L3] address was set (DECnet v4). The advantage was they didn't need to use the equivalent of ARP. Of course this is a violation of strict layer separation. Octet1-Octet3 - Broadcom assigned MAC IDs. I found the following: 00-05-B5 00-10-18 00-1B-E9 18-C0-86 Octet4-octet6 - Lowest three octets of the unixtime. Advantages: for the local area network all TZ settings should be the same, so the MAC addresses *will* be different. Beyond the first router that won't matter. Also for the same machine different interfaces are GUARANTEED to have different MAC addresses. For two machines to have the same MAC they would have to be booted at (same time x processing factor) such that the B43 initialization will result in the same MAC address. I'd like to think those odds are even lower than your lottery. A million dollars? http://www.active-domain.com/resources/million-dollar-domains.htm Yeah got the t-shirt. E smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
