You are not logged in.

#1 2020-01-27 20:26:45

Brocellous
Member
Registered: 2017-11-27
Posts: 44

[SOLVED] ping -6 _gateway invalid argument

Okay so I' not sure if this is expected or a bug, but I'm trying to get to the bottom of this failure:

$ ping -n -c1 -6 _gateway
PING _gateway(fe80::42b0:76ff:feaf:1578) 56 data bytes
ping: sendmsg: Invalid argument

--- _gateway ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

"_gateway" has a synthesized RR from systemd-resolved.

systemd-resolved(8):

SYNTHETIC RECORDS
       systemd-resolved synthesizes DNS resource records (RRs) for the following cases:
       [...]
       •   The hostname "_gateway" is resolved to all current default routing gateway addresses, ordered by their metric. This assigns a stable hostname to the current gateway, useful for referencing it
           independently of the current network configuration state.

It seems clear to me that the ping failure is because of a missing scope ID after resolution. Notice the ping example is missing a scope ID for the returned link-local address. If I add it manually ping works as expected:

$ ping -6 fe80::42b0:76ff:feaf:1578%3
PING fe80::42b0:76ff:feaf:1578%wlp2s0(fe80::42b0:76ff:feaf:1578%wlp2s0) 56 data bytes
64 bytes from fe80::42b0:76ff:feaf:1578%wlp2s0: icmp_seq=1 ttl=64 time=3.76 ms

--- fe80::42b0:76ff:feaf:1578%wlp2s0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

But the thing is, systemd-resolved also seems to return the correct scope ID with the address

$ resolvectl --legend=no query _gateway
_gateway: 10.1.0.254                                        -- link: wlp2s0
          fe80::42b0:76ff:feaf:1578%3                       -- link: wlp2s0

Also of interest is that the scope ID isn't displayed when I explicitly request a AAAA record:

$ resolvectl --legend=no query _gateway -t AAAA
_gateway IN AAAA fe80::42b0:76ff:feaf:1578                  -- link: wlp2s0

But after some investigation I think that's just a difference in presentation, as the returned data is basically the same and does identify the interface:

$ busctl -j call org.freedesktop.resolve1 /org/freedesktop/resolve1 org.freedesktop.resolve1.Manager ResolveRecord isqqt 0 "_gateway" 1 28 0 # annotated
{
"type" : "a(iqqay)t",
"data" : [
[
[
    3,  # IFACE 3 (wlp2s0)
    1,  # CLASS IN
    28, # TYPE AAAA
    [
        8, # NAME LEN 8
        95, 103, 97, 116, 101, 119, 97, 121, # NAME "_gateway"
        0, 0, # ???
        28, 0, # TYPE AAAA
        1, 0,  # CLASS A
        0, 0, 0, 0, # TTL 0
        16, # ADDR LEN 16
        254, 128, 0, 0, 0, 0, 0, 0, 66, 176, 118, 255, 254, 175, 21, 120 # ADDR fe80::42b0:76ff:feaf:1578
    ]
]
],
513 # FLAGS 0b1000000001 [SD_RESOLVED_DNS, SD_RESOLVED_AUTHENTICATED]
]
}

I understand that ping uses getaddrinfo(3) for name resoution. I am using the nss-resolve module:

$ grep hosts /etc/nsswitch.conf
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname

So I'd expect those calls to be fulfilled by sd-resolved. It does appear that nss-resolve reports the scope ID in the filled sockaddr here.

so I'm not sure why the ping fails.

EDIT: Built ping with debug and stepped through. The sin6_scopeid is not filled by getaddrinfo. So I think this means the issue is nss-resolve's problem.

EDIT2: glibc and systemd with debug to step into getaddrinfo and nss-resolve. getaddrinfo appears to only call nss_gethostsbyname3_r from nss-resolve. It seems it must if it wants to only query for a AAAA record. I can't find any documentation on exactly how nss_gethostbyname{3,4}_r are supposed to behave, but it doesn't appear there is any method for nss_gethostbyname3_r to indcate a scope ID to the caller based on the function signature alone. I suppose this failure is a limitation of how the getaddrinfo works. So expected, though unfortunate, behavior. I'm going to mark this thread solved based on these findings.

Last edited by Brocellous (2020-01-28 09:41:38)

Offline

#2 2020-09-13 22:09:50

Brocellous
Member
Registered: 2017-11-27
Posts: 44

Re: [SOLVED] ping -6 _gateway invalid argument

This is now fixed in ping with the release of iputils 20200821-1

Offline

Board footer

Powered by FluxBB