Discussion:
[RFT] DHCPv4 support in networkd
(too old to reply)
Tom Gundersen
2014-01-01 15:41:39 UTC
Permalink
Hi guys,

I just pushed the last couple of patches to enable DHCPv4 support in
networkd[0]. Testing and feedback would be greatly appreciated.

It is still very basic, but I'm personally using it full-time on my
laptop (replacing NetworkManager/ConnMan), so it should be complete
enough to at least start testing. If you want to use it with wifi (as
I'm doing), just (e.g.) enable wpa_supplicant-***@.service for
your device and configure that for your networks manually.

Cheers,

Tom

[0]: <http://cgit.freedesktop.org/systemd/systemd/commit/?id=f5be560181d092c5f52a2b819aedcd48220f36ab>
Kay Sievers
2014-01-02 02:43:49 UTC
Permalink
Post by Tom Gundersen
I just pushed the last couple of patches to enable DHCPv4 support in
networkd[0]. Testing and feedback would be greatly appreciated.
It is still very basic, but I'm personally using it full-time on my
laptop (replacing NetworkManager/ConnMan), so it should be complete
enough to at least start testing. If you want to use it with wifi (as
your device and configure that for your networks manually.
I have a wired e1000e connection to a DSL router.

I removed NetworkManager and added that:

$ cat /etc/systemd/network/wired.network
[Match]
Name=enp0s25

[Network]
DHCP=yes

$ journalctl -b -o short-monotonic -u systemd-networkd.service
[ 1.318123] lon systemd[1]: Started Network Service.
[ 3.073097] lon systemd-networkd[205]: Network '(null)' being
applied to link 'enp0s25'
[ 3.301739] lon systemd-networkd[205]: Interface 'enp0s25' is up
[ 4.815708] lon systemd-networkd[205]: Interface 'enp0s25' is connected
[ 8.943769] lon systemd-networkd[205]: Received config over DHCPv4
[ 8.952326] lon systemd-networkd[205]: Addresses set for link 'enp0s25'
[ 8.952614] lon systemd-networkd[205]: Routes set for link 'enp0s25'
[ 8.952957] lon systemd-networkd[205]: Link 'enp0s25' configured

Any idea why it takes 4 seconds? Do you have any numbers for your setup?

And there is a "(null)" in the log output.

Kay
Tom Gundersen
2014-01-02 10:16:00 UTC
Permalink
Post by Kay Sievers
Post by Tom Gundersen
I just pushed the last couple of patches to enable DHCPv4 support in
networkd[0]. Testing and feedback would be greatly appreciated.
It is still very basic, but I'm personally using it full-time on my
laptop (replacing NetworkManager/ConnMan), so it should be complete
enough to at least start testing. If you want to use it with wifi (as
your device and configure that for your networks manually.
I have a wired e1000e connection to a DSL router.
$ cat /etc/systemd/network/wired.network
[Match]
Name=enp0s25
[Network]
DHCP=yes
$ journalctl -b -o short-monotonic -u systemd-networkd.service
[ 1.318123] lon systemd[1]: Started Network Service.
[ 3.073097] lon systemd-networkd[205]: Network '(null)' being
applied to link 'enp0s25'
[ 3.301739] lon systemd-networkd[205]: Interface 'enp0s25' is up
[ 4.815708] lon systemd-networkd[205]: Interface 'enp0s25' is connected
[ 8.943769] lon systemd-networkd[205]: Received config over DHCPv4
[ 8.952326] lon systemd-networkd[205]: Addresses set for link 'enp0s25'
[ 8.952614] lon systemd-networkd[205]: Routes set for link 'enp0s25'
[ 8.952957] lon systemd-networkd[205]: Link 'enp0s25' configured
Any idea why it takes 4 seconds? Do you have any numbers for your setup?
Depending on the network I'm connecting to it takes between 200 ms and
5 seconds (the numbers seem to be stable for any given network). As
far as I have been able to tell we are not doing anything wrong (i.e.,
it simply takes the dhcp server that long to send us a reply). It has
been some time since I tried with debug output from the dhcp library
though, so should re-test to verify.
Post by Kay Sievers
And there is a "(null)" in the log output.
Ah, that should be changed (it tries to print the Description).

-t
Holger Schurig
2014-01-02 11:56:23 UTC
Permalink
AFAIK Mac OSX does a trick here: it uses the last IP (still in the old
lease file) and immediately configures the network with that. *) Then
it does the DHCP, asking for the same IP. If the IP returned was
changed, it will re-change. But usually it's the same IP address, and
therefore on this OS DHCP doesn't take longer than static IP.

Strictly speaking the DHCP protocol is not violated that way: DHCP
itself works as expected, e.g. the DHCP packets are following the RFC.
And ip clients should copy with changed IP addresses anyway, because
DHCP can assign any IP address at renogiation time.


*) it might do an RARP to find out if the IP is available ...
Tom Gundersen
2014-01-02 12:55:52 UTC
Permalink
Post by Holger Schurig
AFAIK Mac OSX does a trick here
Yeah, and we should do the same: <http://tools.ietf.org/search/rfc4436>.

Cheers,

Tom
Reindl Harald
2014-01-02 14:52:39 UTC
Permalink
Post by Tom Gundersen
Post by Holger Schurig
AFAIK Mac OSX does a trick here
Yeah, and we should do the same: <http://tools.ietf.org/search/rfc4436>
because this explains why i sometimes see firewall logs in
the company network where all severs are blocking private
ranges as spoofed address i would be thankful not starting
the same odd behavior with linux clients

this is also really funny if it leads calling your ISP
names because it appears that the managed router let public
IP's connect to the fileserver in a non-public range until
you find out that was the public home IP of a employer

please don't do that - thank you!
Tom Gundersen
2014-01-02 15:29:26 UTC
Permalink
Hei Reindl,
Post by Reindl Harald
Post by Tom Gundersen
Post by Holger Schurig
AFAIK Mac OSX does a trick here
Yeah, and we should do the same: <http://tools.ietf.org/search/rfc4436>
because this explains why i sometimes see firewall logs in
the company network where all severs are blocking private
ranges as spoofed address i would be thankful not starting
the same odd behavior with linux clients
this is also really funny if it leads calling your ISP
names because it appears that the managed router let public
IP's connect to the fileserver in a non-public range until
you find out that was the public home IP of a employer
please don't do that - thank you!
I'm not sure I fully understand what you are referring to. Did you
read the RFC? Could you explain a bit more precisely what setups
causes problems under that RFC?

Cheers,

Tom
Reindl Harald
2014-01-02 15:37:55 UTC
Permalink
Am 02.01.2014 16:29, schrieb Tom Gundersen:> Hei Reindl,
Post by Tom Gundersen
Post by Reindl Harald
Post by Tom Gundersen
Post by Holger Schurig
AFAIK Mac OSX does a trick here
Yeah, and we should do the same: <http://tools.ietf.org/search/rfc4436>
because this explains why i sometimes see firewall logs in
the company network where all severs are blocking private
ranges as spoofed address i would be thankful not starting
the same odd behavior with linux clients
this is also really funny if it leads calling your ISP
names because it appears that the managed router let public
IP's connect to the fileserver in a non-public range until
you find out that was the public home IP of a employer
please don't do that - thank you!
I'm not sure I fully understand what you are referring to. Did you
read the RFC? Could you explain a bit more precisely what setups
causes problems under that RFC?
the problems are that if someone comes back with his Apple notebook
this crap starts to using the old ip-address and triggering all sorts
of alarms, firewall-rules and so on

at least in one case i called our ISP names because i did not imagine
that any operating system may be that stupid to use the public IP
of the users home-internet to re-connect to the fileserver and after
that failed ask our DHCP for a correct IP
Tom Gundersen
2014-01-02 15:41:01 UTC
Permalink
Post by Reindl Harald
Am 02.01.2014 16:29, schrieb Tom Gundersen:> Hei Reindl,
Post by Tom Gundersen
Post by Reindl Harald
Post by Tom Gundersen
Post by Holger Schurig
AFAIK Mac OSX does a trick here
Yeah, and we should do the same: <http://tools.ietf.org/search/rfc4436>
because this explains why i sometimes see firewall logs in
the company network where all severs are blocking private
ranges as spoofed address i would be thankful not starting
the same odd behavior with linux clients
this is also really funny if it leads calling your ISP
names because it appears that the managed router let public
IP's connect to the fileserver in a non-public range until
you find out that was the public home IP of a employer
please don't do that - thank you!
I'm not sure I fully understand what you are referring to. Did you
read the RFC? Could you explain a bit more precisely what setups
causes problems under that RFC?
the problems are that if someone comes back with his Apple notebook
this crap starts to using the old ip-address and triggering all sorts
of alarms, firewall-rules and so on
Hm, sounds odd. This protocol is precisely meant to avoid that sort of
problem (by detecting whether or not you are connecting to the same
network). I heard that some old Apple devices used a more naive
protocol that would indeed just reuse the old IP... When did you last
experience this? Any clue about what hardware/software version it was
causing the problem?

-t
Reindl Harald
2014-01-02 15:48:13 UTC
Permalink
Post by Tom Gundersen
Post by Reindl Harald
the problems are that if someone comes back with his Apple notebook
this crap starts to using the old ip-address and triggering all sorts
of alarms, firewall-rules and so on
Hm, sounds odd. This protocol is precisely meant to avoid that sort of
problem (by detecting whether or not you are connecting to the same
network). I heard that some old Apple devices used a more naive
protocol that would indeed just reuse the old IP... When did you last
experience this? Any clue about what hardware/software version it was
causing the problem?
2013, OSX 10.6, the first Mac Book Pro generation not supported
by OSX > 10.6 as far as i know, one bought a few months later
would be supported

given that this machines are not that old and expensive they
will exist longer here and there (yes i know about the securtiy
nightmare but in that context OSX should be banned at all)
Tom Gundersen
2014-01-02 15:52:13 UTC
Permalink
Post by Reindl Harald
Post by Tom Gundersen
Post by Reindl Harald
the problems are that if someone comes back with his Apple notebook
this crap starts to using the old ip-address and triggering all sorts
of alarms, firewall-rules and so on
Hm, sounds odd. This protocol is precisely meant to avoid that sort of
problem (by detecting whether or not you are connecting to the same
network). I heard that some old Apple devices used a more naive
protocol that would indeed just reuse the old IP... When did you last
experience this? Any clue about what hardware/software version it was
causing the problem?
2013, OSX 10.6, the first Mac Book Pro generation not supported
by OSX > 10.6 as far as i know, one bought a few months later
would be supported
given that this machines are not that old and expensive they
will exist longer here and there (yes i know about the securtiy
nightmare but in that context OSX should be banned at all)
Thanks, I'll try to dig into this a bit before implementing anything
(and anyway, I expect this to be configurable if we add it).

Cheers,

Tom
Patrik Flykt
2014-01-03 09:55:58 UTC
Permalink
Post by Tom Gundersen
Post by Reindl Harald
Post by Tom Gundersen
Post by Reindl Harald
the problems are that if someone comes back with his Apple notebook
this crap starts to using the old ip-address and triggering all sorts
of alarms, firewall-rules and so on
Hm, sounds odd. This protocol is precisely meant to avoid that sort of
problem (by detecting whether or not you are connecting to the same
network). I heard that some old Apple devices used a more naive
protocol that would indeed just reuse the old IP... When did you last
experience this? Any clue about what hardware/software version it was
causing the problem?
2013, OSX 10.6, the first Mac Book Pro generation not supported
by OSX > 10.6 as far as i know, one bought a few months later
would be supported
given that this machines are not that old and expensive they
will exist longer here and there (yes i know about the securtiy
nightmare but in that context OSX should be banned at all)
Thanks, I'll try to dig into this a bit before implementing anything
(and anyway, I expect this to be configurable if we add it).
So from the DHCP point of view, once we'll get around to implement
Init-Reboot, let's not set up the IP address before a positive response
is received from the DHCP server. Unless RFC 4436 will give some other
indications that it indeed is the same network.

Cheers,

Patrik
Holger Winkelmann [TP]
2014-01-06 09:43:13 UTC
Permalink
just a small off topic question here. How far is IPv6 support in
networks incl. DHCPv6?

Many thanks and a happy new year!

Holger
--
Holger Winkelmann
Tom Gundersen
2014-01-06 09:59:20 UTC
Permalink
On Mon, Jan 6, 2014 at 10:43 AM, Holger Winkelmann [TP]
Post by Holger Winkelmann [TP]
just a small off topic question here. How far is IPv6 support in
networks incl. DHCPv6?
So far we only support static IPv6.

-t

Loading...