My wish is to eventually run OpenWRT on a RPi4B, but with 3 Ethernet ports.
I have read (I believe) most of the OpenWRT docs in this connection but I am still missing something. Let me try to explain things this way:
I'll use the term PH0, PH1, PH2 for the physical Ethernet ports 0,1 and 2 in this note. (In some places in discussion I think some folks use the term, e.g., Eth2 when they don't mean the physical/tangible Ethernet port but the abstracted internal lan2 port. Or the other way around. I just want to avoid that problem in this little chat. If I am wrong - just say so.)
PH0 is (should be) Eth0, the port on the Raspberry Pi 4B.
I keep PH0 as Eth0 as a static (192.168.1.1) DHCP serving inside port.
PH1 is one of my USB3/Ethernet adapters based on the RTL8153 chip.
In Luci I make PH1 Eth1 on Lan1.
I try to have Eth1 associated with its MAC address. Luci does that automatically. Good.
PH2 is my other USB3/Ethernet adapter based on the AX88179 chip
I try to make PH2 Eth2 for WAN and/or WAN6.
I try to have Eth2 WAN associated with its MAC address - this may be my whole problem though.
LuCi does not let me set a MAC address for PPPoE and setting it manually in /etc/config/network does not work well. More on that below.
Both PH1 and PH2 are seen by the RPi/OpenWRT 25737 r16121 snapshot code.
I never had to install or add any other code/drivers for either PH1 or PH2.
In snapshot 25737 r16121 I can set either PH1 or PH2 (one adapter at a time) as either an outgoing PPPoE port or an inside static DHCP serving port. Either adapter can perform either task without problems.
The problem comes about when I try to have PH0, PH1 -and- PH2 (Eth0 and two adapters) all in the system at once.
PH0 as Eth0 on Lan, static 192.168.1.1 serving DHCP
PH1 as Eth1 on Lan1, static 192.168.1.2 serving DHCP
PH2 as Eth2 PPPoE (IPv4)
In this configuration PH2 (WAN/PPPoE) occasionally jumps from its PH2 MAC address to PH1's MAC address, even once it has been up and running for a while.
I have edited /etc/config/network adding to the WAN portion the line:
option macaddr 'MAC address'
(Nataurally 'MAC addr' is the adapter's MAC address separated by :'s) but that does not work well. It messes with the PPPoE connection to the DSLAM.
......
I just had the idea to try (in Luci) adding ports Eth1 and Eth2 (perhaps I can put the MACs in there too) before adding LAN1 and WAN. This is fun.
yup... this is a known issue with interface probing... I will add an /etc/config/network parameter you can use to assign the usb nics based on original mac address in the next release...
( the obvious cheat workaround being to use dissimilar chipsets or if you are an electronics guru you could also add a slow-start relay on the second nic usb +5v rail )
Just for general interest, I ran another scenario here (what I suggested above);
Set my PH1 as interface Eth1 (in LuCI) with its MAC address (what this test was all about) with the protocol unspecified.
Set my PH2 as interface Eth2 (in LuCI) again with its MAC and unspecified protocol
After that I set up LAN1 as static (192.168.1.2) and DHCP enabled using the Eth1 from above. Lan1 and Lan were bridged (I think that is the term/language to use here).
Similarly, WAN/PPPoE was set up using Eth2 from above.
Everything was working.
NOW for the pull test (kill and reapply power).... The PPPoE connection cannot be established. I get the "unknown error (USER_REQUEST)" error when I try to restart WAN in LuCI Interfaces. I get the same problem if I replace WAN with WAN6 and pull/reapply the power.
If I delete the WAN from the LuCI interface page and manually replace it, I do get a PPPoE connection again, but PPPoE does not come up after a power cycle.
I used the same PPPoE setting as I have in my copy of OpenWRT 19.07 in both of my TP Link AC1750's and other routers. No concentrators were needed, default LCP settings were fine (fields left blank). 19.07 on my AC1750s has no problems with cycling power and PPPoE connections.
I did fiddle with LCP echo failure figures of 0,1,2 to 5 and LCP echo intervals of 0 to 5, and a few combinations of these, but nothing worked yet on the RPi4B.
I am running 2.7.15-2 r15599 with pppoe on the usb3toeth adapter (r8152). Plus I have extended the partition with gparted.
No problems whatsoever after power outages and pppoe is rock steady.
a while ago (pretty much official build) I had a pegasusII that I was using as a trunk line to a cisco-gs... it probed earlier (sometimes?) and took over eth1(wan)...
so I had to use a custom script to rename it to 'mgmt9' ... ( could have manually modprobed from the end of rc.local or later etc. I suppose )
in all honesty splitting a single eth1 into vlans over a managed switch is probably the most reliable short term fix...
switching to the official build and tackle this in a general forum thread or within upstream codebase... may yeild more input / faster more extensible solutions...
usage-notes
build-based interface reassign is likely to be touch and go depending on demand or the number of testers / what they expect from the feature / and any long term complexities or interactions with typical / common use of the build (i.e. some 'build' scripts statically rely on eth1 being a wan interface not having one may lead to unusual results regarding some build features );
assumes medium/advanced pre-existing skills for its usage
will have to be first tested manually ( curl @ github/utilities > hotplug ) probably fairly extensively... so you'd have to manually put that in sysupgrade.conf etc. etc.
the initial testing code will operate as follows...
uses /etc/config/network 'option macmatch'
for initial testing you should use some whack interface name in that section... i.e. ifname 'mgmt9' or ifname 'eth9'... this hopefully limits the need to switch out two wrongly conflicting assigned names during the initial script testing...
prefferably should be used on interfaces that spring up early and take over 'eth1' etc. but it may work well re-assigning all to whackyer non system assigned names
you will(should) not be able to assign alternate official 'macaddr' during the initial testing of the script... ( edit: there is a second 'w-macaddr' variant @ github )
here is my config section that takes a second UE300 and moves it from the system detected 'eth2' to something likely free @ ifname 'eth9||mgmt11'
curl -sSL "https://raw.github.com/wulfy23/rpi4/master/utilities/000-nicmove" > /etc/hotplug.d/net/000-nicmove
##########################################iface-probably-uneeded but put one there too whilst in beta
curl -sSL "https://raw.github.com/wulfy23/rpi4/master/utilities/000-nicmove" > /etc/hotplug.d/iface/000-nicmove
Ok, are you among other things (I'll be considering your config) saying that I may be hoping/assuming that OpenWRT is more flexible and general purpose than it presently is?
There is no problem in saying so if that is the case. Every system has some limit somewhere. It is only in using a tool that one learns where those limits are. I don't mean that in a derogatory way; OpenWRT is wonderful, but there are (will be) limits. I will now simply reconsider and adjust my goal in the context of those limits. This is is not a show stopper.
do what suits you best... fwiw... your feedback has been valued and utilized... know that your experience and the sharing thereof has been of benefit to others...
thankyou for sharing and pushing the capabilities of this build beyond what existed before you arrived...
Web performance feels faster, buffering time for video content feels lower using this version of the script than the currently shipping version.
I'm not sure how to put some quant data around this so I can give some better feedback than 'it feels faster', any ideas @anon50098793 ?
Edit: Feels like there should be a 'web experience speed test' that measures experienced performance rather than just bandwidth/latency/bufferbloat etc
ages ago... there was a linux utility called httpbench ... but I dont know if its current or qosspecific...
there are quite a few iterations and subtle tweaks to that script... some earlier versions really bumped up 443 and used a higher CS in general... but that was a bit of cheating on my part that really seems to suit both of our network patterns...
accommodating for gaming and voip a bit better... I think I dumbed those down a little... so might be the case I can provide a 'tunable' ... or could just be some oversight / suboptimal match...
Today my samba shares started not working, and the log shows:
Error loading module '/usr/lib/samba/vfs/io_uring.so': Error loading shared library liburing.so.1: No such file or directory (needed by /usr/lib/samba/vfs/io_uring.so)
without that, none of my network shares work. It seems to be caused by a package upgrade, since yesterday it was working and I didn't upgrade the version.
without a log / detailed description of what actions were undertaken it's very difficult to comment... ( but credit to you for being up front about this )...
this appears to be 'advice' from a bumped package ( and not technically build related ) ... but I do appreciate/need notice of these things here...
you can try asking for more detail in the simple-adblock support thread about how critical it is to have those additional tools ( what won't work without them ) especially as the message says: 'recommended'
stangri's user docs are usually very good... so you could also probably find out on his website... / simple-adblock readme...
normally i'd just advise you to run the recommended command... and i'd give a rough 90% chance they would be ok... in general tho' with this build ( or any openwrt install really )... I usually approach 'full-utils' with considerable caution... as i've seen many breakages of custom scripts and core functionality ( most recently gzip breaking sysupgrade ) by adding 'full' variants of things...
That's the thing, the way I know it must be from a package upgrade is because that's the only action I did between yesterday and today. I have a script to upgrade all packages:
opkg update && opkg list-upgradable | cut -f 1 -d '"'"' '"'"' | xargs opkg upgrade
I'll still test some things today to try and make this work, but my guess is really that I did an upgrade on some samba package that removed that file. I just posted to see if the same happened to anyone else.
Upgrading packages (via the CLI opkg upgrade command or the LuCI Upgrade... button) can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.
Requirements for Faster Block-list Processing
The gawk, grep, sed and coreutils-sort are the optional, but recommended packages as they speed up processing dramatically. You can install these recommended packages by running the following command:
opkg --force-overwrite install gawk grep sed coreutils-sort