Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
On Sat, Jul 12, 2014 at 7:38 AM, Camilo Aguilar camilo.agui...@gmail.com wrote: Hm, if I read the DHCP spec correctly it requires the networks to deal with broadcast packets, as NAK is always sent as broadcast, so if this is the case we have a bigger problem. My interpretation is that a DHCPNAK is usually sent through unicast unless the broadcast bit flag is ON in the DHCPDISCOVERY or DHCPREQUEST packet. (Page 25) This is what I had in mind (section 4.1)In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0x. Anyway, see below. I was also cc'ed recently to a new case in Linode: https://bugs.freedesktop.org/show_bug.cgi?id=81225 If what Linode says in this blog post still holds true, then it seems Linode is filtering ARP broadcasts. Seems like you are right, and that there are cases where we must use unicast, and other cases where we must use broadcast (regardless of what the RFC says). Appears to be confirmed by the pcaps on fdo. I put your suggestion (unicast by default, but broadcast opt-in) in the TODO, I'd be happy to take a patch, otherwise I'll get to it soon. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
Notice that the current client code should be ok with the server ignoring the broadcast flag, and just accept either broadcast or unicast packages. agreed Hm, if I read the DHCP spec correctly it requires the networks to deal with broadcast packets, as NAK is always sent as broadcast, so if this is the case we have a bigger problem. My interpretation is that a DHCPNAK is usually sent through unicast unless the broadcast bit flag is ON in the DHCPDISCOVERY or DHCPREQUEST packet. (Page 25) I was also cc'ed recently to a new case in Linode: https://bugs.freedesktop.org/show_bug.cgi?id=81225 If what Linode says in this blog post https://blog.linode.com/2003/09/24/network-filtering-improvements/ still holds true, then it seems Linode is filtering ARP broadcasts. I'd be ok with making broadcast opt-in like this if we really have to, but I'd like to understand the problems seen by Friedrich first (still haven't gotten around to reproduce it). I'm not against understanding why this is failing on a case by case basis. it will be very useful if Friedrich could send us a dhcp dump http://www.cyberciti.biz/faq/linux-unix-dhcpdump-monitor-dhcp-traffic/. My suggestions are based on what I've seen implemented in dhcpcd and ISC dhcp, as well as my personal experience with some networks. Best, Camilo On Sun, Jun 29, 2014 at 2:56 PM, Tom Gundersen t...@jklm.no wrote: Hi Camilo, Sorry for taking some time to get back to you. On Sat, Jun 21, 2014 at 9:08 PM, Camilo Aguilar camilo.agui...@gmail.com wrote: This is another reason why I previously suggested to expose a directive to allow administrators to enable/disable the broadcast flag. I have seen DHCP servers ignoring the flag and always sending broadcasted DHCPOFFERs. There could be other servers that may only use unicast, Notice that the current client code should be ok with the server ignoring the broadcast flag, and just accept either broadcast or unicast packages. and even networks that might disallow broadcast traffic altogether. Hm, if I read the DHCP spec correctly it requires the networks to deal with broadcast packets, as NAK is always sent as broadcast, so if this is the case we have a bigger problem. Set broadcast flag always ON for Firewire interfaces: http://tools.ietf.org/html/rfc2855#section-2 Set broadcast flag always ON for Infiniband interfaces: http://tools.ietf.org/html/rfc4390#section-2.2 Once we support these RFC's, I agree that we should enable broadcast unconditionally for them (some work still needs to be done before we support DHCP over firewire/infiniband). Set broadcast flag OFF by default, if and only if the interface is not Infiniband or Firewire Expose a configuration directive to allow administrators to configure the broadcast flag in case there are DHCP servers ignoring the RFC, or networks disallowing broadcast traffic. I'd be ok with making broadcast opt-in like this if we really have to, but I'd like to understand the problems seen by Friedrich first (still haven't gotten around to reproduce it). Cheers, Tom -- *Camilo Aguilar* Software Engineer http://github.com/c4milo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
Hi Camilo, Sorry for taking some time to get back to you. On Sat, Jun 21, 2014 at 9:08 PM, Camilo Aguilar camilo.agui...@gmail.com wrote: This is another reason why I previously suggested to expose a directive to allow administrators to enable/disable the broadcast flag. I have seen DHCP servers ignoring the flag and always sending broadcasted DHCPOFFERs. There could be other servers that may only use unicast, Notice that the current client code should be ok with the server ignoring the broadcast flag, and just accept either broadcast or unicast packages. and even networks that might disallow broadcast traffic altogether. Hm, if I read the DHCP spec correctly it requires the networks to deal with broadcast packets, as NAK is always sent as broadcast, so if this is the case we have a bigger problem. Set broadcast flag always ON for Firewire interfaces: http://tools.ietf.org/html/rfc2855#section-2 Set broadcast flag always ON for Infiniband interfaces: http://tools.ietf.org/html/rfc4390#section-2.2 Once we support these RFC's, I agree that we should enable broadcast unconditionally for them (some work still needs to be done before we support DHCP over firewire/infiniband). Set broadcast flag OFF by default, if and only if the interface is not Infiniband or Firewire Expose a configuration directive to allow administrators to configure the broadcast flag in case there are DHCP servers ignoring the RFC, or networks disallowing broadcast traffic. I'd be ok with making broadcast opt-in like this if we really have to, but I'd like to understand the problems seen by Friedrich first (still haven't gotten around to reproduce it). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
On Fri, Jun 20, 2014 at 12:12 PM, Michal Sekletar msekl...@redhat.com wrote: On Wed, Jun 18, 2014 at 09:51:02PM +0200, Friedrich Kröner wrote: Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address, nor sets the configured IPv6. Jun 18 18:44:31 localhost systemd[1]: Starting Network Service... Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of '/etc/systemd/network' changed Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link 3 added Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: gained carrier Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link 1 added Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : flags change: +LOOPBACK +UP +LOWER_UP +RUNNING Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : gained carrier Jun 18 18:44:31 localhost systemd[1]: Started Network Service. Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: found matching network '/etc/systemd/network/80-dhcp.network' Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: acquiring DHCPv4 lease Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): STARTED on ifindex 3 with address 52:54:e4:d2:24:44 Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : getting address failed: Device or resource busy Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: fe80::5054:e4ff:fed2:2444/64 Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address for a nonexistent link, ignoring Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: ::1/128 Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: 123.23.23.21/22 Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: 127.0.0.1/8 Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.45 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=signal sender=org.freedesktop.DBus destination=:1.45 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Jun 18 18:44:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:34 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:38 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:46 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:02 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:46:36 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:47:41 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:48:44 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request broadcast restores the previous behavior. Upon restart of systemd-networkd I get the usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well. This is on a kvm-machine with virtio_net as module. Please let me know if you want me to test anything or need further information. What DHCP server do you use? I was running networkd with 63a070415db09f5b5bcc5c
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
On Saturday 21 June 2014 15:24:03 Tom Gundersen wrote: On Fri, Jun 20, 2014 at 12:12 PM, Michal Sekletar msekl...@redhat.com wrote: On Wed, Jun 18, 2014 at 09:51:02PM +0200, Friedrich Kröner wrote: Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address, nor sets the configured IPv6. Jun 18 18:44:31 localhost systemd[1]: Starting Network Service... Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of '/etc/systemd/network' changed Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link 3 added Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: gained carrier Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link 1 added Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : flags change: +LOOPBACK +UP +LOWER_UP +RUNNING Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : gained carrier Jun 18 18:44:31 localhost systemd[1]: Started Network Service. Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: found matching network '/etc/systemd/network/80-dhcp.network' Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: acquiring DHCPv4 lease Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): STARTED on ifindex 3 with address 52:54:e4:d2:24:44 Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : getting address failed: Device or resource busy Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: fe80::5054:e4ff:fed2:2444/64 Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address for a nonexistent link, ignoring Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: ::1/128 Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: 123.23.23.21/22 Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: 127.0.0.1/8 Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.45 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=signal sender=org.freedesktop.DBus destination=:1.45 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Jun 18 18:44:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:34 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:38 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:46 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:02 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:46:36 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:47:41 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:48:44 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request broadcast restores the previous behavior. Upon restart of systemd-networkd I get the usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well.
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
This is another reason why I previously suggested to expose a directive to allow administrators to enable/disable the broadcast flag. I have seen DHCP servers ignoring the flag and always sending broadcasted DHCPOFFERs. There could be other servers that may only use unicast, and even networks that might disallow broadcast traffic altogether. IMHO, a pragmatic solution to this could be: - Set broadcast flag always ON for Firewire interfaces: http://tools.ietf.org/html/rfc2855#section-2 - Set broadcast flag always ON for Infiniband interfaces: http://tools.ietf.org/html/rfc4390#section-2.2 - Set broadcast flag OFF by default, if and only if the interface is not Infiniband or Firewire - Expose a configuration directive to allow administrators to configure the broadcast flag in case there are DHCP servers ignoring the RFC, or networks disallowing broadcast traffic. Best, Camilo Aguilar On Sat, Jun 21, 2014 at 12:03 PM, Friedrich Kröner friedr...@mailstation.de wrote: On Saturday 21 June 2014 15:24:03 Tom Gundersen wrote: On Fri, Jun 20, 2014 at 12:12 PM, Michal Sekletar msekl...@redhat.com wrote: On Wed, Jun 18, 2014 at 09:51:02PM +0200, Friedrich Kröner wrote: Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address, nor sets the configured IPv6. Jun 18 18:44:31 localhost systemd[1]: Starting Network Service... Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of '/etc/systemd/network' changed Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link 3 added Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: gained carrier Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link 1 added Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : flags change: +LOOPBACK +UP +LOWER_UP +RUNNING Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : gained carrier Jun 18 18:44:31 localhost systemd[1]: Started Network Service. Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: found matching network '/etc/systemd/network/80-dhcp.network' Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: acquiring DHCPv4 lease Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): STARTED on ifindex 3 with address 52:54:e4:d2:24:44 Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : getting address failed: Device or resource busy Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: fe80::5054:e4ff:fed2:2444/64 Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address for a nonexistent link, ignoring Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: ::1/128 Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: 123.23.23.21/22 Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: 127.0.0.1/8 Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.45 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=signal sender=org.freedesktop.DBus destination=:1.45 object=/org/freedesktop/DBus interface=org.freedesktop.DBus
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
On Wed, Jun 18, 2014 at 09:51:02PM +0200, Friedrich Kröner wrote: Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address, nor sets the configured IPv6. Jun 18 18:44:31 localhost systemd[1]: Starting Network Service... Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of '/etc/systemd/network' changed Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link 3 added Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: gained carrier Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link 1 added Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : flags change: +LOOPBACK +UP +LOWER_UP +RUNNING Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : gained carrier Jun 18 18:44:31 localhost systemd[1]: Started Network Service. Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: found matching network '/etc/systemd/network/80-dhcp.network' Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: acquiring DHCPv4 lease Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): STARTED on ifindex 3 with address 52:54:e4:d2:24:44 Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : getting address failed: Device or resource busy Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: fe80::5054:e4ff:fed2:2444/64 Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address for a nonexistent link, ignoring Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: ::1/128 Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: 123.23.23.21/22 Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: 127.0.0.1/8 Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.45 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=signal sender=org.freedesktop.DBus destination=:1.45 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Jun 18 18:44:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:34 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:38 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:46 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:02 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:46:36 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:47:41 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:48:44 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request broadcast restores the previous behavior. Upon restart of systemd-networkd I get the usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well. This is on a kvm-machine with virtio_net as module. Please let me know if you want me to test anything or need further information. What DHCP server do you use? I was running networkd with 63a070415db09f5b5bcc5c included and was able to
Re: [systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
On Wed, 18.06.14 21:51, Friedrich Kröner (friedr...@mailstation.de) wrote: Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request broadcast restores the previous behavior. Upon restart of systemd-networkd I get the usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well. This is on a kvm-machine with virtio_net as module. Please let me know if you want me to test anything or need further information. Interestingly I see the exact same problem over a veth link between a networkd container and a networkd host... And indeed reverting the commit you mention makes this work again. Checking with tcpdump it appears as if sendmsg() while succeeds doesn't have any effect anymore with the patch applied as no messages is ever seen by tcpdump... seriously weird... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address, nor sets the configured IPv6. Jun 18 18:44:31 localhost systemd[1]: Starting Network Service... Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of '/etc/systemd/network' changed Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link 3 added Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: gained carrier Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link 1 added Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : flags change: +LOOPBACK +UP +LOWER_UP +RUNNING Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : gained carrier Jun 18 18:44:31 localhost systemd[1]: Started Network Service. Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: found matching network '/etc/systemd/network/80-dhcp.network' Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: acquiring DHCPv4 lease Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): STARTED on ifindex 3 with address 52:54:e4:d2:24:44 Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : getting address failed: Device or resource busy Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: fe80::5054:e4ff:fed2:2444/64 Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address for a nonexistent link, ignoring Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: ::1/128 Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: 123.23.23.21/22 Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: 127.0.0.1/8 Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.45 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=signal sender=org.freedesktop.DBus destination=:1.45 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Jun 18 18:44:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:34 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:38 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:46 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:02 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:46:36 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:47:41 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:48:44 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request broadcast restores the previous behavior. Upon restart of systemd-networkd I get the usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well. This is on a kvm-machine with virtio_net as module. Please let me know if you want me to test anything or need further information. Thank you, Friedrich Kröner ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
