Re: [PATCH] babel: Add support for dual-stack v4/v6 operation
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Mon, May 29, 2017 at 10:24:57PM +0200, Toke Høiland-Jørgensen wrote:
This adds support for dual-stack v4/v6 operation to the Babel protocol. Routing messages will be exchanged over IPv6, but IPv4 routes can be carried in the messages being exchanged. This matches how the reference Babel implementation (babeld) works.
Hi
Thanks for the patch. I have one major remark - If i undestand it correctly, both IPv4 and IPv6 FIBs are always created and used, but IPv4 and IPv6 channels may or may not be configured and created. Although when a channel is not configured, Babel would not propagate routes (as they have to be imported to nest and back exported to Babel to be propagated outside), it is still strange to keep received routes.
Yeah, that's true I guess. I'll fix that.
Also channel_is_active() is called but channel may not even exist?
Ah, proto_configure_channel can leave the channel var entirely unset? I was assuming it was just leaving it in place but inactive. Can I just check for NULL, then? -Toke
On Tue, May 30, 2017 at 01:37:56PM +0200, Toke Høiland-Jørgensen wrote:
Also channel_is_active() is called but channel may not even exist?
Ah, proto_configure_channel can leave the channel var entirely unset?
Yes, it could add/remove/reconfigure the channel, based on whether there is or is not the configuration and the old channel.
was assuming it was just leaving it in place but inactive. Can I just check for NULL, then?
Yes, that should be enough, as all channels goes up together with the protocol and channel cannot be deconfigured when up (protocol will be restarted in that case). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Tue, May 30, 2017 at 01:48:10PM +0200, Ondrej Zajicek wrote:
On Tue, May 30, 2017 at 01:37:56PM +0200, Toke Høiland-Jørgensen wrote:
Also channel_is_active() is called but channel may not even exist?
Ah, proto_configure_channel can leave the channel var entirely unset?
Yes, it could add/remove/reconfigure the channel, based on whether there is or is not the configuration and the old channel.
was assuming it was just leaving it in place but inactive. Can I just check for NULL, then?
Yes, that should be enough, as all channels goes up together with the protocol and channel cannot be deconfigured when up (protocol will be restarted in that case).
Well i checked that one more time and it is possible that channel is added after the protocol is up. So you should check that channel is non-NULL and in state CS_UP, which is something slightly different than what is checked by channel_is_active(). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Ondrej Zajicek -
Toke Høiland-Jørgensen