Hello All, I ran telnet on both machines: First from the server [235] to the client [236] Then from the client [236] to the server [235] The result in both cases: Trying 192.168.1.xxx telnet: Unable to connect to remote host: Connection refused. BTW: I use PuTTY to connect from my Linux machine to both of the RPi's via SSH. Since the UPS RPis are headless, I don't know enough about ssh from the command line to make that work between RPis. [I did take a crack the manpage; I suppose I'd eventually figure it out but would take awhile.] It really is kind of you all to spend time helping to sort this out. I'm just stumped. Bill -- Fredericksburg, VA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220216/1bacd13b/attachment.htm>
Matus UHLAR - fantomas
2022-Feb-16 15:37 UTC
[Nut-upsuser] NUT Client Not Working, Server OK
I see you have On 16.02.22 10:06, William Cole via Nut-upsuser wrote:>I ran telnet on both machines: > First from the server [235] to the client [236] > Then from the client [236] to the server [235] > >The result in both cases: > Trying 192.168.1.xxx > telnet: Unable to connect to remote host: Connection refused.you don't need to connect from server to the client. the server (connected to UPS or another server) runs upsd listening on port (usually 3493) and clients connect to that port.>BTW: I use PuTTY to connect from my Linux machine to both of the RPi's via >SSH. Since the UPS RPis are headless, I don't know enough about ssh from >the command line to make that work between RPis. [I did take a crack the >manpage; I suppose I'd eventually figure it out but would take awhile.] > >It really is kind of you all to spend time helping to sort this out. I'm >just stumped.if you do on the client: upsc -l 192.168.1.235 it should list your available upses on it. -- Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest.
On Wed, 16 Feb 2022, William Cole via Nut-upsuser wrote:> I ran telnet on both machines: > ?? First from the server [235] to the client [236] > ?? Then from the client [236] to the server [235] > > The result in both cases: > ?? Trying 192.168.1.xxx > ?? telnet: Unable to connect to remote host: Connection refused.This makes it clear that the problem is not with nut, but rather the basic setup of network 192.168.1/24 Google proposes plenty of help for Connection refused, but start with command netstat -lntp For example, I see Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 832/sshd ... tcp 0 0 0.0.0.0:3493 0.0.0.0:* LISTEN 3066/upsd Roger
On 2/16/22 17:06, William Cole via Nut-upsuser wrote:> Hello All, > > I ran telnet on both machines: > ?? First from the server [235] to the client [236] > ?? Then from the client [236] to the server [235] > > The result in both cases: > ?? Trying 192.168.1.xxx > ?? telnet: Unable to connect to remote host: Connection refused. >I am 90% sure that you have a firewall that blocks TCP connections. Many modern linux distros come with a default firewall which blocks all incoming connections or allow a very limited subset of ports, like ssh? ( port 22 ) and web ( port 80 and/or 443 ). You can do a quick test by running as root ( or via sudo if needed ) one of the following two commands on the server machine: ??? iptables -I INPUT -p tcp --dport 3493 -j ACCEPT <==? this will enable access to port TCP/3493 or ??? iptables -F <=== this should disable the firewall completely. Note that depending on the distribution that you use, a more civilized way to ( temporary ) disable the firewall exists, for instance in recent Debian/Ubuntu you'd run /ufw disable/ while on CentOS/RHEL you'd use /systemctl stop firewalld ( /with the obvious /ufw enable/ resp /systemctl start firewalld/ to enable the firewall back ) If I am right, once you've allowed the incoming connection, repeating the telnet command should succeed. In this case you must modify the firewall and add a permanent rule to allow the connection. wolfy // -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220217/fb30d5bc/attachment-0001.htm>