search for: 3493

...log contains entries like [2003/10/02 02:27:34, 0] client/smbmount.c:send_fs_socket(383) mount.smbfs: entering daemon mode for service \\machine\c, pid=3487 and nothing else. Running mount with strace -v -f -s 128 gives the following: <snip endless normal-looking output> [pid 3493] open("/mnt/machine", O_RDONLY|O_LARGEFILE) = 6 [pid 3493] ioctl(6, SMB_IOC_NEWCONN, 0xbfffd080) = 0 [pid 3493] setsid() = 3493 [pid 3493] kill(3492, SIGTERM) = 0 [pid 3493] close(6) = 0 [pid 3493] brk(0) =...

...stallations but not 100% sure yet... [root at mail1 paul]# uname -a Linux mail1.xxxxxx.xxx 2.6.18-238.9.1.el5PAE #1 SMP Tue Apr 12 18:52:55 EDT 2011 i686 i686 i386 GNU/Linux [root at mail1 paul]# cat /etc/issue CentOS release 5.6 (Final) Kernel \r on an \m Apr 24 10:26:24 mail1 snmpd[3493]: netsnmp_assert 1 == new_val->high failed int64.c:419 netsnmp_c64_check32_and_update() Apr 24 10:26:24 mail1 snmpd[3493]: netsnmp_assert 1 == new_val->high failed int64.c:419 netsnmp_c64_check32_and_update() Apr 24 10:26:54 mail1 snmpd[3493]: c64 32 bit check failed Apr 24 10:26:54 mail1...

On 12/17/2013 10:43 AM, David C. Rankin wrote: > Huh? Why the : in Servname? So I just hardwired it passing the port "Servname" > as "3493" (could have just used "nut" from /etc/services): Sheepishly looking for a place to hide.... Yes there was a ':' there all right. Seems I was hit by a vi error: [12:04 phoinix:/etc/ups] # grep 3493 *.conf upsd.conf:LISTEN 127.0.0.1 3493 upsd.conf:LISTEN ::1 3493 upsd.con...

...27151]: =========== Error Block Hit ============ Dec 17 10:21:01 phoinix upsd[27151]: getaddrinfo : Servname not supported for ai_socktype Dec 17 10:21:01 phoinix upsd[27151]: Server addr (Nodename) : 192.168.7.16 Dec 17 10:21:01 phoinix upsd[27151]: Server port (Servname) : :3493 Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_flags : 1 Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_family : 0 Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_socktype : 1 Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_protocol : 6 Huh? Why the : in Servna...

O.S. Ubuntu 10.10, Maverick Meerkat 32 bit. NUT 2.4.3-1ubuntu5, package installed Belkin F6C1500-TW-RK I am having trouble starting uspd whenever I add a client from my lan to uspd.conf: LISTEN 127.0.0.1 3493 LISTEN 192.168.36.106 3493 naknight at nak-server:~$ sudo upsd -DDDD Network UPS Tools upsd 2.4.3 0.000000 listen_add: added 127.0.0.1:3493 0.000093 listen_add: added 192.168.36.106:3495 0.000224 setuptcp: try to bind to 192.168.36.106 port 3495 0.000428 setuptcp: b...

...led: No such host". It is not able to connect at all until the service is bounced. This seems to indicate a name resolution problem but shouldn't this auto correct once name resolution is working properly regardless? upsmon on the Raspbian NUT server works fine and is attached to localhost:3493. I have tried tweaking the systemd file to require upsmon to come up after network-online.target. This doesn't help. After boot I am always able to resolve the name from the client correctly but upsmon continues to fail with no such host. If I use an ip instead of a DNS name this config works...

NUT recently stopped working on my debian. I'm not sure which upgrade broke it. ups.conf: [mustek] driver = megatec port = /dev/ttyS0 desc = "mustek ups" # upsd -DDDD Network UPS Tools upsd 2.4.1 listen_add: added ::1:3493 listen_add: added 127.0.0.1:3493 setuptcp: try to bind to 127.0.0.1 port 3493 listening on 127.0.0.1 port 3493 setuptcp: try to bind to ::1 port 3493 listening on ::1 port 3493 Can't connect to UPS [mustek] (megatec-mustek): No such file or directory # strace -f upsd [...] connect(6, {sa_fami...

$ sudo /usr/sbin/upsd -DDDD Network UPS Tools upsd 2.4.3 0.000000 listen_add: added ::1:3493 0.000084 listen_add: added 127.0.0.1:3493 0.000102 setuptcp: try to bind to 127.0.0.1 port 3493 0.000185 listening on 127.0.0.1 port 3493 0.000204 setuptcp: try to bind to ::1 port 3493 0.001328 setuptcp: socket: Address family not supported by protocol 0.00138...

...sa upsdrvctl[868]: Network UPS Tools - UPS driver controller 2.6.5 Oct 12 22:28:22 melissa bestfortress[937]: Startup successful Oct 12 22:28:22 melissa upsd[938]: fopen /var/run/nut/upsd.pid: No such file or directory Oct 12 22:28:22 melissa upsd[938]: not listening on 2001:470:8:809::1005 port 3493 Oct 12 22:28:22 melissa upsd[938]: listening on ::1 port 3493 Oct 12 22:28:22 melissa upsd[938]: listening on 127.0.0.1 port 3493 Oct 12 22:28:22 melissa upsd[938]: no listening interface available Oct 12 22:28:22 melissa upsd[938]: Network UPS Tools upsd 2.6.5 Oct 12 22:28:22 melissa upsd[938]: no...

