On Donnerstag, 10. Mai 2018 17:27:52 CEST Marek Lindner wrote:
Amongst other things, the MAC address of the VLAN interface itself has to be stored.
Without this change a VLAN and its infrastructure could be created while the interface MAC address is not stored without triggering any error, thus creating issues in other parts of the code.
Actually, the call to batadv_tt_local_add is using the address from the softif and not from the vlan interface. Just some remark because it let me think about the way the "-1" no-VLAN is added.
I would really like to know what exactly failed here. Does Leonardo's system really try to add the VLAN 0 before it is storing the info for the no-vlan (-1/BATADV_NO_FLAGS) and the mac address is "invalid" for VLAN 0? Or maybe both failed and he is just lucky that he got some non-permanent entries for this device on the non-vlan "vlan" - I am not sure about that.
On Donnerstag, 10. Mai 2018 18:24:50 CEST Antonio Quartulli wrote:
A failure of this function will cause a failure of the ndo_vlan_rx_add_vid() call made by the kernel/netlink API which in turns will reach the userspace.
Ideally any userspace application that attempted to create the VLAN should be in charge of re-attempting the creation again (I believe).
About your point 4, this should not be possible, because in case of error the bat0.X interface won't be created by the kernel at all. no?
Yes, this seems to be true for batadv_interface_add_vid. Still an open question for the batadv_hard_if_event (which cannot return an error to the caller). Would be interesting to know whether Leonardo's node fails for both calls or only for one (see above).
Kind regards, Sven