ALDB_Delta: Force a link database change for ALDB_Delta 00 #3
Assignees
Labels
Comments
ghost
assigned 
|
Yup, even on my newest device, pulling the air gap resulted in resetting the aldb_delta to 00. |
|
Initial code in SHA: 5e36d50dc5. Doesn't quite work right yet. Logic not fully thought through |
krkeegan
added a commit
that referenced
this issue
Feb 5, 2013
The ALDB_Delta gets reset to 00 when devices lose power. The ALDB_Delta also gets reset to 00 when the devices are factory reset. Since we can't distinguish between these two states, we never allow the ALDB_delta to stay at 00. If a devices loses power, the ALDB_delta will change and a full scan will be conducted. At the conclusion of the scan we attempt to query and store the aldb_delta. If the aldb_delta is 00 we find the first empty address on the device. We then peek the aldb_flag(the first byte) of this address We then poke the same value back into the device. We use an empty address to decrease the potential harm from writing an incorrect byte if something goes wrong We then scan this address, being empty, the scan should end after the first byte We then query the ALDB_delta which should now be 01 since we "wrote" a single byte. The value increases even though the data didn't change. I reverted the previous commit as I was headed down the wrong path. Solves #3
krkeegan
added a commit
that referenced
this issue
Feb 19, 2013
The ALDB_Delta gets reset to 00 when devices lose power. The ALDB_Delta also gets reset to 00 when the devices are factory reset. Since we can't distinguish between these two states, we never allow the ALDB_delta to stay at 00. If a devices loses power, the ALDB_delta will change and a full scan will be conducted. At the conclusion of the scan we attempt to query and store the aldb_delta. If the aldb_delta is 00 we find the first empty address on the device. We then peek the aldb_flag(the first byte) of this address We then poke the same value back into the device. We use an empty address to decrease the potential harm from writing an incorrect byte if something goes wrong We then scan this address, being empty, the scan should end after the first byte We then query the ALDB_delta which should now be 01 since we "wrote" a single byte. The value increases even though the data didn't change. I reverted the previous commit as I was headed down the wrong path. Solves #3
krkeegan
pushed a commit
that referenced
this issue
Nov 6, 2013
Added Alsa support to allow different sound card channels to be PA rooms through amixer in Linux.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It looks like ALDB_Delta gets reset to 00 whenever a device loses power, at least some devices. Likely the ALDB_Delta is stored in volatile memory in these devices. However the link databse is not stored in volatile memory.
As a result we can't determine the state of a link database on a device where the ALDB_delta = 0. This is because the device may be factory reset, or the device may have been programmed and simply lost power. In the later case, if we scan the device at this state and log the ALDB_delta of 0, we will not be able to detect a factory reset.
A small problem to be sure, but there is the potential for error.
The solution may be to simply force write something to the device when ever the ALDB_delta equals 0, thus increasing the value.
The question becomes, can we write something that doesn't increase or really alter the devices ALDB size? We don't want to have the situation where a device which intermittently loses power has a link device that constantly grows in size.
The text was updated successfully, but these errors were encountered: