[OpenWrt-Devel] Migration in ath79 for swapped ethernet

Tue Jan 21 09:10:39 EST 2020

Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On
> Behalf Of Piotr Dymacz
> Sent: Dienstag, 21. Januar 2020 00:34
> To: mail at adrianschmutzler.de; 'David Bauer' <mail at david-bauer.net>;
> gch981213 at gmail.com
> Cc: openwrt-devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
> 
> Hi Adrian, David, Chuanhong,
> 
> On 07.09.2019 12:15, mail at adrianschmutzler.de wrote:
> > Hi,
> >
> >> > However, this will obviously swap eth0/eth1 on EVERY upgrade, not just
> >> when coming from ar71xx.
> >> > So, does anyone have an idea how to limit this to run only when updated
> >> from ar71xx?
> >>
> >> I was thinking about the same. As we have no information about the
> >> previously installed platform, i was thinking about abusing the wmac path we
> >> already use to migrate the WiFi configuration.
> >> However, i think this is not the most elegant way to solve this issue.
> >
> > I have to think about that. I recently thought one could just check whether the
> lan/wan assignment matches the one expected for ar71xx, but that would
> obviously also catch cases were the user modified it to be like this.
> >
> >>
> >> > Despite, while having the abstraction of "rename_all_eth", I wonder
> >> whether it would be possible and desirable to do all renames in one step:
> >> > sed -i -e 's/eth0/ethX/' -e 's/eth1/eth0/' -e 's/ethX/eth1/' $file or
> >> > even sed -i -e 's/eth0/eth1/' -e  's/eth0/eth1/' $file depending on
> >> > how sed handles this internally. These options would mean less flash writes
> >> (although this might not be too important here).
> >>
> >> A rewrite with sed is not sufficient, as we will possible rewrite uci section
> >> names, possibly referenced elsewhere. We have to loop thru all interface
> >> values and lists, rewriting each occurrence.
> >
> > Actually, I could well live with that. What kind of references are you referring
> to?
> > If just someone really named a section with ethX, it will be renamed
> consistently throught all uci files (unless they are stored in another location).
> > Only in case someone uses a section name with ethX and refers to it e.g. in a
> custom script, this will be a problem.
> > And this is where I think we do not have to account for every tiny possibility. If
> someone upgrades to another architecture, I think it's fair to expect him to check
> whether his custom scripts still work. We do not have to overdo it.
> > But that's just my point of view at the moment.
> 
> I'm in the middle of migrating some devices from soon-to-be-obsolete
> ar71xx to ath79 target and was wondering about status of the eth0/eth1
> vs. LAN/WAN assignment issue.

To start with the end: I've decided to stop working on this.

The two major problems are obvious:
1. How to make sure we find every possible location of eth0/eth1 in user code

This is a problem which can be solved, and if it does not cover every single special case I could live with it.

2. How to find out whether we are updating from ar71xx or not.

This is a hard one: We cannot rely on the ethernet setup itself, as the user might have changed it for whatever reason. We could rely on some other parameters as suggested (wmac path etc.), but that would not be generally applicable and still would impose some boundary conditions (e.g. start before the wmac migration, as then config would be "old" and paths on the device would already be "new", making identification of the update possible).

An alternative way would be to exploit /etc/board.json for that, given that it is not updated during sysupgrade (I'm not sure what's happening here). If it is not updated, it would give us access to the configuration when the user installed the device, and without the changes the user would have made to /etc/config/network. One could then parse and compare /etc/board.json to some (device-specific) reference (e.g. wan=eth0) and base the decision to apply migration on that. Afterwards, a new /etc/board.json is generated, so the condition is not met anymore. Despite for the device-specific condition, this would also be a generally applicable concept.

All in all, this second problem (when to migrate) is the bigger problem. We also have a similar case in https://github.com/openwrt/openwrt/pull/2649 

So far for the technical aspects. From the organizational point of view, for a long time I thought I'm the only one caring about this topic. Since there was not much interest in bringing this to 19.07 before the release, I do not see much use of adding it afterwards now.

In any case, the migration script will be a complicated task and will certainly introduce cornercases as well. All in all, I do not think it's worth it, and we should keep to advise people to flash with "-n" that single time when upgrading from ar71xx to ath79. For the pros that will change their Ethernet setup by hand later without using "-n", I'd still provide the "easy" migrations like e.g. LED names.

> 
> I'm aware of the 8dde11d521 ("ath79: dts: drop "simple-mfd" for gmacs in
> SoC dtsi") [0] and following changes but that "fixed" the problem only
> for devices which were following already reversed (I wouldn't call it
> wrong or incorrect, I also prefer to have LAN on eth0 interface) SOC's
> GMACx <> ethx assignment/register under ar71xx target - e.g. LAN on eth0
> which is in fact SOC's GMAC1 and WAN on eth1 which is SOC's GMAC0. Good
> explanation of that inverted assignment can be found in Jeff's patch
> here: [1].

Well, effectively a lot of devices match ar71xx order again, but also several do not match anymore after that.

For the underlying logic, I think Chuanhong will be the best person to discuss with.

I've tried to start a list of devices where eth0/eth1 are swapped compared to ar71xx _now_ here:
https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79#devices_with_known_config_changes_without_migration_available

> 
> I have a feeling that the idea with migration script got abandoned
> (Adrian?), so I was wondering if there is any other way we could
> preserve ar71xx LAN/WAN <> ethX assignment in ath79?

See above, yes, I effectively abandoned that.

> 
> For example, I have a QCA9531 based device with PHY4 (connected directly
> to GMAC0) labeled as LAN (and registered as eth0 in kernel) and PHY3
> (connected to GMAC1 over internal switch) labeled as WAN. On ath79, due
> to change introduced in 8dde11d521, LAN and WAN order gets swapped (as
> expected) but partially reverting above change (adding back "simple-mfd"
> to eth1 in device's DTS, see below) brings back the "old" order of
> interfaces.
> 
> &eth1 {
> 	compatible = "qca,ar9330-eth", "syscon", "simple-mfd";
> 	mtd-mac-address = <&art 0x6>;
> };
> 
> But it doesn't seem as a proper fix to me (maybe I'm wrong?) thus the
> question about any other, better approach?

That's how I feel. For me, this always looked like a hack to me (based on my shallow level of understanding, though).
There might be special cases where this is necessary (e.g. force a device to be eth0 due to failsafe), but I still do not like it.

With the first device where I observed the swapped eth0/eth1, the GLinet AR150, Chuanhong explained me that the setup in ath79 would be more correct than the one in ar71xx.
After all, if we advise to flash with -n anyway, I would prefer to have the "more correct" setup in ath79 compared to having to stick to the setup from ar71xx where that applies.

So, no matter what we do, there is no easy way forward.

Best

Adrian

> 
> [0] https://github.com/openwrt/openwrt/commit/8dde11d521
> [1]
> https://www.mail-archive.com/openwrt-
> devel at lists.openwrt.org/msg48526.html
> 
> --
> Cheers,
> Piotr
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200121/3a40c04d/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel