linux-dect

linux-dect@lists.osmocom.org

80 discussions

dectmon released
by Patrick McHardy 28 Oct '10

28 Oct '10

I've uploaded a first release of dectmon, a DECT protocol decoder. It can decode MAC, DLC and NWK-layer messages and show their content in a human readable form. See http://dect.osmocom.org/trac/dect/wiki/Siemens#Traces for examples. Details, including links to the git repository, can be found at http://dect.osmocom.org/trac/dect/blog/kaber-2010/10/27/dectmon_released

1 0

Re: Architecture and software development
by Oscar Soriano Riera 24 Oct '10

24 Oct '10

Hi Patrick The scenario that I find most attractive is 2, can associate with a PC with a card pcmcia to any type of FP either an asterisk or any other manufacturer's base seems exciting. I'll be anxious to try any new developments that take place in the software, if you think that the slides can be useful for the web I can send examples to illustrate the sources, since it is a topic largely unknown in Spain and could help. Anything that can help you be an honor for me. Thank you very much for your work Heavy greetings On Sat, 23 Oct 2010 18:29:29 +0200, Patrick McHardy wrote: > Am 21.10.2010 12:37, schrieb Oscar Soriano Riera: >> Hi Patrick >> >> I have a question about the architecture and software development >> today. >> I've prepared an image(Dect-labv1.0.jpg) on the 3 scenarios in which >> I >> work, basically would be the following: >> >> 1) DECT Terminals Connected to Asterisk >> This lab works perfectly, with the latest versions that have posted >> until today. >> >> 2) Connect a PC card pcmcia Dosh & Amand like a Portable Part (PP) >> You can use a pc with a pcmcia and associate as a PP to asterisk >> server-Dect for make calls with other users?, I have questions / >> problems as a register from the laptop to asterix >> >> 3) Linking two Asterisk servers using the DECT protocol to share >> calls >> between PBXs >> >> It is possible this configuration? > > Both 2) and 3) certainly can be done, but are not implemented - its > basically the same thing, in scenario 3) one of the asterisk servers > would pose as PP. It shouldn't be that much work to add support for > this to the asterisk dect channel plugin, I'd estimate a few hours.

1 0

Re: Problems during compiling dect_raw_event with lasted libdect
by Patrick McHardy 21 Oct '10

21 Oct '10

Am 17.10.2010 02:30, schrieb Oscar Soriano Riera: > Hi > I would like to install the lasted libdect modification , but on the make > step i see a posible problem with a pointer > > root@DECT:/usr/src/libdect# make > SUBDIR include/ > SUBDIR src/ > CC src/raw.c > src/raw.c: In function ‘dect_raw_event’: > src/raw.c:140: error: ‘slot’ undeclared (first use in this function) > src/raw.c:140: error: (Each undeclared identifier is reported only once > src/raw.c:140: error: for each function it appears in.) > src/raw.c:142: warning: passing argument 3 of ‘dh->ops->raw_ops->raw_rcv’ > makes integer from pointer without a cast > src/raw.c:142: note: expected ‘uint8_t’ but argument is of type ‘struct > dect_msg_buf *’ > src/raw.c:142: error: too few arguments to function > ‘dh->ops->raw_ops->raw_rcv’ > make[1]: *** [src/raw.o] Error 1 > make: *** [src] Error 2 Fixed now in git.

2 1

Asterisk DECT channel driver
by Patrick McHardy 15 Oct '10

15 Oct '10

