[Nut-upsuser] NUT v2.7.1 - Not working on UPS SOLA BASIC SR MICRONET XRN-21-481

2014-02-25 Thread Victor Romero
I got a UPS Sola Basic but it is not working, I'm providing the details. I
hope that someone can help me to get it working.

Please let me know if there is some other information that I should provide
:)

OS name and version
Ubuntu 12.04
$ uname -a
Linux olimpo 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Exact NUT version,

2.7.1 compiled and installed from source tarball

NUT installation method: from source tarball, package or Subversion,

Compiled and installed from source tarball

Exact device name and related information (manufacturing date, web
pointers, ...),

UPS SOLA BASIC SR MICRONET XRN-21-481
http://www.isbmex.com/PDF/XRN21801E.pdf
http://www.isbmex.com/microsrinet.html


complete problem description, with any relevant traces, like system log
excerpts, and driver debug output. You can obtain the latter using the
following command, as root and after having stopped NUT:

$ sudo /usr/local/ups/bin/isbmex -a solabasic -u ups -DD
Network UPS Tools - ISBMEX UPS driver 0.06 (2.7.1)
   0.00 debug level is '2'

Unable to open auto: No such file or directory

Things to try:

 - Check 'port=' in ups.conf

 - Check owner/permissions of all parts of path

   0.001027 Fatal error: unusable configuration


zeus@olimpo:~$ lsusb -vv -d 0483:0035

Bus 002 Device 003: ID 0483:0035 SGS Thomson Microelectronics
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x0483 SGS Thomson Microelectronics
  idProduct  0x0035
  bcdDevice1.11
  iManufacturer   3
  iProduct1
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   41
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower   20mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  29
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10


Best Regards

Victor
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Arch Linux and Tripp Lite web snmp card issues.

2014-02-25 Thread Jason R Begley

Sorry, I just now figured out how to get a usable output.
-Option one doesn't work at all for me.

