From me at noone.at Mon Nov 1 10:51:42 2010 From: me at noone.at (NoOne) Date: Mon, 1 Nov 2010 11:51:42 +0100 Subject: Asterisk with cluster in PP mode Message-ID: Hi ... I successfully ran asterisk with a cluster in FP mode with one handset. Now I tried to use asterisk acting as a PP so that it can accept calls from PSTN. I catched EMC and FPN of my base station via dect-llme-scan. Where do I pass the PIN code for access_rights_requests? When I want to start asterisk I get following error messages: netlink: cu: mode PP ARI: class A: EMC: 0d13 FPN: 126f4 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 LCE: set default pmid e16c8 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: MAC_ME_RFP_PRELOAD-req netlink: HLC: adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,standard_ciphering,location_registration,ciss_service,clms_service,list_access_features [Nov 1 11:44:09] ERROR[3477]: chan_dect.c:2338 dect_load_module: Unable to set FP capabilities == Unregistered channel type 'DECT' Kind regards TheNoOne From kaber at trash.net Wed Nov 3 03:07:03 2010 From: kaber at trash.net (Patrick McHardy) Date: Wed, 03 Nov 2010 04:07:03 +0100 Subject: Asterisk with cluster in PP mode In-Reply-To: References: Message-ID: <4CD0D1D7.50106@trash.net> Am 01.11.2010 11:51, schrieb NoOne: > > Hi ... I successfully ran asterisk with a cluster in FP mode with one handset. > Now I tried to use asterisk acting as a PP so that it can accept calls from PSTN. > > I catched EMC and FPN of my base station via dect-llme-scan. > Where do I pass the PIN code for access_rights_requests? > > When I want to start asterisk I get following error messages: > > > netlink: cu: mode PP ARI: class A: EMC: 0d13 FPN: 126f4 > 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 > LCE: set default pmid e16c8 > 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: MAC_ME_RFP_PRELOAD-req > netlink: HLC: adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,standard_ciphering,location_registration,ciss_service,clms_service,list_access_features > [Nov 1 11:44:09] ERROR[3477]: chan_dect.c:2338 dect_load_module: Unable to set FP capabilities > == Unregistered channel type 'DECT' Running asterisk in PP mode is currently not supported. From kaber at trash.net Wed Nov 3 03:11:53 2010 From: kaber at trash.net (Patrick McHardy) Date: Wed, 03 Nov 2010 04:11:53 +0100 Subject: Problems with dectmon In-Reply-To: References: Message-ID: <4CD0D2F9.5070603@trash.net> Am 31.10.2010 21:03, schrieb Oscar Soriano Riera: > Hi Patrick > I compile and install the dectmon perfect, but when i will to execute the dectmon always get a segment default, here are the output kerneloops: For the last time, please use the linux-dect list for reporting problems. Also don't send your mail as reply to an arbitrary mail but start a new thread for a new subject. > *root at DECT:/usr/src/dectmon/src# ./dectmon * > **** glibc detected *** ./dectmon: free(): invalid next size (normal): 0x095bf5c8 **** > *======= Backtrace: =========* > */lib/i686/cmov/libc.so.6(+0x6b281)[0xb771b281]* > */lib/i686/cmov/libc.so.6(+0x6cad8)[0xb771cad8]* > */lib/i686/cmov/libc.so.6(cfree+0x6d)[0xb771fbbd]* > */usr/local/lib/libnl.so.3(nlmsg_free+0x83)[0xb78381d3]* > */usr/local/lib/libnl-dect.so.3(nl_dect_cluster_query+0x50)[0xb78450b0]* > */usr/lib/libdect.so.0(+0x1cc9d)[0xb781ec9d]* > */usr/lib/libdect.so.0(dect_open_handle+0xbd)[0xb7806e5d]* > *./dectmon[0x804cbec]* > */lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb76c6c76]* > *./dectmon[0x8049021]* This unfortunately doesn't show the cause of the crash, the nlmsg_free() is definitely correct. It is also unreproducable here. Please try running dectmon under valgrind to see whether it can locate the real cause (valgrind src/dectmon). From oskar at enrutador.com Sun Nov 7 23:43:13 2010 From: oskar at enrutador.com (Oscar Soriano Riera) Date: Mon, 08 Nov 2010 00:43:13 +0100 Subject: Dectmon problems on malloc function Message-ID: <63cacf1cef5a8077305f80f16ddfddea@enrutador.com> Hello Everyone for Spain I have some problems in the startup or running Dectmon. I use the lasted drivers (today 20101008) packets on http://dect.osmocom.org. This is my runbook: 1) I compile dectmon with this: #sh autogen.sh #sh configure #make #make install 2)I getup the interface: #dect-cluster-add --name cluster0 --emc 0x12f5 --fpn 0x0be9f --mode PP #dect-cell-add --name cell0 --cluster cluster0 --flags monitor #dect-transceiver-bind --transceiver trx0 --cell cell0 Added: 0: DECT Cluster cluster0: Mode: PP PARI: class A (residential) EMC: 12f5 FPN: 0be9f Added: 0: DECT Cell cell0 at cluster0: Bound: DECT Transceiver trx0 at cell0: RF-band: 00000 Events: busy: 0 late: 0 3)I can see in the log that the device is correct getup (some fragment): [ 3709.832225] extended fixed part capabilities: fpc: 00022 hlc: 000000 [ 3710.099164] extended fixed part capabilities: fpc: 00020 hlc: 000000 [ 3710.914148] identities information: e: 0 class: 0 emc: 1106 fpn: 08f71 rpn: 0 [ 3711.382176] identities information: e: 0 class: 0 emc: 065f fpn: 1d9d8 rpn: 0 [ 3712.039334] identities information: e: 0 class: 0 emc: 0f73 fpn: 1066a rpn: 0 [ 3712.120434] identities information: e: 0 class: 0 emc: 0d24 fpn: 04834 rpn: 0 [ 3713.079207] identities information: e: 0 class: 0 emc: 1056 fpn: 158ee rpn: 0 [ 3713.345455] identities information: e: 0 class: 0 emc: 1133 fpn: 1e399 rpn: 0 [ 3713.467939] identities information: e: 0 class: 0 emc: 0de9 fpn: 1bc8c rpn: 0 [ 3713.550437] page: RFPI: 241a0 bearer description: bt: 5000000000 sn: 2 sp: 0 cn: 4 [ 3713.632170] identities information: e: 0 class: 0 emc: 065f fpn: 1d9d8 rpn: 0 [ 3713.877937] identities information: e: 0 class: 0 emc: 0de9 fpn: 1bc8c rpn: 0 [ 3714.736021] identities information: e: 0 class: 0 emc: 0726 fpn: 16bc9 rpn: 0 [ 3714.960698] page: RFPI: cf0b0 blind full slots: 2aa [ 3715.329202] identities information: e: 0 class: 0 emc: 1056 fpn: 158ee rpn: 0 [ 3715.390439] static system information: nr: 0 sn: 2 cn: 4 pscn: 4 [ 3716.044455] identities information: e: 0 class: 0 emc: 12fd fpn: 1b11b rpn: 0 [ 3716.166016] identities information: e: 0 class: 0 emc: 0726 fpn: 16bc9 rpn: 0 [ 3716.576015] full/long page: extend: 0 length: 4000000000000000 [ 3716.986016] identities information: e: 0 class: 0 emc: 0726 fpn: 16bc9 rpn: 0 [ 3717.230442] page: RFPI: 241a0 bearer description: bt: 5000000000 sn: 2 sp: 0 cn: 4 [ 3717.392245] identities information: e: 0 class: 0 emc: 101b fpn: 13012 rpn: 0 [ 3717.432942] identities information: e: 0 class: 0 emc: 1133 fpn: 1e399 rpn: 0 [ 3717.757908] identities information: e: 0 class: 0 emc: 0de9 fpn: 1bc8c rpn: 0 [ 3718.023878] identities information: e: 0 class: 0 emc: 14d4 fpn: 18fc7 rpn: 0 [ 3718.779329] identities information: e: 0 class: 0 emc: 0f73 fpn: 1066a rpn: 0 [ 3719.086319] identities information: e: 0 class: 0 emc: 0747 fpn: 06960 rpn: 0 [ 3719.433269] identities information: e: 0 class: 0 emc: 0a6d fpn: 061c7 rpn: 0 [ 3719.494174] identities information: e: 0 class: 0 emc: 1106 fpn: 08f71 rpn: 0 [ 3719.657595] identities information: e: 0 class: 0 emc: 07ef fpn: 17322 rpn: 0 4) Launch Dectmon return a segment fault root at DECT:/usr/src/dectmon# src/dectmon *** glibc detected *** ./dectmon: free(): invalid next size (normal): 0x084d15c8 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6(+0x6b281)[0xb772d281] /lib/i686/cmov/libc.so.6(+0x6cad8)[0xb772ead8] /lib/i686/cmov/libc.so.6(cfree+0x6d)[0xb7731bbd] /usr/local/lib/libnl.so.3(nlmsg_free+0x83)[0xb784a1d3] /usr/local/lib/libnl-dect.so.3(nl_dect_cluster_query+0x50)[0xb78570b0] /usr/lib/libdect.so.0(+0x1cc9d)[0xb7830c9d] /usr/lib/libdect.so.0(dect_open_handle+0xbd)[0xb7818e5d] ./dectmon[0x804cbec] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb76d8c76] ./dectmon[0x8049021] ======= Memory map: ======== 08048000-0804e000 r-xp 00000000 03:01 794829 /usr/src/dectmon/src/dectmon 0804e000-0804f000 rw-p 00006000 03:01 794829 /usr/src/dectmon/src/dectmon 084d1000-084f2000 rw-p 00000000 00:00 0 [heap] b7500000-b7521000 rw-p 00000000 00:00 0 b7521000-b7600000 ---p 00000000 00:00 0 b7669000-b7686000 r-xp 00000000 03:01 2154538 /lib/libgcc_s.so.1 b7686000-b7687000 rw-p 0001c000 03:01 2154538 /lib/libgcc_s.so.1 b769b000-b769c000 rw-p 00000000 00:00 0 b769c000-b76c0000 r-xp 00000000 03:01 2171097 /lib/i686/cmov/libm-2.11.2.so b76c0000-b76c1000 r--p 00023000 03:01 2171097 /lib/i686/cmov/libm-2.11.2.so b76c1000-b76c2000 rw-p 00024000 03:01 2171097 /lib/i686/cmov/libm-2.11.2.so b76c2000-b7802000 r-xp 00000000 03:01 2171331 /lib/i686/cmov/libc-2.11.2.so b7802000-b7804000 r--p 0013f000 03:01 2171331 /lib/i686/cmov/libc-2.11.2.so b7804000-b7805000 rw-p 00141000 03:01 2171331 /lib/i686/cmov/libc-2.11.2.so b7805000-b7808000 rw-p 00000000 00:00 0 b7808000-b7813000 r-xp 00000000 03:01 2048785 /usr/lib/libev.so.3.0.0 b7813000-b7814000 rw-p 0000b000 03:01 2048785 /usr/lib/libev.so.3.0.0 b7814000-b783a000 r-xp 00000000 03:01 2048792 /usr/lib/libdect.so.0.0.1 b783a000-b783e000 rw-p 00025000 03:01 2048792 /usr/lib/libdect.so.0.0.1 b783e000-b783f000 rw-p 00000000 00:00 0 b783f000-b7851000 r-xp 00000000 03:01 762960 /usr/local/lib/libnl.so.3.0.0 b7851000-b7852000 rw-p 00012000 03:01 762960 /usr/local/lib/libnl.so.3.0.0 b7852000-b785b000 r-xp 00000000 03:01 762976 /usr/local/lib/libnl-dect.so.3.0.0 b785b000-b785c000 rw-p 00009000 03:01 762976 /usr/local/lib/libnl-dect.so.3.0.0 b7870000-b7872000 rw-p 00000000 00:00 0 b7872000-b7873000 r-xp 00000000 00:00 0 [vdso] b7873000-b788e000 r-xp 00000000 03:01 2155169 /lib/ld-2.11.2.so b788e000-b788f000 r--p 0001a000 03:01 2155169 /lib/ld-2.11.2.so b788f000-b7890000 rw-p 0001b000 03:01 2155169 /lib/ld-2.11.2.so bfcae000-bfccf000 rw-p 00000000 00:00 0 [stack] 5) I use Valgrid to see a problem, but valgrid fails, i think that is a problem with the malloc when it get memory for the stack: root at DECT:/usr/src/dectmon# valgrind src/dectmon ==10731== Memcheck, a memory error detector ==10731== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==10731== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==10731== Command: src/dectmon ==10731== ==10731== Invalid write of size 2 ==10731== at 0x408E568: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d8 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408E57C: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7c0 is 0 bytes after a block of size 88 alloc'd ==10731== at 0x4023FE0: malloc (vg_replace_malloc.c:236) ==10731== by 0x407897D: dect_malloc (utils.c:21) ==10731== by 0x4078486: dect_fd_alloc (io.c:56) ==10731== by 0x4077BBF: dect_netlink_init (netlink.c:352) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408E582: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7cc is 12 bytes after a block of size 88 alloc'd ==10731== at 0x4023FE0: malloc (vg_replace_malloc.c:236) ==10731== by 0x407897D: dect_malloc (utils.c:21) ==10731== by 0x4078486: dect_fd_alloc (io.c:56) ==10731== by 0x4077BBF: dect_netlink_init (netlink.c:352) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408E589: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d0 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408E590: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7c8 is 8 bytes after a block of size 88 alloc'd ==10731== at 0x4023FE0: malloc (vg_replace_malloc.c:236) ==10731== by 0x407897D: dect_malloc (utils.c:21) ==10731== by 0x4078486: dect_fd_alloc (io.c:56) ==10731== by 0x4077BBF: dect_netlink_init (netlink.c:352) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408E593: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7c4 is 4 bytes after a block of size 88 alloc'd ==10731== at 0x4023FE0: malloc (vg_replace_malloc.c:236) ==10731== by 0x407897D: dect_malloc (utils.c:21) ==10731== by 0x4078486: dect_fd_alloc (io.c:56) ==10731== by 0x4077BBF: dect_netlink_init (netlink.c:352) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408E596: event_set (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804940E: register_fd (event_ops.c:35) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d4 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid read of size 2 ==10731== at 0x408EC70: event_add (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804941E: register_fd (event_ops.c:36) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d8 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid read of size 4 ==10731== at 0x408ECD3: event_add (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804941E: register_fd (event_ops.c:36) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7c8 is 8 bytes after a block of size 88 alloc'd ==10731== at 0x4023FE0: malloc (vg_replace_malloc.c:236) ==10731== by 0x407897D: dect_malloc (utils.c:21) ==10731== by 0x4078486: dect_fd_alloc (io.c:56) ==10731== by 0x4077BBF: dect_netlink_init (netlink.c:352) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== ==10731== Invalid read of size 4 ==10731== at 0x408ECF0: event_add (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804941E: register_fd (event_ops.c:36) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d4 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid read of size 4 ==10731== at 0x408ED2F: event_add (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804941E: register_fd (event_ops.c:36) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d4 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408ED35: event_add (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804941E: register_fd (event_ops.c:36) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d4 is not stack'd, malloc'd or (recently) free'd ==10731== ==10731== Invalid write of size 4 ==10731== at 0x408ECB5: event_add (in /usr/lib/libev.so.3.0.0) ==10731== by 0x804941E: register_fd (event_ops.c:36) ==10731== by 0x4078361: dect_fd_register (io.c:103) ==10731== by 0x4077C14: dect_netlink_init (netlink.c:358) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) ==10731== Address 0x41ff7d4 is not stack'd, malloc'd or (recently) free'd ==10731== --10731-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --10731-- si_code=1; Faulting address: 0x74616874; sp: 0x62bdea58 valgrind: the 'impossible' happened: Killed by fatal signal ==10731== at 0x3809F551: myvprintf_str (m_debuglog.c:530) ==10731== by 0x3809FD32: vgPlain_debugLog_vprintf (m_debuglog.c:877) ==10731== by 0x3802A555: vprintf_WRK (m_libcprint.c:111) ==10731== by 0x3802A617: vgPlain_printf (m_libcprint.c:143) ==10731== by 0x380286C6: vgPlain_assert_fail (m_libcassert.c:261) ==10731== by 0x656C501F: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==10731== at 0x402331F: calloc (vg_replace_malloc.c:467) ==10731== by 0x4055394: nl_object_alloc (object.c:49) ==10731== by 0x404284F: nl_dect_cluster_alloc (cluster_obj.c:64) ==10731== by 0x4077C34: dect_netlink_init (netlink.c:148) ==10731== by 0x405FE5C: dect_open_handle (libdect.c:66) ==10731== by 0x804CBEB: main (main.c:108) Thanks for help me -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaber at trash.net Mon Nov 8 06:33:42 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 08 Nov 2010 07:33:42 +0100 Subject: Dectmon problems on malloc function In-Reply-To: <63cacf1cef5a8077305f80f16ddfddea@enrutador.com> References: <63cacf1cef5a8077305f80f16ddfddea@enrutador.com> Message-ID: <4CD799C6.3000102@trash.net> On 08.11.2010 00:43, Oscar Soriano Riera wrote: > ... > 5) I use Valgrid to see a problem, but valgrid fails, i think > that is a problem with the malloc when it get memory for the > stack: > > root at DECT:/usr/src/dectmon# valgrind src/dectmon > ==10731== > Memcheck, a memory error detector > ==10731== Copyright (C) 2002-2010, and > GNU GPL'd, by Julian Seward et al. > ==10731== Using Valgrind-3.6.0 and > LibVEX; rerun with -h for copyright info > ==10731== Command: > src/dectmon > ==10731== > ==10731== Invalid write of size 2 > ==10731== at > 0x408E568: event_set (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804940E: register_fd (event_ops.c:35) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d8 is not stack'd, malloc'd or (recently) > free'd Thanks, that helps, I'll try to figure out what's wrong. Cheers, Patrick > ==10731== > ==10731== Invalid write of size 4 > ==10731== at > 0x408E57C: event_set (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804940E: register_fd (event_ops.c:35) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7c0 is 0 bytes after a block of size 88 alloc'd > ==10731== > at 0x4023FE0: malloc (vg_replace_malloc.c:236) > ==10731== by 0x407897D: > dect_malloc (utils.c:21) > ==10731== by 0x4078486: dect_fd_alloc > (io.c:56) > ==10731== by 0x4077BBF: dect_netlink_init > (netlink.c:352) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > > ==10731== Invalid write of size 4 > ==10731== at 0x408E582: event_set (in > /usr/lib/libev.so.3.0.0) > ==10731== by 0x804940E: register_fd > (event_ops.c:35) > ==10731== by 0x4078361: dect_fd_register > (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7cc is 12 bytes after a block of size 88 alloc'd > ==10731== > at 0x4023FE0: malloc (vg_replace_malloc.c:236) > ==10731== by 0x407897D: > dect_malloc (utils.c:21) > ==10731== by 0x4078486: dect_fd_alloc > (io.c:56) > ==10731== by 0x4077BBF: dect_netlink_init > (netlink.c:352) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > > ==10731== Invalid write of size 4 > ==10731== at 0x408E589: event_set (in > /usr/lib/libev.so.3.0.0) > ==10731== by 0x804940E: register_fd > (event_ops.c:35) > ==10731== by 0x4078361: dect_fd_register > (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d0 is not stack'd, malloc'd or (recently) > free'd > ==10731== > ==10731== Invalid write of size 4 > ==10731== at > 0x408E590: event_set (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804940E: register_fd (event_ops.c:35) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7c8 is 8 bytes after a block of size 88 alloc'd > ==10731== > at 0x4023FE0: malloc (vg_replace_malloc.c:236) > ==10731== by 0x407897D: > dect_malloc (utils.c:21) > ==10731== by 0x4078486: dect_fd_alloc > (io.c:56) > ==10731== by 0x4077BBF: dect_netlink_init > (netlink.c:352) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > > ==10731== Invalid write of size 4 > ==10731== at 0x408E593: event_set (in > /usr/lib/libev.so.3.0.0) > ==10731== by 0x804940E: register_fd > (event_ops.c:35) > ==10731== by 0x4078361: dect_fd_register > (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7c4 is 4 bytes after a block of size 88 alloc'd > ==10731== > at 0x4023FE0: malloc (vg_replace_malloc.c:236) > ==10731== by 0x407897D: > dect_malloc (utils.c:21) > ==10731== by 0x4078486: dect_fd_alloc > (io.c:56) > ==10731== by 0x4077BBF: dect_netlink_init > (netlink.c:352) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > > ==10731== Invalid write of size 4 > ==10731== at 0x408E596: event_set (in > /usr/lib/libev.so.3.0.0) > ==10731== by 0x804940E: register_fd > (event_ops.c:35) > ==10731== by 0x4078361: dect_fd_register > (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d4 is not stack'd, malloc'd or (recently) > free'd > ==10731== > ==10731== Invalid read of size 2 > ==10731== at > 0x408EC70: event_add (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804941E: register_fd (event_ops.c:36) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d8 is not stack'd, malloc'd or (recently) > free'd > ==10731== > ==10731== Invalid read of size 4 > ==10731== at > 0x408ECD3: event_add (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804941E: register_fd (event_ops.c:36) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7c8 is 8 bytes after a block of size 88 alloc'd > ==10731== > at 0x4023FE0: malloc (vg_replace_malloc.c:236) > ==10731== by 0x407897D: > dect_malloc (utils.c:21) > ==10731== by 0x4078486: dect_fd_alloc > (io.c:56) > ==10731== by 0x4077BBF: dect_netlink_init > (netlink.c:352) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > > ==10731== Invalid read of size 4 > ==10731== at 0x408ECF0: event_add (in > /usr/lib/libev.so.3.0.0) > ==10731== by 0x804941E: register_fd > (event_ops.c:36) > ==10731== by 0x4078361: dect_fd_register > (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d4 is not stack'd, malloc'd or (recently) > free'd > ==10731== > ==10731== Invalid read of size 4 > ==10731== at > 0x408ED2F: event_add (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804941E: register_fd (event_ops.c:36) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d4 is not stack'd, malloc'd or (recently) > free'd > ==10731== > ==10731== Invalid write of size 4 > ==10731== at > 0x408ED35: event_add (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804941E: register_fd (event_ops.c:36) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d4 is not stack'd, malloc'd or (recently) > free'd > ==10731== > ==10731== Invalid write of size 4 > ==10731== at > 0x408ECB5: event_add (in /usr/lib/libev.so.3.0.0) > ==10731== by > 0x804941E: register_fd (event_ops.c:36) > ==10731== by 0x4078361: > dect_fd_register (io.c:103) > ==10731== by 0x4077C14: dect_netlink_init > (netlink.c:358) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > ==10731== > Address 0x41ff7d4 is not stack'd, malloc'd or (recently) > free'd > ==10731== > --10731-- VALGRIND INTERNAL ERROR: Valgrind received a > signal 11 (SIGSEGV) - exiting > --10731-- si_code=1; Faulting address: > 0x74616874; sp: 0x62bdea58 > > valgrind: the 'impossible' happened: > Killed > by fatal signal > ==10731== at 0x3809F551: myvprintf_str > (m_debuglog.c:530) > ==10731== by 0x3809FD32: vgPlain_debugLog_vprintf > (m_debuglog.c:877) > ==10731== by 0x3802A555: vprintf_WRK > (m_libcprint.c:111) > ==10731== by 0x3802A617: vgPlain_printf > (m_libcprint.c:143) > ==10731== by 0x380286C6: vgPlain_assert_fail > (m_libcassert.c:261) > ==10731== by 0x656C501F: ??? > > sched status: > > running_tid=1 > > Thread 1: status = VgTs_Runnable > ==10731== at 0x402331F: > calloc (vg_replace_malloc.c:467) > ==10731== by 0x4055394: nl_object_alloc > (object.c:49) > ==10731== by 0x404284F: nl_dect_cluster_alloc > (cluster_obj.c:64) > ==10731== by 0x4077C34: dect_netlink_init > (netlink.c:148) > ==10731== by 0x405FE5C: dect_open_handle > (libdect.c:66) > ==10731== by 0x804CBEB: main (main.c:108) > > Thanks for > help me > > From kaber at trash.net Fri Nov 12 05:12:29 2010 From: kaber at trash.net (Patrick McHardy) Date: Fri, 12 Nov 2010 06:12:29 +0100 Subject: Dectmon problems on malloc function In-Reply-To: <4CD799C6.3000102@trash.net> References: <63cacf1cef5a8077305f80f16ddfddea@enrutador.com> <4CD799C6.3000102@trash.net> Message-ID: <4CDCCCBD.9030001@trash.net> Am 08.11.2010 07:33, schrieb Patrick McHardy: > On 08.11.2010 00:43, Oscar Soriano Riera wrote: >> ... >> 5) I use Valgrid to see a problem, but valgrid fails, i think >> that is a problem with the malloc when it get memory for the >> stack: >> >> root at DECT:/usr/src/dectmon# valgrind src/dectmon >> ==10731== >> Memcheck, a memory error detector >> ==10731== Copyright (C) 2002-2010, and >> GNU GPL'd, by Julian Seward et al. >> ==10731== Using Valgrind-3.6.0 and >> LibVEX; rerun with -h for copyright info >> ==10731== Command: >> src/dectmon >> ==10731== >> ==10731== Invalid write of size 2 >> ==10731== at >> 0x408E568: event_set (in /usr/lib/libev.so.3.0.0) >> ==10731== by >> 0x804940E: register_fd (event_ops.c:35) >> ==10731== by 0x4078361: >> dect_fd_register (io.c:103) >> ==10731== by 0x4077C14: dect_netlink_init >> (netlink.c:358) >> ==10731== by 0x405FE5C: dect_open_handle >> (libdect.c:66) >> ==10731== by 0x804CBEB: main (main.c:108) >> ==10731== >> Address 0x41ff7d8 is not stack'd, malloc'd or (recently) >> free'd > > > Thanks, that helps, I'll try to figure out what's wrong. I think I know what's happening - you've installed libev3, but are compiling against the libevent headers, which use a different size for struct event. Assuming you're running Debian, try installing libev-libevent-dev, run configure again and rebuild dectmon. I'll try whether this can be caught by the configure script. From oskar at enrutador.com Fri Nov 12 13:33:56 2010 From: oskar at enrutador.com (Oscar Soriano Riera) Date: Fri, 12 Nov 2010 14:33:56 +0100 Subject: Dectmon problems on malloc function In-Reply-To: <4CDCCCBD.9030001@trash.net> References: <63cacf1cef5a8077305f80f16ddfddea@enrutador.com> <4CD799C6.3000102@trash.net> <4CDCCCBD.9030001@trash.net> Message-ID: How great are you Patrick, ohh yeahhhh I made the recommended modifications and dectmon has begun to function properly ?? Runbook: #apt-get install libev-libevent-dev #cd /usr/src/dectmon #make clean #sh autogen.sh #sh configure #make #make install As well I have observed my distribution is Debian: -Debian GNU/Linux squeeze/sid -Linux DECT 2.6.37-rc1+ #3 SMP PREEMPT Mon Nov 8 01:36:34 CET 2010 i686 GNU/Linux 1)Logs dectmon output without adding arguments: root at DECT:/usr/src/dectmon# src/dectmon netlink: cluster0: mode PP ARI: class A: EMC: 0608 FPN: 000cf LCE: set default pmid e3cea 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: extended_fp_info,full_slot,co_setup_on_dummy,basic_a_field_setup,advanced_a_field_setup,cf_messages,in_min_delay,prolonged_preamble netlink: HLC: adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,standard_ciphering,location_registration LCE: BCAST RX: de c0 b4 06 38 c0 ff 05 ff ff 61 3f 3f ff ff |....8.....a??..| LCE: long page: length: 15 CLMS: parse {CLMS-FIXED} message address section: Address: c0b4 Protocol Discriminator: 06 Length Indicator: 38 netlink: message group: 4 netlink: FPC: extended_fp_info,co_setup_on_dummy,basic_a_field_setup,advanced_a_field_setup,cf_messages,in_min_delay,prolonged_preamble netlink: HLC: adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,standard_ciphering,location_registration 2)The output logs running different arguments: root at DECT:/usr/src/dectmon# src/dectmon --dump-mac=yes --dump-dlc=yes --dump-nwk=yes netlink: cluster0: mode PP ARI: class A: EMC: 0608 FPN: 000cf LCE: set default pmid ea3bf 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: extended_fp_info,full_slot,co_setup_on_dummy,basic_a_field_setup,advanced_a_field_setup,cf_messages,in_min_delay,prolonged_preamble netlink: HLC: adpcm_g721_voice,gap_pap_basic_speech,standard_authentication,standard_ciphering,location_registration,generic_media_encapsulation slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 3 B: 7 identities information: E: 0 class: 0 EMC: 0608 FPN: 000cf RPN: 0 slot: 06 A: 7 B: 7 page: RFPI: 678 bearer description: BT: 5000000000 SN: 6 SP: 0 CN: 7 Tonight I'll try the two updates made in git repository: dectmon.git and libdect.git, and will continue studying the protocol. Thank you very much for you work On Fri, 12 Nov 2010 06:12:29 +0100, Patrick McHardy wrote: > Am 08.11.2010 07:33, schrieb Patrick McHardy: >> On 08.11.2010 00:43, Oscar Soriano Riera wrote: >>> ... >>> 5) I use Valgrid to see a problem, but valgrid fails, i think >>> that is a problem with the malloc when it get memory for the >>> stack: >>> >>> root at DECT:/usr/src/dectmon# valgrind src/dectmon >>> ==10731== >>> Memcheck, a memory error detector >>> ==10731== Copyright (C) 2002-2010, and >>> GNU GPL'd, by Julian Seward et al. >>> ==10731== Using Valgrind-3.6.0 and >>> LibVEX; rerun with -h for copyright info >>> ==10731== Command: >>> src/dectmon >>> ==10731== >>> ==10731== Invalid write of size 2 >>> ==10731== at >>> 0x408E568: event_set (in /usr/lib/libev.so.3.0.0) >>> ==10731== by >>> 0x804940E: register_fd (event_ops.c:35) >>> ==10731== by 0x4078361: >>> dect_fd_register (io.c:103) >>> ==10731== by 0x4077C14: dect_netlink_init >>> (netlink.c:358) >>> ==10731== by 0x405FE5C: dect_open_handle >>> (libdect.c:66) >>> ==10731== by 0x804CBEB: main (main.c:108) >>> ==10731== >>> Address 0x41ff7d8 is not stack'd, malloc'd or (recently) >>> free'd >> >> >> Thanks, that helps, I'll try to figure out what's wrong. > > I think I know what's happening - you've installed libev3, but > are compiling against the libevent headers, which use a different > size for struct event. > > Assuming you're running Debian, try installing libev-libevent-dev, > run configure again and rebuild dectmon. I'll try whether this > can be caught by the configure script. -------------- next part -------------- An HTML attachment was scrubbed... URL: From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 8 17:27:22 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 08 Nov 2010 18:27:22 +0100 Subject: Dectmon only recording data partially? Message-ID: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> 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. -------------- 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: From kaber at trash.net Tue Nov 9 10:09:06 2010 From: kaber at trash.net (Patrick McHardy) Date: Tue, 09 Nov 2010 11:09:06 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CD91DC2.8040403@trash.net> 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? From kaber at trash.net Tue Nov 9 10:16:10 2010 From: kaber at trash.net (Patrick McHardy) Date: Tue, 09 Nov 2010 11:16:10 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CD91F6A.6000508@trash.net> 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 From e_tews at cdc.informatik.tu-darmstadt.de Sun Nov 14 00:55:15 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Sun, 14 Nov 2010 01:55:15 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CD91F6A.6000508@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> Message-ID: <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> 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 > -------------- 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: From kaber at trash.net Sun Nov 14 13:04:28 2010 From: kaber at trash.net (Patrick McHardy) Date: Sun, 14 Nov 2010 14:04:28 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CDFDE5C.2070305@trash.net> 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. From kaber at trash.net Sun Nov 14 13:10:07 2010 From: kaber at trash.net (Patrick McHardy) Date: Sun, 14 Nov 2010 14:10:07 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CDFDE5C.2070305@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> Message-ID: <4CDFDFAF.8050602@trash.net> On 14.11.2010 14:04, Patrick McHardy wrote: > 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. > BTW: > 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. From e_tews at cdc.informatik.tu-darmstadt.de Sun Nov 14 13:15:21 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Sun, 14 Nov 2010 14:15:21 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CDFDFAF.8050602@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> Message-ID: <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> Am Sonntag, den 14.11.2010, 14:10 +0100 schrieb Patrick McHardy: > BTW: > > > 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. 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. -------------- 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: From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 14:06:27 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 15:06:27 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> Am Sonntag, den 14.11.2010, 14:15 +0100 schrieb Erik Tews: > Am Sonntag, den 14.11.2010, 14:10 +0100 schrieb Patrick McHardy: > > BTW: > > > > > 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. > > 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. 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 -------------- 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: From kaber at trash.net Mon Nov 15 14:14:49 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 15:14:49 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE14059.6070006@trash.net> On 15.11.2010 15:06, Erik Tews wrote: > Am Sonntag, den 14.11.2010, 14:15 +0100 schrieb Erik Tews: >> Am Sonntag, den 14.11.2010, 14:10 +0100 schrieb Patrick McHardy: >>> BTW: >>> >>>> 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. >> >> 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. > > 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? 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. > 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 > From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 14:25:30 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 15:25:30 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CE14059.6070006@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> Message-ID: <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> 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? -------------- 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: From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 14:29:15 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 15:29:15 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> 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. -------------- 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: From kaber at trash.net Mon Nov 15 14:44:49 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 15:44:49 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE14761.10407@trash.net> 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. From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 15:14:20 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 16:14:20 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CE14761.10407@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> Message-ID: <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> 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 -------------- 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: From kaber at trash.net Mon Nov 15 15:19:44 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 16:19:44 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE14F90.1070902@trash.net> On 15.11.2010 16:14, Erik Tews wrote: > 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 The timings indicate that it only receives very few frames from the FP. Is it possible that it's operating in ECO-mode? From kaber at trash.net Mon Nov 15 15:25:10 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 16:25:10 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CE14F90.1070902@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14F90.1070902@trash.net> Message-ID: <4CE150D6.9020704@trash.net> On 15.11.2010 16:19, Patrick McHardy wrote: > On 15.11.2010 16:14, Erik Tews wrote: >> 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? 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. From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 15:46:52 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 16:46:52 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CE150D6.9020704@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14F90.1070902@trash.net> <4CE150D6.9020704@trash.net> Message-ID: <1289836012.8408.46.camel@tp.cdc.informatik.tu-darmstadt.de> Am Montag, den 15.11.2010, 16:25 +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? > > > 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. 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); -------------- 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: From kaber at trash.net Mon Nov 15 15:58:54 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 16:58:54 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289836012.8408.46.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14F90.1070902@trash.net> <4CE150D6.9020704@trash.net> <1289836012.8408.46.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE158BE.4080706@trash.net> On 15.11.2010 16:46, Erik Tews wrote: > Am Montag, den 15.11.2010, 16:25 +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? >> >> >> 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. > > 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? From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 15:25:24 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 16:25:24 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CE14F90.1070902@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14F90.1070902@trash.net> Message-ID: <1289834724.8408.42.camel@tp.cdc.informatik.tu-darmstadt.de> Am Montag, den 15.11.2010, 16:19 +0100 schrieb Patrick McHardy: > On 15.11.2010 16:14, Erik Tews wrote: > > 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 > > The timings indicate that it only receives very few frames from the > FP. Is it possible that it's operating in ECO-mode? 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. -------------- 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: From kaber at trash.net Mon Nov 15 15:27:43 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 16:27:43 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289834724.8408.42.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14F90.1070902@trash.net> <1289834724.8408.42.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE1516F.8070704@trash.net> On 15.11.2010 16:25, Erik Tews wrote: > Am Montag, den 15.11.2010, 16:19 +0100 schrieb Patrick McHardy: >>> [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? > > 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. From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 15:43:57 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 16:43:57 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <4CE1516F.8070704@trash.net> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> <1289831355.8408.28.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14761.10407@trash.net> <1289834060.8408.32.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14F90.1070902@trash.net> <1289834724.8408.42.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE1516F.8070704@trash.net> Message-ID: <1289835837.8408.43.camel@tp.cdc.informatik.tu-darmstadt.de> Am Montag, den 15.11.2010, 16:27 +0100 schrieb Patrick McHardy: > On 15.11.2010 16:25, Erik Tews wrote: > > Am Montag, den 15.11.2010, 16:19 +0100 schrieb Patrick McHardy: > >>> [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? > > > > 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. Sorry, new firmware makes not difference here. -------------- 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: From kaber at trash.net Mon Nov 15 14:42:51 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 15:42:51 +0100 Subject: Dectmon only recording data partially? In-Reply-To: <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289237242.11986.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CD91F6A.6000508@trash.net> <1289696115.6890.2.camel@tp.cdc.informatik.tu-darmstadt.de> <4CDFDE5C.2070305@trash.net> <4CDFDFAF.8050602@trash.net> <1289740521.9144.2.camel@tp.cdc.informatik.tu-darmstadt.de> <1289829987.8408.22.camel@tp.cdc.informatik.tu-darmstadt.de> <4CE14059.6070006@trash.net> <1289831130.8408.26.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE146EB.8050300@trash.net> On 15.11.2010 15:25, Erik Tews wrote: > 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? 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. From kaber at trash.net Sat Nov 13 16:35:20 2010 From: kaber at trash.net (Patrick McHardy) Date: Sat, 13 Nov 2010 17:35:20 +0100 Subject: dectmon deciphering Message-ID: <4CDEBE48.7090503@trash.net> Just in case someone is interested - I've just pushed out changes to allow dectmon to decipher connections if it was able to track the initial key allocation (and thus knows the UAK). The PIN it uses is currently hardcoded to "0000" in src/nwk.c, so make sure to change it to use your own PIN or add brute forcing :) If someone wants to play with this, I'm still looking for traces of Siemens phones during pairing, location updates etc :) ... NWK: 05 40 0a 03 01 18 18 0c 08 23 b1 0e 03 7d 0d 3f |. at .......#...}.?| NWK: ee 0e 08 77 1c 1c 5f aa a6 06 33 |...w.._...3| {MM-AUTHENTICATION-REQUEST} message: IE: <> id: a len: 5 dst: 0x60c2e0 authentication algorithm: DSAA (1) authentication key type: User authentication key (1) authentication key number: 8 cipher key number: 8 INC: 0 DEF: 0 TXC: 0 UPC: 1 IE: <> id: c len: 10 dst: 0x60c4c0 value: ee3f0d7d030eb123 IE: <> id: e len: 10 dst: 0x60c4e0 value: 3306a6aa5f1c1c77 NWK: 85 41 0d 04 ba 5b b8 af |.A...[..| {MM-AUTHENTICATION-REPLY} message: IE: <> id: d len: 6 dst: 0x60c660 value: afb85bba authentication successful DCK: 30 e5 60 b3 b9 f6 ee e8 |0.`.....| NWK: 05 4c 19 02 81 98 |.L....| {MM-CIPHER-REQUEST} message: IE: <> id: 19 len: 4 dst: 0x60c2b0 enable: 1 cipher algorithm: DECT Standard Cipher 1 (1) cipher key type: derived (9) cipher key num: 8 ciphering enabled: FP->PP ciphering enabled: PP->FP NWK: 83 0d 1e 02 80 88 7c 04 90 02 00 84 |......|.....| {CC-SETUP-ACK} message: IE: <> id: 1e len: 4 dst: 0x60c660 Location: user (0) Progress description: In-band information or appropriate pattern now available (8) IE: <> id: 7c len: 6 dst: 0x60c940 Negotiation Indicator: codec negotiation (1) Codec 1: Codec: G.726 (32kbit) (2) MAC/DLC Service: DLC service: LU1, MAC service: I_NA (0) Slot size: full slot (4) C-Plane routing: C_S only (0) From e_tews at cdc.informatik.tu-darmstadt.de Sat Nov 13 16:44:10 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Sat, 13 Nov 2010 17:44:10 +0100 Subject: dectmon deciphering In-Reply-To: <4CDEBE48.7090503@trash.net> References: <4CDEBE48.7090503@trash.net> Message-ID: Hi Do you know if there is a convention for the cipher key number and the uak number? Usually i assume that they are 0 or 8, but i don't know a way to guess them except eavesdrooping on the key exchange. "Patrick McHardy" schrieb: >Just in case someone is interested - I've just pushed out changes >to allow dectmon to decipher connections if it was able to track >the initial key allocation (and thus knows the UAK). The PIN it >uses is currently hardcoded to "0000" in src/nwk.c, so make sure >to change it to use your own PIN or add brute forcing :) > >If someone wants to play with this, I'm still looking for traces >of Siemens phones during pairing, location updates etc :) > >... >NWK: 05 40 0a 03 01 18 18 0c 08 23 b1 0e 03 7d 0d 3f >|. at .......#...}.?| >NWK: ee 0e 08 77 1c 1c 5f aa a6 06 33 >|...w.._...3| >{MM-AUTHENTICATION-REQUEST} message: > IE: <> id: a len: 5 dst: 0x60c2e0 > authentication algorithm: DSAA (1) > authentication key type: User authentication key (1) > authentication key number: 8 > cipher key number: 8 > INC: 0 DEF: 0 TXC: 0 UPC: 1 > IE: <> id: c len: 10 dst: 0x60c4c0 > value: ee3f0d7d030eb123 > IE: <> id: e len: 10 dst: 0x60c4e0 > value: 3306a6aa5f1c1c77 > >NWK: 85 41 0d 04 ba 5b b8 af >|.A...[..| >{MM-AUTHENTICATION-REPLY} message: > IE: <> id: d len: 6 dst: 0x60c660 > value: afb85bba > >authentication successful >DCK: 30 e5 60 b3 b9 f6 ee e8 >|0.`.....| > >NWK: 05 4c 19 02 81 98 >|.L....| >{MM-CIPHER-REQUEST} message: > IE: <> id: 19 len: 4 dst: 0x60c2b0 > enable: 1 > cipher algorithm: DECT Standard Cipher 1 (1) > cipher key type: derived (9) > cipher key num: 8 > >ciphering enabled: FP->PP >ciphering enabled: PP->FP > >NWK: 83 0d 1e 02 80 88 7c 04 90 02 00 84 >|......|.....| >{CC-SETUP-ACK} message: > IE: <> id: 1e len: 4 dst: 0x60c660 > Location: user (0) > Progress description: In-band information or appropriate pattern now >available (8) > IE: <> id: 7c len: 6 dst: 0x60c940 > Negotiation Indicator: codec negotiation (1) > Codec 1: > Codec: G.726 (32kbit) (2) > MAC/DLC Service: DLC service: LU1, MAC service: I_NA (0) > Slot size: full slot (4) > C-Plane routing: C_S only (0) -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From kaber at trash.net Sat Nov 13 16:55:18 2010 From: kaber at trash.net (Patrick McHardy) Date: Sat, 13 Nov 2010 17:55:18 +0100 Subject: dectmon deciphering In-Reply-To: References: <4CDEBE48.7090503@trash.net> Message-ID: <4CDEC2F6.7040209@trash.net> On 13.11.2010 17:44, Erik Tews wrote: > Hi > > Do you know if there is a convention for the cipher key number and the uak number? Usually i assume that they are 0 or 8, but i don't know a way to guess them except eavesdrooping on the key exchange. The key numbers are contained in the authentication and cipher request messages (see below, 8 means key 0 associated with the current IPUI/PARK pair). I've so far not seen any phone using anything else but key number 0 and especially for the cipher key that also doesn't seem to make much sense since ideally its generated directly before its used. In case of the authentication key I don't think its even possible for a normal phone to have more than one since you can't derive it from an existing UAK, so it would have to pair multiple times. Its probably intended for using foreign keys like GSM or a DAM. Anyways, what you could do to get the authentication key number instead of eavesdropping is to send a message to the FP that will trigger authentication using the IPUI of the phone you're interested in. >> {MM-AUTHENTICATION-REQUEST} message: >> IE: <> id: a len: 5 dst: 0x60c2e0 >> authentication algorithm: DSAA (1) >> authentication key type: User authentication key (1) >> authentication key number: 8 >> cipher key number: 8 >> INC: 0 DEF: 0 TXC: 0 UPC: 1 >> {MM-CIPHER-REQUEST} message: >> IE: <> id: 19 len: 4 dst: 0x60c2b0 >> enable: 1 >> cipher algorithm: DECT Standard Cipher 1 (1) >> cipher key type: derived (9) >> cipher key num: 8 From kaber at trash.net Sat Nov 13 17:35:51 2010 From: kaber at trash.net (Patrick McHardy) Date: Sat, 13 Nov 2010 18:35:51 +0100 Subject: dectmon deciphering In-Reply-To: <4CDEBE48.7090503@trash.net> References: <4CDEBE48.7090503@trash.net> Message-ID: <4CDECC77.1050900@trash.net> Am 13.11.2010 17:35, schrieb Patrick McHardy: > Just in case someone is interested - I've just pushed out changes > to allow dectmon to decipher connections if it was able to track > the initial key allocation (and thus knows the UAK). The PIN it > uses is currently hardcoded to "0000" in src/nwk.c, so make sure > to change it to use your own PIN or add brute forcing :) Its configurable now using -p/--auth-pin=PIN. From e_tews at cdc.informatik.tu-darmstadt.de Mon Nov 15 17:53:29 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Mon, 15 Nov 2010 18:53:29 +0100 Subject: tcpdump build problems / new tcpdump tree? Message-ID: <1289843609.8408.49.camel@tp.cdc.informatik.tu-darmstadt.de> Hi Building the libpcap tree works fine, but because libpcap depends on libnl for dect monitoring, every programm using libpcap.a needs to be linked with libnl and libnl-dect. Just trying to build tcpdump from git fails because of that. What would be the best solution for this problem? Starting a new tcpdump tree or trying to fix it in the libpcap tree? -------------- 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: From kaber at trash.net Mon Nov 15 18:37:05 2010 From: kaber at trash.net (Patrick McHardy) Date: Mon, 15 Nov 2010 19:37:05 +0100 Subject: tcpdump build problems / new tcpdump tree? In-Reply-To: <1289843609.8408.49.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1289843609.8408.49.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CE17DD1.2020800@trash.net> Am 15.11.2010 18:53, schrieb Erik Tews: > Hi > > Building the libpcap tree works fine, but because libpcap depends on > libnl for dect monitoring, every programm using libpcap.a needs to be > linked with libnl and libnl-dect. Just trying to build tcpdump from git > fails because of that. > > What would be the best solution for this problem? Starting a new tcpdump > tree or trying to fix it in the libpcap tree? Perhaps we could use weak symbol bindings or dlopen to get at the libnl symbols. Both should work I guess. From e_tews at cdc.informatik.tu-darmstadt.de Tue Nov 23 22:32:25 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Tue, 23 Nov 2010 23:32:25 +0100 Subject: Two small problems with libpcap Message-ID: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> Hi I spotted two small problems with libpcap: * Preables for received PP frames are missing, the dedected.org tools used to include the preamble as well. This can easily be fixed by adding a default preamble if the kernel doesn't report the preamble to the userspace. * The slottime wraps around at 2^12 and not at 2^11 as it used to wrap around with the dedected.org tools. I am not sure about the best solution here, one could also use the full 16 bits for the time which are available in the header. -------------- 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: From kaber at trash.net Wed Nov 24 12:50:29 2010 From: kaber at trash.net (Patrick McHardy) Date: Wed, 24 Nov 2010 13:50:29 +0100 Subject: Two small problems with libpcap In-Reply-To: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CED0A15.2090101@trash.net> On 23.11.2010 23:32, Erik Tews wrote: > Hi > > I spotted two small problems with libpcap: > > * Preables for received PP frames are missing, the dedected.org > tools used to include the preamble as well. This can easily be > fixed by adding a default preamble if the kernel doesn't report > the preamble to the userspace. I guess the kernel should report it, at least with double simplex bearers the sender can't be determined based on the slot number. > * The slottime wraps around at 2^12 and not at 2^11 as it used to > wrap around with the dedected.org tools. I am not sure about the > best solution here, one could also use the full 16 bits for the > time which are available in the header. I'm not sure what you're referring to here. The slot numbers are in the range of 0-23. Generally I think the header format should be revamped: - we don't need the fake ethernet addresses - the preamble should use 5 bytes for the case of a prolonged preamble - the RSSI shouldn't use the raw COA values but defined units - the multiframe number should be added - the RF-band and/or specific frequency should be added. Using the RF-band is probably the more flexible way. - drift for received packets could be added additionally we could optionally ignore S-field errors in the driver and indicate them in the frame header. The easiest way to make these changes is probably to add a new link type for the new header and have wireshark etc. deal with that. From kaber at trash.net Wed Nov 24 12:55:36 2010 From: kaber at trash.net (Patrick McHardy) Date: Wed, 24 Nov 2010 13:55:36 +0100 Subject: Two small problems with libpcap In-Reply-To: <4CED0A15.2090101@trash.net> References: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED0A15.2090101@trash.net> Message-ID: <4CED0B48.9020106@trash.net> On 24.11.2010 13:50, Patrick McHardy wrote: > On 23.11.2010 23:32, Erik Tews wrote: >> Hi >> >> I spotted two small problems with libpcap: >> >> * Preables for received PP frames are missing, the dedected.org >> tools used to include the preamble as well. This can easily be >> fixed by adding a default preamble if the kernel doesn't report >> the preamble to the userspace. > > I guess the kernel should report it, at least with double simplex > bearers the sender can't be determined based on the slot number. > >> * The slottime wraps around at 2^12 and not at 2^11 as it used to >> wrap around with the dedected.org tools. I am not sure about the >> best solution here, one could also use the full 16 bits for the >> time which are available in the header. > > I'm not sure what you're referring to here. The slot numbers are in > the range of 0-23. > > Generally I think the header format should be revamped: > > - we don't need the fake ethernet addresses > - the preamble should use 5 bytes for the case of a prolonged > preamble > - the RSSI shouldn't use the raw COA values but defined units > - the multiframe number should be added > - the RF-band and/or specific frequency should be added. Using > the RF-band is probably the more flexible way. > - drift for received packets could be added One more thing - for good measure we should also somehow indicate whether/which half slots are used, the slot number alone is not enough for that. > > additionally we could optionally ignore S-field errors in the driver > and indicate them in the frame header. > > The easiest way to make these changes is probably to add a new > link type for the new header and have wireshark etc. deal with > that. > From e_tews at cdc.informatik.tu-darmstadt.de Wed Nov 24 13:12:27 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Wed, 24 Nov 2010 14:12:27 +0100 Subject: Two small problems with libpcap In-Reply-To: <4CED0A15.2090101@trash.net> References: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED0A15.2090101@trash.net> Message-ID: <1290604347.9039.0.camel@tp.cdc.informatik.tu-darmstadt.de> Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy: > I'm not sure what you're referring to here. The slot numbers are in > the range of 0-23. Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if I am not mistaken, now they are in range 0-4095. -------------- 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: From kaber at trash.net Wed Nov 24 13:30:13 2010 From: kaber at trash.net (Patrick McHardy) Date: Wed, 24 Nov 2010 14:30:13 +0100 Subject: Two small problems with libpcap In-Reply-To: <1290604347.9039.0.camel@tp.cdc.informatik.tu-darmstadt.de> References: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED0A15.2090101@trash.net> <1290604347.9039.0.camel@tp.cdc.informatik.tu-darmstadt.de> Message-ID: <4CED1365.2060902@trash.net> On 24.11.2010 14:12, Erik Tews wrote: > Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy: >> I'm not sure what you're referring to here. The slot numbers are in >> the range of 0-23. > > Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if > I am not mistaken, now they are in range 0-4095. Still not sure what this would indicate. I see nothing of this sort in the coa_syncsniff.c code, byte 18 is 0, byte 19 contains the RSSI. From kaber at trash.net Wed Nov 24 13:34:40 2010 From: kaber at trash.net (Patrick McHardy) Date: Wed, 24 Nov 2010 14:34:40 +0100 Subject: Two small problems with libpcap In-Reply-To: <4CED1365.2060902@trash.net> References: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED0A15.2090101@trash.net> <1290604347.9039.0.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED1365.2060902@trash.net> Message-ID: <4CED1470.3000506@trash.net> On 24.11.2010 14:30, Patrick McHardy wrote: > On 24.11.2010 14:12, Erik Tews wrote: >> Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy: >>> I'm not sure what you're referring to here. The slot numbers are in >>> the range of 0-23. >> >> Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if >> I am not mistaken, now they are in range 0-4095. > > Still not sure what this would indicate. I see nothing of this sort > in the coa_syncsniff.c code, byte 18 is 0, byte 19 contains the RSSI. > I see what you mean - it's the slot number, but in network byte order. The range is 0-23. From e_tews at cdc.informatik.tu-darmstadt.de Wed Nov 24 13:42:26 2010 From: e_tews at cdc.informatik.tu-darmstadt.de (Erik Tews) Date: Wed, 24 Nov 2010 14:42:26 +0100 Subject: Two small problems with libpcap In-Reply-To: <4CED1470.3000506@trash.net> References: <1290551545.7185.4.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED0A15.2090101@trash.net> <1290604347.9039.0.camel@tp.cdc.informatik.tu-darmstadt.de> <4CED1365.2060902@trash.net> <4CED1470.3000506@trash.net> Message-ID: <1290606146.9039.23.camel@tp.cdc.informatik.tu-darmstadt.de> Am Mittwoch, den 24.11.2010, 14:34 +0100 schrieb Patrick McHardy: > On 24.11.2010 14:30, Patrick McHardy wrote: > > On 24.11.2010 14:12, Erik Tews wrote: > >> Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy: > >>> I'm not sure what you're referring to here. The slot numbers are in > >>> the range of 0-23. > >> > >> Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if > >> I am not mistaken, now they are in range 0-4095. > > > > Still not sure what this would indicate. I see nothing of this sort > > in the coa_syncsniff.c code, byte 18 is 0, byte 19 contains the RSSI. > > > > I see what you mean - it's the slot number, but in network byte order. > The range is 0-23. Sorry for that, I still had an old version of wireshark installed. -------------- 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: