Re: [B.A.T.M.A.N.] [RFC maint] batman-adv: fix adding VLANs with partial state

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]