NUT server listens on wrong IPv6 address

Configuration
1

Since reinstalling the NUT server I use I’ve been getting:

Failed setup, will retry:
  Error fetching UPS state: Multiple exceptions:
  [Errno 111] Connect call failed ('2403:de00:2200:f06:xxxx:xxxx:xxxx:703c', 3493, 0, 0),
  [Errno 111] Connect call failed ('192.168.1.25', 3493)

The reason for this is pretty obvious, checking on the server:

> netstat -Wan | grep 3493
tcp        0      0 127.0.0.1:3493          0.0.0.0:*               LISTEN
tcp6       0      0 2403:de00:2200:f06:xxxx:xxxx:xxxx:c0cc:3493 :::*                    LISTEN
tcp6       0      0 ::1:3493                :::*                    LISTEN

when:

dig upsserver.lan AAAA		// On both upsserver.lan and othermachine.lan

;; ANSWER SECTION:
upsserver.lan.         0       IN      AAAA    2403:de00:2200:f06:xxxx:xxxx:xxxx:703c

So the NUT server is listening on the wrong IPv6 address/interface:

> cat /etc/nut/upsd.conf

LISTEN 127.0.0.1 3493
LISTEN upsserver.lan 3493
LISTEN ::1 3493

The NUT forums contains several discussions about IPv6 issues, usually about IPv4 vs IPv6 or config issues, but this is just a simple case of the server listening on an expiring IPv6 address/interface rather than the current one for the server:

> ifconfig | grep 703c
    inet6 2403:de00:2200:f06:xxxx:xxxx:xxxx:703c/64 scope global temporary dynamic
> ifconfig | grep c0cc
    inet6 2403:de00:2200:f06:xxxx:xxxx:xxxx:c0cc/64 scope global temporary deprecated dynamic

Does anyone have any ideas on how to fix this? I assume it’s not a NUT bug since it would make it unusable on IPv6 systems and there’d be noticeable wailing and gnashing of teeth, so some config issue? I’ve temporarily worked around it with LISTEN */::, but I’d prefer to be a bit more restrictive than that.

2

The sit command shows it pretty clear.
Your DNS for .lan is wrong and needs to be updated.

3

The DNS is correct, it’s pointing to the currently active IPv6 address. The problem is that NUT is listening on an expired IPv6 address, it’s not switching over to the current one for the server. Everything else, HTTP, SSH, etc, get it right, it’s only NUT that has this problem:

tcp6       0     64 2403:de00:2200:f06:xxxx:xxxx:xxxx:703c:22 xxxx:yyyy ESTABLISHED
4

I see that you have given a hostname in the listen entry for NUT.
Hostnames should never be used in such entries, because the service to resolve such hostnames rarely are available at that point in the initialization.

5

So this is a bug in NUT? Meaning something to file an issue over on Github?

6

Looking over this… if I were to summarize:

  • There are two IPv6 addresses of interest (ending with): “c0cc” and “703c”, both are dynamic and temporary but the c0cc address is in a “deprecated” state.
  • NUT Server is configured to use a dns name that appears to be resolving to an address that is dynamically changing. When the NUT Sever started up, the dns likely resolved to the “c0cc” address so the NUT Server sets up a listening socket for the c0cc address and port 3493.
  • The NUT Client is using a dns lookup to connect to the server but at that particular time (sometime later) is failing to connect to the server because dns resolved to the “703c” address,

From my understanding, a “deprecated” address is still useable in its current state and will continue to be until its “valid lifetime” expires, but a “deprecated” address is not suppose to be used for making new connections. I haven’t coded with sockets in a long time, but if I had to guess, I would say there is nothing to notify the NUT Server that the socket it created for c0cc is in a deprecated state, so it probably just sits there happily using the c0cc address.

Perhaps a solution would be to have the NUT Server use a static address if that is possible here.

7

Yeah, I’m not familiar enough with the technical details of IPv6 but I assume it’s due to the IPv6 privacy extensions where you get a random EUI… when the DHCPv6 lease expires? The IPv4 address is stable so I’ll either configure it for IPv4 or keep using LISTEN ::, I can set up an ACL on the router to only allow connections from the HA server so it doesn’t matter what interface it’s listening on.