-
Notifications
You must be signed in to change notification settings - Fork 17
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
Document the helper scripts tools/nut-ddl-dump.sh tools/nut-recorder.sh #3
Comments
I have a UPS that is not officially supported. I want to try to reverse engineer (although I have never done this in practice) the proprietary application that communicates via USB with the UPS. Would these scripts be helpful in any way to do this?
Details of
|
@luzfcb : your question pertains more to the main NUT repository issue tracker, and probably bring it up (add a link) on the NUT mailing list. This repo is specifically about the DDL (device NUT data dumps library), and the scripts above help collect such data snapshots for comparisons or recordings of activity to simulate later. I am not well versed in USB programming specifically, but generally I would guess a new driver would be more about determining the vendor protocol used than about the hardware link details the tools above reported in your post. OTOH, current My first step would be to set up a loop that would try starting the driver programs from command line to dump device information, until something is successful and reasonable, and only investigate vendor protocols or reverse engineering if your device looks like nothing we have coded for earlier. |
@jimklimov Thanks for the explanations.
Is there any official or non-official step-by-step documentation on how I can do this process? |
Not that I'm aware of, quickly... Essentially it would be just a loop of shell scripting to iterate So the skeleton would be roughly like this, to run with debugging and exit after printing one
Which would leave you with a wall of text (and a The Megatec Qx family of protocols typically reply with text strings (USB/serial friendly) which start with a parenthesis and follow up with some voltages, temperatures, and a bit-mask of some states, depending on the query. They are quite recognizable and make sense "visually" if you see them in wire captures or NUT driver logs; but then there are many vendor-specific dialects. USB HID is more formal and binary (and some vendors do botch the encoding). Here probably an explore mode of |
The nut, repository and main distribution, provides 2 helper scripts to help in the generation of device dumps:
This should also be documented in the main DDL repository, and in the Developer (and probably also the User) documentations
The text was updated successfully, but these errors were encountered: