EdgeRouter X: Kein Netz an Ethernetports #205

New Issue

fbl · 2022-01-14T23:48:28+01:00

fbl commented

2022-01-14 23:48:28 +01:00

Seit Firmware 20211224 steht bei EdgeRouter X kein Clientnetz vom Gateway mehr an den Clientports zur Verfügung. Konfiguration und Verbindung mit fdff::1 ist aber möglich. Die Ursache für dieses Verhalten ist unklar.

Ein manuelles Rekonfigurieren des master devices des switch0.1 (VLAN 1 auf CPU-Port der DSA Bridge) löst das Problem bis zum nächsten Neustart:

ip link set nomaster dev switch0.1
ip link set master br-client dev switch0.1

Seit Firmware 20211224 steht bei EdgeRouter X kein Clientnetz vom Gateway mehr an den Clientports zur Verfügung. Konfiguration und Verbindung mit fdff::1 ist aber möglich. Die Ursache für dieses Verhalten ist unklar. Ein manuelles Rekonfigurieren des master devices des switch0.1 (VLAN 1 auf CPU-Port der DSA Bridge) löst das Problem bis zum nächsten Neustart: ``` ip link set nomaster dev switch0.1 ip link set master br-client dev switch0.1 ```

fbl added the

bug

node

labels 2022-01-14 23:48:28 +01:00

fbl commented

2022-01-15 00:07:46 +01:00

Das Problem scheint auch mit einem aktuelleren Kernel (OpenWrt master, Linux 5.10.90) aufzutreten.

fbl commented

2022-02-24 01:20:44 +01:00

Es scheint sich hierbei um einen Kernelbug zu handeln, der bei Verwendung gestapelten Bridges auftritt, wobei die untere Bridge mit DSA Hardware Offloading arbeitet.

                   ┌────────────────────────────────────────┐
                   │                                        │
                   │                br-client               │
                   │                                        │
                   └─────┬────────────────────┬───────┬─────┘
                         │                    │       │
    ┌───────────┐  ┌─────┴─────┐              │       │
    │ switch0.2 │  │ switch0.1 │              │       │
    ├───────────┴──┴───────────┤              │       │
    │                          │          ┌───┴──┐  ┌─┴────┐
    │        switch0           │          │ w2ap │  │ bat0 │
    │                          │          └──────┘  └──────┘
    └───┬───────┬────────┬─────┘
        │       │        │
        │       │        │
    ┌───┴──┐ ┌──┴───┐ ┌──┴───┐
    │ eth0 │ │ eth1 │ │ eth2 │
    └──────┘ └──────┘ └──────┘

Interessant ist dabei das Flag skb->offload_fwd_mark, welches für auf dem CPU-Port der DSA Bridge eingehende Frames gesetzt wird, wenn dieses von einem Switch-User-Port kommt, der die Bridge offloaded. Dadurch wird in der DSA Bridge sichergestellt, dass selbiger Frame nicht erneut auf einen der Ports gesendet wird, der bereits in Hardware bedient wurde (e.g. broadcast, multicast, flooding, ..).

Problematisch wird es, wenn der Frame an die darüberliegende Bridge (br-client) weitergegeben wird. In diesem Fall scheint das offload_fwd_mark erhalten zu bleiben, löst dann einen WARN_ON_ONCE im br_handle_frame_finsh der oberen Bridge aus und wird dann wohl nicht mehr richtig auf die anderen Ports der oberen Bridge weitergeleitet.

Das resultierende Kernel Warning:

