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/.
Erik Tews e_tews at cdc.informatik.tu-darmstadt.deAm 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.osmocom.org/pipermail/linux-dect/attachments/20101115/b061cf40/attachment.bin>