On Sat, Mar 22, 2008 at 11:28:57PM +0100, Marco d'Itri wrote:
> On Mar 22, Kurt Roeckx <[EMAIL PROTECTED]> wrote:
>
> > I assumed that either you or upstream has some expierence with dealing
> > with such situation. I assume the kernel breaks things once in a while.
> > I have no idea if there are any workarounds for simular problems.
> Yes, but the report was confusing. People can't assume that I know about
> every broken version of every wifi driver around...
> I do not understand if removing the old rules and reloading the modules
> fixed the problem or not.
Removing the rules and then letting udev add the new rules does work.
> Also, what changed exactly from the kernel side?
It changed from driver bcm43xx to b43. bcm43xx only showed 1 interface,
wlan0 or something. b43 also has a wmaster0.
> And where did the eth3 name came from?
Some previous version of udev assigned that name while I was still using
the bcm43xx driver.
> > My first idea was that if the b43 driver is loaded and the MAC adddress
> > matches that the 'ATTRS{type}="1"' gets added automaticly if it's not
> > present.
> Automatically modifying exising rules is hard.
>
> > Alternativly udev should know that (for the b43 driver) it should only
> > attemp to rename it if the type is 1.
> It does:
>
> if [ $basename = "ath" -o $basename = "wlan" ]; then
> match="$match, ATTR{type}==\"1\"" # do not match the wifi* interfaces
> fi
For some reason that didn't work. Is there a way I can debug this?
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