[   50.986809] ------------[ cut here ]------------
[   50.996147] WARNING: CPU: 0 PID: 9 at net/bridge/br_switchdev.c:46 br_handle_frame_finish+0xac/0x4ac
[   51.025200] Modules linked in: xt_connlimit nf_conncount batman_adv xt_state xt_helper xt_conntrack xt_connmark xt_connbytes xt_CT nf_conntrack ipt_REJECT ebtable_nat ebtable_filter ebtable_broute cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_bpf xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables ebtables ebt_vlan ebt_stp ebt_snat ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_ip6 ebt_ip ebt_dnat ebt_arpreply ebt_arp ebt_among ebt_802_3 compat arptable_filter arpt_mangle arp_tables sch_teql sch_sfq sch_red sch_prio sch_pie sch_multiq sch_gred sch_fq sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp act_simple act_pedit act_ipt act_csum libcrc32c sch_htb sch_hfsc cls_tcindex cls_route cls_matchall cls_fw cls_flow act_skbedit act_mirred
[   51.025510]  nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 tun leds_gpio act_police sch_tbf sch_ingress gpio_button_hotplug crc32c_generic
[   51.293410] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.4.163 #0
[   51.305742] Stack : 80680000 8007af80 80660000 8065b6d8 806a0000 8065b6a0 8065a71c 8fc5d934
[   51.322392]         807d0000 8fc3b0a8 8067ce03 805f0f10 00000000 00000001 8fc5d8d8 f6d24db4
[   51.339018]         00000000 00000000 80810000 00000000 00000030 00000108 35206465 312e342e
[   51.355645]         00000000 00000002 00000000 00047a22 00000000 806a0000 00000000 80522cc0
[   51.372272]         00000009 00000002 00000001 00000003 00000001 803152b0 00000000 807d0000
[   51.388898]         ...
[   51.393756] Call Trace:
[   51.398644] [<8000b60c>] show_stack+0x30/0x100
[   51.407507] [<805457f8>] dump_stack+0xa4/0xdc
[   51.416183] [<8002bfcc>] __warn+0xc0/0x10c
[   51.424328] [<8002c074>] warn_slowpath_fmt+0x5c/0xac
[   51.434207] [<80522cc0>] br_handle_frame_finish+0xac/0x4ac
[   51.445117] [<80523478>] br_handle_frame+0x3b8/0x4dc
[   51.454992] [<803d2b68>] __netif_receive_skb_core+0x65c/0xc3c
[   51.466420] [<803d316c>] __netif_receive_skb_one_core+0x24/0x50
[   51.478193] [<803d3264>] netif_receive_skb+0x34/0xb0
[   51.488066] [<80522ba4>] br_pass_frame_up+0x178/0x1e8
[   51.498112] [<80522dac>] br_handle_frame_finish+0x198/0x4ac
[   51.509194] [<80523478>] br_handle_frame+0x3b8/0x4dc
[   51.519066] [<803d2b68>] __netif_receive_skb_core+0x65c/0xc3c
[   51.530497] [<803d34dc>] __netif_receive_skb_list_core+0x84/0x238
[   51.542616] [<803d3840>] netif_receive_skb_list_internal+0x1b0/0x2b4
[   51.555255] [<803d3980>] gro_normal_list.part.177+0x20/0x40
[   51.566338] [<803d4890>] napi_complete_done+0x128/0x1d4
[   51.576744] [<80412f84>] gro_cell_poll+0x90/0xb8
[   51.585925] [<803d4c60>] __napi_poll+0x3c/0x10c
[   51.594932] [<803d4ed4>] net_rx_action+0x114/0x28c
[   51.604475] [<80563bf4>] __do_softirq+0x16c/0x334
[   51.613837] [<800302a0>] run_ksoftirqd+0x5c/0x70
[   51.623034] [<8004e648>] smpboot_thread_fn+0x188/0x1e0
[   51.633273] [<8004a7b0>] kthread+0x140/0x148
[   51.641765] [<800067d8>] ret_from_kernel_thread+0x14/0x1c
[   51.653186] ---[ end trace e633f58ea6c0c92c ]---

Siehe auch:

