-
-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
apc_modbus "buffer overflow detected" - usb enabled libmodbus #2289
Comments
CC @EchterAgo |
Searching in sources, the error does not seem to be reported - by neither NUT, nor libmodubs (rtu_usb branch), nor libusb (at least 1.0.26 that I have locally). Probably there is some security-conscious libmalloc variant used on your platform which detects (or claims) an overflow and causes the program to abort. Arbitrarily, as common errors go, I would guess that in the driver we provide a buffer for I/O, maybe even pass the length, and the other side in one of those libraries does not honour this limit. Points to check:
Maybe it would symptomatically help to find the buffer involved and just allocate it larger than the expected transfers. Brute, uncivilized, prone to repeating if something changes later and we are none the wiser from debugging - but a quick and dirty hotfix, at least. You both mentioned that kernel complains about lack of claiming the device. Maybe it is also involved, but I am not sure how :) If the kernel did hand off the device (and nobody else intervenes, especially with virtualization and pass-through involved in that #2063 comment), I suppose it does pass all the data between devices and programs honestly. |
For It may help to pass |
For some cases, it may be simpler to run programs through |
I should probably mention that this is all being done on a raspberry pi 3b+ But, okay so here's the weird thing.... I've just gone and re-configured both libmodbus and nut with the CFLAGS and make / installed, and now the driver just started working.
The only thing that I can think of having changed between the two times building libmodbus, was that inbetween i'd installed nut and nut-cgi via apt, and as part of the nut package installation it installed |
I think the libmodbus changes for USB support might primarily require libusb-1.x - so wonder if it got somehow built against wrong implementation then (would rely on having the "dev" packages and so headers for both, and then mixing something up while building modbus and NUT). But that's mostly a guess. I think the USB-capable drivers should report which libusb they use, in debug and recently (since 2.8.0) in
Regarding how it started working... maybe the nut package re-installation restarted |
I have the same problem with using
|
CC @EchterAgo : does this ring a bell, please? |
/usr/local/ups/bin$ sudo ./apc_modbus -a ups -DDDDDD |
gcc -D_FORTIFY_SOURCE=1 ? |
Getting same error... |
UPDATE: Seems like a practical duplicate of #2609, please continue discussion there to keep it compact :) |
Running in to a similar (if not the same), issue as mentioned in #2063 (comment)
This is with a 2020 SMT2200RM12U, connected via USB and attempting to use apc_modbus.
Have been able to build the modified libmodbus fine (and attempted to use apc-test-client but showed a similar error), but upon building nut with this modified lib for the driver, copying driver to the correct place, and installing over the apt package of nut as described in wiki/comments on the issue thread, the driver won't load.
Output when trying to start the driver directly:
And my syslog has the entry at the time of trying to run the driver of:
kernel: [ 2104.577931] usb 1-1.3: usbfs: process 1371 (apc_modbus) did not claim interface 0 before use
Not really sure where to start on this one if anyone has any ideas?
Can't say i've done any debugging before, but if someone could possibly give me a rundown on what i'd need to do to get something useful out of gdb, I could run through it. I'm aware that on Ubuntu i've apport installed by default for crash dumps and i've enabled it taking these in crashdb.conf
The text was updated successfully, but these errors were encountered: