I've been working on a local build of 18.06.8 to get an old WN604 working for me to extend home wifi. Since it is physically an access point device removing the iptables, DHCP, etc packages has left enough room for LUCI, which is nice for early monitoring of how it is running, although I'm pretty comfortable with command line only configuration.
I'm at the point where I have LEDs, wi-fi, Ethernet, etc all working, but I'd like to make sure things are as correct and tidy as possible before building a patch to potentially add to the main sources. And I'm confused on Ethernet configuration...
Basically I'm unclear on how much the hardware leads the definition of interfaces like eth0, eth1, eth0.1 rather than these being entirely software artifacts. When defining /etc/board.d/02_network , etc how much does the hardware mandate the use of eth0 and ...1 rather than it being an OpenWRT / Linux convention? For example, could they equally be eth77 and eth88? Or eth1 and ...0 (ie, swapped around)?
I think there is a clue if I do ls /sys/devices/platform - which shows ag71xx.0 and .1 devices timestamped at epoch. I assume these are ports bound to the CPU, like two physical NIC cards that lspci would show in a "proper" PC.
As noted here, the WN604 is electronically / physically similar to the WNR1000 and WPN824N so assume the "PCI to NIC" bit of the WAN side is on the SoC / board, but not the physical RJ45 jack.
Net result is that if the SoC is presenting two CPU ports even though only one is connected to any physical hardware I think I can check in the same 2-port eth0 / ...1 configuration that is at the board level for the similar devices and simply ignore the "spare" eth0 (which maps to WAN) everywhere higher up like /etc/network .
Does that sound right? Or should I explicitly make it a 1-port device in 02_network ? Or be making sure that the in use port is eth0 for some reason? And how would I do those if necessary / preferred?
As far as the kernel is involved, and unlikely -e.g. udev- OpenWrt doesn't add an abstraction layer on top of the kernel, it only knows about eth%d[0]. It does enumerate these starting from 0, in the random[1] order of discovery. Following this eth77 could be possible, but rather unlikely.
eth%d.%d Is a notation to access tagged VLANs on top of the underlying physical ethernet interface, in general OpenWrt always uses VLAN tagging on the CPU ports and lets the switch untag them, even if it wouldn't be strictly necessary[2].
Be aware that new device additions are only merged to master, so your patches need to apply (and be tested) against current master, this also means they must apply for ath79(-tiny), not ar71xx.
--
[0] Technically speaking this is a lie, the different ethernet drivers could choose a name here, but using eth%d is pretty much a convention to use for ethernet interfaces
[1] This is a real problem on more versatile systems as x86_64, which is why udev is abstracting this to the upper levels of userspace. On embedded systems like OpenWrt, the order of interface enumeration is usually rather stable, by the way the hardware and its hardware definition is laid out, be aware that ar71xx --> ath79 might switch this around though. Adding USB ethernet cards to your router however could create a naming issue, as those are by definition enumerated in a random order - probably after the native interfaces, but certainly random among each other.
[2] As a matter of consistency and to make it easier for the user to change the tagging, if their requirements (e.g. ISP side) require this.
Thanks, I think that tells me what I needed to know.
Although only one CPU port has a way to talk to the world (because of the absence of an RJ45 on the other) it is a fact that two are being enumerated. I'll therefore take the simple route of using the low level config from the similar devices (which use the "missing" port for WAN) while adjusting the use of interfaces higher up.
@slh, I'm not sure if I'm misunderstanding the significance of your comments on ath79. The source tree looks to be the same in 18.06 and 19.02 (which I repeated the device addition to) , with a ath79 directory within the ar71xx and the same code structure, functions, etc. Is there a deeper change that I've missed?
18.06.x didn't have the ath79 target yet (only ar71xx), 19.07.x has both ar71xx and ath79 - 20.x.y will have only ath79, but no ar71xx at all (master hasn't been building ar71xx for almost a year by now, even though the source is technically still present).
For ar71xx support, you needed to write a mach file for your device - for ath79 you need a DTS file instead, besides a number of other technical differences. So if you've started your endeavour with adding your device support for 18.06.x, you inevitably added it to the obsolete ar71xx target - which will still work in 19.07.x largely unchanged, but is not going to work in master with the ath79 target - and master/ ath79 is the only place where new devices additions will be accepted.
OK, the ath79 folder under ar71xx was confusing me. I see a similar device recently added under the ath79 target so will see how I get on using that as a template for the new style.