Closed kb1lqd closed 7 years ago
I'm closing this issue as the root cause analysis showed that the bug lives in the software FLASK interface and allowable byte values ensuring safe framing without BASE 64 encoding. Moving issue to software section.
New bug issue ticket: https://github.com/FaradayRF/Faraday-Software/issues/43
When attempting to read a factory reset device the JSON decoding fails.
Reading the configuration from a unit programmed with the device configuration tool works fine.
I suspect that the factory default setting firmware code is slightly incorrect from that expected from the device configuration tool.
Device Configuration Software Application Packet
Firmware Default Configuration
Device Configuration Module Library
I am getting data back from the unit but it is in a default state, the unit is transferring BASE64 data to the proxy and device configuration program but the program errors on the RETURN of the device configuration application after it has been unpacked. I think I might have been dumb and I'm trying to push non BASE64 encoded data over localhost and I got lucky that in prior configurations invalid symbols were not transferred. I believe I need to re-encoded it into BASE64.
REV B1 Faraday
Debugging the device configuration default factory and user-configured operational bug. on a known working REV B1.
Pre-Configured
Testing the device programming status of a working and configured REV B1. This unit has a good prior callsign and setup and I am running device configuration script to see if it reads and writes properly.
Yes the unit correctly reads and reprograms:
The CCS memory browser shows device info segment 0x1800 as:
Resetting to factory default (needs to be made into a command from UART):
I manually in debug mode set the programmed bit to 0.
The memory browser now shows the memory contents of device information segment as:
The unit now fails to read the current device configuration:
This confirms that the origine of the root cause is the default factory reset of the device configuration.
Root Cause Analysis
The device information configuration memory definition:
Device Configuration Bitmask (1 Byte)
Callsign (9 Bytes)
Callsign Length (1 Byte)
Callsign ID (1 Byte)
Default GPIO P3 (1 Byte)
Default GPIO P4 (1 Byte)
Default GPIO P5 (1 Byte)
Boot Frequency (3 Bytes) Assignment says max size is 1 byte which is wrong, numbers below look not correct! Maybe this is causing a calculate frequency error on parsing during a read?
Catching Error - Device Configuration Application
I updated the device configuration code to have a try/except statement along with debugging print statements to determine the location of the error code.
Looks like it can't decode the BASE64. I modified the code again to print the data retrieve.
Data returned is None type. Not what we want...
I just realized that I had the unit debug paused.... Running it again shows a much different story!
The data is parsing! It looks like the error occurs during the transfer of the parsed data from the application through the GET command:
I believe I'm passing dangerous characters that are causing framing errors (not byte escaped!) through the FLASK server GET interface. This is a credible failure mode and the entire reason BASE64 is used. A working configured unit gets lucky not sending the frame "start byte".
I'm going to try to re-encode into BASE64 prior to transfering data over the GET command from the Tutorial #3 for device configuration I'm running.