snmp_build: unknown failuresnmpget: Error building ASN.1 representation 
(Can't build OID for variable)

COUNT = 0 / 0
Creating /usr/share/snmp/mibs/ups-mib.txt-mib.h
Creating /usr/share/snmp/mibs/ups-mib.txt-mib.c
Done.

-Option 2 is attached. I ran the following to get the output.
snmpwalk -Os -v2c -c XX  .1.3.6.1.4.1.850.100 -m 
//usr/share/snmp/mibs/TRIPPLITE-MIB.txt > snmpwalk-Os.log
snmpwalk -On -v2c -c XX  .1.3.6.1.4.1.850.100 -m 
/usr/share/snmp/mibs/TRIPPLITE-MIB.txt > snmpwalk-On.log
./gen-snmp-subdriver.sh -s .1.3.6.1.4.1.850.100 snmpwalk-On.log 
snmpwalk-Os.log




Thanks again for the help,
Jason

On 2/25/2014 7:03 PM, Charles Lepple wrote:

On Feb 25, 2014, at 4:23 PM, Arnaud Quette wrote:


gen-snmp-subdriver.sh simply hasn't done its job, for some reasons.
well, 1 clear is that's it not a completed effort... at all
but, still IIRC, it should have produced at least a bit more


Hi Arnaud,

I may not have been specific enough in my description.

The crash that Jason saw is with the version of snmp-ups that is 
currently in Git - including the new 'xppc' MIB, but the NULL pointer 
in question is also in 'delta_ups'.


Given that mib2nut[i]->oid_auto_check is only used for the "classic" 
OID check, I think we can just add a special case to check for NULL, 
and continue the loop if oid_auto_check has not been provided.



@Jason: how have you called the script?
could you please also send an archive including:
- the results of the adapted commands on #L73, #L74
https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh
- your mib file


Jason,

this would still be useful to address the issue of gen-snmp-subdriver 
not parsing things correctly.


--
Charles Lepple
clepple@gmail





___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser




trippups1.tar.gz
Description: application/gzip
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Arch Linux and Tripp Lite web snmp card issues.

2014-02-25 Thread Charles Lepple
On Feb 25, 2014, at 4:23 PM, Arnaud Quette wrote:

> gen-snmp-subdriver.sh simply hasn't done its job, for some reasons.
> well, 1 clear is that's it not a completed effort... at all
> but, still IIRC, it should have produced at least a bit more

Hi Arnaud,

I may not have been specific enough in my description.

The crash that Jason saw is with the version of snmp-ups that is currently in 
Git - including the new 'xppc' MIB, but the NULL pointer in question is also in 
'delta_ups'.

Given that mib2nut[i]->oid_auto_check is only used for the "classic" OID check, 
I think we can just add a special case to check for NULL, and continue the loop 
if oid_auto_check has not been provided.

> @Jason: how have you called the script?
> could you please also send an archive including:
> - the results of the adapted commands on #L73, #L74
> https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh
> - your mib file


Jason,

this would still be useful to address the issue of gen-snmp-subdriver not 
parsing things correctly.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Arch Linux and Tripp Lite web snmp card issues.

2014-02-25 Thread Arnaud Quette
2014-02-25 12:58 GMT+01:00 Charles Lepple :

> On Feb 24, 2014, at 11:48 PM, Jason R Begley wrote:
>
> >   0.073855 load_mib2nut: trying classic method with 'delta_ups' mib
> >   0.073878 Entering nut_snmp_get_str()
> >   0.073899 nut_snmp_get((null))
> >   0.073918 nut_snmp_walk((null))
>
> Arnaud,
>
> The gen-snmp-subdriver.sh script is setting mib2nut[i]->oid_auto_check to
> NULL for new drivers (with no instructions on what to use in place of
> NULL). However, this seems to be only used with the "classic method" for
> detecting an UPS.
>
> Is the intent to phase out the classic method, or should we just add an
> explicit NULL check in load_mib2nut()?
>
> The full stack trace is below:
>
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xb7da9470 in __strchr_sse2_bsf () from /usr/lib/libc.so.6
> > (gdb) bt
> > #0  0xb7da9470 in __strchr_sse2_bsf () from /usr/lib/libc.so.6
> > #1  0xb7f05758 in snmp_parse_oid () from /usr/lib/libnetsnmp.so.30
> > #2  0x0804afd8 in nut_snmp_walk ()
> > #3  0x0804b261 in nut_snmp_get ()
> > #4  0x0804bab6 in nut_snmp_get_str ()
> > #5  0x0804be7b in load_mib2nut ()
> > #6  0x0804bfd2 in upsdrv_initups ()
> > #7  0x08049fb4 in main (
>

Hi Charles,

gen-snmp-subdriver.sh simply hasn't done its job, for some reasons.
well, 1 clear is that's it not a completed effort... at all
but, still IIRC, it should have produced at least a bit more

@Jason: how have you called the script?
could you please also send an archive including:
- the results of the adapted commands on #L73, #L74
https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh
- your mib file

cheers,
Arno
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Arch Linux and Tripp Lite web snmp card issues.

2014-02-25 Thread Charles Lepple
On Feb 24, 2014, at 11:48 PM, Jason R Begley wrote:

>   0.073855 load_mib2nut: trying classic method with 'delta_ups' mib
>   0.073878 Entering nut_snmp_get_str()
>   0.073899 nut_snmp_get((null))
>   0.073918 nut_snmp_walk((null))

Arnaud,

The gen-snmp-subdriver.sh script is setting mib2nut[i]->oid_auto_check to NULL 
for new drivers (with no instructions on what to use in place of NULL). 
However, this seems to be only used with the "classic method" for detecting an 
UPS.

Is the intent to phase out the classic method, or should we just add an 
explicit NULL check in load_mib2nut()?

The full stack trace is below:

> Program received signal SIGSEGV, Segmentation fault.
> 0xb7da9470 in __strchr_sse2_bsf () from /usr/lib/libc.so.6
> (gdb) bt
> #0  0xb7da9470 in __strchr_sse2_bsf () from /usr/lib/libc.so.6
> #1  0xb7f05758 in snmp_parse_oid () from /usr/lib/libnetsnmp.so.30
> #2  0x0804afd8 in nut_snmp_walk ()
> #3  0x0804b261 in nut_snmp_get ()
> #4  0x0804bab6 in nut_snmp_get_str ()
> #5  0x0804be7b in load_mib2nut ()
> #6  0x0804bfd2 in upsdrv_initups ()
> #7  0x08049fb4 in main ()

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] nut in openwrt

2014-02-25 Thread Virgo Pärna
On Sun, 23 Feb 2014 19:39:02 +0100, Josu Lazkano  wrote:
>
> # dmesg
> ...
> [181041.636190] usb 4-4: new low-speed USB device number 2 using ohci_hcd
>

I recently read about openwrt (for one of the routers I own). And there was 
a 
comment that particular router does not support low-speed USB devices (USB1). 
Could that 
be the issue? The one I read about was TL MR3220. There is suggestion, that 
using 
external USB hub would resolve the issue.

-- 
Virgo Pärna 
virgo.pa...@mail.ee


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser