From: Larry Finger <Larry.Finger@lwfinger.net>
To: Calvin Walton <calvin.walton@gmail.com>
Cc: Michael Buesch <mb@bu3sch.de>,
bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org
Subject: Re: [PATCH V2] ssb: Implement virtual SPROM on disk
Date: Wed, 24 Mar 2010 09:16:03 -0500 [thread overview]
Message-ID: <4BAA1EA3.9060803@lwfinger.net> (raw)
In-Reply-To: <1269377903.21181.8.camel@nayuki>
On 03/23/2010 03:58 PM, Calvin Walton wrote:
>
> 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 for the really good start.
The above routines have a minor problem in that using a random value for the
first byte of the MAC address runs the risk of having the multicast bit set. By
fixing the first one to a multiple of 4, that problem is avoided.
A second minor problem is that the full path must be given for all standard
utilities, otherwise they are assumed to be in /lib/udev. Thus all references to
"ifconfig" were replaced by "/sbin/ifconfig". I hope all distros put ifconfig in
/sbin.
I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
FF:FF:FF:FF:FF:FF. This way the interface can come up even though the new udev
routines are not available. When b43 detects that address, it will log a message
describing why the udev routines are needed, and how to obtain them.
The one remaining problem is that the interface has already been renamed before
60-persistent-b43-mac.rules is processed. In my case, the interface is wlan13,
not wlan0. After I manually modified 60-..., then the new address is applied.
I'm still working on this problem.
Thanks again for the help.
Larry
next prev parent reply other threads:[~2010-03-24 14:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-21 23:22 [PATCH V2] ssb: Implement virtual SPROM on disk Larry Finger
2010-03-22 6:28 ` Calvin Walton
2010-03-22 8:37 ` Michael Buesch
2010-03-22 15:06 ` Larry Finger
2010-03-22 21:55 ` Michael Buesch
2010-03-22 22:19 ` Larry Finger
2010-03-22 22:28 ` Michael Buesch
2010-03-22 21:56 ` Larry Finger
2010-03-22 22:25 ` Michael Buesch
2010-03-22 23:45 ` Larry Finger
2010-03-23 8:52 ` Michael Buesch
2010-03-23 14:25 ` Larry Finger
2010-03-23 20:58 ` Calvin Walton
2010-03-23 22:02 ` Michael Buesch
2010-03-24 14:16 ` Larry Finger [this message]
2010-03-24 19:21 ` Michael Buesch
2010-03-26 3:47 ` Larry Finger
2010-03-28 17:14 ` Nicolas de Pesloüan
2010-03-28 18:25 ` Larry Finger
2010-03-28 19:04 ` Nicolas de Pesloüan
2010-03-29 0:33 ` Larry Finger
2010-03-24 1:25 ` Ehud Gavron
2010-03-23 8:55 ` Florian Fainelli
2010-03-23 11:43 ` Michael Buesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BAA1EA3.9060803@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=calvin.walton@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mb@bu3sch.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).