thr3ads.net - Nut upsdev - [Nut-upsdev] Two APC900 UPS on the same usbbus1 [Jul 2019]

If this information is useful, please help other people find it:
Share via:

Markus Grundmann

2019-Jul-16 13:43 UTC

[Nut-upsdev] Two APC900 UPS on the same usbbus1

Hi!

On my FreeBSD 12.0-RELEASE-p7 server I was unable to retrieve the 
correct information from my two UPS. Every time only the first UPS will 
returned when I entering "upsc apc900" or "upsc apc901". I
don't know
why (Bug or configuration issue on my side?!). I have downloaded the 
latest source code and with my "patch" I was able to get the right 
information from each UPS are expected (correct serial no and other).

In my ups.conf I have added the keyword "serial" to identify the right
UPS.

Whenever I called "lsof -p <pid>" for both
"usbhid-ups" processes I
notice that only the ugen/1.5.0 (aka /dev/usb/1.5.0) device was used. 
After my "patch" the drivers was called corect with the option -x and 
the output of "upsc" reports the right UPS and serialno.

[Drivers after patch]
root 81706   0.0  0.0 11880  3040  -  Ss   15:22       0:00.04 
/usr/local/ups/bin/usbhid-ups -a apc900 -x serial=3B1520X10340
root 83581   0.0  0.0 11880  3040  -  Ss   15:22       0:00.04 
/usr/local/ups/bin/usbhid-ups -a apc901 -x serial=3B1207X25460

[/usr/local/etc/nut/ups.conf]
[apc900]
         driver = usbhid-ups
	port = /dev/usb/1.4.0
	serial = 3B1520X10340
         desc = "APC900-LEFT"

[apc901]
         driver = usbhid-ups
	port = /dev/usb/1.5.0
	serial = 3B1207X25460
         desc = "APC900-RIGHT"
==
The source of drivers/upsdrvctl.c was a little bit enhanced with my 
patch. The structure 'ups_t' contains now a new field labeled
'serial'
and the argument list becomes a new parameter when "serial" is not
NULL.
That's a quick hack but it work's ;-)

Best regards,
Markus

[Patch/Workaround]
root at netstore:~ # diff -u /root/upsdrvctl.c 
nut-2.7.4/drivers/upsdrvctl.c
--- /root/upsdrvctl.c	2019-07-16 15:23:36.496587000 +0200
+++ nut-2.7.4/drivers/upsdrvctl.c	2015-12-29 13:08:34.000000000 +0100
@@ -33,7 +33,6 @@
  	char	*upsname;
  	char	*driver;
  	char	*port;
-	char	*serial;
  	int	sdorder;
  	int	maxstartdelay;
  	void	*next;
@@ -95,9 +94,6 @@
  			if (!strcmp(var, "port"))
  				tmp->port = xstrdup(val);

-			if (!strcmp(var, "serial"))
-				tmp->serial = xstrdup(val);
-
  			if (!strcmp(var, "maxstartdelay"))
  				tmp->maxstartdelay = atoi(val);

@@ -119,7 +115,6 @@
  	tmp->driver = NULL;
  	tmp->port = NULL;
  	tmp->next = NULL;
-	tmp->serial = NULL;
  	tmp->sdorder = 0;
  	tmp->maxstartdelay = -1;	/* use global value by default */

@@ -129,9 +124,6 @@
  	if (!strcmp(var, "port"))
  		tmp->port = xstrdup(val);

-	if (!strcmp(var, "serial"))
-		tmp->serial = xstrdup(val);
-
  	if (last)
  		last->next = tmp;
  	else
@@ -267,7 +259,6 @@
  {
  	char	*argv[8];
  	char	dfn[SMALLBUF];
-	char 	*tval = NULL;
  	int	ret, arg = 0;
  	int	initial_exec_error = exec_error, drv_maxretry = maxretry;
  	struct stat	fs;
@@ -284,15 +275,6 @@
  	argv[arg++] = (char *)"-a";		/* FIXME: cast away const */
  	argv[arg++] = ups->upsname;

-	if (ups->serial) {
-
-		if ((tval = malloc((strlen(ups->serial)+strlen("serial=")+1) * 
sizeof(char)))) {
-
-			argv[arg++] = (char *)"-x";
-			sprintf(argv[arg++],"serial=%s",ups->serial);
-		}
-	}
-
  	/* stick on the chroot / user args if given to us */
  	if (pt_root) {
  		argv[arg++] = (char *)"-r";	/* FIXME: cast away const */
@@ -330,8 +312,6 @@
  				sleep (retrydelay);
  		}
  	}
