The latest messages appeared to be just showing the results of telnet, so was
justnmakijgmcertain thatnwe had jot lost focus on needijg the correct port
number in the test.
- Tim
On February 22, 2022 7:28:45 AM CST, Jim Klimov <[email protected]> wrote:
>Getting a bit lost here. Why telnetd and port 23?
>
>The original suggestion was IIRC to
>
> telnet 192.168.1.235 3493
>
>from .236 and vive-versa to see if the upsd port (3493) is reachabl - so if
>clients on one Pi can see devices served by (connected to) the other.
>
>Am I missing sone context?
>Jim
>
>On Fri, Feb 18, 2022, 00:29 Tim Dawson <[email protected]> wrote:
>
>> It's been a very long time since I have seen a Linux distro enable telnetd
>> to allow telnet connections proper. Test using telnet to the nut port
>> number ("telnet xxx.yyy.zzz.kkk portno") and see if that connects, or try
>> somethhing like ssh . . .
>>
>> On February 17, 2022 11:39:41 AM CST, William Cole via Nut-upsuser <
>> [email protected]> wrote:
>>>
>>> Thank you all for your offerings. Here are some results. All were run
>>> on the Pi server [235] except the change to the firewall setting which was
>>> run on the Mint machine.
>>>
>>> *sudo netstat -lntp*
>>> *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
>>> <http://0.0.0.0:22> 0.0.0.0:* LISTEN
>>> 501/sshd*
>>> * tcp 0 0 0.0.0.0:631 <http://0.0.0.0:631>
>>> 0.0.0.0:* LISTEN 28384/cupsd*
>>>
>>> * tcp 0 0 0.0.0.0:445 <http://0.0.0.0:445>
>>> 0.0.0.0:* LISTEN 1011/smbd *
>>> * tcp 0 0 0.0.0.0:3493 <http://0.0.0.0:3493>
>>> 0.0.0.0:* LISTEN 499/upsd *
>>> * tcp 0 0 0.0.0.0:139 <http://0.0.0.0:139>
>>> 0.0.0.0:* LISTEN 1011/smbd*
>>> * tcp6 0 0 :::22
>>> :::* LISTEN 501/sshd *
>>> * tcp6 0 0 :::631
>>> :::* LISTEN 28384/cupsd *
>>> * tcp6 0 0 :::445
>>> :::* LISTEN 1011/smbd*
>>> * tcp6 0 0 :::139
>>> :::* LISTEN 1011/smbd *
>>> * tcp6 0 0 :::00
>>> :::* LISTEN 530/apache2*
>>>
>>> and the second output:
>>>
>>> *sudo iptables -L -n -v*
>>> *Chain INPUT (policy ACCEPT @ packets, 0 bytes)*
>>>
>>> * pkts bytes target prot opt in out
>>> source destination*
>>>
>>> *Chain FORWARD (policy ACCEPT @ packets, 0 bytes)*
>>> * pkts bytes target prot opt in out
>>> source destination*
>>>
>>> *Chain OUTPUT (policy ACCEPT @ packets, 0 bytes)*
>>> * pkts bytes target prot opt in out
>>> source destination*
>>>
>>> As to firewalls, the Mint 20 that handles Linux network devices uses
>>> *Gufw*.
>>> The Windows networked devices use* Windows Defender's* built-in firewall.
>>>
>>> I added port 23 for telnet to the Gufw firewall and restarted the Mint
>>> machine and both of the Pis. Then ran:
>>>
>>> *sudo telnet 192.168.1.236* from the 235 Pi
>>> *sudo telnet 192.168.1.235* from the 236 Pi
>>>
>>> Result in both cases:
>>>
>>> *Trying 192.168.1.xxx ...*
>>> *telnet: Unable to connect to remote host: Connection refused*.
>>>
>>> If it makes a difference, all the devices are tied together with Plume
>>> mesh network devices which are connected to FiOS.
>>>
>>> Bill
>>>
>>> --
>>>
>>> Fredericksburg, VA
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> Nut-upsuser mailing list
>> [email protected]
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity._______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
