wip-netlink

wip-netlink

[Gábor Boskovits]

Hello guix,

I've pushed a branch with some preliminary work on the netlink wrapper
for guix, so that
we can have ipv6 static network configuration, and a bunch of other
goodies, including hopefully container networking.
This is in quite an early stage, I was mostly doing some research, and
tried to define the data structures needed.
Wdyt?

Best regards,
g_bor

Re: wip-netlink

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <boskovits@gmail.com> skribis:

> I've pushed a branch with some preliminary work on the netlink wrapper
> for guix, so that
> we can have ipv6 static network configuration, and a bunch of other
> goodies, including hopefully container networking.
> This is in quite an early stage, I was mostly doing some research, and
> tried to define the data structures needed.
> Wdyt?

I think it looks like a great start!  Then you’ll need to provide
bindings to ‘sendmsg’ to actually make use of the data structures you
defined (Guile itself already provides ‘sendmsg’ but it’s too high-level
to be usable with netlink sockets, AFAICS.)

We can chat on IRC if you have any questions or comments.

Thank you for working on it!

Ludo’.

Re: wip-netlink

[Ludovic Courtès]

Hi there!

Gábor Boskovits <boskovits@gmail.com> skribis:

> I've pushed a branch with some preliminary work on the netlink wrapper
> for guix, so that
> we can have ipv6 static network configuration, and a bunch of other
> goodies, including hopefully container networking.
> This is in quite an early stage, I was mostly doing some research, and
> tried to define the data structures needed.

Did you have a chance to make further progress on this front?

Thank you!

Ludo’.

Re: wip-netlink

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. ápr. 8., H, 17:20):
>
> Hi there!
>
> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > I've pushed a branch with some preliminary work on the netlink wrapper
> > for guix, so that
> > we can have ipv6 static network configuration, and a bunch of other
> > goodies, including hopefully container networking.
> > This is in quite an early stage, I was mostly doing some research, and
> > tried to define the data structures needed.
>
> Did you have a chance to make further progress on this front?
>

Yes, now I do. I was not well, and had to skip a whole week of work,
then I got overwhelmed when
I got back. I will start working on this again soon. Help is
appreciated however, so if anyone is willing
to have a look into this, that would be great. I feel I have most of
the data structures in place,
I will finish up the defines, which are not completed (I will have to
hunt the headers fo the proper sizes),
and I am thinking about creating a little abstraction on top of the
netlinkmsg, so that we can add attributes
with the proper 4 byte alignment required by netlink. Then I will
create a wrapper for the syscalls. After that
however we should discuss how to actually finish this up, I belive
that this could be done in two steps,
at first expoose the functionality for testing, without a reliable
command transfer, then add in the acknowledge
handling later. Wdyt?

> Thank you!
>
> Ludo’.

Best regards,
g_bor

Re: wip-netlink

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <boskovits@gmail.com> skribis:

> Yes, now I do. I was not well, and had to skip a whole week of work,
> then I got overwhelmed when
> I got back.

I’m sorry to hear that, I hope you’re feeling better now.

> I will start working on this again soon. Help is appreciated however,
> so if anyone is willing to have a look into this, that would be
> great. I feel I have most of the data structures in place, I will
> finish up the defines, which are not completed (I will have to hunt
> the headers fo the proper sizes), and I am thinking about creating a
> little abstraction on top of the netlinkmsg, so that we can add
> attributes with the proper 4 byte alignment required by netlink. Then
> I will create a wrapper for the syscalls. After that however we should
> discuss how to actually finish this up, I belive that this could be
> done in two steps, at first expoose the functionality for testing,
> without a reliable command transfer, then add in the acknowledge
> handling later. Wdyt?

That sounds promising.  I don’t have an opinion on how to move forward
in terms of code since I’m not sufficiently familiar with netlink.

With respect to 1.0, I wonder whether we should start a backup plan
where we simply call out to ‘ip’.  That way, we can develop the netlink
API without pressure and start using it instead of ‘ip’ when it’s ready.

We also need to think about adjustments to be made to
‘static-networking-service’ so that it covers important use cases.

What do people think?

If you’ve ever experienced the shortcomings of
‘static-networking-service’ and had to work around it, please share the
interface that you’d like to see!

Thanks,
Ludo’.

Re: wip-netlink

[Marius Bakke]

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

Ludovic Courtès <ludo@gnu.org> writes:

> If you’ve ever experienced the shortcomings of
> ‘static-networking-service’ and had to work around it, please share the
> interface that you’d like to see!

Hey, that's me!

I *think* what I want is control over network interfaces.  Something
along the lines of

(service network-interface-service-type
  "eth0"
  (network-interface-configuration
    (dhcp? #f)
    (ipv4 '("10.1.1.1/24" "172.16.30.4/22"))
    (ipv6 '(...))
    (routes4 '(("default" . "10.1.1.254")))
    (routes6 '(...))
    (requirement '(vswitchd))))

Ideally, this service would extend "network-route-service-type" and
"network-address-service-type" so that one could compose configurations
from other services too.  E.g. a custom VPN service that extends
network-route-service-type.

Food for thought...  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: wip-netlink

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> If you’ve ever experienced the shortcomings of
>> ‘static-networking-service’ and had to work around it, please share the
>> interface that you’d like to see!
>
> Hey, that's me!

Yay!

> I *think* what I want is control over network interfaces.  Something
> along the lines of
>
> (service network-interface-service-type
>   "eth0"
>   (network-interface-configuration
>     (dhcp? #f)
>     (ipv4 '("10.1.1.1/24" "172.16.30.4/22"))
>     (ipv6 '(...))
>     (routes4 '(("default" . "10.1.1.254")))
>     (routes6 '(...))
>     (requirement '(vswitchd))))
>
> Ideally, this service would extend "network-route-service-type" and
> "network-address-service-type" so that one could compose configurations
> from other services too.  E.g. a custom VPN service that extends
> network-route-service-type.

Interesting!  That sounds like a plan.

If there’s a separate “routes” service, perhaps the ‘routes4’ and
‘routes6’ fields could even be removed from
‘network-interface-configuration’?

We’d also need a ‘name-servers’ service I guess.

Also, in your example, ‘ipv4’ specifies both the IP and the netmask,
right?  Perhaps we should separate the two?

Thanks,
Ludo’.