-
-	if (tval) free(tval);
  }

  static void help(const char *progname)

Charles Lepple

2019-Jul-18 02:51 UTC

head link

[Nut-upsdev] Two APC900 UPS on the same usbbus1

On Jul 16, 2019, at 9:43 AM, Markus Grundmann wrote:> 
> Whenever I called "lsof -p <pid>" for both
"usbhid-ups" processes I notice that only the ugen/1.5.0 (aka
/dev/usb/1.5.0) device was used. After my "patch" the drivers was
called corect with the option -x and the output of "upsc" reports the
right UPS and serialno.
Are you sure that the "serial = ..." parameters were specified in
ups.conf when you started the drivers originally with "-a apc90*"?

The "-x serial=..." parameter to the driver is redundant when ups.conf
has a "serial = " parameter. Also, the "port = ..."
arguments are ignored by usbhid-ups, because there is no way to pass that port
into libusb (and the ports returned during device enumeration are typically not
stable across reboots anyway). We typically recommend "port = auto"
for usbhid-ups (and other USB drivers).

If you are still seeing the problem where both UPSes are opening the same /dev
node, we will need some driver traces to see why it is not matching the serial
number specified in ups.conf. (I am not ready to rule out incompatible changes
in FreeBSD 12.) Probably two "-D" flags should be sufficient. You can
stop them with upsdrvctl first, but I would recommend starting usbhid-ups
directly ("/usr/local/ups/bin/usbhid-ups -a apc900 -D -D"; otherwise,
if you specify "upsdrvctl -D -D", NUT thinks you are trying to debug
upsdrvctl itself.)

Markus Grundmann

2019-Jul-18 06:02 UTC

head link

[Nut-upsdev] Two APC900 UPS on the same usbbus1