I've written an asterisk DECT channel driver as part of an entire open source DECT stack available at http://dect.osmocom.org, which is attached to this email. The patch is not meant for merging at this time, there's still quite a bit of work to by done, but its in a good enough state that some review, especially of the interactions with asterisk, would be very welcome. The channel driver implements a DECT FP (Fixed Part, aka basestation), currently supporting G.726 audio and a few supplementary features like text messages and user authentication. Telephones can register with the FP using a procedure called "access rights requests", during which an authentication key and an extension is allocated for the telephone. When the telephone is active and in range to the FP, it performs a procedure called "location registration" (probably known from GSM) to announce it is ready to receive calls. The extension is then registered in the dialplan in a special context for the Dial() application in order to support completely dynamic setups where the amount of telephones is not known in advance. It is of course also possible to manually define dialplan rules for the telephones. The telephone specific subscription data (extension, keys, capabilities, ...) are stored in the ast_db and read again on startup. This part is not particulary pretty due to the inflexibility of ast_db(), specifically it needs various keys associated with each telephone, which are stored separately and associated again through the database path (/dect/<IPEI>/...). The ast_realtime architecture unfortunately also doesn't seem to be suitable for this since it appears to be lacking a way to iterate over data or query for multiple entries. Call connection can work in two ways: - when the phone supplies an existing extension during call setup, the call is immediately connected. - otherwise the call is placed in "OVERLAP SENDING" state and for each dialed digit, an extension lookup is performed and the call is connected as soon as an existing extension is dialed. I think that should be about everything where the driver's behaviour diverges from other drivers, the remaining parts should be pretty much self-explanatory. Comments and review welcome.

1 0

Siemens proprietary protocol
by Patrick McHardy 15 Oct '10

15 Oct '10

I'm currently trying to reverse engineer the proprietary Siemens protocol carried in <<ESCAPE-TO-PROPRIETARY>> information elements in order to better support the many features that Siemens implements in a proprietary fashion instead of following the standardized methods (see http://dect.osmocom.org/trac/dect/wiki/Siemens for more information). Since I only own two different kinds of telephones, it would be useful to get some more data. What I'm currently looking for is the debug output from the asterisk channel driver (with "dect set debug on") for the initial pairing, location registration and a call. If people could send me that it would be much appreciated. Please also include the telephone type and CC the linux-dect list. I'll also release a program to capture and decode NWK layer dumps between telephones and non-local FPs similar to the traces at http://dect.osmocom.org/trac/dect/wiki/Siemens#Traces in one or two weeks, I'll post an update then. Thanks!

3 5

Re: Posible Bug Asterisk : known formats found in format list (wav49|gsm|wav) on Asterisk git
by Patrick McHardy 15 Oct '10

15 Oct '10

Am 15.10.2010 01:48, schrieb Oscar Soriano Riera: > Hi PAtrick > I can see some errors in debug mode on asterisk problems with the audio: > > [Oct 15 01:17:05] WARNING[19906]: file.c:1396 ast_format_str_reduce: > ignoring unknown format 'wav49' > [Oct 15 01:17:05] WARNING[19906]: file.c:1396 ast_format_str_reduce: > ignoring unknown format 'gsm' > [Oct 15 01:17:05] WARNING[19906]: file.c:1396 ast_format_str_reduce: > ignoring unknown format 'wav' > [Oct 15 01:17:05] WARNING[19906]: file.c:1426 ast_format_str_reduce: no > known formats found in format list (wav49|gsm|wav) > [Oct 15 01:17:05] ERROR[19906]: app_voicemail.c:11702 load_config: Error > processing format string, defaulting to format 'wav' > > > I find in issues of Asterisk and i thing that this version is affected > > https://issues.asterisk.org/view.php?id=17709 > > I download the patch and solved the problem: > > wget > 'https://issues.asterisk.org/file_download.php?file_id=26764&type=bug' -O - > | patch -p0 Yeah, its not related to the DECT channel driver, but my asterisk version is slightly outdated. Unfortunately I can't resync easily without loosing the history since my master tree got corrupted a while ago due to filesystem errors. I'll probably try again to merge my tree with a fresh SVN import, if that doesn't work I guess I'll have to throw the history away. BTW, please use the linux-dect list (CCed) for anything related to my stack.

1 0

Re: Connecting Dect phones with softphones on asterisk new stack
by Patrick McHardy 14 Oct '10

14 Oct '10

