Hello,
On Fri, Jan 27, 2017 at 09:48:22AM +0100, Uwe Kleine-König wrote:
> I acknowledge Norbert's expectations for the ipv4 world. So I did the
> following with python to test my expectations:
>
> >>> import socket
> >>> fd4 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
> >>> fd4.bind(("0.0.0.0", 6969))
>
> This works fine with and without connections in Networkmanager. The
> thing that tftpd stumbles over however is (tftpd/tftpd.c, line 640):
>
> >>> import socket
> >>> socket.getaddrinfo("0.0.0.0", None, socket.AF_INET,
> socket.SOCK_DGRAM, socket.IPPROTO_UDP, socket.AI_CANONNAME |
> socket.AI_ADDRCONFIG)
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/usr/lib/python3.5/socket.py", line 733, in getaddrinfo
> for res in _socket.getaddrinfo(host, port, family, type, proto,
> flags):
> socket.gaierror: [Errno -2] Name or service not known
>
> (in the case where no connection exists) vs
>
> >>> import socket
> >>> socket.getaddrinfo("0.0.0.0", None, socket.AF_INET,
> socket.SOCK_DGRAM, socket.IPPROTO_UDP, socket.AI_CANONNAME |
> socket.AI_ADDRCONFIG)
> [(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17,
> '0.0.0.0', ('0.0.0.0', 0))]
>
> (when there is a connection).
>
> The problem here is (quoting getaddrinfo(3)):
>
> If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses
> are returned in the list pointed to by res only if the local system has
> at least one IPv4 address configured, and IPv6 addresses are returned
> only if the local system has at least one IPv6 address configured. The
> loopback address is not considered for this case as valid as a config‐
> ured address. This flag is useful on, for example, IPv4-only systems,
> to ensure that getaddrinfo() does not return IPv6 socket addresses that
> would always fail in connect(2) or bind(2).After some discussion in #debian-devel and #nm we found out that there is a related network-manager issue. That is, NetworkManager-wait-online.service switches to active state too early. I reported this upstream at https://bugzilla.gnome.org/show_bug.cgi?id=777831 . So actually there are two problems here: - tftpd is started before the machine is online (-> NetworkManager problem); and - tftpd doesn't handle it nicely when being told to bind to 0.0.0.0 before any interface has an ipv4 address (tftpd problem). . One could argue that the second isn't an issue on a well-configured server, but on the other hand there is no reason to not try to handle the dynamic case a tad better. Best regards Uwe
signature.asc
Description: PGP signature
