l3: remove br-client, run radvd on every client interface

[tcatm]

We'd like to remove br-client and also change the local-node feature a little:

• Client interfaces shouldn't be bridged anymore.
• Every client interface should have it's own local-node device (same IP and MAC).
• uradvd must run on all these local-node devices.
• l3roamd must be notified about new client interfaces.

[christf]

translation from irc-discussion with tcatm: "it probably is best to duplicate the macvlan for br-client on all client interfaces. lateron uradvd may be startet on these"

[neocturne]

Do we really need the macvlan? I don't see any reason to have interface-specific MAC addresses on client interfaces, so we could just set the MAC address of all client interfaces to the local-node address.

[tcatm]

macvlan is not strictly required. If we have other means to ensure the anycast MAC works on these interfaces that's fine. I don't know if this works with wifi ap interfaces on Ralink.

[belzebub40k]

Maybe its a good idea to reduce the use of virtual interfaces like macvlan if possible as they can cause errors as described in #680 . The crash is causes by platform independent code and can potentially happen on any device.

[neocturne]

AP mode wifi is no problem, as such a MAC could as well lie behind a bridge, so the WLAN adapter can never filter any packets towards the master.

[christf]

after some more discussion on irc with tcat we seem to have reached the following concept:

• macvlan is not used
• at first client-interfaces are defined in site.conf
• the client interfaces are put in a similar structure like gluon.mesh (gluon.client?) in pr747
• client interfaces are assigned the same mac and the same ipv6 address
• uradvd will be executed on all of them (the init script will handle starting uradvod on all client interfaces)
• l3roamd's init script will work out the client interfaces and hand them over to l3roamd

[christf]

@NeoRaider do we still need this now that your macvlan/veth-work is merged? l3roamd still needs work to detect macs on bridges but I consider this a missing feature in l3roamd instead of wanting to shape the environment around l3roamd.

[neocturne]

We don't need it, but it is still something we might want to consider in the future.

[mweinelt]

@NeoRaider Are we still considering this in any way?

[neocturne]

@mweinelt I really don't know. It might be something to experiment on in the future, but I don't have any concrete plans regarding this matter.