From: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Michael Buesch <mb@bu3sch.de>,
Calvin Walton <calvin.walton@gmail.com>,
linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
Subject: Re: [PATCH V2] ssb: Implement virtual SPROM on disk
Date: Sun, 28 Mar 2010 21:04:27 +0200 [thread overview]
Message-ID: <4BAFA83B.8050505@free.fr> (raw)
In-Reply-To: <4BAF9F11.6050802@lwfinger.net>
Larry Finger wrote:
> On 03/28/2010 12:14 PM, Nicolas de Pesloüan wrote:
>> Larry Finger wrote:
>>> On 03/24/2010 02:21 PM, Michael Buesch wrote:
>>>> On Wednesday 24 March 2010 15:16:03 Larry Finger wrote:
>>>>> I have modified ssb to supply a MAC address of 80:80:80:80:80:80,
>>>>> rather than
>>>> What about also setting the local-assignment bit for this temporary
>>>> address?
>>>>
>>>>> 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.
>>>> Well, udev scripts are processed in alphabetical order. Can't you
>>>> simply run
>>>> the persistent mac rules before the persistent ifname rules?
>>> I finally figured out the problem I was having. The address attribute
>>> was not
>>> being changed by the "ifconfig" call that changed the hardware
>>> address. The fix
>>> is to create a new environment when the hardware address and lock out
>>> the rule
>>> generation process when that value is detected. The new code for
>>> /lib/udev/rules.d/65-persistent-b43-mac-generator.rules is as follows
>>> (Note:
>>> These files are line-wrapped here.):
>>>
>>> #=======================================
>>> #
>>> # Rules file to assign a unique, permanent address to BCM43XX devices
>>> without
>>> # an SPROM.
>>> #
>>> # Copyright (c) 2010 by Calvin Walton <calvin.walton@gmail.com>
>>> # Copyright (c) 2010 by Larry Finger <Larry.Finger@lwfinger.net>
>>>
>>> # skip this code if action is not add, i.e. change or remove
>>>
>>> ACTION!="add", GOTO="persistent_b43_mac_generator_end"
>>>
>>> # Use the value of the MAC_CHANGED environment variable to see if the
>>> address
>>> # has already been changed.
>>>
>>> ENV{MAC_CHANGED}=="yes", GOTO="persistent_b43_mac_generator_end"
>>>
>>> # Call script to get a random address - if this device previously
>>> encountered,
>>> # the address will already have been changed.
>>>
>>> SUBSYSTEM=="net", ATTR{address}=="82:82:82:82:82:82",
>>> IMPORT{program}="write_persistent_b43_mac"
>>>
>>> # Apply the new hardware address returned by the script
>>>
>>> SUBSYSTEM=="net", ATTR{address}=="82:82:82:82:82:82",
>>> RUN+="/sbin/ifconfig
>>> $env{INTERFACE} hw ether $env{MACADDRESS_NEW}"
>> Why do you use ifconfig hw ether instead of ip link set address ?
>>
>>> LABEL="persistent_b43_mac_generator_end"
>>> #=======================================
>>>
>>> The code for /lib/udev/write_persistent_b43_mac is as follows:
>>>
>>> #=======================================
>>> #!/bin/bash
>>>
>>> # Script to Generate a random MAC address for a BCM43XX device without
>>> # an SPROM.
>>> #
>>> # Copyright (c) 2010 by Calvin Walton <calvin.walton@gmail.com>
>>> # Copyright (c) 2010 by Larry Finger <Larry.Finger@lwfinger.net>
>>>
>>> # Use /dev/urandom to generate the last 5 bytes of the address.
>>> # Make the first byte 2 to avoid generating a multicast address and to
>>> set
>>> # the locally administered address bit.
>>>
>>> MACADDRESS=$(/bin/dd if=/dev/urandom bs=1 count=5 2>/dev/null |
>>> /usr/bin/od -tx1
>>> | /usr/bin/head -1 | \
>>> /usr/bin/cut -d' ' -f2- | /usr/bin/awk '{ print
>>> "02:"$1":"$2":"$3":"$4":"$5 }')
>> A suggest the following :
>>
>> - 6 bytes of randomness and force lower half of first byte to 2 if the
>> value does not have bit #2 set.
>> - sed, instead of head|cut|awk
>>
>> MACADDRESS=$(/bin/dd if=/dev/random bs=1 count=6 2>/dev/null |
>> /usr/bin/od -tx1 |
>> sed -ne '1{;s/0000000 //;s/^\(.\)[014589cd]/\12/;y/ /:/;p}'
>
> It also needs to be even as an odd value would be a broadcast address. Using
> only sed instead of head|cut|awk does have merit and the randomness is increased
> by 6 bits. It will take me a while to understand the sed here. Regular
> expressions are not my thing.
Yes, you are right, so I need to change a few things, in order to keep the highest possible level of
randomness while ensuring the lower half of first byte is 2, 6, a or e.
dd if=/dev/random bs=1 count=6 2>/dev/null |
od -tx1 |
sed -ne '1{;s/0000000 //;
s/^\(.\)[013]/\12/;s/^\(.\)[457]/\16/;
s/^\(.\)[89b]/\1a/;s/^\(.\)[cdf]/\1e/;
y/ /:/;p}'
Translation to humain form :
# for the first line only,
# If second char is 0, 1 or 3, replace it with 2.
# If second char is 4, 5 or 7, replace it with 6.
# If second char is 8, 9 or b, replace it with a.
# If second char is c, d or f, replace it with e.
# Replace all spaces with ':'.
# print
# Print nothing for other lines, thanks to -n option.
>
>>> # Define the output rules file
>>> RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'
>>>
>>> . /lib/udev/rule_generator.functions
>>>
>>> # Prevent concurrent processes from modifying the file at the same time.
>>> lock_rules_file
>>>
>>> # Check if the rules file is writeable.
>>> choose_rules_file
>>>
>>> # The rule should apply for all wlan devices -s some other wireless
>>> driver might
>>> # be loaded first - change wlanNN to wlan*
>>> GEN_PATH=$(echo $DEVPATH | /usr/bin/sed s/wlan[0-9]*/wlan*/)
>> sed should be quoted here : /usr/bin/sed -e 's/wlan[0-9]*/wlan*/'
>> Else, it might be fun if you happen to have a file called s/wlan7/wlan15
>> in current directory.
>
> OK - I see your point. As the current directory is /lib/udev, the presence of
> such a file is unlikely, but better to protect against the problem.
>
>>> # Output new rule
>>> echo "SUBSYSTEM==\"net\", DEVPATH==\"$GEN_PATH\",
>>> ATTR{address}==\"82:82:82:82:82:82\", ENV{MAC_CHANGED}=\"yes\",
>>> RUN+=\"/sbin/ifconfig \$env{INTERFACE} hw ether $MACADDRESS\"" >>
>>> $RULES_FILE
>> If DEVPATH is "generic" (wlan*), how would you distinguish between two
>> broadcom NIC present in the system, both without an SPROM ?
>
> That is covered by the /devices/pci0000:00/0000:00:0d.0/0000:04:00.0/... part of
> DEVPATH. A second device on the same bridge would have ...04:01.0... and a
> device on a different bridge would change some other part of the string. The
> change to wlan* handles the case where the BCM43XX device is discovered first
> with some configuration, and second when another device is plugged in at
> discovery time.
Ok, sounds good for me. Did you had the opportunity to test with two such devices ?
>
> Larry
>
next prev parent reply other threads:[~2010-03-28 19:04 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
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 [this message]
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=4BAFA83B.8050505@free.fr \
--to=nicolas.2p.debian@free.fr \
--cc=Larry.Finger@lwfinger.net \
--cc=b43-dev@lists.infradead.org \
--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).