Es scheint sich hierbei um einen Kernelbug zu handeln, der bei Verwendung gestapelten Bridges auftritt, wobei die untere Bridge mit DSA Hardware Offloading arbeitet. ``` ┌────────────────────────────────────────┐ │ │ │ br-client │ │ │ └─────┬────────────────────┬───────┬─────┘ │ │ │ ┌───────────┐ ┌─────┴─────┐ │ │ │ switch0.2 │ │ switch0.1 │ │ │ ├───────────┴──┴───────────┤ │ │ │ │ ┌───┴──┐ ┌─┴────┐ │ switch0 │ │ w2ap │ │ bat0 │ │ │ └──────┘ └──────┘ └───┬───────┬────────┬─────┘ │ │ │ │ │ │ ┌───┴──┐ ┌──┴───┐ ┌──┴───┐ │ eth0 │ │ eth1 │ │ eth2 │ └──────┘ └──────┘ └──────┘ ``` Interessant ist dabei das Flag `skb->offload_fwd_mark`, welches für auf dem CPU-Port der DSA Bridge eingehende Frames [gesetzt](https://elixir.bootlin.com/linux/v5.4.181/source/net/dsa/tag_mtk.c#L109) wird, wenn dieses von einem Switch-User-Port kommt, der die Bridge offloaded. Dadurch wird in der DSA Bridge sichergestellt, dass selbiger Frame nicht erneut auf einen der Ports gesendet wird, der bereits in Hardware bedient wurde (e.g. broadcast, multicast, flooding, ..). Problematisch wird es, wenn der Frame an die darüberliegende Bridge (br-client) weitergegeben wird. In diesem Fall scheint das `offload_fwd_mark` erhalten zu bleiben, löst dann einen [WARN_ON_ONCE](https://elixir.bootlin.com/linux/v5.4.181/source/net/bridge/br_switchdev.c#L46) im [br_handle_frame_finsh](https://elixir.bootlin.com/linux/v5.4.180/source/net/bridge/br_input.c#L86) der oberen Bridge aus und wird dann wohl nicht mehr richtig auf die anderen Ports der oberen Bridge weitergeleitet. Das resultierende Kernel Warning: ``` [ 50.986809] ------------[ cut here ]------------ [ 50.996147] WARNING: CPU: 0 PID: 9 at net/bridge/br_switchdev.c:46 br_handle_frame_finish+0xac/0x4ac [ 51.025200] Modules linked in: xt_connlimit nf_conncount batman_adv xt_state xt_helper xt_conntrack xt_connmark xt_connbytes xt_CT nf_conntrack ipt_REJECT ebtable_nat ebtable_filter ebtable_broute cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_bpf xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables ebtables ebt_vlan ebt_stp ebt_snat ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_ip6 ebt_ip ebt_dnat ebt_arpreply ebt_arp ebt_among ebt_802_3 compat arptable_filter arpt_mangle arp_tables sch_teql sch_sfq sch_red sch_prio sch_pie sch_multiq sch_gred sch_fq sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp act_simple act_pedit act_ipt act_csum libcrc32c sch_htb sch_hfsc cls_tcindex cls_route cls_matchall cls_fw cls_flow act_skbedit act_mirred [ 51.025510] nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 tun leds_gpio act_police sch_tbf sch_ingress gpio_button_hotplug crc32c_generic [ 51.293410] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.4.163 #0 [ 51.305742] Stack : 80680000 8007af80 80660000 8065b6d8 806a0000 8065b6a0 8065a71c 8fc5d934 [ 51.322392] 807d0000 8fc3b0a8 8067ce03 805f0f10 00000000 00000001 8fc5d8d8 f6d24db4 [ 51.339018] 00000000 00000000 80810000 00000000 00000030 00000108 35206465 312e342e [ 51.355645] 00000000 00000002 00000000 00047a22 00000000 806a0000 00000000 80522cc0 [ 51.372272] 00000009 00000002 00000001 00000003 00000001 803152b0 00000000 807d0000 [ 51.388898] ... [ 51.393756] Call Trace: [ 51.398644] [<8000b60c>] show_stack+0x30/0x100 [ 51.407507] [<805457f8>] dump_stack+0xa4/0xdc [ 51.416183] [<8002bfcc>] __warn+0xc0/0x10c [ 51.424328] [<8002c074>] warn_slowpath_fmt+0x5c/0xac [ 51.434207] [<80522cc0>] br_handle_frame_finish+0xac/0x4ac [ 51.445117] [<80523478>] br_handle_frame+0x3b8/0x4dc [ 51.454992] [<803d2b68>] __netif_receive_skb_core+0x65c/0xc3c [ 51.466420] [<803d316c>] __netif_receive_skb_one_core+0x24/0x50 [ 51.478193] [<803d3264>] netif_receive_skb+0x34/0xb0 [ 51.488066] [<80522ba4>] br_pass_frame_up+0x178/0x1e8 [ 51.498112] [<80522dac>] br_handle_frame_finish+0x198/0x4ac [ 51.509194] [<80523478>] br_handle_frame+0x3b8/0x4dc [ 51.519066] [<803d2b68>] __netif_receive_skb_core+0x65c/0xc3c [ 51.530497] [<803d34dc>] __netif_receive_skb_list_core+0x84/0x238 [ 51.542616] [<803d3840>] netif_receive_skb_list_internal+0x1b0/0x2b4 [ 51.555255] [<803d3980>] gro_normal_list.part.177+0x20/0x40 [ 51.566338] [<803d4890>] napi_complete_done+0x128/0x1d4 [ 51.576744] [<80412f84>] gro_cell_poll+0x90/0xb8 [ 51.585925] [<803d4c60>] __napi_poll+0x3c/0x10c [ 51.594932] [<803d4ed4>] net_rx_action+0x114/0x28c [ 51.604475] [<80563bf4>] __do_softirq+0x16c/0x334 [ 51.613837] [<800302a0>] run_ksoftirqd+0x5c/0x70 [ 51.623034] [<8004e648>] smpboot_thread_fn+0x188/0x1e0 [ 51.633273] [<8004a7b0>] kthread+0x140/0x148 [ 51.641765] [<800067d8>] ret_from_kernel_thread+0x14/0x1c [ 51.653186] ---[ end trace e633f58ea6c0c92c ]--- ``` Siehe auch: - https://forum.openwrt.org/t/br-lan-not-working-on-mt7621-in-master-with-batman/77316/10 - https://github.com/torvalds/linux/commit/5e5502e012b8129e11be616acb0f9c34bc8f8adb - https://github.com/torvalds/linux/commit/bea7907837c57a0aaac009931eb14efb056dafab

fbl commented

2022-02-24 01:24:01 +01:00

Hierbei vielleicht Interessant: Gestapelte Bridges scheinen im Kernel nicht vorgesehen zu sein. Eine Bridge kann nicht direkt als Slave einer anderen Bridge verwendet werden: https://elixir.bootlin.com/linux/latest/source/net/bridge/br_if.c#L594

Unsere Konfiguration umgeht diesen Check, da zwischendrin noch ein VLAN Interface ist.

Hierbei vielleicht Interessant: Gestapelte Bridges scheinen im Kernel nicht vorgesehen zu sein. Eine Bridge kann nicht direkt als Slave einer anderen Bridge verwendet werden: https://elixir.bootlin.com/linux/latest/source/net/bridge/br_if.c#L594 Unsere Konfiguration umgeht diesen Check, da zwischendrin noch ein VLAN Interface ist.

fbl commented

2022-02-24 10:58:10 +01:00

Ein möglicher Workaround wäre das offload_fwd_mark zu entfernen, wenn ein Frame weiter nach oben gereicht wird, was in br_pass_frame_up passiert. Allerdings kenne ich mich hier zu wenig aus um einschätzen zu können, was das für Nebeneffekte haben könnte.

So könnte das aussehen: 52ae3e8d4b

Ein möglicher Workaround wäre das offload_fwd_mark zu entfernen, wenn ein Frame weiter nach oben gereicht wird, was in `br_pass_frame_up` passiert. Allerdings kenne ich mich hier zu wenig aus um einschätzen zu können, was das für Nebeneffekte haben könnte. So könnte das aussehen: https://git.freifunk-franken.de/fbl/firmware/commit/52ae3e8d4b8ffdf2b8422ab5b7d5163bf6a3b4ab

fbl referenced a pull request that will close this issue

2022-02-27 01:53:52 +01:00

build_patches: Add hack which fixes forwarding on a stacked bridge #211

fbl added this to the 20220405-beta milestone 2022-03-03 15:49:48 +01:00

fbl referenced this issue from a commit

2022-03-06 19:09:36 +01:00

build_patches: Add hack which fixes forwarding on a stacked bridge

fbl closed this issue

2022-03-06 19:09:36 +01:00

Sign in to join this conversation.