Hello BIRDs! And hello Ondřej.
As a part of my thesis I've been toying with EVPN in BIRD on the oz-evpn branch and I managed to run into a segfault
when I add ethernet interface into a bridge. I am using a couple fedora 42 VMs and I have this running in pnetlab
but I hope virtualization is not a problem here.
I narrowed it down to this very minimal bird.conf:
```
log stderr all;log "/var/log/bird.log" all;
router id 10.10.10.3;
ipv4 table master4;
protocol device {
scan time 10;
}
```
```
[root@debug ~]# ip link add name br0 type bridge vlan_filtering 1[root@debug ~]# ip link add name vxlan0 type vxlan id 100 local 10.10.10.3 dstport 4789 nolearning
[root@debug ~]# ip link set vxlan0 master br0
[root@debug ~]# bridge link set dev vxlan0 learning off [root@debug ~]# ip link set dev eth1 master br0[root@debug ~]# bird -f
Segmentation fault (core dumped)
```
I spent some time debugging this, although I am not too familiar with netlink I hope my description will be useful :)
Segfault happens in "
sysdep/linux/netlink.c" because
this strcmp on line 1037 gets a NULL in the first parameter "kind" which seems
expected based on that "kind" is set conditionally. Looking at the
array li and its size == 3 and into the "nl_parse_attrs" function
I understand that you are only trying to get the first three (?) IFLA_INFO_x items which are
IFLA_INFO_UNSPEC, IFLA_INFO_KIND, IFLA_INFO_DATA.
The first "a->rta_type" that I see on my eth1 interface has a value 4 which is the IFLA_INFO_SLAVE_KIND
and reading the data from it I indeed get "bridge" as a result.
All of these get skipped by the first continue so "nl_parse_attrs" does not return anything useful. Is it possible that netlink is just not sending the data you need?
Bug most likely comes from 66edbe43 commit which is specific to the oz-evpn branch so other non-evpn branches are unaffected. I'm also attaching a patch which fixes it for me and I can have EVPN up and running.
Thank you for your time and I hope you'll have a great day!
Tomáš