NSH equivalent for ChibiOS

Hi all,

I’m trying to follow the instructions to do some auth signing per this page: https://ardupilot.org/dev/docs/how-to-use-the-auth-command-to-sign-a-pixhawk-board-with-your-certificate-of-authenticity.html but am getting stuck at the point of connecting to the Pixhawk terminal.

I have a Cube Orange (and a Black, same results) running Copter 4.0.4 on ChibiOS as I believe is the standard for 4.x. All of the instructions to connect to the Pixhawk in this manner rely on NSH, which I have come to understand is short for ‘NuttX SHell’ and therefore doesn’t work on ChibiOS. In Mission Planner, I’ve tried all the terminal connections (over USB) short of SSH to get into the terminal, but haven’t had any success.

I’ve also tried using a USB-FTDI (well, technically it’s a TTL converter, but I think without flow control that should be fine, no?) into the GPS2, TELEM1, TELEM2, and USB ports with all the terminal options also with no luck (baud rate set to 57600 for all of those per instructions).

Is this auth command still a possibility in 4.x? I would be fairly sure that if I could connect to the system terminal I could compile the auth.c and load it, but without connecting, I can’t get very far…

Thanks in advance!

p.s. this is the only other forum post I’ve found anywhere about this issue: Signing of pixhawk with Certificate of authenticity

p.p.s my ultimate goal is to be able to detect tampering with the parameters on the board. We’d like to be able to detect if our customers have edited parameters for warranty reasons, and as far as I can tell the auth command is the best bet to do that; but if there’s other options I’m open to those too.

I’m not sure anyone has tried this under ChibiOS, but I don’t think there’s anything rtos specific in it. iirc @DavidBuzz was the original author - he would know better.
That aside, the way to prevent tampering with Params is to mark them Read Only.
https://ardupilot.org/dev/docs/apjtools-intro.html is one method of doing that. There’s a slightly neater way if you compile your own firmware.

I gave the apj_tools.py a test – resounding success! So far I have no need for custom-compiled firmware (nor do I have the bandwidth to do proper testing of), but will keep the default file in mind for future if that’s ever needed.

Something else to note – although the parameters were marked as readonly, MP allowed me to modify them and reported success when I clicked ‘Write Params’ as normal. Going back to the messages tab showed that it was denied, and a param refresh brings it back to the original value.

What I found with the NSH connection was that MP told me “COM port opened”, and let me type, but I never got the “nsh>” prompt seen in screenshots/code snippets on the wiki. Anything I typed would appear, but as soon as I hit enter it would vanish as if I never typed it. Could not get anything to produce output.

In the mean time, I have some experimentation I want to try… I’m hopeful although doubtful this @READONLY trick might just work over the regular MP param upload too. Will report back if it works.

Thank you much!

I¢m trying to follow the instructions to do some auth signing per this page: How to use the “auth” command to sign a Pixhawk Board with your Certificate of Authenticity — Dev documentation but am getting stuck at the point of connecting to the Pixhawk terminal.

I think you can sensibly consider that feature dead.

p.p.s my ultimate goal is to be able to detect tampering with the parameters on the board. We¢d like to be able to detect if our customers have edited parameters for warranty reasons, and as far as I can tell the auth command is the best bet to do that; but if there¢s other options I¢m open to those too.

Consider setting these parameters in ROMFS so the users can’t modify the
parameters without reflashing the firmware. This will keep your honest
customers honest.

Peter

completely out of date documentation. page should be retired. i’ve just done a PR to label that page as ‘archived’ , and also throw in a few url’s to the original code in question should anyone really want to re-visit it or see how it worked. in short, the only thing the ‘auth’ command did/does was allow a board manufacturer to positively identify THEIR hardware with a digital signature , and to have that info persist over a flash/reset/reboot etc. https://github.com/ArduPilot/ardupilot_wiki/pull/3495/files

Hi all,

Thanks for the info! Turns out the auth command may not have been exactly what I was looking for anyways but setting the params in ROMFS is a perfect alternative.

Thanks!