Jim Klimov <jimklimov+...@gmail.com> writes: > Thanks to everyone for a fruitful discussion, links and ideas. > > The result is nearing a merge at > https://github.com/networkupstools/nut/pull/2013 and seems to not upset CI > on any platform, including Windows (which behaves funny WRT binding to the > same host:port as many times as you ask). > > Ultimately the chosen logic is that if there was a `LISTEN * <port>` in > `upsd.conf`, the depending on CLI settings (-4/-6) or lack thereof we try > PIv4, IPv6 or both, with the bigger logic for "both" being: > * try to get IPv4 "ANY", to know we can do so > * release IPv4, try to get IPv6 and then IPv4 again
As I commented on github, I think this is unnecessarily complicated and thus not what we should do. > If in the end neither socket works, declare a fatal error (could not > fulfill the config requirement). > If we could get IPv4 initially, and could not after getting IPv6, do not > bother - assume a dual-stack system (and log it so). You mean "a system that defaults to mapped addresses" :-) > Also as part of this change, NUT would ask (although not insist) for the > IPV6_V6ONLY socket option when preparing IPv6 connections, except when > handling `LISTEN *`. I don't know what you mean by insist. To me the right logic is, after opening a socket to be used for v6, very pseudocodish: #ifdef V6ONLY_define_for_setsockopt call setsockopt to set v6only=1 if that fails log an error /* * deal with bug reports later; it really seems buggy/odd to have the * setsockopt and then error on setting it to 1. */ /* * It would be fine to ifdef out the v6only setting on openbsd if * that turns out ot be necessary. But it wouldn't surprise me if on * openbsd setting it to 1 succeeds and setting it to 0 is an error, * in which case there is no need to special case it. */ #else /* * The operating system does not implement the setsockopt to control * whether mapped addresses are used. Assume that it does not support * mapped addresses at all. */ #endif and then for listen * to listen on v6, log erorrs listen on v4, log errors and that's it. I'm not sure what will then error; when we figure out what does we can see what to do about it. Overall I lean to doing things the simplest and most obviously correct way possible and then to accomodate as necessary. > Finally, I noticed that if some configuration hostname resolves to more > than one address, the first one bound wins and others are ignored. This > behavior was here before, the PR change just logs that this happens. Not sure what you mean first bound wins/etc. If you mean the hostname is looked up and then the first address is picked arbirtarily and that address is listened too, then ack that this is a pre-existing likely bug, agreed that noting it is good, and agreed that there is no reason to have to address that in this PR. _______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser