This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/linux-dect@lists.osmocom.org/.
Patrick McHardy kaber at trash.netOn 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.