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 wrote:
>Getting a bit lost here. Why telnetd and port 23?
>
>The
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
I reran the telnet test as when I did it the first time I did not put the
port number 3493 at the end.
[telnet 192.168.1.xxx 3493]
This time telenet from 236 to 235 worked, however telnet from 235 to 236
did not. Here are the messages:
*From 236 to 235:*
*Trying 192.168.1.235*
*Connected to
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
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
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:
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
On Wed, Feb 16, 2022 at 10:40 AM Roger Price wrote:
>
> 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:
> >
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
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:
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
On 2/14/22 17:48, Roger Price wrote:
On Mon, 14 Feb 2022, William Cole via Nut-upsuser wrote:
Here;'s the result of running upsc 1:
Init SSL without certificate database
Error: Unknown UPS
That is normal, I am pretty sure Roger made a typo in his mail when he
asked for this test
I'm
On Mon, 14 Feb 2022, William Cole via Nut-upsuser wrote:
Here;'s the result of running upsc 1:
Init SSL without certificate database
Error: Unknown UPS
I'm trying to find out if TCP/IP based communication is possible between your
machines. Can you ssh from one to another?
Roger
Hello Roger,
Here;'s the result of running *upsc 1*:
*Init SSL without certificate database*
*Error: Unknown UPS*
BTW, I commented the two LISTEN lines in *upsd.conf* that you all flagged
as duplicative.
Rebooted both machines before running *upsc 1*. Didn't seem to make a
difference.
Thanks,
On Sun, 13 Feb 2022, William Cole via Nut-upsuser wrote:
I ran both:
upsc 1LRES850@196.168.1.235
upsc 2UCES750@192.168.1.236
from the server's terminal - which is 192.168.1.235. In both cases the outcome
was:
Error: Connection failure: No route to host.
What does "upsc 1LRES850" do?
Roger,
I ran both:
*upsc 1LRES850@196.168.1.235 <1LRES850@196.168.1.235>*
*upsc 2UCES750@192.168.1.236 <2UCES750@192.168.1.236>*
from the server's terminal - which is 192.168.1.235. In both cases the
outcome was:
*Error: Connection failure: No route to host.*
Which is interesting as I can
On Wed, 9 Feb 2022, William Cole via Nut-upsuser wrote:
In your last post you had suggested that I run the NUT-report bash script that
you had posted to your web site.
### /etc/nut/ups.conf ###
maxretry = 3
[1LRES850]
driver=usbhid-ups
Roger, thank you very much for your note and advice about Nut-upsuser
protocol.
In your last post you had suggested that I run the NUT-report bash script
that you had posted to your web site.
As requested, a compressed output from that script is attached.
Regards,
Bill Cole
--
Fredericksburg,
On 02.02.22 10:28, William Cole via Nut-upsuser wrote:
LISTEN 192.168.1.100 3493
LISTEN 192.168.1.101 3493
LISTEN 0.0.0.0 3493
LISTEN 127.0.0.1 3493
why?
"LISTEN 0.0.0.0 3493" should cover all local IPs, that's what 0.0.0.0 means.
either use this one or any of others.
--
Matus UHLAR -
On Wed, 2 Feb 2022, William Cole via Nut-upsuser wrote:
My upsd.conf [located on the server] is set to listen as follows:
LISTEN 192.168.1.100 3493
LISTEN 192.168.1.101 3493
LISTEN 0.0.0.0 3493
LISTEN 127.0.0.1 3493
After making these changes I shut both the server and client down [sudo
Thank you very much for the advice.
My upsd.conf [located on the server] is set to listen as follows:
LISTEN 192.168.1.100 3493
LISTEN 192.168.1.101 3493
LISTEN 0.0.0.0 3493
LISTEN 127.0.0.1 3493
After making these changes I shut both the server and client down [sudo
shutdown now].
On restart I
[please keep the list CC'd - probably easiest via Reply-All]
On Jan 28, 2022, at 10:20 AM, William Cole wrote:
> However, when executing sudo service nut-client on the Client PC, still
> getting a Connection refused message:
>
> upsmon[491] UPS [APCES750Client@192.168.1.101]:connect failed:
On Jan 26, 2022, at 3:01 PM, William Cole via Nut-upsuser
wrote:
>
> Thank you for your reply and help.
>
> I admit to still learning how to use NUT.
>
> My general NUT-use plan is as follows: the NUT server Pi controls a number of
> network devices; router, VoIP, mesh pod, fiber connection,
Thank you for your reply and help.
I admit to still learning how to use NUT.
My general NUT-use plan is as follows: the NUT server Pi controls a number
of network devices; router, VoIP, mesh pod, fiber connection, etc., but no
computers other than the Pi server. It would shut down last. The
On Jan 25, 2022, at 2:51 PM, William Cole via Nut-upsuser
wrote:
>
> I hope that this is an appropriate post for this group. Please let me know
> if it should go elsewhere.
Yes, this is a good place to ask general questions. However, you may want to
subscribe to the list, at least
On Tue, 25 Jan 2022, William Cole via Nut-upsuser wrote:
I hope that this is an appropriate post for this group. Please let me know if
it should go elsewhere.
This is the right place.
I am running NUT on RaspberryPi 3B+ [RPi] units using Buster. The NUT version
is 2.7.4.
I have two
I hope that this is an appropriate post for this group. Please let me know
if it should go elsewhere.
I am running NUT on RaspberryPi 3B+ [RPi] units using Buster. The NUT
version is 2.7.4.
I have two UPS's in two different physical locations. Each is attached to
its own RPi.
Both UPS's are
27 matches
Mail list logo
