v1.2.0rc1

[JosephHewitt]

Release Candidate version 1.2.0rc1

This version is not yet considered stable due to lack of testing.

No additional features are planned for v1.2.0.

Changes since 1.2.0b5:

• Added support for @CoD-Segfault Mini Wardriver Rev2
• Implement automatic board detection Add support for using ESP32 pins to identify board for configuration. #147 (thanks @CoD-Segfault)

Important note for users on previous betas:

Many of the previous releases contained issues with OTA updates. This release has no known problems which can prevent OTA updates from being installed. It is recommended to install this update manually if you are experiencing problems updating. Please ensure you also update B if you did not install the previous update.

Known issues

• You may be prompted to install an already-installed update for Side B if you installed it manually (with Arduino IDE, esptool, etc) or after performing a factory reset. This will stop happening once you install any update for Side B using the OTA function.

---

This discussion was created from the release v1.2.0rc1.

[pejacoby]

Hi Joseph, afraid I'm going be that guy again having issues with OTA updates on side B. I'm seeing the same behavior I saw in the previous release with the whole process running fine on side A and looking good on B until the end of the B update, failing with Hash Mismatch.

I tried an OTA update from the GUI letting everything get downloaded. That failed.
Then I pulled down the 1.2.0rc1 release ZIP file and uploaded the B.ino.bin from B/build/esp32.esp32.esp32 directory. That too failed.

The hashes match on inspection and in the hashes.txt file. Still not sure what's throwing things off. Thoughts?

This is on my WiSpy build from HackerBoxes.

[JosephHewitt]

I suspect that you could be seeing the result of a hardware issue, and that might also explain some of the other issues you have reported. My theory is that something is interfering with the communication between the 2 ESP's causing the data to get corrupt.

Would it be possible for you to capture the serial output of B during an update? When/if it fails you should see HASH MISMATCH: printed along with 2 hashes (the actual vs the expected). If you do this twice and get a different hash for both attempts, that proves the file is being corrupt during the transfer. Otherwise it could be a bug similar to #85 which I can investigate.

If it does turn out to be corruption, I will improve the communication from the software side so that hopefully corrupt messages can be detected and corrected rather than making the whole thing fail. I did have a task open for this a while ago (#73) but closed it since I was never actually able to cause any corruption on the communication during my tests.

Thanks for your help with this :)

[CoD-Segfault]

I have also seen corruption in the past where it was giving me different hashes on every transfer. The problem went away when I slowed down the transfer rate between the two ESP32s. I suspect (without any actual proof) that it may be occasionally filling the serial data buffer during hash calculation on B. If this is the case, a potential solution may be to do smaller transfers using less computationally heavy error checking like CRC, then doing a retry if it fails. The hash was already verified on A, so you wouldn't need to run the same check on B. It would probably be faster as well.

[JosephHewitt]

@CoD-Segfault That is likely corruption from something electrical rather than the buffers. Slowing down the baud rate makes electrical interference less likely to occur (but indeed could also help fix some software problems). There is basic flow control between the 2 ESP's during an update. Specifically A only sends 110 bytes, waits for B to process it, then sends the next 110 bytes. The buffers are all bigger than 110 bytes so nothing should be getting filled up. Doing a CRC for each block does mean that failed blocks can be resent without failing the entire update during the final check, so I can look into that some more, but I have no reason to suspect the current hashing implementation is the cause of this issue.

[pejacoby]

Here's console output from two runs of a side B updates -- the hash came out different both times :(

First run, I had the B.bin file on the SD card from a previous manual upload from your Build files, so I just ran the manual update process as the unit saw there was an update available.

22:35:43.650 -> Scan of channel 1 returned 0
22:35:45.654 -> Devices found: 24
22:35:45.654 -> Scan done!
22:35:45.687 -> Core2 OTA prep
22:35:45.785 -> Scan of channel 6 returned 1
22:35:45.882 -> Scan of channel 11 returned 0
22:35:46.015 -> Scan of channel 14 returned 0
22:35:46.147 -> Scan of channel 1 returned 0
22:35:46.147 -> Core1 OTA
22:35:46.147 -> OTA preamble
22:35:49.601 -> OTA preamble end
22:39:05.819 -> HASH MISMATCH:
22:39:05.819 -> 2b28ad6a6081161edae3cc5e707db6ee371cc381900f71ab6a1dbff8e48ddce3
22:39:05.819 -> 4cd97a496afc73abba066ae3f86046d4612728304e795d1089ef8fb69ffed0e7
22:39:05.819 -> ets Jul 29 2019 12:21:46
22:39:05.819 ->

Trying again, I did a factory reset, re-added my WiFi network configs, and had to stop quick to move all my older files out so they didn't all get pushed to Wigle again. Once clear, I started up again, I deleted B.bin via the web interface, and went through the manual upload process for B.bin from the same data source as the first time (same Build files)

22:49:04.991 -> Scan of channel 6 returned 2
22:49:05.090 -> Core2 OTA prep
22:49:05.090 -> Scan of channel 11 returned 0
22:49:05.222 -> Scan of channel 14 returned 0
22:49:05.353 -> Scan of channel 1 returned 0
22:49:05.353 -> Core1 OTA
22:49:05.353 -> OTA preamble
22:49:08.776 -> OTA preamble end
22:52:26.021 -> Upload complete
22:52:26.021 -> HASH MISMATCH:
22:52:26.021 -> ff7b3c9e59548f0a196349fb1445202dc02a80590d40f792012740acda72ce43
22:52:26.021 -> 4cd97a496afc73abba066ae3f86046d4612728304e795d1089ef8fb69ffed0e7
22:52:26.068 -> ets Jul 29 2019 12:21:46
22:52:26.068 ->

One thing I hadn't mentioned -- I have been powering the WiSpy via the B board since I first started using it. Cables just routed easier. Should I be powering via the A board? Would that make any difference?

[JosephHewitt]

Thank you for trying this! So this does indeed look like a corruption issue between the 2 ESP's. I will reopen #73 which should address it.

Have you checked the solder joints of your device recently? I wonder if over time one of them has gone bad causing a bad connection somewhere. I was never able to cause any kinds of corruption on my test wardrivers without doing something physical to the connection.

It shouldn't make any difference which board you connect the power to.

[JosephHewitt]

Just to keep you in the loop regarding this:

The plan is to release 1.2.0 without this issue being fixed. The reason is because the fix for this would be a significant refactoring of the OTA code, and then I would like to run through a full beta phase again to find any issues that refactoring may have introduced.

I would prefer to do that at a later date when other large changes are introduced (eg, switching to ESP32 board version 3.0 and the latest libraries which is a high priority) so that everything can be tested together in a single beta phase.

This does mean that you will likely have to install 1.2.0 manually when it is released, but hopefully the issue can be addressed shortly afterwards. Sorry for the inconvenience.

[pejacoby]

No worries at all, thanks for the update! Manual install is no issue here, your instructions work perfectly so it's not an issue.

[pejacoby]

Happy to help. Can I run with b5 on the B board and rc1 on the A board? If it's useful I can revert A back to b5 so the full OTA process can run, just let me know.

I will give the boards a visual inspection and see if there is anything obvious - not my area of expertise but I'll see what's there.

[JosephHewitt]

Sorry for the delay in responding. Yes, it is fine to run b5 and rc1 together like that.