I have a theory that this affects only devices that have a separate ethernet port for uplink (i.e. not a port on the same switch as the LAN). In the case of the RouterStation Pro, it has a 3-port switch on eth1 and a separate single ethernet uplink port on eth0. The Buffalo router that is in the second thread has a similar arrangement (although the uplink appears to be on eth1).
It would be really handy if other similar ath79 based devices could be tested to see if this behavior appears to be consistent across other hardware. It could provide additional insight to help the developers identify the root cause (i.e. 1 or more commits that likely caused this regression).
I filed the bug a bit over 2 weeks ago. In that time, I've done some searches on the commits to the ath79 platform since 19.07.x, but I haven't been able to turn up anything that seems to apply to this situation, although I'm happy to look some more if anyone has any pointers.
The bug itself doesn't appear to have been reviewed yet (it has not been confirmed or assigned). I suspect/hope that it is a relatively simple issue, but I am aware that it is probably considered low priority and low severity. Is there anything that I can do that might help get this through the bug triage process? For example, is there any additional data I can provide or any other info that might be useful to the dev team?
You author a pull request at https://github.com/openwrt/openwrt/pulls
Should be straightforward, if it is about a cherry pick.
The original bug fix commit 766e0f584a32 in master seems to have been made by @blocktrron , so he might be persuaded to backport it even without a PR.
Sounds good. If @blocktrron sees this and takes care of the back port, that would be awesome. Otherwise, I'll do that PR.
Meanwhile, @blocktrron -- thanks for the bug fix and thanks*100 in advance if you are able to back port it. Let me know if you need any additional info or testing on this one or if you need me to do anything to help out in any way.
What I meant by "anything left to do?" was simply with respect to getting the commit merged into the 21.02 branch so it will appear in 21.02.1. Assuming that's all good now, I can indeed close these threads.
That said, in the bug itself, I see a "request closure" button -- should this be done now, or is the convention to wait until 21.02.1 with the fix in place and in the stable release build to close the bug?