| Message ID | 20210523113058.2291-1-musashino.open@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | base-files: fix configuration generation of network if "bridge" exists | expand |
On 23.05.2021 13:30, INAGAKI Hiroshi wrote: > After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b > ("base-files: generate "device UCI type section for bridge"), the wrong > network configuration is generated for the devices that already have the > bridge device section for VLAN, such as the devices in realtek target. > > As a result, the bridge device by additional "device" section is > specified to the "ports" option in the "bridge-vlan" section and netifd > shuts down the switch and the ethernet when the network service started. > > --- generated config --- > > config device 'switch' > option name 'switch' > option type 'bridge' > option macaddr '34:76:c5:xx:xx:a8' > > config device > option name 'br-wan' > option type 'bridge' > list ports 'lan1' > ... (truncated) > list ports 'lan9' > > config bridge-vlan 'wan_vlan' > option device 'switch' > option vlan '1' > option ports 'br-wan' > > --- config end --- Thanks for bringing this up Hiroshi. I'm looking at existing code, at the commit be09c5a3cd65 ("base-files: add board.d support for bridge device") and I have some problems understanding those bridges. If you can, please kindly answer me two questions: 1. Why realtek treats lan ports as WAN? I mean this code: for lan in /sys/class/net/lan*; do lan_list="$lan_list $(basename $lan)" done ucidef_set_interface_wan "$lan_list" 2. What's up with the magic VLAN ID 100? I found this: ucidef_set_interface "lan" ifname "lan1n:t" protocol "static" vlan 100 Why "lan" logic interface requires VLAN ID 100? Finally: could you post your /etc/config/network from a working setup?
On 23.05.2021 23:06, Rafał Miłecki wrote: > I'm looking at existing code, at the commit be09c5a3cd65 ("base-files: > add board.d support for bridge device") and I have some problems > understanding those bridges. > > If you can, please kindly answer me two questions: Please also post your /etc/board.json kindly
Hi Rafał, thank you for your reply. On 2021/05/24 6:06, Rafał Miłecki wrote: > On 23.05.2021 13:30, INAGAKI Hiroshi wrote: >> After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b >> ("base-files: generate "device UCI type section for bridge"), the >> wrong >> network configuration is generated for the devices that already >> have the >> bridge device section for VLAN, such as the devices in realtek target. >> >> As a result, the bridge device by additional "device" section is >> specified to the "ports" option in the "bridge-vlan" section and >> netifd >> shuts down the switch and the ethernet when the network service >> started. >> >> --- generated config --- >> >> config device 'switch' >> option name 'switch' >> option type 'bridge' >> option macaddr '34:76:c5:xx:xx:a8' >> >> config device >> option name 'br-wan' >> option type 'bridge' >> list ports 'lan1' >> ... (truncated) >> list ports 'lan9' >> >> config bridge-vlan 'wan_vlan' >> option device 'switch' >> option vlan '1' >> option ports 'br-wan' >> >> --- config end --- > > Thanks for bringing this up Hiroshi. > > I'm looking at existing code, at the commit be09c5a3cd65 ("base-files: > add board.d support for bridge device") and I have some problems > understanding those bridges. > > If you can, please kindly answer me two questions: > > > 1. Why realtek treats lan ports as WAN? > > I mean this code: > > for lan in /sys/class/net/lan*; do > lan_list="$lan_list $(basename $lan)" > done > ucidef_set_interface_wan "$lan_list" > It's for "standard switching hub behavior", to disable DHCP and allow users to connect the device to other network, such as upstream. > > 2. What's up with the magic VLAN ID 100? > > I found this: > ucidef_set_interface "lan" ifname "lan1n:t" protocol "static" vlan 100 > > Why "lan" logic interface requires VLAN ID 100? > It's a "management VLAN". I haven't participated in the discussion that determines this specification, so I don't know any further details, sorry. There are some discussion about this in the forum[1] and there is a patch series to improve the default configuration[2]. [1]: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/134 [2]: https://patchwork.ozlabs.org/project/openwrt/list/?series=238725&submitter=&state=*&q=&archive=both&delegate= > > Finally: could you post your /etc/config/network from a working setup? /etc/config/network: -------- config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd34:7463:3cea::/48' config device 'switch' option name 'switch' option type 'bridge' option macaddr '34:76:c5:d9:f0:a8' config bridge-vlan 'wan_vlan' option device 'switch' option vlan '1' option ports 'lan1 lan10 lan11 lan12 lan13 lan14 lan15 lan16 lan17 lan18 lan19 lan2 lan20 lan21 lan22 lan23 lan24 lan3 lan4 lan5 lan6 lan7 lan8 lan9' config interface 'wan' option ifname 'switch.1' option proto 'dhcp' config device 'wan_switch_1_dev' option name 'switch.1' option macaddr '34:76:c5:d9:f0:a8' config interface 'wan6' option ifname 'switch.1' option proto 'dhcpv6' config bridge-vlan 'lan_vlan' option device 'switch' option vlan '100' option ports 'lan1:t' config interface 'lan' option ifname 'switch.100' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device 'lan_switch_100_dev' option name 'switch.100' option macaddr '36:76:c5:d9:f0:a8' -------- and /etc/board.json: -------- { "model": { "id": "iodata,bsh-g24mb", "name": "I-O DATA BSH-G24MB" }, "bridge": { "name": "switch", "macaddr": "34:76:c5:d9:f0:a8" }, "network": { "wan": { "ports": [ "lan1", "lan10", "lan11", "lan12", "lan13", "lan14", "lan15", "lan16", "lan17", "lan18", "lan19", "lan2", "lan20", "lan21", "lan22", "lan23", "lan24", "lan3", "lan4", "lan5", "lan6", "lan7", "lan8", "lan9" ], "protocol": "dhcp", "macaddr": "34:76:c5:d9:f0:a8" }, "lan": { "ifname": "lan1:t", "protocol": "static", "vlan": "100", "macaddr": "36:76:c5:d9:f0:a8" } }, "network-device": { "eth0": { "macaddr": "34:76:c5:d9:f0:a8" }, "lan1": { "macaddr": "36:76:c5:d9:f0:a8" }, "lan10": { "macaddr": "36:76:c5:d9:f0:a9" }, "lan11": { "macaddr": "36:76:c5:d9:f0:aa" }, "lan12": { "macaddr": "36:76:c5:d9:f0:ab" }, "lan13": { "macaddr": "36:76:c5:d9:f0:ac" }, "lan14": { "macaddr": "36:76:c5:d9:f0:ad" }, "lan15": { "macaddr": "36:76:c5:d9:f0:ae" }, "lan16": { "macaddr": "36:76:c5:d9:f0:af" }, "lan17": { "macaddr": "36:76:c5:d9:f0:b0" }, "lan18": { "macaddr": "36:76:c5:d9:f0:b1" }, "lan19": { "macaddr": "36:76:c5:d9:f0:b2" }, "lan2": { "macaddr": "36:76:c5:d9:f0:b3" }, "lan20": { "macaddr": "36:76:c5:d9:f0:b4" }, "lan21": { "macaddr": "36:76:c5:d9:f0:b5" }, "lan22": { "macaddr": "36:76:c5:d9:f0:b6" }, "lan23": { "macaddr": "36:76:c5:d9:f0:b7" }, "lan24": { "macaddr": "36:76:c5:d9:f0:b8" }, "lan3": { "macaddr": "36:76:c5:d9:f0:b9" }, "lan4": { "macaddr": "36:76:c5:d9:f0:ba" }, "lan5": { "macaddr": "36:76:c5:d9:f0:bb" }, "lan6": { "macaddr": "36:76:c5:d9:f0:bc" }, "lan7": { "macaddr": "36:76:c5:d9:f0:bd" }, "lan8": { "macaddr": "36:76:c5:d9:f0:be" }, "lan9": { "macaddr": "36:76:c5:d9:f0:bf" } } } -------- Above two files are from I-O DATA BSH-G24MB (RTL8382M, 24 ports), which is WIP device. But there should be no special parts. Regards, Hiroshi
On 23.05.2021 13:30, INAGAKI Hiroshi wrote: > After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b > ("base-files: generate "device UCI type section for bridge"), the wrong > network configuration is generated for the devices that already have the > bridge device section for VLAN, such as the devices in realtek target. > > As a result, the bridge device by additional "device" section is > specified to the "ports" option in the "bridge-vlan" section and netifd > shuts down the switch and the ethernet when the network service started. Applied with a small variable name change for the generate_bridge_vlan
diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate index efcd734242..2d20ead152 100755 --- a/package/base-files/files/bin/config_generate +++ b/package/base-files/files/bin/config_generate @@ -109,7 +109,7 @@ generate_network() { ports="$ifname" } - [ -n "$ports" ] && { + [ -n "$ports" ] && [ -z "$bridge" ] && { uci -q batch <<-EOF add network device set network.@device[-1].name='br-$1' @@ -121,6 +121,7 @@ generate_network() { } [ -n "$bridge" ] && { + [ -n "$ports" ] && ifname="$ports" if [ -z "$vlan" ]; then bridge_vlan_id=$((bridge_vlan_id + 1)) vlan=$bridge_vlan_id
After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b ("base-files: generate "device UCI type section for bridge"), the wrong network configuration is generated for the devices that already have the bridge device section for VLAN, such as the devices in realtek target. As a result, the bridge device by additional "device" section is specified to the "ports" option in the "bridge-vlan" section and netifd shuts down the switch and the ethernet when the network service started. --- generated config --- config device 'switch' option name 'switch' option type 'bridge' option macaddr '34:76:c5:xx:xx:a8' config device option name 'br-wan' option type 'bridge' list ports 'lan1' ... (truncated) list ports 'lan9' config bridge-vlan 'wan_vlan' option device 'switch' option vlan '1' option ports 'br-wan' --- config end --- --- log --- root@OpenWrt:/# /etc/init.d/network start root@OpenWrt:/# [ 159.752015] Using MAC 00003476c5d9f0a8 [ 159.756993] RESETTING 8380, CPU_PORT 28 [ 159.961309] rtl838x-eth bb00a300.ethernet eth0: configuring for fixed/internal link mode [ 159.970338] In rtl838x_mac_config, mode 1 [ 159.975095] device eth0 left promiscuous mode [ 159.980356] In rtl838x_mac_config, mode 1 [ 159.984896] rtl838x-eth bb00a300.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 160.005785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 160.283111] device eth0 entered promiscuous mode [ 160.288322] rtl83xx-switch switch@bb000000 lan1: configuring for phy/qsgmii link mode [ 160.308034] 8021q: adding VLAN 0 to HW filter on device lan1 [ 160.340250] br-wan: port 1(lan1) entered blocking state [ 160.346104] br-wan: port 1(lan1) entered disabled state [ 160.352724] device lan1 entered promiscuous mode ... (truncated) [ 162.123430] rtl83xx-switch switch@bb000000 lan9: configuring for phy/internal link mode [ 162.143153] 8021q: adding VLAN 0 to HW filter on device lan9 [ 162.175597] br-wan: port 24(lan9) entered blocking state [ 162.181669] br-wan: port 24(lan9) entered disabled state [ 162.188327] device lan9 entered promiscuous mode [ 162.209932] device lan1 left promiscuous mode [ 162.215216] br-wan: port 1(lan1) entered disabled state ... (truncated) [ 162.827566] device lan9 left promiscuous mode [ 162.832938] br-wan: port 24(lan9) entered disabled state [ 162.844314] in rtl838x_eth_stop [ 162.847955] rtl838x-eth bb00a300.ethernet eth0: Link is Down [ 163.754337] Using MAC 00003476c5d9f0a8 [ 163.779357] RESETTING 8380, CPU_PORT 28 [ 163.983666] rtl838x-eth bb00a300.ethernet eth0: configuring for fixed/internal link mode [ 163.992695] In rtl838x_mac_config, mode 1 [ 163.997434] device eth0 left promiscuous mode [ 164.002670] In rtl838x_mac_config, mode 1 [ 164.007209] rtl838x-eth bb00a300.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 164.044261] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 164.534390] device eth0 entered promiscuous mode [ 164.539704] rtl83xx-switch switch@bb000000 lan1: configuring for phy/qsgmii link mode [ 164.559826] 8021q: adding VLAN 0 to HW filter on device lan1 [ 164.592421] br-wan: port 1(lan1) entered blocking state [ 164.598270] br-wan: port 1(lan1) entered disabled state [ 164.604910] device lan1 entered promiscuous mode ... (truncated) [ 166.601998] rtl83xx-switch switch@bb000000 lan9: configuring for phy/internal link mode [ 166.622328] 8021q: adding VLAN 0 to HW filter on device lan9 [ 166.653459] br-wan: port 24(lan9) entered blocking state [ 166.659530] br-wan: port 24(lan9) entered disabled state [ 166.666195] device lan9 entered promiscuous mode [ 166.688759] device lan1 left promiscuous mode [ 166.694131] br-wan: port 1(lan1) entered disabled state ... (truncated) [ 167.310359] device lan9 left promiscuous mode [ 167.315636] br-wan: port 24(lan9) entered disabled state [ 167.326988] in rtl838x_eth_stop [ 167.331006] rtl838x-eth bb00a300.ethernet eth0: Link is Down --- log end --- root@OpenWrt:/# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:448 errors:0 dropped:0 overruns:0 frame:0 TX packets:448 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:34944 (34.1 KiB) TX bytes:34944 (34.1 KiB) root@OpenWrt:/# This patch fixes this issue. Fixes: 43fc720657 ("base-files: generate "device" UCI type section for bridge") Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com> --- package/base-files/files/bin/config_generate | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)