1

I'm working on a project using a series of Raspberry Pis, each with two different wireless cards (with different chipsets / using different modules, one is rtl8187 and the other is rt2800usb).

At the moment I've set up persistent naming rules for each Pi, so when I set up a new Pi or swap the wireless cards between Pis, I then have to go and edit it so that the new rtl8187 card is still wlan0 and the new rt2800usb card is still wlan1.

Is there some way I can modify the persistent rules to name the interfaces based on the module they use or something? Ideally I'd like to be able to have it know that whichever rtl8187 card I plug in should be wlan0 and whichever rt2800usb card should be wlan1.

Or as a workaround, is there a way to use a partial wildcard for the MAC address matching? Every card I have of the same chipset has the same vendor MAC prefix.

2 Answers 2

1

First thing I'd try is to just change the

ATTR{address}=="12:34:56:78:9A:AB"

to

ATTR{address}=="12:34:56:*"

in /etc/udev/rules.d/70-persistent-net.rules (assuming it's in the same place on your RaspPi).

I didn't test it, but that's how the usual matching works.

If it works, just copy this file to each new RaspPi.

1
  • I'm not sure why I didn't think to just try that... I saw '*' being used but couldn't find any obvious other fields to specify on instead. This works, thanks :)
    – Andrew
    Oct 25, 2016 at 13:53
0

I don't think naming the device will help as you've noticed the deciding factor on if the device is wan0 or wan1 is bassed off the mac address.

The only solution I could think of is super dirty... have two copies of the network config & use a udev rule to copy the desired network config into place. (This would work but is super dirty...)

Perhaps someone can think of a better solution, but if you choose this, the method is to match the device in a udev rule and at the end of the udev rule have +RUN=/usr/local/bin/bashscript.sh (make sure to lock down permissions).

Only question I have, I don't understand what the problem would be with having one nic as wlan1.

I believe the answer to your problem is not changing from wlan1 to wlan0, but working out why you need to...

here is an example udev rule I have with a bash script:

ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0010|0110|0111|0114|0116|0401|0403|0405|0407|0410", ACTION=="remove", RUN+="/usr/local/bin/secdev_lock.sh"

(lock my laptop screen when i unplug a security key)


UPDATE:

for debugging the card attibutes availible:

SUBSYSTEM=="net", ACTION=="add", RUN+="/usr/local/bin/addnic.sh"

in addnic.sh;

#!/bin/bash

env > /home/user/udev_$RANDOM.txt

I'm sure you'll find all the relevant info to match on in there

3
  • The issue I'm having is that each of the cards has to be used for a distinct purpose -- one of them supports monitor/promiscous mode (let' call it the "capture card") and is used to passsively capture data, the other is used to periodically upload data ("upload cards"). What I'd ideally like to achieve is the ability to plug in any of the different "capture cards" into any of the Raspberry Pis, along with any of the different "upload cards", and have the capture card always be wlan0 and the upload card always be wlan1 respectively.
    – Andrew
    Oct 25, 2016 at 2:43
  • I can probably work around this by working out which of the cards supports monitor mode and then either somehow update the udev rules to reflect this (and make whatever the other card is be wlan1), or by getting rid of the assumption that wlan0 is the capture card, but given how many other hardware issues I'm struggling with I'm trying to minimise any possible room for error and so manually editing the generated udev rules when I swap out one capture card for another is the "safest" thing at the moment. It would just be nice if there were a better way :)
    – Andrew
    Oct 25, 2016 at 2:46
  • added an update which shows how to get all the possible attribs to filter on, (maybe on driver?) Oct 25, 2016 at 2:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.