Fix link_netnsid: None != 0 when applying DSA interfaces #77

magic_rb commented 2025年01月22日 16:38:15 +01:00

See #65 for context.

While this fixes the issue for me, I don't know why its required as the 0 comes from the ifstate.yaml side even though I'm setting that field to null, which I would expect to be deserialized as None.

I haven't actually tried an apply yet, I don't want my flatmates to yell at me in case something breaks, but a check reports ok

See #65 for context. While this fixes the issue for me, I don't know why its required as the `0` comes from the `ifstate.yaml` side even though I'm setting that field to `null`, which I would expect to be deserialized as `None`. I haven't actually tried an apply yet, I don't want my flatmates to yell at me in case something breaks, but a `check` reports `ok`

magic_rb commented 2025年01月22日 22:10:14 +01:00

Flatmates left for a second so I took the liberty of running a apply and it worked, this PR is functional.

Flatmates left for a second so I took the liberty of running a `apply` and it worked, this PR is functional.

liske commented 2025年01月26日 22:54:55 +01:00

@magic_rb wrote in liske/ifstate#77 (comment):

See #65 for context.

While this fixes the issue for me, I don't know why its required as the 0 comes from the ifstate.yaml side even though I'm setting that field to null, which I would expect to be deserialized as None.

The kernel has no concept for netns names but netns IDs to use it as a handle in netlink. The _netns atttributes get transcipted into nsid so they match the nsid value in netlink: liske/ifstate@eef506e565/libifstate/link/base.py (L456-L457)

It seems there is a bug that link_netns is not correctly compared. So the fix is a little bit more complex...

@magic_rb wrote in https://codeberg.org/liske/ifstate/pulls/77#issue-953160: > See #65 for context. > > While this fixes the issue for me, I don't know why its required as the `0` comes from the `ifstate.yaml` side even though I'm setting that field to `null`, which I would expect to be deserialized as `None`. The kernel has no concept for netns names but netns IDs to use it as a handle in netlink. The `_netns` atttributes get transcipted into nsid so they match the nsid value in netlink: https://codeberg.org/liske/ifstate/src/commit/eef506e565f5eeaec1755dba7b7fdf8dce5c0ca6/libifstate/link/base.py#L456-L457 It seems there is a bug that `link_netns` is not correctly compared. So the fix is a little bit more complex...

liske commented 2025年01月26日 23:14:12 +01:00

It seems that I'm not able to debug this issue w/o access to a DSA interface 😢. I did several tests using link_netns on VLAN interfaces which shows no problems - but they are virtual and can be recreated.

It seems that I'm not able to debug this issue w/o access to a DSA interface 😢. I did several tests using `link_netns` on VLAN interfaces which shows no problems - but they are virtual and can be recreated.

liske commented 2025年01月27日 21:47:02 +01:00

@liske wrote in liske/ifstate#77 (comment):

It seems that I'm not able to debug this issue w/o access to a DSA interface 😢. I did several tests using link_netns on VLAN interfaces which shows no problems - but they are virtual and can be recreated.

Thankfully, @m4rc3l has given me access to a SoC router with DSA. Going to refactor the DSA implementation in ifstate... 😎

@liske wrote in https://codeberg.org/liske/ifstate/pulls/77#issuecomment-2653684: > It seems that I'm not able to debug this issue w/o access to a DSA interface :cry:. I did several tests using `link_netns` on VLAN interfaces which shows no problems - but they are virtual and can be recreated. Thankfully, @m4rc3l has given me access to a SoC router with DSA. Going to refactor the DSA implementation in ifstate... 😎

liske commented 2025年01月28日 22:20:10 +01:00

I've tested moving DSA port interfaces with the master branch (ifstate 2.x) and it worked like a charm. I did use the following config w/o using the dsa link kind:

parameters:ignore:ifname:# ignore OpenWRT management- eth0interfaces:- name:dsaaddresses:[]link:state:upkind:physicaladdress:70:a7:41:de:7f:68mtu:1504- name:eth1addresses:[]identify:phys_port_name:p1phys_switch_id:00:00:00:00link:state:upkind:physicaladdress:70:a7:41:de:7f:69- name:eth2addresses:[]identify:phys_port_name:p2phys_switch_id:00:00:00:00link:state:upkind:physicaladdress:70:a7:41:de:7f:6anamespaces:foo:interfaces:- name:eth3addresses:[]identify:phys_port_name:p3phys_switch_id:00:00:00:00link:state:upkind:physicaladdress:70:a7:41:de:7f:6bbar:interfaces:- name:eth4addresses:[]identify:phys_port_name:p4phys_switch_id:00:00:00:00link:state:upkind:physicaladdress:70:a7:41:de:7f:6c

