[PATCH V2] ssb: Implement virtual SPROM on disk

[PATCH V2] ssb: Implement virtual SPROM on disk

[Nicolas de Pesloüan]

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}'

> # 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.

> # 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 ?

	Nicolas.

> 
> # Report the new address back to the caller who will set the address for this
> new interface
> echo "MACADDRESS_NEW=$MACADDRESS"
> 
> unlock_rules_file
> 
> exit 0
> #=======================================
> 
> Is there a location to put a tar file containing the script and rules files?
> 
> Larry
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
> 

[PATCH V2] ssb: Implement virtual SPROM on disk

[Larry Finger]

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.

>> # 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.

Larry

[PATCH V2] ssb: Implement virtual SPROM on disk

[Nicolas de Pesloüan]

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
> 

[PATCH V2] ssb: Implement virtual SPROM on disk

[Larry Finger]

On 03/28/2010 02:04 PM, Nicolas de Peslo?an wrote:
> Larry Finger wrote:
>> On 03/28/2010 12:14 PM, Nicolas de Peslo?an wrote:
>>> Larry Finger wrote:
>>> 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.

That is a lot of work for 2 extra bits, but thanks. I had changed the [014589cd]
of your original with [01345789bcdf], which resulted in X2 as the first byte for
most generated addresses.

>>> 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
> 
> Ok, sounds good for me. Did you had the opportunity to test with two
> such devices ?

Yes. On a machine where I have two PCI versions of BCM43XX devices, one is
...00:08.0/... and the other is ...00:0a.0/... The generated rules are

SUBSYSTEM=="net", DEVPATH=="/devices/pci0000:00/0000:00:08.0/ssb0:0/net/wlan*",
ATTR{address}=="82:82:82:82:82:82", ENV{MAC_CHANGED}="yes", RUN+="/sbin/ifconfig
$env{INTERFACE} hw ether c2:e7:d3:d8:73:a8"
SUBSYSTEM=="net", DEVPATH=="/devices/pci0000:00/0000:00:0a.0/ssb1:0/net/wlan*",
ATTR{address}=="82:82:82:82:82:82", ENV{MAC_CHANGED}="yes", RUN+="/sbin/ifconfig
$env{INTERFACE} hw ether 02:56:31:dd:7f:85"

Incidentally, I tried ip rather than ifconfig, and found that the MAC address
was never changed.

Larry

[PATCH V2] ssb: Implement virtual SPROM on disk

[Peter Stuge]

Larry Finger wrote:
> I tried ip rather than ifconfig, and found that the MAC address
> was never changed.

I like ip too, but to change the MAC the interface needs to be down.


//Peter

[PATCH V2] ssb: Implement virtual SPROM on disk

[Gene Heskett]

On Sunday 28 March 2010, Peter Stuge wrote:
>Larry Finger wrote:
>> I tried ip rather than ifconfig, and found that the MAC address
>> was never changed.
>
>I like ip too, but to change the MAC the interface needs to be down.
>
>
>//Peter

How many servers are emitting this b43 list these days?  I have recently had 
to add 2 more to the kmail filters here in order to route this lists mail 
properly.  I hope a subscription to one is sufficient for all.

>_______________________________________________
>b43-dev mailing list
>b43-dev at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/b43-dev
>


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

firewall needs cooling

[PATCH V2] ssb: Implement virtual SPROM on disk

[Larry Finger]

On 03/28/2010 09:21 PM, Gene Heskett wrote:
> 
> How many servers are emitting this b43 list these days?  I have recently had 
> to add 2 more to the kmail filters here in order to route this lists mail 
> properly.  I hope a subscription to one is sufficient for all.

The list is being switched to infradead. Perhaps berlios is still active. That
should not last too long.

Larry

[PATCH V2] ssb: Implement virtual SPROM on disk

[Stefano Brivio]

On Sun, 28 Mar 2010 21:43:14 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 03/28/2010 09:21 PM, Gene Heskett wrote:
> > 
> > How many servers are emitting this b43 list these days?  I have
> > recently had to add 2 more to the kmail filters here in order to
> > route this lists mail properly.  I hope a subscription to one is
> > sufficient for all.
> 
> The list is being switched to infradead. Perhaps berlios is still
> active. That should not last too long.

Actually, I already disabled sending from berlios (I'll be shutting
it down completely as soon as things have settled), so this shouldn't
happen.

It looks like lists messages on infradead get sent from at least two
different servers, anyway. In order not to be affected by this, I
suggest filtering on the List-Id header instead. The matching value is
"b43-dev.lists.infradead.org".


--
Greetings
Stefano

[PATCH V2] ssb: Implement virtual SPROM on disk

[David Woodhouse]

On Mon, 2010-03-29 at 09:44 +0200, Stefano Brivio wrote:
> 
> Actually, I already disabled sending from berlios (I'll be shutting
> it down completely as soon as things have settled), so this shouldn't
> happen.
> 
> It looks like lists messages on infradead get sent from at least two
> different servers, anyway. In order not to be affected by this, I
> suggest filtering on the List-Id header instead. The matching value is
> "b43-dev.lists.infradead.org". 

