On 15.11.2010 15:25, Erik Tews wrote:
Am Montag, den 15.11.2010, 15:14 +0100 schrieb Patrick McHardy:
Indeed, the multi-frame resync timer has timed out (mfn:9, max is 8). It seems it didn't receive a valid tail message over the entire previous period, judging by the log. I'd guess that the transceiver has drifted off too much. You should be able to see that by watching the output of dect-transceiver-list for the slot in question.
Does locking to that PF work if you don't use monitor mode?
I will check that.
One strange thing, while scanning, I get a lot of messages with:
identities information: e: 0 class: 0 emc: ....
So my kernel finds a lot of PPs around it, but the Fritzbox is in the same room, only a few meters away, and it takes a minute or more until the Fritzbox pops up here.
As I understand the code at the moment, during the initial scan for the FP, the timing of the transmitter doesn't really matter. So we might assume that it is not a timing-problem which is responseable for this effect?
Correct, timing shouldn't matter, at least for receiving the first identity information frame from that FP. The scan isn't really optimal currently though, as soon as it has received all information from one FP, it switches to the next carrier. With some bad luck, this might cause it to miss an FP indefinitely. What it should really do is stay on the same carrier and only switch if the next FP it discovery is already known.