Open problems observed for DSA setups:

• the port devices should not configured before the dsa main link - there is no dependency tracking, yet
• on the SoC I used for testing the dsa and the eth0 interface are looking identical, how we can distinguish them:

interfaces:- name:dsaidentify:perm_address:70:a7:41:de:7f:68parent_dev_name:1e100000.ethernetparent_dev_bus_name:platform- name:eth0identify:perm_address:70:a7:41:de:7f:68parent_dev_name:1e100000.ethernetparent_dev_bus_name:platform# ...

I've tested moving DSA port interfaces with the master branch (ifstate 2.x) and it worked like a charm. I did use the following config w/o using the `dsa` link kind: ```yaml parameters: ignore: ifname: # ignore OpenWRT management - eth0 interfaces: - name: dsa addresses: [] link: state: up kind: physical address: 70:a7:41:de:7f:68 mtu: 1504 - name: eth1 addresses: [] identify: phys_port_name: p1 phys_switch_id: 00:00:00:00 link: state: up kind: physical address: 70:a7:41:de:7f:69 - name: eth2 addresses: [] identify: phys_port_name: p2 phys_switch_id: 00:00:00:00 link: state: up kind: physical address: 70:a7:41:de:7f:6a namespaces: foo: interfaces: - name: eth3 addresses: [] identify: phys_port_name: p3 phys_switch_id: 00:00:00:00 link: state: up kind: physical address: 70:a7:41:de:7f:6b bar: interfaces: - name: eth4 addresses: [] identify: phys_port_name: p4 phys_switch_id: 00:00:00:00 link: state: up kind: physical address: 70:a7:41:de:7f:6c ``` Open problems observed for DSA setups: - [ ] the port devices should not configured before the `dsa` main link - there is no dependency tracking, yet - [x] on the SoC I used for testing the `dsa` and the `eth0` interface are looking identical, how we can distinguish them: ```yaml interfaces: - name: dsa identify: perm_address: 70:a7:41:de:7f:68 parent_dev_name: 1e100000.ethernet parent_dev_bus_name: platform - name: eth0 identify: perm_address: 70:a7:41:de:7f:68 parent_dev_name: 1e100000.ethernet parent_dev_bus_name: platform # ... ```

liske commented 2025年01月30日 15:33:13 +01:00

Ifstate 2 will provides the device tree reference of_node from sysfs (on platforms with device tree support):

interfaces:- name:dsa0addresses:[]link:state:upkind:physicalmtu:1504identify:of_node:base/ethernet@1e100000/mac@0- name:eth0addresses:- 192.0.2.1/24link:state:upkind:physicalidentify:of_node:base/ethernet@1e100000/mac@1- name:p1addresses:[]identify:of_node:base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@1link:state:upkind:physical- name:p3addresses:[]identify:of_node:base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@3link:state:upkind:physicalnamespaces:bar:interfaces:- name:p2addresses:[]identify:of_node:base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@2link:state:upkind:physicalfoo:interfaces:- name:p4addresses:[]identify:of_node:base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@4link:state:upkind:physical

Ifstate 2 will provides the device tree reference `of_node` from sysfs (on platforms with device tree support): ```yaml interfaces: - name: dsa0 addresses: [] link: state: up kind: physical mtu: 1504 identify: of_node: base/ethernet@1e100000/mac@0 - name: eth0 addresses: - 192.0.2.1/24 link: state: up kind: physical identify: of_node: base/ethernet@1e100000/mac@1 - name: p1 addresses: [] identify: of_node: base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@1 link: state: up kind: physical - name: p3 addresses: [] identify: of_node: base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@3 link: state: up kind: physical namespaces: bar: interfaces: - name: p2 addresses: [] identify: of_node: base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@2 link: state: up kind: physical foo: interfaces: - name: p4 addresses: [] identify: of_node: base/ethernet@1e100000/mdio-bus/switch@1f/ports/port@4 link: state: up kind: physical ```