8 Nov
2010
8 Nov
'10
6:27 p.m.
Hi
I have a strange problem with dectmon. I would like to monitor the
conversations between a Siemens AS150 and it's base station. I started
the cluster in monitoring mode with the same emc and fpn as the original
base station in pp mode:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp --monitor
dect-cell-add --name cell0 --cluster cluster0
dect-transceiver-bind --transceiver trx0 --cell cell0
Now, when I launch dectmon, I get these messages:
# ./dectmon -n yes
netlink: cluster0: mode PP ARI: class A: EMC: 0ff6 FPN: 0deb7
LCE: set default pmid e94bd
LCE: registered protocol 0 (Link Control)
LCE: registered protocol 3 (Call Control)
LCE: registered protocol 4 (Call Independant Supplementary Services)
LCE: registered protocol 6 (ConnectionLess Message Service)
LCE: registered protocol 5 (Mobility Management)
netlink: message group: 4
netlink: FPC: full_slot,page_repetition,basic_a_field_setup,in_min_delay
netlink: HLC:
adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,location_registration
unknown
unknown
netlink: message group: 4
Should't there be more output? I am sure that at least some location
registration or authentication messages are exchanged here.
I am running 2.6.36, but I did not update to the latest version in the
git tree yet.
9 Nov
9 Nov
11:09 a.m.
Am 08.11.2010 18:27, schrieb Erik Tews:
Hi
I have a strange problem with dectmon. I would like to monitor the
conversations between a Siemens AS150 and it's base station. I started
the cluster in monitoring mode with the same emc and fpn as the original
base station in pp mode:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp --monitor
dect-cell-add --name cell0 --cluster cluster0
dect-transceiver-bind --transceiver trx0 --cell cell0
Now, when I launch dectmon, I get these messages:
# ./dectmon -n yes
netlink: cluster0: mode PP ARI: class A: EMC: 0ff6 FPN: 0deb7
LCE: set default pmid e94bd
LCE: registered protocol 0 (Link Control)
LCE: registered protocol 3 (Call Control)
LCE: registered protocol 4 (Call Independant Supplementary Services)
LCE: registered protocol 6 (ConnectionLess Message Service)
LCE: registered protocol 5 (Mobility Management)
netlink: message group: 4
netlink: FPC: full_slot,page_repetition,basic_a_field_setup,in_min_delay
netlink: HLC:
adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,location_registration
unknown
unknown
netlink: message group: 4
Should't there be more output? I am sure that at least some location
registration or authentication messages are exchanged here.
I am running 2.6.36, but I did not update to the latest version in the
git tree yet.
This usually happens when the monitor is not properly locked to the
station. If you enable debugging in the kernel, does it show DBC
messages?
11:16 a.m.
Am 08.11.2010 18:27, schrieb Erik Tews:
Hi
I have a strange problem with dectmon. I would like to monitor the
conversations between a Siemens AS150 and it's base station. I started
the cluster in monitoring mode with the same emc and fpn as the original
base station in pp mode:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp --monitor
Actually, this seems to be the problem, the syntax is "--flags monitor".
dect-cell-add --name cell0 --cluster cluster0
dect-transceiver-bind --transceiver trx0 --cell cell0
14 Nov
14 Nov
1:55 a.m.
I now switched that to:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp
dect-cell-add --name cell0 --cluster cluster0 --flags monitor
dect-transceiver-bind --transceiver trx0 --cell cell0
But I still have the same problem.
Do I need a newer kernel than commit
75a0d091dc8074ef940932cf6027fcdf59277070 to run the kernel in
monitoring-mode?
Am Dienstag, den 09.11.2010, 11:16 +0100 schrieb Patrick McHardy:
Am 08.11.2010 18:27, schrieb Erik Tews:
Hi
I have a strange problem with dectmon. I would like to monitor the
conversations between a Siemens AS150 and it's base station. I started
the cluster in monitoring mode with the same emc and fpn as the original
base station in pp mode:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp --monitor
Actually, this seems to be the problem, the syntax is "--flags monitor".
dect-cell-add --name cell0 --cluster cluster0
dect-transceiver-bind --transceiver trx0 --cell cell0
2:04 p.m.
On 14.11.2010 01:55, Erik Tews wrote:
I now switched that to:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp
dect-cell-add --name cell0 --cluster cluster0 --flags monitor
dect-transceiver-bind --transceiver trx0 --cell cell0
But I still have the same problem.
Do I need a newer kernel than commit
75a0d091dc8074ef940932cf6027fcdf59277070 to run the kernel in
monitoring-mode?
No, that one should be fine. If you're still seeing
netlink: message group: 4
without FPC and HLC following, that means that the PP lost lock
with the FP. If you enable debugging for mac_csf.c, you should
see the reason in the logs.
2:10 p.m.
On 14.11.2010 14:04, Patrick McHardy wrote:
On 14.11.2010 01:55, Erik Tews wrote:
BTW:
I now switched that to:
dect-cluster-add --name cluster0 --emc $EMC --fpn $FPN --mode pp
dect-cell-add --name cell0 --cluster cluster0 --flags monitor
dect-transceiver-bind --transceiver trx0 --cell cell0
But I still have the same problem.
Do I need a newer kernel than commit
75a0d091dc8074ef940932cf6027fcdf59277070 to run the kernel in
monitoring-mode?
No, that one should be fine. If you're still seeing
netlink: message group: 4
without FPC and HLC following, that means that the PP lost lock
with the FP. If you enable debugging for mac_csf.c, you should
see the reason in the logs.
netlink: message group: 4
netlink: FPC: full_slot,page_repetition,basic_a_field_setup,in_min_delay
netlink: HLC:
adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,location_registration
It seems your FP doesn't support ciphering, so its possible that it
doesn't broadcast the multi-frame number, which my stack expects.
It shouldn't have locked to the FP in that case though.
Perhaps the FP broadcasts the MFN at a lesser frequency than defined
in the standard - if the stack doesn't receive the MFN at least every
8 multiframes (T216), it unlocks from the FP.
2:15 p.m.
Am Sonntag, den 14.11.2010, 14:10 +0100 schrieb Patrick McHardy:
BTW:
Well, I tried the base station of my AS150 phone, where I am not sure if
it supports ciphering, I guess it doesn't support ciphering.
However, I tried my Fritzbox 7270 too, which definitely supports
ciphering. I will try again with my Fritzbox.
netlink: message group: 4
netlink: FPC:
full_slot,page_repetition,basic_a_field_setup,in_min_delay
netlink: HLC:
adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,location_registration
It seems your FP doesn't support ciphering, so its possible that it
doesn't broadcast the multi-frame number, which my stack expects.
It shouldn't have locked to the FP in that case though.
Perhaps the FP broadcasts the MFN at a lesser frequency than defined
in the standard - if the stack doesn't receive the MFN at least every
8 multiframes (T216), it unlocks from the FP.
15 Nov
15 Nov
3:06 p.m.
Am Sonntag, den 14.11.2010, 14:15 +0100 schrieb Erik Tews:
Am Sonntag, den 14.11.2010, 14:10 +0100 schrieb
Patrick McHardy:
OK, here is the kern.log for my Fritzbox. I am running the PCI card on a
32 bit Linux system. It takes minutes, until my computer in monitor-mode
has found the Fritzbox. During the discovery, it finds a lot of other
FPs. I am running that test in a very populated area with most probably
a lot of other phones around my house.
What happens after my box has found the Fritzbox and got a lock on it
is, that it seems to be able to hold the lock for a few seconds, but
then runs into a timeout. Then it needs some seconds, but more like
10-40 to get the lock again.
Nov 15 14:57:49 pc2 kernel: [603017.486809] cell0: RX 218329.02.00: timer cd139df8:
218329.2.0
Nov 15 14:57:49 pc2 kernel: [603017.486817] cell0: RX 218329.02.00: timer cd139df8:
schedule for 218329.3.0
Nov 15 14:57:49 pc2 kernel: [603017.489319] cell0: RX 218329.01.23: timer cd139dd8:
218329.1.23
Nov 15 14:57:49 pc2 kernel: [603017.489326] cell0: RX 218329.01.23: timer cd139dd8:
schedule for 218329.2.23
Nov 15 14:57:49 pc2 kernel: [603017.494315] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.496818] cell0: RX 218329.03.00: timer cd139df8:
218329.3.0
Nov 15 14:57:49 pc2 kernel: [603017.496827] cell0: RX 218329.03.00: timer cd139df8:
schedule for 218329.4.0
Nov 15 14:57:49 pc2 kernel: [603017.499531] RX 218329.02.20: trx0: Q1: 0 Q2: 1 A/B: 40
carrier: 6 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.499541] cell0: RX 218329.02.23: timer cd139dd8:
218329.2.23
Nov 15 14:57:49 pc2 kernel: [603017.499546] cell0: RX 218329.02.23: timer cd139dd8:
schedule for 218329.3.23
Nov 15 14:57:49 pc2 kernel: [603017.502040] RX 218329.03.04: trx0: Q1: 1 Q2: 1 A/B: 24
carrier: 8 A-CRC: 0 X-CRC: 0 DBC slot 6 carrier 7: RSSI: selection: 0 now: 246
Nov 15 14:57:49 pc2 kernel: [603017.506808] cell0: RX 218329.04.00: timer cd139df8:
218329.4.0
Nov 15 14:57:49 pc2 kernel: [603017.506816] cell0: RX 218329.04.00: timer cd139df8:
schedule for 218329.5.0
Nov 15 14:57:49 pc2 kernel: [603017.509317] cell0: RX 218329.03.23: timer cd139dd8:
218329.3.23
Nov 15 14:57:49 pc2 kernel: [603017.509324] cell0: RX 218329.03.23: timer cd139dd8:
schedule for 218329.4.23
Nov 15 14:57:49 pc2 kernel: [603017.514539] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.514554] RX 218329.04.10: trx0: Q1: 1 Q2: 0 A/B: ae
carrier: 9 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.516815] cell0: RX 218329.05.00: timer cd139df8:
218329.5.0
Nov 15 14:57:49 pc2 kernel: [603017.516824] cell0: RX 218329.05.00: timer cd139df8:
schedule for 218329.6.0
Nov 15 14:57:49 pc2 kernel: [603017.519301] cell0: RX 218329.04.23: timer cd139dd8:
218329.4.23
Nov 15 14:57:49 pc2 kernel: [603017.519306] cell0: RX 218329.04.23: timer cd139dd8:
schedule for 218329.5.23
Nov 15 14:57:49 pc2 kernel: [603017.524308] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.526805] cell0: RX 218329.06.00: timer cd139df8:
218329.6.0
Nov 15 14:57:49 pc2 kernel: [603017.526813] cell0: RX 218329.06.00: timer cd139df8:
schedule for 218329.7.0
Nov 15 14:57:49 pc2 kernel: [603017.529314] cell0: RX 218329.05.23: timer cd139dd8:
218329.5.23
Nov 15 14:57:49 pc2 kernel: [603017.529321] cell0: RX 218329.05.23: timer cd139dd8:
schedule for 218329.6.23
Nov 15 14:57:49 pc2 kernel: [603017.534535] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.534547] RX 218329.06.08: trx0: Q1: 0 Q2: 0 A/B: 80
carrier: 1 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.536811] cell0: RX 218329.07.00: timer cd139df8:
218329.7.0
Nov 15 14:57:49 pc2 kernel: [603017.536821] cell0: RX 218329.07.00: timer cd139df8:
schedule for 218329.8.0
Nov 15 14:57:49 pc2 kernel: [603017.539299] cell0: RX 218329.06.23: timer cd139dd8:
218329.6.23
Nov 15 14:57:49 pc2 kernel: [603017.539305] cell0: RX 218329.06.23: timer cd139dd8:
schedule for 218329.7.23
Nov 15 14:57:49 pc2 kernel: [603017.544302] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.546802] cell0: RX 218329.08.00: timer cd139df8:
218329.8.0
Nov 15 14:57:49 pc2 kernel: [603017.546810] cell0: RX 218329.08.00: timer cd139df8:
schedule for 218329.9.0
Nov 15 14:57:49 pc2 kernel: [603017.549311] cell0: RX 218329.07.23: timer cd139dd8:
218329.7.23
Nov 15 14:57:49 pc2 kernel: [603017.549318] cell0: RX 218329.07.23: timer cd139dd8:
schedule for 218329.8.23
Nov 15 14:57:49 pc2 kernel: [603017.554527] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.554541] RX 218329.08.10: trx0: Q1: 1 Q2: 0 A/B: 6e
carrier: 3 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.557038] cell0: RX 218329.09.00: timer cd139df8:
218329.9.0
Nov 15 14:57:49 pc2 kernel: [603017.557048] cell0: RX 218329.09.00: timer cd139df8:
schedule for 218329.10.0
Nov 15 14:57:49 pc2 kernel: [603017.557057] RX 218329.08.14: trx0: Q1: 0 Q2: 0 A/B: a0
carrier: 2 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.559297] cell0: RX 218329.08.23: timer cd139dd8:
218329.8.23
Nov 15 14:57:49 pc2 kernel: [603017.559302] cell0: RX 218329.08.23: timer cd139dd8:
schedule for 218329.9.23
Nov 15 14:57:49 pc2 kernel: [603017.564299] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.566800] cell0: RX 218329.10.00: timer cd139df8:
218329.10.0
Nov 15 14:57:49 pc2 kernel: [603017.566808] cell0: RX 218329.10.00: timer cd139df8:
schedule for 218329.11.0
Nov 15 14:57:49 pc2 kernel: [603017.569307] cell0: RX 218329.09.23: timer cd139dd8:
218329.9.23
Nov 15 14:57:49 pc2 kernel: [603017.569314] cell0: RX 218329.09.23: timer cd139dd8:
schedule for 218329.10.23
Nov 15 14:57:49 pc2 kernel: [603017.574303] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.576808] cell0: RX 218329.11.00: timer cd139df8:
218329.11.0
Nov 15 14:57:49 pc2 kernel: [603017.576816] cell0: RX 218329.11.00: timer cd139df8:
schedule for 218329.12.0
Nov 15 14:57:49 pc2 kernel: [603017.579294] cell0: RX 218329.10.23: timer cd139dd8:
218329.10.23
Nov 15 14:57:49 pc2 kernel: [603017.579299] cell0: RX 218329.10.23: timer cd139dd8:
schedule for 218329.11.23
Nov 15 14:57:49 pc2 kernel: [603017.584300] DBC slot 6 carrier 7: RSSI: selection: 0 now:
242
Nov 15 14:57:49 pc2 kernel: [603017.586796] cell0: RX 218329.12.00: timer cd139df8:
218329.12.0
Nov 15 14:57:49 pc2 kernel: [603017.586804] cell0: RX 218329.12.00: timer cd139df8:
schedule for 218329.13.0
Nov 15 14:57:49 pc2 kernel: [603017.589306] cell0: RX 218329.11.23: timer cd139dd8:
218329.11.23
Nov 15 14:57:49 pc2 kernel: [603017.589313] cell0: RX 218329.11.23: timer cd139dd8:
schedule for 218329.12.23
Nov 15 14:57:49 pc2 kernel: [603017.594301] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.596805] cell0: RX 218329.13.00: timer cd139df8:
218329.13.0
Nov 15 14:57:49 pc2 kernel: [603017.596814] cell0: RX 218329.13.00: timer cd139df8:
schedule for 218329.14.0
Nov 15 14:57:49 pc2 kernel: [603017.599517] RX 218329.12.18: trx0: Q1: 0 Q2: 1 A/B: ee
carrier: 6 A-CRC: 0 X-CRC: 0 Z-CRC: 0 Unknown MAC control 6000000000000000
### Any idea where that Unknown MAC control comes from?
Nov 15 14:57:49 pc2 kernel: [603017.599530] cell0: RX 218329.12.23: timer cd139dd8:
218329.12.23
Nov 15 14:57:49 pc2 kernel: [603017.599535] cell0: RX 218329.12.23: timer cd139dd8:
schedule for 218329.13.23
Nov 15 14:57:49 pc2 kernel: [603017.604294] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.606795] cell0: RX 218329.14.00: timer cd139df8:
218329.14.0
Nov 15 14:57:49 pc2 kernel: [603017.606803] cell0: RX 218329.14.00: timer cd139df8:
schedule for 218329.15.0
Nov 15 14:57:49 pc2 kernel: [603017.609536] RX 218329.13.22: trx0: Q1: 1 Q2: 0 A/B: 20
carrier: 7 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.609545] cell0: RX 218329.13.23: timer cd139dd8:
218329.13.23
Nov 15 14:57:49 pc2 kernel: [603017.609551] cell0: RX 218329.13.23: timer cd139dd8:
schedule for 218329.14.23
Nov 15 14:57:49 pc2 kernel: [603017.614301] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 14:57:49 pc2 kernel: [603017.616802] cell0: RX 218329.15.00: timer cd139df8:
218329.15.0
Nov 15 14:57:49 pc2 kernel: [603017.616811] cell0: RX 218329.15.00: timer cd139df8:
schedule for 218330.0.0
Nov 15 14:57:49 pc2 kernel: [603017.619512] RX 218329.14.22: trx0: Q1: 0 Q2: 0 A/B: ca
carrier: 8 A-CRC: 0 X-CRC: 0 Unknown MAC control 3000000000000000
Nov 15 14:57:49 pc2 kernel: [603017.619522] cell0: RX 218329.14.23: timer cd139dd8:
218329.14.23
Nov 15 14:57:49 pc2 kernel: [603017.619527] cell0: RX 218329.14.23: timer cd139dd8:
schedule for 218329.15.23
Nov 15 14:57:49 pc2 kernel: [603017.624291] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 14:57:49 pc2 kernel: [603017.626792] cell0: RX 218330.00.00: timer cd139df8:
218330.0.0
Nov 15 14:57:49 pc2 kernel: [603017.626800] cell0: RX 218330.00.00: timer cd139df8:
schedule for 218330.1.0
Nov 15 14:57:49 pc2 kernel: [603017.629300] cell0: RX 218329.15.23: timer cd139dd8:
218329.15.23
Nov 15 14:57:49 pc2 kernel: [603017.629307] cell0: RX 218329.15.23: timer cd139dd8:
schedule for 218330.0.23
Nov 15 14:57:49 pc2 kernel: [603017.629312] timeout, unlock, a: 159 nt: 101 mfn: 9
### From here on, it seems to have lost the lock of the FP
Nov 15 14:57:49 pc2 kernel: [603017.629322] cl cd2e0000: MAC_INFO-ind: rpn: 0
Nov 15 14:57:50 pc2 kernel: [603018.283036] connectionless: identities information: e: 1
class: 0 emc: 0080 fpn: 07405 rpn: 7
Nov 15 14:57:50 pc2 kernel: [603018.527295] unknown tail a0
Nov 15 14:57:50 pc2 kernel: [603018.568814] identities information: e: 0 class: 0 emc:
11f0 fpn: 1611c rpn: 0
Nov 15 14:57:51 pc2 kernel: [603018.731582] extended rf carrier information: rfcars
50000000 band 26 num 1
Nov 15 14:57:51 pc2 kernel: [603018.954793] connectionless: identities information: e: 0
class: 0 emc: 08a7 fpn: 040b2 rpn: 0
Nov 15 14:57:51 pc2 kernel: [603018.974890] encctrl: cmd: 1 fmid: 0a3a pmid: 00d34
Nov 15 14:57:51 pc2 kernel: [603019.179211] identities information: e: 0 class: 0 emc:
006b fpn: 0ff38 rpn: 0
Nov 15 14:57:51 pc2 kernel: [603019.223252] unknown system information type
7000000000000000
Nov 15 14:57:52 pc2 kernel: [603019.998634] identities information: e: 0 class: 0 emc:
11f0 fpn: 1691c rpn: 0
Nov 15 14:57:52 pc2 kernel: [603020.384959] C_S tail sequence number 0
Nov 15 14:57:52 pc2 kernel: [603020.567434] identities information: e: 0 class: 0 emc:
0397 fpn: 141be rpn: 0
Nov 15 14:57:52 pc2 kernel: [603020.629240] identities information: e: 0 class: 1 emc:
a362 fpn: 00010 rpn: 10
Nov 15 14:57:53 pc2 kernel: [603020.791895] identities information: e: 0 class: 0 emc:
07f6 fpn: 03463 rpn: 0
Nov 15 14:57:53 pc2 kernel: [603021.547044] connectionless: identities information: e: 0
class: 0 emc: d31a fpn: 1842c rpn: 6
Nov 15 14:57:54 pc2 kernel: [603021.994986] page: RFPI: ea9d8 blind full slots: a28
Nov 15 14:57:54 pc2 kernel: [603022.035430] identities information: e: 0 class: 0 emc:
0a43 fpn: 0c048 rpn: 0
Nov 15 14:57:54 pc2 kernel: [603022.157050] identities information: e: 0 class: 3 emc:
f439 fpn: 0008b rpn: f7
Nov 15 14:57:54 pc2 kernel: [603022.197227] connectionless: identities information: e: 0
class: 0 emc: 0387 fpn: 14494 rpn: 0
Nov 15 14:57:55 pc2 kernel: [603022.831636] identities information: e: 0 class: 0 emc:
07f6 fpn: 13443 rpn: 0
Nov 15 14:57:56 pc2 kernel: [603023.851170] connectionless: identities information: e: 1
class: 3 emc: a183 fpn: 000a9 rpn: 8b
Nov 15 14:57:56 pc2 kernel: [603024.054154] identities information: e: 0 class: 0 emc:
0804 fpn: 000a2 rpn: 0
Nov 15 14:57:56 pc2 kernel: [603024.074242] unknown tail a0
Nov 15 14:57:56 pc2 kernel: [603024.278570] static system information: nr: 0 sn: 6 cn: 9
pscn: 6
Nov 15 14:57:56 pc2 kernel: [603024.461427] unknown cctrl command: 900000000000000
Nov 15 14:57:57 pc2 kernel: [603025.054607] C_S tail sequence number 1
Here is another log on the same machine, but this time, it doesn't say a word about
unknown MAC control:
Nov 15 15:03:07 pc2 kernel: [603335.317365] cell0: RX 220315.13.00: timer cd139df8:
schedule for 220315.14.0
Nov 15 15:03:07 pc2 kernel: [603335.319844] cell0: RX 220315.12.23: timer cd139dd8:
220315.12.23
Nov 15 15:03:07 pc2 kernel: [603335.319850] cell0: RX 220315.12.23: timer cd139dd8:
schedule for 220315.13.23
Nov 15 15:03:07 pc2 kernel: [603335.324850] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 15:03:07 pc2 kernel: [603335.327341] cell0: RX 220315.14.00: timer cd139df8:
220315.14.0
Nov 15 15:03:07 pc2 kernel: [603335.327349] cell0: RX 220315.14.00: timer cd139df8:
schedule for 220315.15.0
Nov 15 15:03:07 pc2 kernel: [603335.329855] cell0: RX 220315.13.23: timer cd139dd8:
220315.13.23
Nov 15 15:03:07 pc2 kernel: [603335.329862] cell0: RX 220315.13.23: timer cd139dd8:
schedule for 220315.14.23
Nov 15 15:03:07 pc2 kernel: [603335.334847] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 15:03:07 pc2 kernel: [603335.337355] cell0: RX 220315.15.00: timer cd139df8:
220315.15.0
Nov 15 15:03:07 pc2 kernel: [603335.337364] cell0: RX 220315.15.00: timer cd139df8:
schedule for 220316.0.0
Nov 15 15:03:07 pc2 kernel: [603335.340083] RX 220315.14.18: trx0: Q1: 0 Q2: 0 A/B: 80
carrier: 4 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 15:03:07 pc2 kernel: [603335.340093] cell0: RX 220315.14.23: timer cd139dd8:
220315.14.23
Nov 15 15:03:07 pc2 kernel: [603335.340099] cell0: RX 220315.14.23: timer cd139dd8:
schedule for 220315.15.23
Nov 15 15:03:07 pc2 kernel: [603335.344846] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 15:03:07 pc2 kernel: [603335.347340] cell0: RX 220316.00.00: timer cd139df8:
220316.0.0
Nov 15 15:03:07 pc2 kernel: [603335.347348] cell0: RX 220316.00.00: timer cd139df8:
schedule for 220316.1.0
Nov 15 15:03:07 pc2 kernel: [603335.349853] cell0: RX 220315.15.23: timer cd139dd8:
220315.15.23
Nov 15 15:03:07 pc2 kernel: [603335.349860] cell0: RX 220315.15.23: timer cd139dd8:
schedule for 220316.0.23
Nov 15 15:03:07 pc2 kernel: [603335.349865] timeout, unlock, a: 199 nt: 171 mfn: 9
Nov 15 15:03:07 pc2 kernel: [603335.349875] cl cd2e0000: MAC_INFO-ind: rpn: 0
Nov 15 15:03:08 pc2 kernel: [603335.758892] unknown MAC page info 0
Nov 15 15:03:08 pc2 kernel: [603336.351786] identities information: e: 0 class: 0 emc:
07f6 fpn: 12072 rpn: 0
Nov 15 15:03:09 pc2 kernel: [603336.761731] identities information: e: 0 class: 0 emc:
07f4 fpn: 13462 rpn: 0
Nov 15 15:03:09 pc2 kernel: [603337.008980] C_S tail sequence number 0
Nov 15 15:03:10 pc2 kernel: [603338.090210] C_S tail sequence number 0
Nov 15 15:03:10 pc2 kernel: [603338.274403] static system information: nr: 0 sn: 5 cn: 2
pscn: 3
Nov 15 15:03:10 pc2 kernel: [603338.601499] identities information: e: 0 class: 0 emc:
06e4 fpn: 02042 rpn: 0
Nov 15 15:03:10 pc2 kernel: [603338.643032] connectionless: identities information: e: 1
class: 2 emc: dd7a fpn: 0005f rpn: df
Nov 15 15:03:11 pc2 kernel: [603338.785825] C_S tail sequence number 1
Nov 15 15:03:11 pc2 kernel: [603339.280452] C_S tail sequence number 0
Nov 15 15:03:12 pc2 kernel: [603339.848379] identities information: e: 0 class: 0 emc:
11f0 fpn: 1691c rpn: 0
Nov 15 15:03:12 pc2 kernel: [603340.093837] C_S tail sequence number 1
Nov 15 15:03:12 pc2 kernel: [603340.114035] Unknown MAC control d000000000000000
Nov 15 15:03:12 pc2 kernel: [603340.215766] identities information: e: 0 class: 4 emc:
0410 fpn: 007b1 rpn: d8
Nov 15 15:03:13 pc2 kernel: [603340.746906] unknown tail a0
Nov 15 15:03:13 pc2 kernel: [603340.827436] identities information: e: 0 class: 1 emc:
0397 fpn: 00020 rpn: 64
Nov 15 15:03:13 pc2 kernel: [603340.888397] C_S tail sequence number 1
Nov 15 15:03:13 pc2 kernel: [603340.970535] full/long page: extend: 1 length:
7000000000000000
Nov 15 15:03:13 pc2 kernel: [603341.174531] unknown tail a0
Nov 15 15:03:13 pc2 kernel: [603341.235558] unknown tail a0
Nov 15 15:03:13 pc2 kernel: [603341.318620] connectionless: identities information: e: 0
class: 4 emc: ce3a fpn: 00020 rpn: 10
Nov 15 15:03:13 pc2 kernel: [603341.420344] extended rf carrier information: rfcars
e0000000 band 22 num 1
BTW:
Well, I tried the base station of my AS150 phone, where I am not sure if
it supports ciphering, I guess it doesn't support ciphering.
However, I tried my Fritzbox 7270 too, which definitely supports
ciphering. I will try again with my Fritzbox. netlink: message group: 4
netlink: FPC:
full_slot,page_repetition,basic_a_field_setup,in_min_delay
netlink: HLC:
adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,location_registration
It seems your FP doesn't support ciphering, so its possible that it
doesn't broadcast the multi-frame number, which my stack expects.
It shouldn't have locked to the FP in that case though.
Perhaps the FP broadcasts the MFN at a lesser frequency than defined
in the standard - if the stack doesn't receive the MFN at least every
8 multiframes (T216), it unlocks from the FP.
3:14 p.m.
On 15.11.2010 15:06, Erik Tews wrote:
Am Sonntag, den 14.11.2010, 14:15 +0100 schrieb Erik
Tews:
0x6 is "Tail for use with the first transmission of a B-field "bearer
request" message". This is simply not handled by my code. Often these
are just reception errors or frames received from different FPs/PPs.
Am Sonntag, den 14.11.2010, 14:10 +0100 schrieb
Patrick McHardy:
OK, here is the kern.log for my Fritzbox. I am running the PCI card on a
32 bit Linux system. It takes minutes, until my computer in monitor-mode
has found the Fritzbox. During the discovery, it finds a lot of other
FPs. I am running that test in a very populated area with most probably
a lot of other phones around my house.
What happens after my box has found the Fritzbox and got a lock on it
is, that it seems to be able to hold the lock for a few seconds, but
then runs into a timeout. Then it needs some seconds, but more like
10-40 to get the lock again.
Nov 15 14:57:49 pc2 kernel: [603017.486809] cell0: RX 218329.02.00: timer cd139df8:
218329.2.0
Nov 15 14:57:49 pc2 kernel: [603017.486817] cell0: RX 218329.02.00: timer cd139df8:
schedule for 218329.3.0
Nov 15 14:57:49 pc2 kernel: [603017.489319] cell0: RX 218329.01.23: timer cd139dd8:
218329.1.23
Nov 15 14:57:49 pc2 kernel: [603017.489326] cell0: RX 218329.01.23: timer cd139dd8:
schedule for 218329.2.23
Nov 15 14:57:49 pc2 kernel: [603017.494315] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.496818] cell0: RX 218329.03.00: timer cd139df8:
218329.3.0
Nov 15 14:57:49 pc2 kernel: [603017.496827] cell0: RX 218329.03.00: timer cd139df8:
schedule for 218329.4.0
Nov 15 14:57:49 pc2 kernel: [603017.499531] RX 218329.02.20: trx0: Q1: 0 Q2: 1 A/B: 40
carrier: 6 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.499541] cell0: RX 218329.02.23: timer cd139dd8:
218329.2.23
Nov 15 14:57:49 pc2 kernel: [603017.499546] cell0: RX 218329.02.23: timer cd139dd8:
schedule for 218329.3.23
Nov 15 14:57:49 pc2 kernel: [603017.502040] RX 218329.03.04: trx0: Q1: 1 Q2: 1 A/B: 24
carrier: 8 A-CRC: 0 X-CRC: 0 DBC slot 6 carrier 7: RSSI: selection: 0 now: 246
Nov 15 14:57:49 pc2 kernel: [603017.506808] cell0: RX 218329.04.00: timer cd139df8:
218329.4.0
Nov 15 14:57:49 pc2 kernel: [603017.506816] cell0: RX 218329.04.00: timer cd139df8:
schedule for 218329.5.0
Nov 15 14:57:49 pc2 kernel: [603017.509317] cell0: RX 218329.03.23: timer cd139dd8:
218329.3.23
Nov 15 14:57:49 pc2 kernel: [603017.509324] cell0: RX 218329.03.23: timer cd139dd8:
schedule for 218329.4.23
Nov 15 14:57:49 pc2 kernel: [603017.514539] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.514554] RX 218329.04.10: trx0: Q1: 1 Q2: 0 A/B: ae
carrier: 9 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.516815] cell0: RX 218329.05.00: timer cd139df8:
218329.5.0
Nov 15 14:57:49 pc2 kernel: [603017.516824] cell0: RX 218329.05.00: timer cd139df8:
schedule for 218329.6.0
Nov 15 14:57:49 pc2 kernel: [603017.519301] cell0: RX 218329.04.23: timer cd139dd8:
218329.4.23
Nov 15 14:57:49 pc2 kernel: [603017.519306] cell0: RX 218329.04.23: timer cd139dd8:
schedule for 218329.5.23
Nov 15 14:57:49 pc2 kernel: [603017.524308] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.526805] cell0: RX 218329.06.00: timer cd139df8:
218329.6.0
Nov 15 14:57:49 pc2 kernel: [603017.526813] cell0: RX 218329.06.00: timer cd139df8:
schedule for 218329.7.0
Nov 15 14:57:49 pc2 kernel: [603017.529314] cell0: RX 218329.05.23: timer cd139dd8:
218329.5.23
Nov 15 14:57:49 pc2 kernel: [603017.529321] cell0: RX 218329.05.23: timer cd139dd8:
schedule for 218329.6.23
Nov 15 14:57:49 pc2 kernel: [603017.534535] DBC slot 6 carrier 7: RSSI: selection: 0 now:
246
Nov 15 14:57:49 pc2 kernel: [603017.534547] RX 218329.06.08: trx0: Q1: 0 Q2: 0 A/B: 80
carrier: 1 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.536811] cell0: RX 218329.07.00: timer cd139df8:
218329.7.0
Nov 15 14:57:49 pc2 kernel: [603017.536821] cell0: RX 218329.07.00: timer cd139df8:
schedule for 218329.8.0
Nov 15 14:57:49 pc2 kernel: [603017.539299] cell0: RX 218329.06.23: timer cd139dd8:
218329.6.23
Nov 15 14:57:49 pc2 kernel: [603017.539305] cell0: RX 218329.06.23: timer cd139dd8:
schedule for 218329.7.23
Nov 15 14:57:49 pc2 kernel: [603017.544302] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.546802] cell0: RX 218329.08.00: timer cd139df8:
218329.8.0
Nov 15 14:57:49 pc2 kernel: [603017.546810] cell0: RX 218329.08.00: timer cd139df8:
schedule for 218329.9.0
Nov 15 14:57:49 pc2 kernel: [603017.549311] cell0: RX 218329.07.23: timer cd139dd8:
218329.7.23
Nov 15 14:57:49 pc2 kernel: [603017.549318] cell0: RX 218329.07.23: timer cd139dd8:
schedule for 218329.8.23
Nov 15 14:57:49 pc2 kernel: [603017.554527] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.554541] RX 218329.08.10: trx0: Q1: 1 Q2: 0 A/B: 6e
carrier: 3 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.557038] cell0: RX 218329.09.00: timer cd139df8:
218329.9.0
Nov 15 14:57:49 pc2 kernel: [603017.557048] cell0: RX 218329.09.00: timer cd139df8:
schedule for 218329.10.0
Nov 15 14:57:49 pc2 kernel: [603017.557057] RX 218329.08.14: trx0: Q1: 0 Q2: 0 A/B: a0
carrier: 2 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.559297] cell0: RX 218329.08.23: timer cd139dd8:
218329.8.23
Nov 15 14:57:49 pc2 kernel: [603017.559302] cell0: RX 218329.08.23: timer cd139dd8:
schedule for 218329.9.23
Nov 15 14:57:49 pc2 kernel: [603017.564299] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.566800] cell0: RX 218329.10.00: timer cd139df8:
218329.10.0
Nov 15 14:57:49 pc2 kernel: [603017.566808] cell0: RX 218329.10.00: timer cd139df8:
schedule for 218329.11.0
Nov 15 14:57:49 pc2 kernel: [603017.569307] cell0: RX 218329.09.23: timer cd139dd8:
218329.9.23
Nov 15 14:57:49 pc2 kernel: [603017.569314] cell0: RX 218329.09.23: timer cd139dd8:
schedule for 218329.10.23
Nov 15 14:57:49 pc2 kernel: [603017.574303] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.576808] cell0: RX 218329.11.00: timer cd139df8:
218329.11.0
Nov 15 14:57:49 pc2 kernel: [603017.576816] cell0: RX 218329.11.00: timer cd139df8:
schedule for 218329.12.0
Nov 15 14:57:49 pc2 kernel: [603017.579294] cell0: RX 218329.10.23: timer cd139dd8:
218329.10.23
Nov 15 14:57:49 pc2 kernel: [603017.579299] cell0: RX 218329.10.23: timer cd139dd8:
schedule for 218329.11.23
Nov 15 14:57:49 pc2 kernel: [603017.584300] DBC slot 6 carrier 7: RSSI: selection: 0 now:
242
Nov 15 14:57:49 pc2 kernel: [603017.586796] cell0: RX 218329.12.00: timer cd139df8:
218329.12.0
Nov 15 14:57:49 pc2 kernel: [603017.586804] cell0: RX 218329.12.00: timer cd139df8:
schedule for 218329.13.0
Nov 15 14:57:49 pc2 kernel: [603017.589306] cell0: RX 218329.11.23: timer cd139dd8:
218329.11.23
Nov 15 14:57:49 pc2 kernel: [603017.589313] cell0: RX 218329.11.23: timer cd139dd8:
schedule for 218329.12.23
Nov 15 14:57:49 pc2 kernel: [603017.594301] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.596805] cell0: RX 218329.13.00: timer cd139df8:
218329.13.0
Nov 15 14:57:49 pc2 kernel: [603017.596814] cell0: RX 218329.13.00: timer cd139df8:
schedule for 218329.14.0
Nov 15 14:57:49 pc2 kernel: [603017.599517] RX 218329.12.18: trx0: Q1: 0 Q2: 1 A/B: ee
carrier: 6 A-CRC: 0 X-CRC: 0 Z-CRC: 0 Unknown MAC control 6000000000000000
### Any idea where that Unknown MAC control comes from? BTW:
Well, I tried the base station of my AS150 phone, where I am not sure if
it supports ciphering, I guess it doesn't support ciphering.
However, I tried my Fritzbox 7270 too, which definitely supports
ciphering. I will try again with my Fritzbox. netlink: message group: 4
netlink: FPC:
full_slot,page_repetition,basic_a_field_setup,in_min_delay
netlink: HLC:
adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,location_registration
It seems your FP doesn't support ciphering, so its possible that it
doesn't broadcast the multi-frame number, which my stack expects.
It shouldn't have locked to the FP in that case though.
Perhaps the FP broadcasts the MFN at a lesser frequency than defined
in the standard - if the stack doesn't receive the MFN at least every
8 multiframes (T216), it unlocks from the FP. Nov 15 14:57:49 pc2 kernel: [603017.599530] cell0: RX
218329.12.23: timer cd139dd8: 218329.12.23
Nov 15 14:57:49 pc2 kernel: [603017.599535] cell0: RX 218329.12.23: timer cd139dd8:
schedule for 218329.13.23
Nov 15 14:57:49 pc2 kernel: [603017.604294] DBC slot 6 carrier 7: RSSI: selection: 0 now:
238
Nov 15 14:57:49 pc2 kernel: [603017.606795] cell0: RX 218329.14.00: timer cd139df8:
218329.14.0
Nov 15 14:57:49 pc2 kernel: [603017.606803] cell0: RX 218329.14.00: timer cd139df8:
schedule for 218329.15.0
Nov 15 14:57:49 pc2 kernel: [603017.609536] RX 218329.13.22: trx0: Q1: 1 Q2: 0 A/B: 20
carrier: 7 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 14:57:49 pc2 kernel: [603017.609545] cell0: RX 218329.13.23: timer cd139dd8:
218329.13.23
Nov 15 14:57:49 pc2 kernel: [603017.609551] cell0: RX 218329.13.23: timer cd139dd8:
schedule for 218329.14.23
Nov 15 14:57:49 pc2 kernel: [603017.614301] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 14:57:49 pc2 kernel: [603017.616802] cell0: RX 218329.15.00: timer cd139df8:
218329.15.0
Nov 15 14:57:49 pc2 kernel: [603017.616811] cell0: RX 218329.15.00: timer cd139df8:
schedule for 218330.0.0
Nov 15 14:57:49 pc2 kernel: [603017.619512] RX 218329.14.22: trx0: Q1: 0 Q2: 0 A/B: ca
carrier: 8 A-CRC: 0 X-CRC: 0 Unknown MAC control 3000000000000000
Nov 15 14:57:49 pc2 kernel: [603017.619522] cell0: RX 218329.14.23: timer cd139dd8:
218329.14.23
Nov 15 14:57:49 pc2 kernel: [603017.619527] cell0: RX 218329.14.23: timer cd139dd8:
schedule for 218329.15.23
Nov 15 14:57:49 pc2 kernel: [603017.624291] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 14:57:49 pc2 kernel: [603017.626792] cell0: RX 218330.00.00: timer cd139df8:
218330.0.0
Nov 15 14:57:49 pc2 kernel: [603017.626800] cell0: RX 218330.00.00: timer cd139df8:
schedule for 218330.1.0
Nov 15 14:57:49 pc2 kernel: [603017.629300] cell0: RX 218329.15.23: timer cd139dd8:
218329.15.23
Nov 15 14:57:49 pc2 kernel: [603017.629307] cell0: RX 218329.15.23: timer cd139dd8:
schedule for 218330.0.23
Nov 15 14:57:49 pc2 kernel: [603017.629312] timeout, unlock, a: 159 nt: 101 mfn: 9
### From here on, it seems to have lost the lock of the FP
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?
Nov 15 14:57:49 pc2 kernel: [603017.629322] cl
cd2e0000: MAC_INFO-ind: rpn: 0
Nov 15 14:57:50 pc2 kernel: [603018.283036] connectionless: identities information: e: 1
class: 0 emc: 0080 fpn: 07405 rpn: 7
Nov 15 14:57:50 pc2 kernel: [603018.527295] unknown tail a0
Nov 15 14:57:50 pc2 kernel: [603018.568814] identities information: e: 0 class: 0 emc:
11f0 fpn: 1611c rpn: 0
Nov 15 14:57:51 pc2 kernel: [603018.731582] extended rf carrier information: rfcars
50000000 band 26 num 1
Nov 15 14:57:51 pc2 kernel: [603018.954793] connectionless: identities information: e: 0
class: 0 emc: 08a7 fpn: 040b2 rpn: 0
Nov 15 14:57:51 pc2 kernel: [603018.974890] encctrl: cmd: 1 fmid: 0a3a pmid: 00d34
Nov 15 14:57:51 pc2 kernel: [603019.179211] identities information: e: 0 class: 0 emc:
006b fpn: 0ff38 rpn: 0
Nov 15 14:57:51 pc2 kernel: [603019.223252] unknown system information type
7000000000000000
Nov 15 14:57:52 pc2 kernel: [603019.998634] identities information: e: 0 class: 0 emc:
11f0 fpn: 1691c rpn: 0
Nov 15 14:57:52 pc2 kernel: [603020.384959] C_S tail sequence number 0
Nov 15 14:57:52 pc2 kernel: [603020.567434] identities information: e: 0 class: 0 emc:
0397 fpn: 141be rpn: 0
Nov 15 14:57:52 pc2 kernel: [603020.629240] identities information: e: 0 class: 1 emc:
a362 fpn: 00010 rpn: 10
Nov 15 14:57:53 pc2 kernel: [603020.791895] identities information: e: 0 class: 0 emc:
07f6 fpn: 03463 rpn: 0
Nov 15 14:57:53 pc2 kernel: [603021.547044] connectionless: identities information: e: 0
class: 0 emc: d31a fpn: 1842c rpn: 6
Nov 15 14:57:54 pc2 kernel: [603021.994986] page: RFPI: ea9d8 blind full slots: a28
Nov 15 14:57:54 pc2 kernel: [603022.035430] identities information: e: 0 class: 0 emc:
0a43 fpn: 0c048 rpn: 0
Nov 15 14:57:54 pc2 kernel: [603022.157050] identities information: e: 0 class: 3 emc:
f439 fpn: 0008b rpn: f7
Nov 15 14:57:54 pc2 kernel: [603022.197227] connectionless: identities information: e: 0
class: 0 emc: 0387 fpn: 14494 rpn: 0
Nov 15 14:57:55 pc2 kernel: [603022.831636] identities information: e: 0 class: 0 emc:
07f6 fpn: 13443 rpn: 0
Nov 15 14:57:56 pc2 kernel: [603023.851170] connectionless: identities information: e: 1
class: 3 emc: a183 fpn: 000a9 rpn: 8b
Nov 15 14:57:56 pc2 kernel: [603024.054154] identities information: e: 0 class: 0 emc:
0804 fpn: 000a2 rpn: 0
Nov 15 14:57:56 pc2 kernel: [603024.074242] unknown tail a0
Nov 15 14:57:56 pc2 kernel: [603024.278570] static system information: nr: 0 sn: 6 cn: 9
pscn: 6
Nov 15 14:57:56 pc2 kernel: [603024.461427] unknown cctrl command: 900000000000000
Nov 15 14:57:57 pc2 kernel: [603025.054607] C_S tail sequence number 1
This is just random crap received while trying to regain lock.
Here is another log on the same machine, but this
time, it doesn't say a word about unknown MAC control:
Nov 15 15:03:07 pc2 kernel: [603335.317365] cell0: RX 220315.13.00: timer cd139df8:
schedule for 220315.14.0
Nov 15 15:03:07 pc2 kernel: [603335.319844] cell0: RX 220315.12.23: timer cd139dd8:
220315.12.23
Nov 15 15:03:07 pc2 kernel: [603335.319850] cell0: RX 220315.12.23: timer cd139dd8:
schedule for 220315.13.23
Nov 15 15:03:07 pc2 kernel: [603335.324850] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 15:03:07 pc2 kernel: [603335.327341] cell0: RX 220315.14.00: timer cd139df8:
220315.14.0
Nov 15 15:03:07 pc2 kernel: [603335.327349] cell0: RX 220315.14.00: timer cd139df8:
schedule for 220315.15.0
Nov 15 15:03:07 pc2 kernel: [603335.329855] cell0: RX 220315.13.23: timer cd139dd8:
220315.13.23
Nov 15 15:03:07 pc2 kernel: [603335.329862] cell0: RX 220315.13.23: timer cd139dd8:
schedule for 220315.14.23
Nov 15 15:03:07 pc2 kernel: [603335.334847] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 15:03:07 pc2 kernel: [603335.337355] cell0: RX 220315.15.00: timer cd139df8:
220315.15.0
Nov 15 15:03:07 pc2 kernel: [603335.337364] cell0: RX 220315.15.00: timer cd139df8:
schedule for 220316.0.0
Nov 15 15:03:07 pc2 kernel: [603335.340083] RX 220315.14.18: trx0: Q1: 0 Q2: 0 A/B: 80
carrier: 4 A-CRC: 0 X-CRC: 0 Z-CRC: 0
Nov 15 15:03:07 pc2 kernel: [603335.340093] cell0: RX 220315.14.23: timer cd139dd8:
220315.14.23
Nov 15 15:03:07 pc2 kernel: [603335.340099] cell0: RX 220315.14.23: timer cd139dd8:
schedule for 220315.15.23
Nov 15 15:03:07 pc2 kernel: [603335.344846] DBC slot 6 carrier 7: RSSI: selection: 0 now:
234
Nov 15 15:03:07 pc2 kernel: [603335.347340] cell0: RX 220316.00.00: timer cd139df8:
220316.0.0
Nov 15 15:03:07 pc2 kernel: [603335.347348] cell0: RX 220316.00.00: timer cd139df8:
schedule for 220316.1.0
Nov 15 15:03:07 pc2 kernel: [603335.349853] cell0: RX 220315.15.23: timer cd139dd8:
220315.15.23
Nov 15 15:03:07 pc2 kernel: [603335.349860] cell0: RX 220315.15.23: timer cd139dd8:
schedule for 220316.0.23
Nov 15 15:03:07 pc2 kernel: [603335.349865] timeout, unlock, a: 199 nt: 171 mfn: 9
Same problem, multiframe resync has timed out, apparently no valid tails
received.
Nov 15 15:03:07 pc2 kernel: [603335.349875] cl
cd2e0000: MAC_INFO-ind: rpn: 0
Nov 15 15:03:08 pc2 kernel: [603335.758892] unknown MAC page info 0
Nov 15 15:03:08 pc2 kernel: [603336.351786] identities information: e: 0 class: 0 emc:
07f6 fpn: 12072 rpn: 0
Nov 15 15:03:09 pc2 kernel: [603336.761731] identities information: e: 0 class: 0 emc:
07f4 fpn: 13462 rpn: 0
Nov 15 15:03:09 pc2 kernel: [603337.008980] C_S tail sequence number 0
Nov 15 15:03:10 pc2 kernel: [603338.090210] C_S tail sequence number 0
Nov 15 15:03:10 pc2 kernel: [603338.274403] static system information: nr: 0 sn: 5 cn: 2
pscn: 3
Nov 15 15:03:10 pc2 kernel: [603338.601499] identities information: e: 0 class: 0 emc:
06e4 fpn: 02042 rpn: 0
Nov 15 15:03:10 pc2 kernel: [603338.643032] connectionless: identities information: e: 1
class: 2 emc: dd7a fpn: 0005f rpn: df
Nov 15 15:03:11 pc2 kernel: [603338.785825] C_S tail sequence number 1
Nov 15 15:03:11 pc2 kernel: [603339.280452] C_S tail sequence number 0
Nov 15 15:03:12 pc2 kernel: [603339.848379] identities information: e: 0 class: 0 emc:
11f0 fpn: 1691c rpn: 0
Nov 15 15:03:12 pc2 kernel: [603340.093837] C_S tail sequence number 1
Nov 15 15:03:12 pc2 kernel: [603340.114035] Unknown MAC control d000000000000000
Nov 15 15:03:12 pc2 kernel: [603340.215766] identities information: e: 0 class: 4 emc:
0410 fpn: 007b1 rpn: d8
Nov 15 15:03:13 pc2 kernel: [603340.746906] unknown tail a0
Nov 15 15:03:13 pc2 kernel: [603340.827436] identities information: e: 0 class: 1 emc:
0397 fpn: 00020 rpn: 64
Nov 15 15:03:13 pc2 kernel: [603340.888397] C_S tail sequence number 1
Nov 15 15:03:13 pc2 kernel: [603340.970535] full/long page: extend: 1 length:
7000000000000000
Nov 15 15:03:13 pc2 kernel: [603341.174531] unknown tail a0
Nov 15 15:03:13 pc2 kernel: [603341.235558] unknown tail a0
Nov 15 15:03:13 pc2 kernel: [603341.318620] connectionless: identities information: e: 0
class: 4 emc: ce3a fpn: 00020 rpn: 10
Nov 15 15:03:13 pc2 kernel: [603341.420344] extended rf carrier information: rfcars
e0000000 band 22 num 1
3:25 p.m.
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?
3:29 p.m.
Am Montag, den 15.11.2010, 15:25 +0100 schrieb Erik Tews:
Am Montag, den 15.11.2010, 15:14 +0100 schrieb Patrick
McHardy:
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.
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?
3:44 p.m.
On 15.11.2010 15:29, Erik Tews wrote:
Am Montag, den 15.11.2010, 15:25 +0100 schrieb Erik
Tews:
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.
Am Montag, den 15.11.2010, 15:14 +0100 schrieb
Patrick McHardy:
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. 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?
4:14 p.m.
Am Montag, den 15.11.2010, 15:44 +0100 schrieb Patrick McHardy:
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.
OK, that seems to improve the scanning results:
diff --git a/net/dect/mac_csf.c b/net/dect/mac_csf.c
index a77f19f..9ec7a75 100644
--- a/net/dect/mac_csf.c
+++ b/net/dect/mac_csf.c
@@ -3656,9 +3656,11 @@ void dect_mac_irc_tick(struct dect_transceiver *trx)
switch (trx->state) {
case DECT_TRANSCEIVER_UNLOCKED:
- /* maintain scan until clock is running */
- irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
- dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
+ if (net_random() > 0x7fffffff) {
+ /* maintain scan until clock is running */
+ irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
+ dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
+ }
break;
case DECT_TRANSCEIVER_LOCK_PENDING:
irc->si.ssi.pscn = dect_next_carrier(0x3ff, irc->si.ssi.pscn);
However, I don't get a lock just in PP mode, if I don't use the monitor
flag:
[607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ
18
[607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
[607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
[607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
4:19 p.m.
On 15.11.2010 16:14, Erik Tews wrote:
Am Montag, den 15.11.2010, 15:44 +0100 schrieb Patrick
McHardy:
The timings indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode?
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.
OK, that seems to improve the scanning results:
diff --git a/net/dect/mac_csf.c b/net/dect/mac_csf.c
index a77f19f..9ec7a75 100644
--- a/net/dect/mac_csf.c
+++ b/net/dect/mac_csf.c
@@ -3656,9 +3656,11 @@ void dect_mac_irc_tick(struct dect_transceiver *trx)
switch (trx->state) {
case DECT_TRANSCEIVER_UNLOCKED:
- /* maintain scan until clock is running */
- irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
- dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
+ if (net_random() > 0x7fffffff) {
+ /* maintain scan until clock is running */
+ irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
+ dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
+ }
break;
case DECT_TRANSCEIVER_LOCK_PENDING:
irc->si.ssi.pscn = dect_next_carrier(0x3ff, irc->si.ssi.pscn);
However, I don't get a lock just in PP mode, if I don't use the monitor
flag:
[607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) ->
IRQ 18
[607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
[607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
[607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
4:25 p.m.
On 15.11.2010 16:19, Patrick McHardy wrote:
On 15.11.2010 16:14, Erik Tews wrote:
One more thing you could try (I had the same problem occasionally, but
it always magically disappeared at some point) is to change
drivers/dect/coa/sc1442x.c and remove SC1442X_BC5_DO_FR from the
BMC configuration. That sometimes helped in my case.
However, I don't get a lock just in PP mode,
if I don't use the monitor
flag:
[607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) ->
IRQ 18
[607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
[607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
[607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
The timings indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode?
4:46 p.m.
Am Montag, den 15.11.2010, 16:25 +0100 schrieb Patrick McHardy:
Sorry, again no luck:
diff --git a/drivers/dect/coa/sc1442x.c b/drivers/dect/coa/sc1442x.c
index 9b15e81..c1cf9a8 100644
--- a/drivers/dect/coa/sc1442x.c
+++ b/drivers/dect/coa/sc1442x.c
@@ -911,7 +911,8 @@ static void sc1442x_write_bmc_config(const struct coa_device *dev,
cfg |= 0x80;
sc1442x_dwriteb(dev, off + 4, cfg);
- cfg = SC1442X_BC5_DO_FR;
+ // cfg = SC1442X_BC5_DO_FR;
+ cfg = 0;
cfg |= tx ? SC1442X_BC5_TDO_DIGITAL : SC1442X_BC5_TDO_POWER_DOWN;
sc1442x_dwriteb(dev, off + 5, cfg);
The timings
indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode?
One more thing you could try (I had the same problem occasionally, but
it always magically disappeared at some point) is to change
drivers/dect/coa/sc1442x.c and remove SC1442X_BC5_DO_FR from the
BMC configuration. That sometimes helped in my case.
4:58 p.m.
On 15.11.2010 16:46, Erik Tews wrote:
Am Montag, den 15.11.2010, 16:25 +0100 schrieb Patrick
McHardy:
Sorry, again no luck:
diff --git a/drivers/dect/coa/sc1442x.c b/drivers/dect/coa/sc1442x.c
index 9b15e81..c1cf9a8 100644
--- a/drivers/dect/coa/sc1442x.c
+++ b/drivers/dect/coa/sc1442x.c
@@ -911,7 +911,8 @@ static void sc1442x_write_bmc_config(const struct coa_device *dev,
cfg |= 0x80;
sc1442x_dwriteb(dev, off + 4, cfg);
- cfg = SC1442X_BC5_DO_FR;
+ // cfg = SC1442X_BC5_DO_FR;
+ cfg = 0;
cfg |= tx ? SC1442X_BC5_TDO_DIGITAL : SC1442X_BC5_TDO_POWER_DOWN;
sc1442x_dwriteb(dev, off + 5, cfg);
OK, I'm out of ideas currently. Just to gather some more information,
are you seeing large frequency offsets on the slot where the DBC
is received in dect-transceiver-list?
The
timings indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode?
One more thing you could try (I had the same problem occasionally, but
it always magically disappeared at some point) is to change
drivers/dect/coa/sc1442x.c and remove SC1442X_BC5_DO_FR from the
BMC configuration. That sometimes helped in my case.
4:25 p.m.
Am Montag, den 15.11.2010, 16:19 +0100 schrieb Patrick McHardy:
On 15.11.2010 16:14, Erik Tews wrote:
The Fritzbox 7270 supports ECO-mode, however I have disabled that
feature in the settings dialog. However, I cannot check if ECO-mode is
really disabled.
Anyway, I will upgrade my firmware to the latest version, perhaps the
bug has been fixed and the new firmware operates properly now.
Am Montag, den 15.11.2010, 15:44 +0100 schrieb
Patrick McHardy:
The timings indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode? 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.
OK, that seems to improve the scanning results:
diff --git a/net/dect/mac_csf.c b/net/dect/mac_csf.c
index a77f19f..9ec7a75 100644
--- a/net/dect/mac_csf.c
+++ b/net/dect/mac_csf.c
@@ -3656,9 +3656,11 @@ void dect_mac_irc_tick(struct dect_transceiver *trx)
switch (trx->state) {
case DECT_TRANSCEIVER_UNLOCKED:
- /* maintain scan until clock is running */
- irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
- dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
+ if (net_random() > 0x7fffffff) {
+ /* maintain scan until clock is running */
+ irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
+ dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
+ }
break;
case DECT_TRANSCEIVER_LOCK_PENDING:
irc->si.ssi.pscn = dect_next_carrier(0x3ff, irc->si.ssi.pscn);
However, I don't get a lock just in PP mode, if I don't use the monitor
flag:
[607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) ->
IRQ 18
[607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
[607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
[607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
4:27 p.m.
On 15.11.2010 16:25, Erik Tews wrote:
Am Montag, den 15.11.2010, 16:19 +0100 schrieb Patrick
McHardy:
The Fritzbox 7270 supports ECO-mode, however I have disabled that
feature in the settings dialog. However, I cannot check if ECO-mode is
really disabled.
Anyway, I will upgrade my firmware to the latest version, perhaps the
bug has been fixed and the new firmware operates properly now.
I own a 7240 and at least that one does properly disable ECO mode
when not configured.
[607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ
18
[607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
[607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
[607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
The timings indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode?
4:43 p.m.
Am Montag, den 15.11.2010, 16:27 +0100 schrieb Patrick McHardy:
On 15.11.2010 16:25, Erik Tews wrote:
Sorry, new firmware makes not difference here.
Am Montag, den 15.11.2010, 16:19 +0100 schrieb
Patrick McHardy:
The Fritzbox 7270 supports ECO-mode, however I have disabled that
feature in the settings dialog. However, I cannot check if ECO-mode is
really disabled.
Anyway, I will upgrade my firmware to the latest version, perhaps the
bug has been fixed and the new firmware operates properly now.
I own a 7240 and at least that one does properly disable ECO mode
when not configured.
[607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ
18
[607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
[607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
[607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
[607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
The timings indicate that it only receives very few frames from the
FP. Is it possible that it's operating in ECO-mode?
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?
5334
days inactive
5341
days old
20 comments
2 participants
participants (2)
-
Erik Tews -
Patrick McHardy