Insteon: ALDB_i2 Link Scan, Link Data Received out of Order May Cause Queue to Stall

[krkeegan]

This issue was discovered by @pmatis.

The sequence of events appears to be as follows, these events occur in the scanning of an ALDB_i2 link table:

1. MH issues a read command for link address 0FE7
2. ACK Received
3. Link Data for 0FE7 is received
4. MH issues a read command for link address 0FDF
5. Ack Received
6. Link Data for 0FE7 is received <-- duplicate out of order packet
   6a. Because of the long delay, this packet is not caught as a duplicate packet
7. This message is passed to the ALDB_i2 Link parser which perceives this as a corrupt response.
8. The parser then tries to queue a request to read link address 0FDF again
9. MH catches this as an attempt to queue a command already in the queue and ignores it
10. Another ACK is received
    10a. It is unclear what this is in response to
11. The ALDB_i2 Link parser ignores the ACK because it can't correlate it to a sent message
12. Link Data for 0FDF is finally received
13. The ALDB_i2 Link parser ignores the link data claiming that an ACK was not received.
14. At this point, the queue for the device stalls and nothing else happens.

Quick Diagnosis:

1. At step 8, I don't think the parser should be trying to queue a new message request. Instead, the parser should just fail to acknowledge receiving anything, this should result in the message handler sending a message retry in its normal course of action.
2. Steps 11 and 13. It is unclear to me why the parser initially claims that it cannot correlate the ACK to anything, but then subsequently claims that an ACK was never received that it was expecting.
3. It is also unclear why the queue timer is being cleared and never reset. This is what causes the entire process to stall.