Response parsing error

blizzardfinnegan commented

2023-06-21 10:22:52 -04:00

Owner

In the current version of this software, it is possible for a device to temporarily fall out of the predefined state machine, and remain uncaught for a single iteration. This appears to be mostly an edge case, however it will affect the final generated data.

Replicating the issue in a contained environment will be somewhat difficult, as it is due to serial response timings which cannot be manipulated easily. The following steps for reproduction assume that a control over response times is possible.

Reboot a device.
Once device has rebooted, run go_to_lifecycle_menu (See: device.rs), this logs in, then sends the debugmenu command.
Device takes sufficiently long to load the debug menu that the only thing received back from the device is the echo from the send command.
Device object catches unknown response, marks as error. Breaks out of loop.
Device object believes itself to be in State::DebugMenu, when it isn't yet.
Device object sends the LifecycleMenu command to TTY, despite not knowing what state the device on the other end of the TTY is in. Crucially, the device on the other end of the TTY drops the LifecycleMenu command rather than storing it. This leads to the device falling out of the expected state in the state machine.
Continues following expected sequence for iteration, according to the Device object. Iteration fails after some time, sending the Quit command to the TTY, which reboots the device successfully.

In the current version of this software, it is possible for a device to temporarily fall out of the predefined state machine, and remain uncaught for a single iteration. This appears to be mostly an edge case, however it will affect the final generated data. --- Replicating the issue in a contained environment will be somewhat difficult, as it is due to serial response timings which cannot be manipulated easily. The following steps for reproduction assume that a control over response times is possible. 1. Reboot a device. 2. Once device has rebooted, run `go_to_lifecycle_menu` (See: `device.rs`), this logs in, then sends the debugmenu command. 3. Device takes sufficiently long to load the debug menu that the only thing received back from the device is the echo from the send command. 4. Device object catches unknown response, marks as error. Breaks out of loop. 5. Device object believes itself to be in State::DebugMenu, when it isn't yet. 6. Device object sends the LifecycleMenu command to TTY, despite not knowing what state the device on the other end of the TTY is in. Crucially, the device on the other end of the TTY drops the LifecycleMenu command rather than storing it. This leads to the device falling out of the expected state in the state machine. 7. Continues following expected sequence for iteration, according to the Device object. Iteration fails after some time, sending the Quit command to the TTY, which reboots the device successfully.