Roger that! ;) As it stands, NUT sources (even for the current release and development trunk) still have some steps to make in order to fully implement the RFC we have published.
In related news which I've forgot since last year, Unifi Tower UPS apparently has a NUT compatible server too, although it seems to be an independent implementation which is not fully compatible - see https://github.com/networkupstools/nut/issues/3155 (issue about this and a general call to design "A tool for testing NUT protocol compliance" -- probably that should more generally cover RFC 9271 too, so we can use it to test NUT itself in CI runs). Thanks for highlighting the LOGIN/LOGOUT commands, I missed these so far -- probably, aliases with fallbacks should be created in server and client/binding layers (similar to deprecation of master/slave terminology). Posted as https://github.com/networkupstools/nut/issues/3637 A similar issue was raised earlier and discussed in https://github.com/networkupstools/nut/issues/3403#issuecomment-4236061617 - essentially that per RFC all communications should be authenticated, and NUT historically allows anonymous read access. Some steps were already taken, others planned, to improve this, including: * https://github.com/networkupstools/nut/issues/3359 - general direction towards refusing insecure startup (as an option, to eventually become on by default), covering config file security, plaintext comms, now anonymous access, etc. * https://github.com/networkupstools/nut/issues/3411 and client-side implementation with https://github.com/networkupstools/nut/pull/3435 - now all clients have a way to specify their logins (and use SSL/TLS, recently enhanced and available in all bindings, per other tickets), some with command-line options, all with new "nutauth.conf" file support. Server was not yet changed to require all activity to be authenticated, though. It is however already tested by CI, that having `upsc`, `upslog` etc. logged in does not prevent these clients from doing their jobs for the queries they had always sent. By the way, while we are on this standards-related topic: there was an idea to extend the protocol with a notification from client to server like "LOGOUT PENDING" (now probably also "DETACH PENDING"), so the server would know not to wait somehow for a lost client - tracked in https://github.com/networkupstools/nut/issues/3102. Does any wording in RFC 9271, and the practice about standardized protocols in general, prevent such extensions of existing commands with new options (or introduction of new commands like "LOGOUT_PENDING", if extensions are a no-no)? Thanks, Jim Klimov On Thu, Sep 10, 2026 at 10:54 AM Roger Price <[email protected]> wrote: > On Thu, 10 Sep 2026, Jim Klimov via Nut-upsuser wrote: > > > Kudos to the NetCube team, although with their occasional involvement > in NUT > > issues and PRs I did not catch wind of such a product being prepared :\ > > > > Still, the idea of shipping NUT onboard the UPS itself was long waiting > for > > someone to pick it up, I think it can be derived from the wording of RFC > 9271 > > etc. > > Hello Jim, This is exactly figure 3 in the RFC 9271 Protocol Overview > https://www.rfc-editor.org/info/rfc9271/#section-3 . > > Out of curiosity I wondered where NUT stood with respect to the RFC. (I > don't > say "conformance", since the RFC is not a Standard.) On the machine I use > to > type this, I see : > > rprice@titan ~ inxi -S > System: > Host: titan Kernel: 6.12.107+deb13-amd64 arch: x86_64 bits: 64 > Desktop: Xfce v: 4.20.1 Distro: Debian GNU/Linux 13 (trixie) > rprice@titan ~ netcat localhost 3493 > VER > Network UPS Tools upsd 2.8.1 - https://www.networkupstools.org/ > HELP > Commands: HELP VER GET LIST SET INSTCMD LOGIN LOGOUT USERNAME PASSWORD > STARTTLS > ATTACH > ERR UNKNOWN-COMMAND > LOGIN > ERR USERNAME-REQUIRED > > So at version 2.8.1, as shipped by Debian, it was still LOGIN and LOGOUT > rather > than the ATTACH and DETACH described by the RFC. > > I'm not going to worry about this, but if UPS's appear that contain the > NUT > Attachment Daemon upsd, then there may be a future interest in a Standards > Track > rewrite of RFC 9271, and conformance becomes a more serious matter. > > Cheers, Roger_______________________________________________ > Nut-upsuser mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