...seems to be too high level for me.) My major problem seems to be that I do not understand the concept in full yet, especially: - What needs to be started to have a system that: - - reads the state of an attached UPS frequently - - can be requested from a TCP Client using <ip-of-machine>:3493 - What needs to be modified to: - - have a local installation that would run local programs upon events from the UPS (like "onpower", "onbattery") - - have the machine respond (or allow to open) to clients using the <ip-of-machine>:3493 to connect - is there any way to...

...0:00 /lib/nut/upsmon nut 20309 0.0 0.0 45632 4884 ? S 08:41 0:00 /lib/nut/upsmon mythuser at amethi:/etc/nut$ grep upsd /var/log/syslog Dec 3 08:38:16 amethi nut-server[18216]: No upsd found running; none killed. Dec 3 08:38:16 amethi upsd[18234]: not listening on ::1 port 3493 Dec 3 08:38:16 amethi upsd[18234]: listening on 127.0.0.1 port 3493 Dec 3 08:38:16 amethi upsd[18234]: no listening interface available Dec 3 08:41:11 amethi nut-server[19674]: No upsd found running; none killed. Dec 3 08:41:19 amethi upsd[19725]: not listening on ::1 port 3493 Dec 3 08:41:19...

...9; is not a valid variable name for this driver./ /#??? bus = "001"//# //upsdrvctl start => //Fatal error: '//bus//' is not a valid variable name for this driver./ /?? ?desc = "Riello IDG 800 du bureau" / Si Fichier : upsd.conf /LISTEN localhost 3493/ /LISTEN 127.0.0.1 3493/ /LISTEN 192.168.0.49 # Adresse IP de mon HomeAssistant/ /LISTEN 192.168.0.49 3493//# Adresse IP de mon HomeAssistant/ Alors/: / /$ upsc UPS_Bureau/ /Error: Connection failure: Connection refused/ /$ systemctl restart nut-server.service Job for nut-server.ser...

...r ip] No listening interface available" If I use sudo service nut status I get the following output: "Checking status of Network UPS Tools * Upsd is not running * Upsmon is running" If I check the output of the default port for the service sudo netstat -altp|grep :3493 I then get the following: Tcp 0 0 [server address]:3493 0.0.0.0:* LISTEN 26648/upsd Tcp 0 0 127.0.0.1:3493 0.0.0.0:* LISTEN 23679/upsd Tcp 0 0 127.0.0.1:41385 127.0.0.1:3493 ESTABLISHED 27947/upsmon Tcp 0 0 127.0.0.1:3493 127.0.0.1:41385 ESTABLISHED 23679/upsd Tcp6 0 0 ::1:3493 :::* LISTEN 236...

..., so communication with the UPS itself seems to work. However, when I try to run 'upsc xs1500', I get the following output from upsd (running with debugging output): C:\Program Files (x86)\NUT\sbin>upsd -DDDDD Network UPS Tools upsd 2.6.5-3723:3731M 0.000000 listen_add: added ::1:3493 0.000000 listen_add: added 127.0.0.1:3493 0.015628 setuptcp: try to bind to 127.0.0.1 port 3493 0.031310 listening on 127.0.0.1 port 3493 0.031310 setuptcp: try to bind to ::1 port 3493 0.031310 listening on ::1 port 3493 0.031310 Connected to UPS [xs1500]:...

...roblems. Now I'm trying to hang another machine off the same ups as a slave, and it isn't working. The problem I'm getting is best illustrated by what happens when I run this on the server: upsd -DDDDDDDDD Network UPS Tools upsd 2.4.3 0.000000 listen_add: added 127.0.0.1:3493 0.000070 listen_add: added 192.168.1.104:3493 0.000117 setuptcp: try to bind to 192.168.1.104 port 3493 0.000204 setuptcp: bind: Cannot assign requested address 0.000226 not listening on 192.168.1.104 port 3493 Or when I run this on the slave : /etc/init.d/nut start St...

Cheers all, TL;DR version: I've recently found that at least on my test box the `LISTEN *` line had only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for `upsd`. In fact, at least on a "dual-stack" system, it seems impossible to bind to both - so depending on binding order I either lose IPv6 or lose IPv4 directly (but have it practically as IPv4-over-IPv6).

Cheers all, TL;DR version: I've recently found that at least on my test box the `LISTEN *` line had only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for `upsd`. In fact, at least on a "dual-stack" system, it seems impossible to bind to both - so depending on binding order I either lose IPv6 or lose IPv4 directly (but have it practically as IPv4-over-IPv6).

I would like to suggest that if we modify the IANA registration of nut/3493, we do it formally using the official IANA form https://www.iana.org/form/ports-services , and that we agree on the form contents before submitting it. For example, who is the new assignee and who is the new contact? The last thing the IANA services manager needs is to talk to an unstructured...

The NUT project uses port 3493 to receive traffic to the upsd server. Unlike the protocols http (80) and https (443), NUT has no specific port for encrypted traffic. For the upsdTLS.py daemon. I squatted port 563, but it would be much better to have an officially assigned port. Port 3494 was at one time assigned to ibm34...

On Nov 9, 2014, at 3:48 PM, Steve Read <sd_read at hotmail.com> wrote: > I would like to verify my understanding keeping in mind I have a one master and one slave computer. > > When the master gets the low batt/noAC signal it initiates a broadcast packet(s) on port 3493. > > 1) Is this correct? No, the slave computer's upsmon process connects to the master (via TCP, so point-to-point, not broadcast), and listens for the OB (on battery) and then "OB LB" (on battery; low battery) status. (Not to say that some other UPS shutdown software couldn...