15 Nov
2010
15 Nov
'10
3:42 p.m.
On 15.11.2010 15:25, Erik Tews wrote:
Am Montag, den 15.11.2010, 15:14 +0100 schrieb Patrick
McHardy:
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.
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?