They should only come from one server; currently bombadil.infradead.org
although it may change occasionally as I migrate services between
machines.

Filtering on List-Id: will give you false positives in some
circumstances (especially when people resend list messages to you
personally, which often happens to me on lists I don't pay much
attention to).

The best thing to filter on is the SMTP sender, which usually ends up in
a 'Return-Path' header. For the b43 list, that be something like
b43-dev-bounces+dwmw2=infradead.org at lists.infradead.org (with your own
email address, not mine).

In Exim's filter language, the correct check would be:

if "$sender_address" matches "b43-dev-bounces.*@lists.infradead.org" then
        save Maildir/.lists.b43/
endif

In procmail I think it's something like:

* ^Return-Path: b43-dev-bounces.*@lists.infradead.org
$MAILDIR/.lists.b43/

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

[PATCH V2] ssb: Implement virtual SPROM on disk

[Gene Heskett]

On Monday 29 March 2010, Stefano Brivio wrote:
>On Sun, 28 Mar 2010 21:43:14 -0500
>
>Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 03/28/2010 09:21 PM, Gene Heskett wrote:
>> > How many servers are emitting this b43 list these days?  I have
>> > recently had to add 2 more to the kmail filters here in order to
>> > route this lists mail properly.  I hope a subscription to one is
>> > sufficient for all.
>>
>> The list is being switched to infradead. Perhaps berlios is still
>> active. That should not last too long.
>
>Actually, I already disabled sending from berlios (I'll be shutting
>it down completely as soon as things have settled), so this shouldn't
>happen.
>
>It looks like lists messages on infradead get sent from at least two
>different servers, anyway. In order not to be affected by this, I
>suggest filtering on the List-Id header instead. The matching value is
>"b43-dev.lists.infradead.org".
>
No, its "b43-dev at lists.infradead.org"
>--
>Greetings
>Stefano

There is no such header on the incoming messages, or kmail is stripping it. 
It cannot be found in a view all headers setting.  So if I hit reply, it 
goes back to the OP (if it will go at all), and a 'reply all' gets me a list 
I have to clean up in order to just leave the server as the recipient.  It 
starts out as a CC:

This isn't a very satisfactory method, highly prone to errors and its the 
only list of about 40 I have to do that to.  If I leave the OP addresses in, 
the messages are either stuck in the outbox, or bounce if the OP isn't 
Larry.  I presume many are using fake addresses to control spam or some 
such.


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Lie, n.:
	A very poor substitute for the truth, but the only one
	discovered to date.

[PATCH V2] ssb: Implement virtual SPROM on disk

[Peter Stuge]

Gene Heskett wrote:
> >suggest filtering on the List-Id header instead. The matching value
> >is "b43-dev.lists.infradead.org".
> 
> No, its "b43-dev at lists.infradead.org"

Here it is:

List-Id: b43/b43legacy Linux driver discussions <b43-dev.lists.infradead.org>


> There is no such header on the incoming messages, or kmail is
> stripping it.

Strange.


> So if I hit reply, it goes back to the OP

Look for "Reply to mailing list" in KMail.

http://www.kdedevelopers.org/node/1651

Maybe it's triggered by a List-Id header though, and if you don't
have that in your messages then you might also not have the
button/action available in KMail. Look for any configuration about
mailing lists in KMail, maybe you can let it know that you're
subscribed to a list with a particular address so that it will always
allow list reply for messages to that address.


//Peter

[PATCH V2] ssb: Implement virtual SPROM on disk

[Gene Heskett]

On Tuesday 30 March 2010, Peter Stuge wrote:
>Gene Heskett wrote:
>> >suggest filtering on the List-Id header instead. The matching value
>> >is "b43-dev.lists.infradead.org".
>>
>> No, its "b43-dev at lists.infradead.org"
>
>Here it is:
>
>List-Id: b43/b43legacy Linux driver discussions
> <b43-dev.lists.infradead.org>
>
>> There is no such header on the incoming messages, or kmail is
>> stripping it.
>
>Strange.
>
>> So if I hit reply, it goes back to the OP
>
>Look for "Reply to mailing list" in KMail.
>
>http://www.kdedevelopers.org/node/1651
>
>Maybe it's triggered by a List-Id header though, and if you don't
>have that in your messages then you might also not have the
>button/action available in KMail. Look for any configuration about
>mailing lists in KMail, maybe you can let it know that you're
>subscribed to a list with a particular address so that it will always
>allow list reply for messages to that address.
>
>
>//Peter
>
That header is now present, and has been since the next message after I 
mentioned it.  I hadn't change my filtering yet, other than adding 
infradead, and its all working, including a single reply like this going 
back only to the list.  I think that is how its supposed to work?


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

A bore is someone who persists in holding his own views after we have
enlightened him with ours.