[Nut-upsdev] blazer_usb: compatibility with Ippon BackPro UPSes (Phoenix Power Co., Ltd usb-to-serial controller)

[Alexey Loukianov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

08.01.2010 12:59, Arjen de Korte wrote:
> 
> We probably need a small delay between sending a command and reading  
> the reply. Currently it seems to read just three characters. Since we  
> only try reading once (instead of repeatedly until a timeout or end of  
> line occurs), this probably fails.
> 

Well, looks like data corruption from megatec_usb somehow got into blazer_usb.

Here are my debug additions to ippon_command:

Index: blazer_usb.c
===================================================================
- --- blazer_usb.c        (revision 2240)
+++ blazer_usb.c        (working copy)
@@ -170,10 +170,11 @@

 static int ippon_command(const char *cmd, char *buf, size_t buflen)
 {
- -       char    tmp[64];
+       char    tmp[65], tmp1[65];
        int     ret;
        size_t  i;

+       memset(tmp, 0, sizeof(tmp));
        snprintf(tmp, sizeof(tmp), "%s", cmd);

        for (i = 0; i < strlen(tmp); i += ret) {
@@ -190,8 +191,10 @@

        upsdebugx(3, "send: %.*s", (int)strcspn(tmp, "\r"), tmp);

+       usleep(200000);
+
        /* Read all 64 bytes of the reply in one large chunk */
- -       ret = usb_interrupt_read(udev, 0x81, tmp, sizeof(tmp), 1000);
+       ret = usb_interrupt_read(udev, 0x81, tmp, 64, 2000);

        /*
         * Any errors here mean that we are unable to read a reply (which
@@ -202,6 +205,13 @@
                return ret;
        }

+       tmp[ret] = 0;
+       for(i = 0; i < ret; i++) {
+           tmp1[i] = (tmp[i] >= ' ') ? tmp[i] : '^';
+       }
+       tmp1[i] = 0;
+       upsdebugx(3, "read(raw) %d bytes: %s", ret, tmp1);
+
        snprintf(buf, sizeof(buf), "%.*s", ret, tmp);

        upsdebugx(3, "read: %.*s", (int)strcspn(buf, "\r"), buf);
- -------------------------------------------------------------------------


And here is part of the output:
.........
   0.033782     Trying megatec protocol...
   0.038754     send: Q1
   0.357153     read(raw) 64 bytes: (222.3 2001001^2.3 007 50.1 13.8 25.0 00001001^2.3 007 50.1 13.8
   0.357182     read: (22
   0.357284     blazer_status: parsing failed
   0.357296     Status read 1 failed
..............


P.S. I had revised svn diff from r2219 till current HEAD and I can't find any principal difference in code
that makes my older patch to work correctly while your ippon_command subdriver to fail. Looks
like some kind of a mystery! I'm going to try totally different approach in debugging situation:
to create small and totally separate from the NUT program which will just connect to USB UPS
and query it with Q1 and I commands. In case it will work reliably and correctly - that would be a 
good sign that it is time to do NUT code audit for incorrect pointer operations and other things of 
such kind. That is the only way I can explain this strange behavior and sudden data corruption.

P.P.S. RHEL4 GNU autotools versions:

[allukjanov at server nut-trunk]$ rpm -q automake autoconf
automake-1.9.2-3
autoconf-2.59-5

- -- 
Best regards,
Alexey Loukianov                          mailto:mooroon2 at mail.ru
System Engineer,                            Mob.:+7(926)218-1320
*nix Specialist

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLSFW2AAoJEPB9BOdTkBUL6RUH/jVcPYNKgbqRf0Bsf0wfooag
YSJkDhhfrS+FuCicAElio4f8Hxv7UArZDw2taD7W+VWD3mAQOk0rpoGbcICys72D
J9+vS7Cls1f0hXPp9HU3RSHpVIFNCH6M2weHxMIzTFyiac4glhp/MmBrFgNSgeee
ntSDqVefG4ASF7cKOmwO0p8dhLbPzn32ESV6paj22yIUSC3e8QeC3FZn8LRWN8cU
nedKD6RqG4cSfkoNFzy0VdYOPHnjeXdeD22SUKkZbSxqHP5MSBfls6s8gBli+DYm
JoHYrOXQWTmHG3ZKOc7q5oxAAXUZN70LnLa1QLdzxSqFh0DZX3YlHnUl+d+DpUY=
=o9jB
-----END PGP SIGNATURE-----