PiBox » Iron Man

The problem here will be that the server side is written in JS using Node. And there are a ton of Node modules in use, likely for things like encrypting and decrypting.

I need to switch to a PHP only implementation on the server side. Client side JS is fine. imwww is implemented like this for configuring the AP and Client Wifi connections (which is what PiNet on PiSentry and PiStore use).

So before I can continue work on sensors for Ironman, I need to port imrest from Node/JS to PHP.

The port is essentially complete. The unit tests are written but not fully working (which means there are bugs in the port).

Tests 3, 4 and 5 (see unittest.sh) generate valgrind errors. I need to fix those next. Then write some negative tests and add some configuration options to make the tests more flexible.

Actually, running the tests one at a time and restarting valgrind on each test shows no errors. But if I run tests 1, 2 and 3 without restarting valgrind I get the following:

==3962864== Invalid write of size 1
==3962864==    at 0x10DAD1: cryptoDoDecode (crypto.c:92)
==3962864==    by 0x10E0C2: cryptoDecrypt (crypto.c:285)
==3962864==    by 0x10F02C: deviceListDevices (device.c:441)
==3962864==    by 0x10BB99: handlePost (imrest.c:165)
==3962864==    by 0x10BB99: frontEnd (imrest.c:265)
==3962864==    by 0x10BB99: frontEnd (imrest.c:248)
==3962864==    by 0x1190EB: mg_call (mongoose.c:1351)
==3962864==    by 0x1190EB: http_cb.part.0 (mongoose.c:3231)
==3962864==    by 0x118839: mg_call (mongoose.c:1352)
==3962864==    by 0x118839: iolog (mongoose.c:7128)
==3962864==    by 0x11F833: read_conn (mongoose.c:7316)
==3962864==    by 0x11F833: mg_mgr_poll (mongoose.c:7724)
==3962864==    by 0x10B75C: main (imrest.c:340)
==3962864==  Address 0x5b61e40 is 0 bytes after a block of size 32 alloc'd
==3962864==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==3962864==    by 0x10D781: unbase64 (base64.c:258)
==3962864==    by 0x10DA09: cryptoDoDecode (crypto.c:74)
==3962864==    by 0x10E0C2: cryptoDecrypt (crypto.c:285)
==3962864==    by 0x10F02C: deviceListDevices (device.c:441)
==3962864==    by 0x10BB99: handlePost (imrest.c:165)
==3962864==    by 0x10BB99: frontEnd (imrest.c:265)
==3962864==    by 0x10BB99: frontEnd (imrest.c:248)
==3962864==    by 0x1190EB: mg_call (mongoose.c:1351)
==3962864==    by 0x1190EB: http_cb.part.0 (mongoose.c:3231)
==3962864==    by 0x118839: mg_call (mongoose.c:1352)
==3962864==    by 0x118839: iolog (mongoose.c:7128)
==3962864==    by 0x11F833: read_conn (mongoose.c:7316)
==3962864==    by 0x11F833: mg_mgr_poll (mongoose.c:7724)
==3962864==    by 0x10B75C: main (imrest.c:340)
==3962864==
==3962864== Invalid read of size 1
==3962864==    at 0x483BC94: strlen (vg_replace_strmem.c:459)
==3962864==    by 0x4AF3B77: __vfprintf_internal (vfprintf-internal.c:1647)
==3962864==    by 0x4B04605: __vsnprintf_internal (vsnprintf.c:114)
==3962864==    by 0x49AB240: _piboxLogger (log.c:262)
==3962864==    by 0x10DAEF: cryptoDoDecode (crypto.c:94)
==3962864==    by 0x10E0C2: cryptoDecrypt (crypto.c:285)
==3962864==    by 0x10F02C: deviceListDevices (device.c:441)
==3962864==    by 0x10BB99: handlePost (imrest.c:165)
==3962864==    by 0x10BB99: frontEnd (imrest.c:265)
==3962864==    by 0x10BB99: frontEnd (imrest.c:248)
==3962864==    by 0x1190EB: mg_call (mongoose.c:1351)
==3962864==    by 0x1190EB: http_cb.part.0 (mongoose.c:3231)
==3962864==    by 0x118839: mg_call (mongoose.c:1352)
==3962864==    by 0x118839: iolog (mongoose.c:7128)
==3962864==    by 0x11F833: read_conn (mongoose.c:7316)
==3962864==    by 0x11F833: mg_mgr_poll (mongoose.c:7724)
==3962864==    by 0x10B75C: main (imrest.c:340)
==3962864==  Address 0x5b61e40 is 0 bytes after a block of size 32 alloc'd
==3962864==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==3962864==    by 0x10D781: unbase64 (base64.c:258)
==3962864==    by 0x10DA09: cryptoDoDecode (crypto.c:74)
==3962864==    by 0x10E0C2: cryptoDecrypt (crypto.c:285)
==3962864==    by 0x10F02C: deviceListDevices (device.c:441)
==3962864==    by 0x10BB99: handlePost (imrest.c:165)
==3962864==    by 0x10BB99: frontEnd (imrest.c:265)
==3962864==    by 0x10BB99: frontEnd (imrest.c:248)
==3962864==    by 0x1190EB: mg_call (mongoose.c:1351)
==3962864==    by 0x1190EB: http_cb.part.0 (mongoose.c:3231)
==3962864==    by 0x118839: mg_call (mongoose.c:1352)
==3962864==    by 0x118839: iolog (mongoose.c:7128)
==3962864==    by 0x11F833: read_conn (mongoose.c:7316)
==3962864==    by 0x11F833: mg_mgr_poll (mongoose.c:7724)
==3962864==    by 0x10B75C: main (imrest.c:340)

I'm pretty sure this is an off-by-1 allocation problem for a buffer. Possibly more than 1. Note that the problem only shows up on multiple API calls in a single session.

• 1
• 1, 2
• 1, 2, 3

And each unit test was also run by itself. I'll need to continue running these tests, adding one more to the list each time. Then try running them in varying order.

Okay, I was actually doing things correctly. But I had a bug in where I did matching of POST's URIs. Fixing that seemed to clear up all valgrind errors.

Then I found bugs in cross builds and packaging. I've now fixed those.

There are updates to the lightsw Arduino and Jarvis code required to match minor changes to the C port of imrest, this is essentially done. I'll debug it with Jarvis and sensors later, though I think the unit tests are good enough to validate proper operation (but not necessarily handling of bad inputs).

The metabuild has been tested with this new package.

So this is essentially done for now. New issues will be opened as bugs are found.

Code committed and pushed.

Closing issue.