Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2694 - Clearfog Pro: Default LAN / WAN Interface assignment is wrong #7490

Open
openwrt-bot opened this issue Dec 25, 2019 · 5 comments
Open
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release

Comments

@openwrt-bot
Copy link

Artox_:

On my Clearfog Pro Rev 2.0 the interfaces map as follows:

eth0: switch
eth1: SFP
eth2: standalone ethernet

This does not match the current description in /etc/board.d/02_network:
# eth0 is standalone ethernet

eth1 is switch (-pro) or standalone ethernet (-base)

eth2 is SFP

ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"

While I don't agree with the lan/wan decision made here, at least the comment should match reality.
So I suggest changing it to:
# eth2 is standalone ethernet

eth0 is switch (-pro) or standalone ethernet (-base)

eth1 is SFP

ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2"

Please also see the attached patch file, which also changes the switch configuration accordingly.

@openwrt-bot
Copy link
Author

Artox_:

Created a proper patch-file that doesn't change thje lan/wan assignmenmt described in the code comments, but does update the ethY handles accordingly.

@openwrt-bot
Copy link
Author

WouterH:

I can confirm this bug on my own clearfog pro device.
Using 18.06.1 everything still worked out of the box. On more recent versions (I tested 18.06.5 and a compiled master branch) the switch is bridged with the wan rj45 port.

Applying the patch above by Josua fixes the problem and openwrt behaves as expected again.

@openwrt-bot
Copy link
Author

menschentier:

I can also confirm this behaviour on my clearfog pro.

it works on 18.06 branch (up to 18.06.6), but does not work on 19.07 as every available copper port is bridged to wan.

@openwrt-bot
Copy link
Author

svfrd:

I can also confirm this bug.

The interface numbering has been changed with 4.14 kernel and the former "ip name" workaround breaks the default network configuration.

[..] [ 0.890885] mvneta f1070000.ethernet eth0: Using device tree mac address ea:d1:29:18:cf:d2 [ 0.900185] mvneta f1030000.ethernet eth1: Using device tree mac address 82:da:47:2b:88:2d [ 0.909479] mvneta f1034000.ethernet eth2: Using device tree mac address 9a:80:7f:c4:b0:f5 [..] [ 8.666435] init: - preinit - [ 8.853268] mvneta f1070000.ethernet tmp0: renamed from eth0 [ 8.903286] mvneta f1030000.ethernet eth0: renamed from eth1 [ 8.943257] mvneta f1034000.ethernet eth1: renamed from eth2 [ 8.983232] mvneta f1070000.ethernet eth2: renamed from tmp0 [..]

This breaks the correct interface naming..

/lib/preinit/06_set_iface_mac:

(..)
marvell,a385-db-ap|solidrun,clearfog*a1)
# rename interfaces back to the way they were with 4.4
case "$(readlink /sys/class/net/eth0)" in
f1070000)
ip link set eth0 name tmp0
ip link set eth1 name eth0
ip link set eth2 name eth1
ip link set tmp0 name eth2
;;
esac
;;
(..)

after interface renaming:

eth0 => standalone (base), switch (pro)
eth1 => sfp
eth2 => wan (standalone)

without interface renaming:

eth0 => wan (standalone)
eth1 => standalone (base), switch (pro)
eth2 => sfp

Without the interface renaming the default network configuration applies cleanly.

/etc/board.d/02_network:

(..)
solidrun,clearfog*a1)
# eth0 is standalone ethernet
# eth1 is switch (-pro) or standalone ethernet (-base)
# eth2 is SFP
ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"

# if switch exists (clearfog-pro)
# switch port 5 is connected to eth1
swconfig list 2>&1 | grep -q switch0 && \
    ucidef_add_switch "switch0" \
        "0:lan:5" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "5u@eth1" "6:lan:6"
;;

(..)

Also take a look on "mvebu: Clearfog Pro fix emmc boot without microSD card".
#2732

@openwrt-bot
Copy link
Author

adrianschmutzler:

Pasting my comment to the Pull Request here as well for documentation:

Just had another look at this, since we now have settled the changes in master.

I think this should be handled as in the latest version of the patch here, i.e. by not touching the migration script, but only the default setup in 02_network.

However, I had a look into the history:

  1. The migration script has been introduced when going from 4.4 to 4.9, being present in all versions starting from 18.06.0(-rc):
    2bf9ea6
  2. After that, the configuration has been updated by @Artox here, still effective starting from 18.06.0(-rc):
    48cc065
  3. Again, a bit later, the SFP port was moved by @Artox , still effective for 18.06.0(-rc):
    d41a441

Since then, the respective sections of 02_network and the migration script are untouched. Despite, the reports in the bug report deviate with respect to when the assignment became wrong: one person states the latest version of 18.06 is fine, another one states that late versions of 18.06 are broken.

So, either:

  1. the config in kernel changed after 18.06.0, i.e. within the same stable kernel version 4.14, which is rather unlikely
  2. something happened during the bump to 4.14 here (which would mean that all 18.06 versions should be wrong as well): 4ccad92
  3. The patch 48cc065 from @Artox was wrong
  4. The migration script is not always working (or working as intended), leaving us with different ethX order

Since this is about changing stable targets after a lot of point-releases, I'd be happy to learn more about the real reasons for the problem (and whether it really exists), before applying this.

If we narrow it down, I'm willing to merge the outcome of the discussion (in a similar shape as the current patch).

@aparcar aparcar added the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release
Projects
None yet
Development

No branches or pull requests

2 participants