Closed faragher closed 1 year ago
faragher
commented
1 year ago Changing the directory to a numeric entry solves the problem above (again, I entirely misunderstood your intent) but it now errors with:
[18:39:11] [WinError 193] %1 is not a valid Win32 application
Since it also attempts to "clear" the screen, which produces a warning, I presume you're doing all the testing on a POSIX system?
markqvist
commented
1 year ago Yes, Windows is not really supported for the rnodeconf tool. It assumes a lot of POSIX stuff, and I do not have the time and resources currently to ensure windows compatibility. There will be a Web-USB based flasher in the future, that will work on Windows, but for now I recommend using Linux or similar for rnodeconf.
That being said, there are things that could be made easier in regards to offline firmware flashing. Currently the offline flashing only works with files that are already downloaded to the local firmware storage cache. I think it would be beneficial to add an option to download all release files to the local cache for later use. Then it would also be easy to just copy the "update" folder from one system to another to allow offline flashing.
It's worth mentioning the --extract-firmware and --use-extracted options here, which uses an existing RNode to extract a working firmware, and then allows flashing that to other target devices.
faragher
commented
1 year ago If it's not supported on Windows, then the issue makes sense. As a bit of an aside, I wanted to make a similar system at about the time you first announced Reticulum. You have done an absolutely astounding amount of work and POSIX is far more useful than Windows. I am exceptionally happy I finally have functioning RNodes.
I'm going to close this as it's not really a bug so much as not yet implemented.
Python doesn't play well with my firewall. I may use my Kali system to bypass this problem, but I feel it's important to address this. (Honestly, I'd be happy to do the documentation for a pull request, but it doesn't work at the end)
When unable to connect to the Internet, rnodeconf tells me to use --fw_version to designate a firmware file. Thank you.
When designating a file, it provides no feedback on where it's looking for the firmware. Suggestion: add "Place firmware files in ~/.config/rnodeconf/update" in error message.
When designated with an extension, the directory also has that extension. Unsure if intended behavior.
When contents extracted to directory, install errors out due to lack of a.release file that contains the hash. (only tested on rnode_firmware_lora32v21.zip)
When hash is taken from release.json and placed in second index in the .version file, hash passes, but fails to upload with the following log.
At this point, I believe I am misunderstanding how you intend the firmware to be located and installed from disk. While I realize an effectively offline system is an edge case, I think it's an important edge case. Again, I'm happy to troubleshoot and document on my fork then set up a pull request, but trying to convert the filename into a float suggests I am entirely misunderstanding your intent.