Working with a Raspberry Pi 4 and need minimum 3 ethernet, 2 for WAN and 1 for switch. Would prefer 4 so I can always have one available for direct PC connect.
The problem I face is OPENWRT does not always assign the same dongle to the same ETHx. So after reboot, I may find my switch connected dongle assigned to WAN, WANb assigned to WAN. There seems to be randomness here.
This is definitely an issue. I'd suggest to write something where early in the boot sequence you match on MAC address and use ip commands to rename the devices. I like useful names like "lan", "wan", and "guest" for example.
Another way to go is to use bridges for all interfaces, and then in /etc/rc.local move the devices to the appropriate bridge, based on matching the MAC.
so... let me clarify what the state/function of the discussed script versions do...
I would not say unpredictable... i'd say 'difficult for the average user to debug'...
the script implementation relies on the NEW destination interface name to be FREE... 'swapping' aka tearing down and re-assigning an occupied interface name during asynchronous hotplug is challenging... OP was advised to use uniq new interface names and provide config/output which did not manifest...
lower level solution(or at least partial logic) is the way forward... said implementation is targeted at USB only devices... and having 'lan' predictable helps alot... but in the case of something like virtualbox or similar where we may wish to assign a physical nic to an interface name the said implementation would likely require alteration re-assessment
spent 50-100 or more hours on this (3 attempts from scratch)... so pretty mentally burn't out on efforts... (but have tested and had functional versions on several occasions)
code from @bobafetthotmail@vgaetera and one or two more who I don't have the names in front of me was very helpful / used during these attempts...
thinking about this topic afresh... should a new attempt / mods to be made... i'd consider naming usb nics> intPHYMAC... but this carries some reverse uci walk implications and likely interferes with firstboot/setup logic... (and name size limitations?)...
this is interesting... had not considered this... worth adding tho' that matching mac can change depending on if an override is present and at what stage of the initialization process the move is made...
This works if your dongles aren't trash that change MAC address every time you unplug them. Realtek chipsets had that issues in my testing, ASIX chipsets (the ones in the "good quality" dongles) did not and maintained the same MAC address.
I think it would be cool if default UCI interface config could be anchored to MAC address instead than device name, because device name can change depending on what device is initialized first.
Afaik this is not a major problem on x86 because there you use mostly cards on PCI and PCIe slots (or electrical interfaces if it's an integrated chipset), and those will always be initialized in the same order so will always get the same device name.
But yes if you change a card or for some reason a card dies and you reboot the device yes all interfaces are reassigned and usually ends up in a non-functional state.
I'm assuming rc.local runs very late in the game right? So things should be stable.
My impression is that realtek is far better chipset and ASIX is the cheaper and less performing. At least that was the case in my tests... I haven't tested MAC stability though.
tested extensively with 8152 no mac issues with UE300... although... one had a low power (or associated probing complication) issue that forced it to be detected as a cdrom... (due to non-powered usb<>ssd conned aka 'predicatable')
For a noob, I'd suggest simply run a custom script in /etc/rc.local which runs near end of boot...
I'd probably run something like
ip -o link show | grep <MAC GOES HERE> | sed -e 's/[0-9]*: ([^:]*):/\1/'
run that several times one for each mac address and you'll get the interface names. Then choose some good names that aren't "ethx", like "lan","wan","guest","dmz" etc and do:
Given what you also said in the OP, I'd guess this is more of a raspberry issue:
When I plugged the ASIX USB device directly into my laptop and went direct laptop->server I got 900+ Mbps, so the USB device is capable of handling near line speed.
which is also what I've noticed. I've been using ASIX USB dongles (Ugreen brand of USB 3.0 gigabit dongles, specifically) on a Linux-based DYI NAS that has been transferring data at nearly line speed for days on end, and they are perfectly fine, also used for passthrough around in VMs (windows or linux) and so on, never had a problem in years.
A few realtek USB dongles I tried tend to crap out after a hour or so of actual serious use, and may or may not like being passed through without being unplugged first. This is also the case on a Macbook when syncing data to the same NAS (using a different dongle but stil a realtek chipset).
that said, if you also actually look at the market, dongles with ASIX chipsets are more expensive than ones with Realtek chipsets.
Or at least if you look at sub-10 euro dongles on ebay you only get stuff with Realtek chipsets.
EDIT: speaking of raspberry and ethernet, recently a youtuber also did some benchmarking of raspberry CM4 on two "router" boards, one with ethernet on PCIe and one with Ethernet on USB.
It had similar results to you, top speed was lower and throughput was less than half with the USB ethernet controller https://www.youtube.com/watch?v=w7teLVwi408 (skip to 10:40 to see the graph)
On my next build I am going to try the script @bobafetthotmail posted. It seems simple enough which is good for a guy like me that was banned from writing code in 1999. Its a long story......
But seriously, for novice users, a LUCI page could probe for the mac addresses and ask the user to assign them, then generate the config file at /etc/config/mac-static-interfaces. @anon50098793 perhaps the default on the build is not to bring up interfaces if we detect them to be USB until this is done. Kindly take this all in the context of a noob trying to do everything via LUCI...
good idea... re-reading how it works... it bypasses the need to 'swap' names... so you don't need to use new uniq names...
probably more sensible in retrospect...
point taken... and thanks... can't exactly work like that due to interactions with typical OS functions... but I do understand the point you are making and will consider it if tackling this again...
I have been experiencing issues with the realtek chipsets from 2 vendors. The dongles seem to get hot to the touch and crap out. This has happened on OPENWRT on the PI and now with OPNSENSE on an i7 PC when there is no load on the router, just the MWAN pinging every minute. I put a fan on the dongle to stabilize it. Really odd behavior.
that's a very dramatic thing to say, but ok.
I mean I'm not a programmer either but I can hack together some shell (Linux) or batch (Windows) scripts with the help of online documentation and tutorials.
The config file is written with OpenWrt standard configuration syntax so people can add a Luci package to manipulate the config.
If someone wants to do that I can submit my script as a package in the package feed (technically speaking it's already a package, just a local package I use in my builds).
@bobafetthotmail now that I re-read what I wrote, it is pretty dramatic. So Explanation. Sometime in 1999 some really smart guys code reviewed the c++ I had checked into the build and told me there were things that I was pretty good at and coding was not one of them. They strongly recommended I should stick to what I am good at :-(.
Unfortunately, I never learned to write bash hence my pleas for help.
Ok, with the following instructions the script will be run on device start and will assign the interface name you want to a device that has the MAC address you want, for all devices defined in the config file.
Devices not defined in the config will be ignored. It's better if you define all network interfaces you have in the config.
You need to put the script in /etc/init.d folder and call it staticeth (or whatever you want, name does not matter)
#!/bin/sh /etc/rc.common
START=11
# don't run within buildroot
[ -n "${IPKG_INSTROOT}" ] && return 0
#use busybox grep as GNU grep may be set differently and break the script
grep(){
/bin/busybox 'grep' $@
}
#shutting down all interfaces, then assigning temporary name to free up interface names
#bridges and virtual interfaces are already excluded by /sys/class/net/*/device/uevent as only physical interfaces have that
for i in $( ls /sys/class/net/*/device/uevent | awk -F'/' '{print $5}' | tr '\n' ' ' ) ;
do
mac_address=$( grep $i /etc/config/mac-static-interfaces | awk '{print $3}' | tr -d '"' )
if [ "$mac_address" != '' ]; then
ip link set "$i" down
ip link set "$i" name old"$i"
fi
done
for i in $( ls /sys/class/net/*/device/uevent | awk -F'/' '{print $5}' | tr '\n' ' ' ) ;
do
mac_address=$( cat /sys/class/net/$i/address )
interface_name=$( grep -i $mac_address /etc/config/mac-static-interfaces | awk '{print $2}' )
if [ "$interface_name" != '' ]; then
ip link set "$i" down
ip link set "$i" name "$interface_name"
fi
done
Then make it executable with chmod +x /etc/init.d/staticeth
Then "enable" it to make it start as a service when the system is turned on.
service staticeth enable
now create the config file /etc/config/mac-static-interfaces
and write the interface name and the mac address of the devices you want to remap. The interface names and mac addresses below are just examples, please write the right ones for your device.
yes, although I'm dumb and originally I copied only half of it, now the script is complete (both in that post and in my answer to the other guy).
It is simply run on boot and will rename interfaces with a temporary name to "make space" if the same name already exists before doing the actual rename so you can freely choose interface names. It is run before network service but after hardware initialization so it should not screw up network.
If you want to call it after device boot (like by a script in /etc/hotplug.d to react to hotplugged devices), call the script and then service network restart to force network service to adjust to new device names.
I configured and ran. It broke after the rename and I am left with interfaces named "old".
I think I have a problem with my bridge config and am generating one less interface than I should have and am breaking the "for i in... " loop. Will work on it more tomorrow.
