Dectmon only recording data partially?

Patrick McHardy kaber at
Mon Nov 15 14:44:49 UTC 2010

On 15.11.2010 15:29, Erik Tews wrote:
> Am Montag, den 15.11.2010, 15:25 +0100 schrieb Erik Tews:
>> 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?
> OK, so even without the monitor flag. my PC is now scanning for the FP
> since multiple minutes. So I assume that the problem is not related to
> the monitor flag.

You could try to add to dect_mac_irc_tick, the DECT_TRANSCEIVER_UNLOCKED
case, around the carrier increment:

if (net_random() > 0x7fffffff) {

to have it stay on the same carrier half the time.

More information about the linux-dect mailing list