<div dir="ltr">Roger that! ;)<br><br><div> 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.</div><div><br></div><div> 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 <a href="https://github.com/networkupstools/nut/issues/3155">https://github.com/networkupstools/nut/issues/3155</a> (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).</div><div><br></div><div> 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 <a href="https://github.com/networkupstools/nut/issues/3637">https://github.com/networkupstools/nut/issues/3637</a></div><div><br></div><div> A similar issue was raised earlier and discussed in <a href="https://github.com/networkupstools/nut/issues/3403#issuecomment-4236061617">https://github.com/networkupstools/nut/issues/3403#issuecomment-4236061617</a> - 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:</div><div><br></div><div> * <a href="https://github.com/networkupstools/nut/issues/3359">https://github.com/networkupstools/nut/issues/3359</a> - 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.</div><div> * <a href="https://github.com/networkupstools/nut/issues/3411">https://github.com/networkupstools/nut/issues/3411</a> and client-side implementation with <a href="https://github.com/networkupstools/nut/pull/3435">https://github.com/networkupstools/nut/pull/3435</a> - 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.</div><div><br></div><div> 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 <a href="https://github.com/networkupstools/nut/issues/3102">https://github.com/networkupstools/nut/issues/3102</a>. 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)?</div><div><br></div><div>Thanks,</div><div>Jim Klimov</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2026 at 10:54 AM Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 10 Sep 2026, Jim Klimov via Nut-upsuser wrote:<br>
<br>
> Kudos to the NetCube team, although with their occasional involvement in NUT <br>
> issues and PRs I did not catch wind of such a product being prepared :\ <br>
<br>
> Still, the idea of shipping NUT onboard the UPS itself was long waiting for <br>
> someone to pick it up, I think it can be derived from the wording of RFC 9271 <br>
> etc.<br>
<br>
Hello Jim, This is exactly figure 3 in the RFC 9271 Protocol Overview <br>
<a href="https://www.rfc-editor.org/info/rfc9271/#section-3" rel="noreferrer" target="_blank">https://www.rfc-editor.org/info/rfc9271/#section-3</a> .<br>
<br>
Out of curiosity I wondered where NUT stood with respect to the RFC. (I don't <br>
say "conformance", since the RFC is not a Standard.) On the machine I use to <br>
type this, I see :<br>
<br>
rprice@titan ~ inxi -S<br>
System:<br>
Host: titan Kernel: 6.12.107+deb13-amd64 arch: x86_64 bits: 64<br>
Desktop: Xfce v: 4.20.1 Distro: Debian GNU/Linux 13 (trixie)<br>
rprice@titan ~ netcat localhost 3493<br>
VER<br>
Network UPS Tools upsd 2.8.1 - <a href="https://www.networkupstools.org/" rel="noreferrer" target="_blank">https://www.networkupstools.org/</a><br>
HELP<br>
Commands: HELP VER GET LIST SET INSTCMD LOGIN LOGOUT USERNAME PASSWORD STARTTLS<br>
ATTACH<br>
ERR UNKNOWN-COMMAND<br>
LOGIN<br>
ERR USERNAME-REQUIRED<br>
<br>
So at version 2.8.1, as shipped by Debian, it was still LOGIN and LOGOUT rather <br>
than the ATTACH and DETACH described by the RFC.<br>
<br>
I'm not going to worry about this, but if UPS's appear that contain the NUT <br>
Attachment Daemon upsd, then there may be a future interest in a Standards Track <br>
rewrite of RFC 9271, and conformance becomes a more serious matter.<br>
<br>
Cheers, Roger_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>