RE: [PATCH] IPv4 over IPv6 nexthop support on FreeBSD
Hi Ondrej, Could you please consider merging IPv4 over IPv6 support for FreeBSD Netlink as well? It seems like the patch slipped through the cracks :-( Sorry for not replying to the thread, it got purged by my email client. The original message: https://bird.network.cz/pipermail/bird-users/2023-April/016857.html /Alexander
On Wed, Jun 14, 2023 at 11:14:55AM +0100, Alexander Chernikov wrote:
Hi Ondrej,
Could you please consider merging IPv4 over IPv6 support for FreeBSD Netlink as well? It seems like the patch slipped through the cracks :-(
Hi I did not find any other patch (for Netlink) in that thread, but i could try to hack it myself. -- 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 14 Jun 2023, at 13:41, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Wed, Jun 14, 2023 at 11:14:55AM +0100, Alexander Chernikov wrote:
Hi Ondrej,
Could you please consider merging IPv4 over IPv6 support for FreeBSD Netlink as well? It seems like the patch slipped through the cracks :-(
Hi
I did not find any other patch (for Netlink) in that thread, but i could try to hack it myself. Posted as https://people.freebsd.org/~melifaro/bird_rfc5549_netlink.diff Please note that the authorship should go to "Luiz Amaral<email@luiz.eng.br <http://luiz.eng.br/>>"
-- 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 Wed, Jun 14, 2023 at 02:54:49PM +0200, Luiz Amaral wrote:
Hello,
I did not find any other patch (for Netlink) in that thread, but i could try to hack it myself.
Here is the patch as an attachment.
Merged. It breaks build for some very old Linux systems (e.g. Debian 8, CentOS 7), as HAVE_MPLS_KERNEL also checks for struct rtvia existence, but these systems have obsolete/unsupported kernel versions anyways. There is a question how handle feature divergence (primarily divergence in which structures and enum values are defined for compile-time) in Netlink between Linux and FreeBSD. I would prefer to not have autoconf test for each such feature. For example we could probably remove HAVE_MPLS_KERNEL altogether just for Linux (as the check is unnecessary for non-obsolete kernels, but i am not sure about FreeBSD headers). -- 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 15 Jun 2023, at 15:33, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Wed, Jun 14, 2023 at 02:54:49PM +0200, Luiz Amaral wrote:
Hello,
I did not find any other patch (for Netlink) in that thread, but i could try to hack it myself.
Here is the patch as an attachment.
Merged. It breaks build for some very old Linux systems (e.g. Debian 8, CentOS 7), as HAVE_MPLS_KERNEL also checks for struct rtvia existence, but these systems have obsolete/unsupported kernel versions anyways.
There is a question how handle feature divergence (primarily divergence in which structures and enum values are defined for compile-time) in Netlink between Linux and FreeBSD. I would prefer to not have autoconf test for each such feature. For example we could probably remove HAVE_MPLS_KERNEL altogether just for Linux (as the check is unnecessary for non-obsolete kernels, but i am not sure about FreeBSD headers). I understand the pain. To add to this, the feature existence doesn’t always mean the full feature parity. For example, current nexthop/nexthop group implementation doesn’t have the support for adding resilient nexthop groups.
The only solution I could think of is adding a bit of ugliness to the headers and have the defines for each enum item (for commands) and a separate define for the structures / small enums. Then the features could be defined in the sysdep/<flavor>/netlink-sys.h . What do you think?
-- 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 Mon, Jun 19, 2023 at 10:32:45AM +0100, Alexander Chernikov wrote:
There is a question how handle feature divergence (primarily divergence in which structures and enum values are defined for compile-time) in Netlink between Linux and FreeBSD. I would prefer to not have autoconf test for each such feature. For example we could probably remove HAVE_MPLS_KERNEL altogether just for Linux (as the check is unnecessary for non-obsolete kernels, but i am not sure about FreeBSD headers).
I understand the pain. To add to this, the feature existence doesn’t always mean the full feature parity. For example, current nexthop/nexthop group implementation doesn’t have the support for adding resilient nexthop groups.
The only solution I could think of is adding a bit of ugliness to the headers and have the defines for each enum item (for commands) and a separate define for the structures / small enums. Then the features could be defined in the sysdep/<flavor>/netlink-sys.h .
What do you think?
I think it would be nice. First, i thought it does not really help considering they are not in Linux kernel headers and even when added, we would still need to support older ones, but we can just define them for Linux in sysdep/linux/netlink-sys.h Strange is that some enums in Linux rtnetlink headers have these (e.g. RTM_* values), while others do not * (e.g. RTN_* values): enum { RTM_BASE = 16, #define RTM_BASE RTM_BASE RTM_NEWLINK = 16, #define RTM_NEWLINK RTM_NEWLINK RTM_DELLINK, #define RTM_DELLINK RTM_DELLINK RTM_GETLINK, #define RTM_GETLINK RTM_GETLINK RTM_SETLINK, #define RTM_SETLINK RTM_SETLINK ... enum { RTN_UNSPEC, RTN_UNICAST, /* Gateway or direct route */ RTN_LOCAL, /* Accept locally */ RTN_BROADCAST, /* Accept locally as broadcast, send as broadcast */ ... (not sure if there is any system in that, or just usual ad-hoc inconsistencies) -- 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 (3)
-
Alexander Chernikov -
Luiz Amaral -
Ondrej Zajicek