| Message ID | 20210412122725.29430-2-bjorn@mork.no |
|---|---|
| State | Accepted |
| Delegated to: | Hauke Mehrtens |
| Headers | show |
| Series | realtek: fix default network configuration | expand |
This has my full support, even as a developer I had trouble getting Realtek devices to work in the default configuration. For OpenWRT users it is very confusing that these devices do not have a standard setup and the user first has to learn about VLANs to make use of the devices. Birger On 12.04.21 14:27, Bjørn Mork wrote: > The default management interface should be easy to find for users > doing "blind" installations without console access. There are > already multiple examples in the forum of advanced early adopters > having problems locating the management interface after installing > OpenWrt. > > Requiring tagged VLAN configration to access the initial management > interface creates unnecessary hassle at best. Errors on the other > end are close to impossible to debug without console access, even > for advanced users. Less advanced users might have problems with > the concept of VLAN tagging. > > Limiting management access to a single arbitrary port among up to > 52 possible LAN ports makes this even more difficult, for no > reason at all. Users might have reasons to use a different port > for management. And they might even have difficulties using the > OpenWrt selected one. The port might be the wrong type for their > management link (e.g copper instead of fibre). Or they might > depend on PoE power from a device which they can't reconfigure. > > User expectations will be based on > - OpenWrt defaults for other devices > - stock firmware default for the device in question > - common default behaviour of similar devices > > All 3 cases point to a static IP address accessible on the native > VLAN of any LAN port. A switch does not have any WAN port. All > ports are LAN ports. > > This changes the default network configuration in line with these > expectations. > > Cc: John Crispin <john@phrozen.org> > Signed-off-by: Bjørn Mork <bjorn@mork.no> > --- > .../realtek/base-files/etc/board.d/02_network | 14 +++++--------- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network > index 1e199db5897f..44f1f0a7a5c1 100644 > --- a/target/linux/realtek/base-files/etc/board.d/02_network > +++ b/target/linux/realtek/base-files/etc/board.d/02_network > @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do > lan_list="$lan_list $(basename $lan)" > done > ucidef_set_bridge_device switch > -ucidef_set_interface_wan "$lan_list" > -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 > +ucidef_set_interface_lan "$lan_list" > > lan_mac="" > -wan_mac="" > label_mac="" > case $board in > *) > - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) > + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) > label_mac=$lan_mac > ;; > esac > > -lan_mac=$(macaddr_setbit_la $wan_mac) > - > ucidef_set_interface_macaddr "lan" $lan_mac > -ucidef_set_interface_macaddr "wan" $wan_mac > -ucidef_set_bridge_mac "$wan_mac" > -ucidef_set_network_device_mac eth0 $wan_mac > +ucidef_set_bridge_mac "$lan_mac" > +ucidef_set_network_device_mac eth0 $lan_mac > for lan in $lan_list; do > ucidef_set_network_device_mac $lan $lan_mac > + lan_mac=$(macaddr_setbit_la $lan_mac) > lan_mac=$(macaddr_add $lan_mac 1) > done > [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac >
On 4/12/21 2:27 PM, Bjørn Mork wrote: > The default management interface should be easy to find for users > doing "blind" installations without console access. There are > already multiple examples in the forum of advanced early adopters > having problems locating the management interface after installing > OpenWrt. > > Requiring tagged VLAN configration to access the initial management > interface creates unnecessary hassle at best. Errors on the other > end are close to impossible to debug without console access, even > for advanced users. Less advanced users might have problems with > the concept of VLAN tagging. > > Limiting management access to a single arbitrary port among up to > 52 possible LAN ports makes this even more difficult, for no > reason at all. Users might have reasons to use a different port > for management. And they might even have difficulties using the > OpenWrt selected one. The port might be the wrong type for their > management link (e.g copper instead of fibre). Or they might > depend on PoE power from a device which they can't reconfigure. > > User expectations will be based on > - OpenWrt defaults for other devices > - stock firmware default for the device in question > - common default behaviour of similar devices > > All 3 cases point to a static IP address accessible on the native > VLAN of any LAN port. A switch does not have any WAN port. All > ports are LAN ports. > > This changes the default network configuration in line with these > expectations. > > Cc: John Crispin <john@phrozen.org> > Signed-off-by: Bjørn Mork <bjorn@mork.no> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> > --- > .../realtek/base-files/etc/board.d/02_network | 14 +++++--------- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network > index 1e199db5897f..44f1f0a7a5c1 100644 > --- a/target/linux/realtek/base-files/etc/board.d/02_network > +++ b/target/linux/realtek/base-files/etc/board.d/02_network > @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do > lan_list="$lan_list $(basename $lan)" > done > ucidef_set_bridge_device switch > -ucidef_set_interface_wan "$lan_list" > -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 > +ucidef_set_interface_lan "$lan_list" > > lan_mac="" > -wan_mac="" > label_mac="" > case $board in > *) > - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) > + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) > label_mac=$lan_mac > ;; > esac > > -lan_mac=$(macaddr_setbit_la $wan_mac) > - > ucidef_set_interface_macaddr "lan" $lan_mac > -ucidef_set_interface_macaddr "wan" $wan_mac > -ucidef_set_bridge_mac "$wan_mac" > -ucidef_set_network_device_mac eth0 $wan_mac > +ucidef_set_bridge_mac "$lan_mac" > +ucidef_set_network_device_mac eth0 $lan_mac > for lan in $lan_list; do > ucidef_set_network_device_mac $lan $lan_mac > + lan_mac=$(macaddr_setbit_la $lan_mac) > lan_mac=$(macaddr_add $lan_mac 1) > done > [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac >
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 1e199db5897f..44f1f0a7a5c1 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do lan_list="$lan_list $(basename $lan)" done ucidef_set_bridge_device switch -ucidef_set_interface_wan "$lan_list" -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 +ucidef_set_interface_lan "$lan_list" lan_mac="" -wan_mac="" label_mac="" case $board in *) - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) label_mac=$lan_mac ;; esac -lan_mac=$(macaddr_setbit_la $wan_mac) - ucidef_set_interface_macaddr "lan" $lan_mac -ucidef_set_interface_macaddr "wan" $wan_mac -ucidef_set_bridge_mac "$wan_mac" -ucidef_set_network_device_mac eth0 $wan_mac +ucidef_set_bridge_mac "$lan_mac" +ucidef_set_network_device_mac eth0 $lan_mac for lan in $lan_list; do ucidef_set_network_device_mac $lan $lan_mac + lan_mac=$(macaddr_setbit_la $lan_mac) lan_mac=$(macaddr_add $lan_mac 1) done [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
The default management interface should be easy to find for users doing "blind" installations without console access. There are already multiple examples in the forum of advanced early adopters having problems locating the management interface after installing OpenWrt. Requiring tagged VLAN configration to access the initial management interface creates unnecessary hassle at best. Errors on the other end are close to impossible to debug without console access, even for advanced users. Less advanced users might have problems with the concept of VLAN tagging. Limiting management access to a single arbitrary port among up to 52 possible LAN ports makes this even more difficult, for no reason at all. Users might have reasons to use a different port for management. And they might even have difficulties using the OpenWrt selected one. The port might be the wrong type for their management link (e.g copper instead of fibre). Or they might depend on PoE power from a device which they can't reconfigure. User expectations will be based on - OpenWrt defaults for other devices - stock firmware default for the device in question - common default behaviour of similar devices All 3 cases point to a static IP address accessible on the native VLAN of any LAN port. A switch does not have any WAN port. All ports are LAN ports. This changes the default network configuration in line with these expectations. Cc: John Crispin <john@phrozen.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> --- .../realtek/base-files/etc/board.d/02_network | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)