Am 13.10.2010 20:11, schrieb Oscar Soriano Riera: > Hi everyone > > 1)Its posible connect the dect phones to softphone and vicevers , on > asterisk server and do calls between them? Yes. > 2)Its posible that two dect PP that are correct register on asterisk can > run on the same channel ? On the same carrier yes, on the exact same channel (timeslot + carrier) no, unless you have multiple transceivers. > I have 2 siemens a260 their connect perfect to Asterisk PF with dect > channel, but cant call between this two units, but in the log i can see > that the connection is ok: > *CLI> dect show portables > Name Extension > DECT-PT-600 600 > DECT-PT-601 601 > > When do a call from dect 600 to dect 601, doesnt work: > > LCE: link -1 (RELEASED): alloc > LCE: link 24 (ESTABLISHED): start SDU timer > LCE: link 24 (ESTABLISHED): new link: PMID: bb600 LCN: 0 LLN: 1 SAPI: 0 > > LCE: RX: 03 05 05 07 80 a8 00 c0 d3 ae 2a 06 07 a0 a5 01 > |..........*.....| > LCE: RX: 18 27 d6 18 e0 80 7b 06 81 00 02 18 01 44 > |.'....{......D| > LCE: link 24 (ESTABLISHED): stop SDU timer > LCE: link 24 (ESTABLISHED): new transaction: protocol: Call Control F: 0 > TV: 0 > CC: unknown transaction: msg type: 5 > CC-SETUP > parse {CC-SETUP} message > IE: <<PORTABLE-IDENTITY>> id: 5 len: 9 dst: 0xc655568 > type: IPUI (0) > PUT: N (IPEI) > EMC: 0c0d > PSN: 3ae2a > IE: <<FIXED-IDENTITY>> id: 6 len: 9 dst: 0xc69a448 > type: PARK (20) > class: A > EMC: 1182 > FPN: 0fac3 > IE: <<BASIC-SERVICE>> id: e0 len: 2 dst: 0xc5bd578 > call class: normal call (8) > service: basic speech default attributes (0) > IE: <<ESCAPE-TO-PROPRIETARY>> id: 7b len: 8 dst: 0xc65f940 > EMC: 2 > Content: 18 01 44 > LCE: link 24 (ESTABLISHED): set IPUI N EMC: 0c0d PSN: 3ae2a > LCE: link 24 (ESTABLISHED): confirm transaction: Call Control TV: 0 Role: > 1 > CC: call 0xc65e758 (CALL INITIATED): new call > CC: call 0xc65e758 (CALL INITIATED): MNCC_SETUP-ind > > CC: call 0xc65e758 (CALL INITIATED): MNCC_SETUP_ACK-req > build {CC-SETUP-ACK} message > IE: <<PORTABLE-IDENTITY>> id: 5 0xc655568 > type: IPUI (0) > PUT: N (IPEI) > EMC: 0c0d > PSN: 3ae2a > IE: <<FIXED-IDENTITY>> id: 6 0xc69a448 > type: PARK (20) > class: A > EMC: 1182 > FPN: 0fac3 > IE: <<SIGNAL>> id: e4 0xb2c48e2c > signal: ring tone on (0) > IE: <<DELIMITER-REQUEST>> id: a2 0xb2c48e38 > LCE: TX: 83 0d 05 07 80 a8 00 c0 d3 ae 2a 06 07 a0 a5 01 > |..........*.....| > LCE: TX: 18 27 d6 18 e4 00 a2 |.'.....| > [Oct 13 20:09:17] NOTICE[2365]: chan_dect.c:1000 dect_mncc_setup_ind: > Incoming call from DECT-PT-600 > > LCE: RX: 03 7b 2c 03 36 30 31 |.{,.601| > CC: call 0xc65e758 (OVERLAP SENDING): receive msg type 7b > CC: call 0xc65e758 (OVERLAP SENDING): CC-INFO > parse {CC-INFO} message > IE: <<MULTI-KEYPAD>> id: 2c len: 5 dst: 0xc606da8 > info: '601' > CC: call 0xc65e758 (OVERLAP SENDING): MNCC_INFO-ind It seems your dialplan is not set up correctly to direct outgoing calls to the PTs. When registering the PTs, an Dial() extension is automatically created in the context specified as "regcontext". Incoming calls are placed in the context specified as "context". Try adding "include => <regcontext>" to <context", that should make it work. > > LCE: RX: 03 7b 7b 05 81 00 02 30 00 |.{{....0.| > CC: call 0xc65e758 (OVERLAP SENDING): receive msg type 7b > CC: call 0xc65e758 (OVERLAP SENDING): CC-INFO > parse {CC-INFO} message > IE: <<ESCAPE-TO-PROPRIETARY>> id: 7b len: 7 dst: 0xc6680c0 > EMC: 2 > Content: 30 00 > CC: call 0xc65e758 (OVERLAP SENDING): MNCC_INFO-ind > CC: call 0xc65e758 (OVERLAP SENDING): <CC.01>: overlap sending timer > build {CC-RELEASE} message > IE: <<RELEASE-REASON>> id: e2 0xb2c491e8 > release reason: timer expiry (d) > LCE: TX: 83 4d e2 0d |.M..| > CC: call 0xc65e758 (RELEASE PENDING): MNCC_REJECT-ind: cause: > DECT_CAUSE_LOCAL_TIMER_EXPIRY > > LCE: RX: 03 5a e2 00 |.Z..| > CC: call 0xc65e758 (RELEASE PENDING): receive msg type 5a > CC: call 0xc65e758 (RELEASE PENDING): CC-RELEASE-COM > parse {CC-RELEASE-COM} message > IE: <<RELEASE-REASON>> id: e2 len: 2 dst: 0x9420ea0 > release reason: normal (0) > CC: call 0xc65e758 (RELEASE PENDING): MNCC_RELEASE-cfm > LCE: link 24 (ESTABLISHED): close transaction: Call Control TV: 0 Role: 1 > LCE: link 24 (ESTABLISHED): normal release > > LCE: recvmsg: Transport endpoint is not connected > LCE: link 24 (RELEASE_PENDING): normal release complete > LCE: link 24 (RELEASED): destroy > > > > I probe the demo test on extension.conf runs perfect with clients iax.conf > with softphones, but when i do a call to 600 extension this fails: > >>From the Softphone: > > LCE: link 24 (RELEASED): destroy > -- Accepting AUTHENTICATED call from 10.0.0.1: > > requested format = unknown, > > requested prefs = (), > > actual format = ulaw, > > host prefs = (), > > priority = mine > -- Executing [700@from-dect:1] Playback("IAX2/tst-1089", > "demo-echotest") in new stack > -- <IAX2/tst-1089> Playing 'demo-echotest.gsm' (language 'en') > == Spawn extension (from-dect, 700, 1) exited non-zero on > 'IAX2/tst-1089' > -- Hungup 'IAX2/tst-1089' > >>From the Softphone to dect phone siemmens A260: > > -- Accepting AUTHENTICATED call from 10.0.0.1: > > requested format = unknown, > > requested prefs = (), > > actual format = ulaw, > > host prefs = (), > > priority = mine > -- Executing [600@from-dect:1] Gosub("IAX2/tst-7748", > "stdexten(600,DECT/DECT-PT-600)") in new stack > -- Executing [600@from-dect:50000] NoOp("IAX2/tst-7748", "Start > stdexten") in new stack > -- Executing [600@from-dect:50001] Set("IAX2/tst-7748", > "LOCAL(ext)=600") in new stack > -- Executing [600@from-dect:50002] Set("IAX2/tst-7748", > "LOCAL(dev)=600") in new stack > -- Executing [600@from-dect:50003] Set("IAX2/tst-7748", > "LOCAL(cntx)=DECT/DECT-PT-600") in new stack > -- Executing [600@from-dect:50004] Set("IAX2/tst-7748", > "LOCAL(mbx)="600""@DECT/DECT-PT-600"") in new stack > -- Executing [600@from-dect:50005] Dial("IAX2/tst-7748", "600,20") in > new stack > [Oct 13 19:51:51] WARNING[2447]: app_dial.c:1940 dial_exec_full: Dial > argument takes format (technology/[device:]number1) > == Spawn extension (from-dect, 600, 50005) exited non-zero on > 'IAX2/tst-7748' > -- Hungup 'IAX2/tst-7748' > >

2 4

Re: Release of the DECT stack
by Patrick McHardy 30 Sep '10

30 Sep '10

On 30.09.2010 11:53, Rik Snel wrote: > Hi all, > > On Thu, Sep 23, 2010 at 01:08:43PM +0200, Patrick McHardy wrote: >> I've released my DECT stack, its available at http://dect.osmocom.org. >> There's also a small README file explaining its use, more documentation >> will probably follow over the next one or two weeks. > > That's great work! Thanks for the timing comments in the firmware; they > make the workings clearer for me. > > I have a Type III card with an LMX3161, for which support doesn't seem > to be complete (I get an OOPS at > > sc1442x.c: dev->radio_ops->rx_init(dev, off); > > because rx_init is NULL). > > Are there design issues that need to be addressed before LMX3136 support > can be easily implemented? (eg: labels in the firmware explicitly refer > to U2785) I've started working on the radio support for LMX3161 last weekend, the frequency calculations and radio programming is basically complete, however there are some differences in the firmware besides the radio initialization which I still need to analyze. I'm hoping we can use the same firmware for both radios. Will let you know once I have something testable. BTW, there is a new list for topics related to the stack: linux-dect(a)lists.osmocom.org

2 2

Re: Help Compiling libpcap support DECT
by Patrick McHardy 30 Sep '10

30 Sep '10

On 29.09.2010 20:24, Oscar Soriano Riera wrote: > > Hi > I try to install libpcap git, But i cant install: > > I Do #./CONFIGURE > perfect > > But when i do make the error is the next one: > > MAKE: *** NO HAY > NINGUNA REGLA PARA CONSTRUIR EL OBJETIVO `@DECT_SRC@', NECESARIO PARA > `LIBPCAP.A'. ALTO. > > In the makefile: > PSRC = pcap-linux.c pcap-usb-linux.c > @DECT_SRC@ > > I do a modification of Makefile and change @DECT_SRC@ to > libdect.c , but the same failed error. > > What is this value ? You might need to run autoreconf before configure. If that doesn't help, please post the configure output (in english).

1 0

Re: Curious startup of Asterisk + Dect stack 2.6.36-rc5+
by Patrick McHardy 28 Sep '10

28 Sep '10

Am 28.09.2010 01:04, schrieb Oscar Soriano Riera: > I see a curious startup with the new stack of Dect protocol. I have one > laptop (Debian+Dect DOSCH-AMAND pcmcia radio U2785B) and a computer > with DOSCH-AMAND PCI with the same kernel and compilation > > I do all instructions of http://dect.osmocom.org/README. When finish all > configurations and start the daemon Asterix in debug mode i can see the > next event on the log: > > 1) Start the daemon: > > # /etc/init.d/asterisk debug > > > == Registered channel type 'DECT' (Digital Enhanced Cordless > Telecommunications (DECT)) > == Parsing '/etc/asterisk/dect.conf': == Found > -- Registered extension context 'dect_register' (0xc548c10) in table > 0xc5b21c0; registrar: DECT > -- Added extension '601' priority 1 to dect_register (0xc548c10) > -- Added extension '602' priority 1 to dect_register (0xc548c10) > -- Added extension '603' priority 1 to dect_register (0xc548c10) > *dect_netlink_init: Object not found* This indicates the cluster doesn't exist. > *[Sep 28 00:31:22] ERROR[20318]: chan_dect.c:1905 dect_load_module: > Unable to initialize DECT handle* > > 2)Here's what I think that first create the cluster, and proceed to > activate FP mode to realize the call server: > > #dect-cluster-add --name cluster0 --emc 0x1182 --fpn 0x0fac2 --mode fp > #dect-cell-add --name cell0 --cluster cluster0 > #dect-transceiver-bind --transceiver trx0 --cell cell0 > > 3) Launch another time Asterix in Debug, and failed too: > > # /etc/init.d/asterisk debug > > > == Registered channel type 'DECT' (Digital Enhanced Cordless > Telecommunications (DECT)) > == Parsing '/etc/asterisk/dect.conf': == Found > -- Registered extension context 'dect_register' (0xbfc4d50) in table > 0xbebd608; registrar: DECT > -- Added extension '601' priority 1 to dect_register (0xbfc4d50) > -- Added extension '602' priority 1 to dect_register (0xbfc4d50) > -- Added extension '603' priority 1 to dect_register (0xbfc4d50) > *LCE: dect_lce_init: Permission denied* Asterisk is dropping permissions at startup, so you're unable to bind to the cluster. Try starting it as root using "asterisk -pfc". I'll look into fixing this, AFAIK asterisk retains the CAP_NET_ADMIN capability, so I'll probably adjust the permission checks to accept that. > *[Sep 28 00:33:56] ERROR[20438]: chan_dect.c:1905 dect_load_module: > Unable to initialize DECT handle* > > 4) The posible Workaround (I think that all my config is correct) to get > up the daemon Asterix is do this order: > > *delete the cluster:* > > #dect-cluster-delete --name cluster0 > #dect-cell-delete --cell cell0 > > *Detected broadcast message for all:* > > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.933296] Oops: 0000 [#1] SMP > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.933318] last sysfs file: /sys/module/nfnetlink/initstate > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.934154] Process lt-dect-cell-de (pid: 20504, ti=d7a0a000 > task=f6b64c70 task.ti=d7a0a000) > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.934184] Stack: > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.934361] Call Trace: > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.934927] Code: 39 83 08 02 00 00 74 07 89 d8 e8 04 da ff > ff 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 8b 40 28 85 c0 74 08 > 8b 08 8d 53 20 <ff> 51 04 0f b7 83 b4 03 00 00 31 f6 85 c0 74 48 83 ca > ff 0f bc > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.935158] EIP: [<f8452d64>] dect_cell_shutdown+0x14/0x142 > [dect] SS:ESP 0068:d7a0bc90 > > Message from syslogd@WIFI at Sep 28 00:36:12 ... > kernel:[42723.935203] CR2: 0000000000000004 Please send the full oops message. > 5)Then start daemon on debug > *#/etc/init.d/asterisk debug* > > func_blacklist.so => (Look up Caller*ID name/number from blacklist > database) > == Registered channel type 'DECT' (Digital Enhanced Cordless > Telecommunications (DECT)) > == Parsing '/etc/asterisk/dect.conf': == Found > -- Registered extension context 'dect_register' (0xd3bcd50) in table > 0xd2b5608; registrar: DECT > -- Added extension '601' priority 1 to dect_register (0xd3bcd50) > -- Added extension '602' priority 1 to dect_register (0xd3bcd50) > -- Added extension '603' priority 1 to dect_register (0xd3bcd50) > > > And then the Daemon start "apparently" correct > > Some questions: > > 1) its posible that need create the cluster,cell and Rtx before launch > Asterix ? Yes, that's how its supposed to work. > 2)Its posible that need create all the componets of the cluster with and > only with user as asterisk? > > 3) When i run "*nl-link-list" *i can see all interfaces , but i cant > see "a dect interface" , its is normal ? > > # ./nl-link-list > lo loopback <loopback,up,running,lowerup> > eth0 ether 00:06:1b:de:ee:4c <broadcast,multicast> > eth1 ether 00:0c:f1:28:60:f4 <broadcast,multicast,up,running,lowerup> > pan0 ether 6a:08:e2:74:24:db <broadcast,multicast> There is dect-cluster-list, dect-cell-list and dect-transceiver-list for listing the respective DECT components.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linux-dect