On 18.07.19 04:51, Charles Lepple wrote:> On Jul 16, 2019, at 9:43 AM, Markus Grundmann wrote:
>> Whenever I called "lsof -p <pid>" for both
"usbhid-ups" processes I notice that only the ugen/1.5.0 (aka
/dev/usb/1.5.0) device was used. After my "patch" the drivers was
called corect with the option -x and the output of "upsc" reports the
right UPS and serialno.
> Are you sure that the "serial = ..." parameters were specified in
ups.conf when you started the drivers originally with "-a apc90*"?
>
> The "-x serial=..." parameter to the driver is redundant when
ups.conf has a "serial = " parameter. Also, the "port = ..."
arguments are ignored by usbhid-ups, because there is no way to pass that port
into libusb (and the ports returned during device enumeration are typically not
stable across reboots anyway). We typically recommend "port = auto"
for usbhid-ups (and other USB drivers).
>
> If you are still seeing the problem where both UPSes are opening the same
/dev node, we will need some driver traces to see why it is not matching the
serial number specified in ups.conf. (I am not ready to rule out incompatible
changes in FreeBSD 12.) Probably two "-D" flags should be sufficient.
You can stop them with upsdrvctl first, but I would recommend starting
usbhid-ups directly ("/usr/local/ups/bin/usbhid-ups -a apc900 -D -D";
otherwise, if you specify "upsdrvctl -D -D", NUT thinks you are trying
to debug upsdrvctl itself.)
You are right Chalres !!! But I don't know why I have not probed this
variant in the past :-(

I have used the origin upsdrvctl binary in the following test and it
works also and I'm little bit irritated now. Thanks for your reply!

Please forget my "PATCH" request *LOL*


$ tail -n15 /usr/local/etc/nut/ups.conf
# the -h option and/or read the driver's documentation.

user = root

[apc900]
        driver = usbhid-ups
    port = auto
    serial = 3B1520X10340
        desc = "APC900-LEFT"

[apc901]
        driver = usbhid-ups
    port = auto
    serial = 3B1207X25460
        desc = "APC900-RIGHT"

$ service nut start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: APC HID 0.96
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: APC HID 0.96
Starting nut.
Network UPS Tools upsd 2.7.4
fopen /var/db/nut/upsd.pid: No such file or directory
listening on 0.0.0.0 port 3493
Connected to UPS [apc901]: usbhid-ups-apc901
Connected to UPS [apc900]: usbhid-ups-apc900

$ ps auxw|grep -e nut -e ups
root  4929   0.0  0.0 11880  3040  -  Ss   07:45       0:00.01
/usr/local/libexec/nut/usbhid-ups -a apc900
root  6418   0.0  0.0 11880  3040  -  Ss   07:45       0:00.00
/usr/local/libexec/nut/usbhid-ups -a apc901
uucp  8097   0.0  0.0 30088  2892  -  Ss   07:45       0:00.00
/usr/local/sbin/upsd

$ upsc apc900 | grep -i serial
device.serial: 3B1520X10340 
driver.parameter.serial: 3B1520X10340
ups.serial: 3B1520X10340 

$ upsc apc901 | grep -i serial
device.serial: 3B1207X25460 
driver.parameter.serial: 3B1207X25460
ups.serial: 3B1207X25460

### Both drivers using the right device. Without the serial statement in
ups.conf only '/dev/usb/1.5.0' was used.

$ lsof -p 4929
COMMAND    PID USER   FD   TYPE                DEVICE SIZE/OFF  NODE NAME
usbhid-up 4929 root  cwd   VDIR 1643202022,2213797598        9 44338
/var/db/nut
usbhid-up 4929 root  rtd   VDIR 1643202022,2213797598       27     4 /
usbhid-up 4929 root  txt   VREG 1643202022,2213797598   191832 44147
/usr/local/libexec/nut/usbhid-ups
usbhid-up 4929 root  txt   VREG 1643202022,2213797598   148320   223
/libexec/ld-elf.so.1
usbhid-up 4929 root  txt   VREG 1643202022,2213797598    93672 13486
/usr/lib/libusb.so.3
usbhid-up 4929 root  txt   VREG 1643202022,2213797598   131824   200
/lib/libthr.so.3
usbhid-up 4929 root  txt   VREG 1643202022,2213797598  1949672 33820
/lib/libc.so.7
usbhid-up 4929 root    0u  VCHR                  0,16      0t0    16
/dev/null
usbhid-up 4929 root    1u  VCHR                  0,16      0t0    16
/dev/null
usbhid-up 4929 root    2u  VCHR                  0,16      0t0    16
/dev/null
usbhid-up 4929 root    3u  unix    0xfffff8023ff4c6d0      0t0      
->0xfffff800134846d0
usbhid-up 4929 root    4u  VCHR                 0,140      0t0   140
/dev/usb/1.4.0
usbhid-up 4929 root    5u  VCHR                 0,140      0t0   140
/dev/usb/1.4.0
usbhid-up 4929 root    6u  unix    0xfffff80013483000      0t0      
/var/db/nut/usbhid-ups-apc900
usbhid-up 4929 root    7u  unix    0xfffff800735046d0      0t0      
/var/db/nut/usbhid-ups-apc900

$ lsof -p 6418
COMMAND    PID USER   FD   TYPE                DEVICE SIZE/OFF  NODE NAME
usbhid-up 6418 root  cwd   VDIR 1643202022,2213797598        9 44338
/var/db/nut
usbhid-up 6418 root  rtd   VDIR 1643202022,2213797598       27     4 /
usbhid-up 6418 root  txt   VREG 1643202022,2213797598   191832 44147
/usr/local/libexec/nut/usbhid-ups
usbhid-up 6418 root  txt   VREG 1643202022,2213797598   148320   223
/libexec/ld-elf.so.1
usbhid-up 6418 root  txt   VREG 1643202022,2213797598    93672 13486
/usr/lib/libusb.so.3
usbhid-up 6418 root  txt   VREG 1643202022,2213797598   131824   200
/lib/libthr.so.3
usbhid-up 6418 root  txt   VREG 1643202022,2213797598  1949672 33820
/lib/libc.so.7
usbhid-up 6418 root    0u  VCHR                  0,16      0t0    16
/dev/null
usbhid-up 6418 root    1u  VCHR                  0,16      0t0    16
/dev/null
usbhid-up 6418 root    2u  VCHR                  0,16      0t0    16
/dev/null
usbhid-up 6418 root    3u  unix    0xfffff80013754000      0t0      
->0xfffff800134846d0
usbhid-up 6418 root    4u  VCHR                 0,232      0t0   232
/dev/usb/1.5.0
usbhid-up 6418 root    5u  VCHR                 0,232      0t0   232
/dev/usb/1.5.0
usbhid-up 6418 root    6u  unix    0xfffff8023ff4c368      0t0      
/var/db/nut/usbhid-ups-apc901
usbhid-up 6418 root    7u  unix    0xfffff800134836d0      0t0      
/var/db/nut/usbhid-ups-apc901


-- 
Best regards,
Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20190718/ad8290fe/attachment.html>

Seemingly Similar Threads

Search for more possibly parallel threads

Nut upsdev - Jul 2019 - Two APC900 UPS on the same usbbus1

[Nut-upsdev] Two APC900 UPS on the same usbbus1

[Nut-upsdev] Two APC900 UPS on the same usbbus1

[Nut-upsdev] Two APC900 UPS on the same usbbus1

Seemingly Similar Threads