Hi!
I'd like to play around with OsmocomDECT a bit, but my prehistoric
laptop with PCMCIA (my Pismo) has given up on me and all desktop
computers I have are PCIe, none has PCI (the oldest being a PowerMac
G5).
But they all do have USB, and I have a Sinus 702 data, also known as
Gigaset M34, a USB DECT adapter. Here are the details as seen from the
PC side:
DECT Data Device:
Produkt-ID: 0x0026
Hersteller-ID: 0x0681 (Siemens Information and Communication Products)
Version: 1,00
Seriennummer: 00045ABF42
Geschwindigkeit: Bis zu 12 MBit/s
Hersteller: Siemens AG
Standort-ID: 0x04100000 / 5
Verfügbare Stromstärke (mA): 500
Erforderliche Stromstärke (mA): 90
I couldn't find too much information on the chipset in these things,
but if anyone is interested in hacking around with this, I could bring
it to the camp.
Cheers,
Simon
--
ATOM-STROM-AUSSTIEG JETZT!
Noch heute zum günstigsten Ökostromanbieter wechseln!
Naturstrom: 22,5 Cent/kWh, Preisgarantie bis Jahresende!
Einfach anmelden unter http://naturstrom-jetzt.de/
I've merged the DECT tree with the Linux 3.0 release. Due to some
recent firmware changes, I'd appreciate feedback whether things are
still working properly for everyone.
Greetings-
I've been banging my head against a wall today trying to identify hardware and a source of supply.
What I'm trying to do is implement a an Asterisk solution that uses DECT headsets. The headset endpoints have no requirement to dial out, only to participate in a conference bridge. I haven't been able to identify a DECT interface that will allow this.
I'd also entertain a SIP-DECT interface that would be SIP to the asterisk box. Range for this solution needs to be about 40-50m.
Does anyone have any suggestions or thoughts?
To anyone who has had problems cloning the git kernel tree
from dect.osmocom.org, thanks to Harald the problem should
be fixed now.
Please retry and report any problems.
It's seems the osmocom kernel is the only one who have a driver for the pci
quicklogic dosh armand card . is it possible to use this drivers with the
dump pcap tool of dedected (dect_cli) ??
Or, is it possible to dump pcap files with commands in libnl + dectmon ???
Thx for your answers and have nice days ;)
unter Kanotix 2.6.30-10-generic habe ich nun folgenden Fehler bei make:
CC [M] net/dect/mac_ccf.o
net/dect/mac_ccf.c:65: warning: ‘dect_slotnum’ defined but not used
net/dect/mac_ccf.c:75: warning: ‘dect_mfn’ defined but not used
net/dect/mac_ccf.c:211: warning: ‘dect_mbc_tb_get_by_lbn’ defined but not used
CC [M] net/dect/dsc.o
CC [M] net/dect/dlc.o
CC [M] net/dect/dlc_cplane.o
CC [M] net/dect/dlc_b_sap.o
CC [M] net/dect/dlc_s_sap.o
CC [M] net/dect/dlc_uplane.o
CC [M] net/dect/ccp.o
net/dect/ccp.c: In function ‘dect_ccp_send_to_cell’:
net/dect/ccp.c:55: error: implicit declaration of function ‘tipc_send_buf’
make[2]: *** [net/dect/ccp.o] Fehler 1
make[1]: *** [net/dect] Fehler 2
make: *** [net] Fehler 2
Kann jemand helfen?
___________________________________________________________
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://produkte.web.de/go/webdefreephone
I'm using the linux-dect code and experimenting with dectmon and the libdect
examples. Mostly, I think they are working well. I have a com-on-air type II
card and it's in an aging P4 laptop. However, I'm having some kernel stability
problems. The machine runs stabily forever before the card is configured with
the netlink utilities. However, once the card is configured then a few minutes
later the kernel will oops.
I'm configuring the card something like:
dect-cluster-add --name cluster0 --emc 0xABCD --fpn 0x12345 --mode PP
dect-cell-add --name cell0 --cluster cluster0 --flags monitor
dect-transceiver-bind --transceiver trx0 --cell cell0
Until the kernel oops then everything seems to work fine and dectmon, for
example will happily log what it sees.
I've attached two kernel logs which seem fairly typical of what is happening.
Can anyone help?
--
Barry Myles
drivers/dect/coa/com_on_air_cs.o
drivers/dect/coa/com_on_air_cs.c:22:23: Fehler: pcmcia/cs.h: Datei oder Verzeichnis nicht gefunden
drivers/dect/coa/com_on_air_cs.c: In Funktion »com_on_air_probe«:
drivers/dect/coa/com_on_air_cs.c:41: Fehler: »win_req_t« nicht deklariert (erste Benutzung in dieser Funktion)
drivers/dect/coa/com_on_air_cs.c:41: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt
drivers/dect/coa/com_on_air_cs.c:41: Fehler: für jede Funktion in der er auftritt.)
drivers/dect/coa/com_on_air_cs.c:41: Fehler: expected »;« before »req«
drivers/dect/coa/com_on_air_cs.c:42: Warnung: ISO C90 forbids mixed declarations and code
drivers/dect/coa/com_on_air_cs.c:67: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:68: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:68: Fehler: »INT_MEMORY_AND_IO« nicht deklariert (erste Benutzung in dieser Funktion)
drivers/dect/coa/com_on_air_cs.c:69: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:70: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:71: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:73: Fehler: »req« nicht deklariert (erste Benutzung in dieser Funktion)
drivers/dect/coa/com_on_air_cs.c:78: Fehler: »struct pcmcia_device« hat kein Element namens »win«
drivers/dect/coa/com_on_air_cs.c:91: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:100: Fehler: Implizite Deklaration der Funktion »pcmcia_request_configuration«
drivers/dect/coa/com_on_air_cs.c:100: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:106: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:109: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:110: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:111: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:112: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
Fehler habe ich unter Kanotix,Ubuntu 10.04,Mandriva 2010.
Normalen Kernel kann ich bauen, aber dieser will nicht.
drivers/dect/coa/com_on_air_cs.c:112: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:112: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:112: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:116: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:118: Warnung: format »%llx« erwartet Typ »long long unsigned int«, aber Argument 4 hat Typ »resource_size_t«
drivers/dect/coa/com_on_air_cs.c:119: Warnung: format »%llx« erwartet Typ »long long unsigned int«, aber Argument 4 hat Typ »resource_size_t«
drivers/dect/coa/com_on_air_cs.c:121: Warnung: format »%llx« erwartet Typ »long long unsigned int«, aber Argument 4 hat Typ »resource_size_t«
drivers/dect/coa/com_on_air_cs.c:122: Warnung: format »%llx« erwartet Typ »long long unsigned int«, aber Argument 4 hat Typ »resource_size_t«
drivers/dect/coa/com_on_air_cs.c:146: Fehler: »struct pcmcia_device« hat kein Element namens »conf«
drivers/dect/coa/com_on_air_cs.c:164: Fehler: »struct pcmcia_device« hat kein Element namens »win«
make[3]: *** [drivers/dect/coa/com_on_air_cs.o] Fehler 1
make[2]: *** [drivers/dect/coa] Fehler 2
make[1]: *** [drivers/dect] Fehler 2
make: *** [drivers] Fehler 2
[root@localhost linux-2.6]#
___________________________________________________________
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://produkte.web.de/go/webdefreephone
I'm using the linux-dect code and experimenting with dectmon and the libdect
examples. Mostly, I think they are working well. I have a com-on-air type II
card and it's in an aging P4 laptop. However, I'm having some kernel stability
problems. The machine runs stabily forever before the card is configured with
the netlink utilities. However, once the card is configured then a few minutes
later the kernel will oops.
I'm configuring the card something like:
dect-cluster-add --name cluster0 --emc 0xABCD --fpn 0x12345 --mode PP
dect-cell-add --name cell0 --cluster cluster0 --flags monitor
dect-transceiver-bind --transceiver trx0 --cell cell0
Until the kernel oops then everything seems to work fine and dectmon, for
example will happily log what it sees.
I've attached two kernel logs which seem fairly typical of what is happening.
Can anyone help?
--
Barry Myles
Hi
I tried to write some code, which checks all possible pins in a
handshake, so that you don't need to specify the pin. However, I am
currently not able to put my system into a proper monitoring-mode, so I
could not test this patch so far. Could someone check the patch
available at:
http://www.cdc.informatik.tu-darmstadt.de/~e_tews/dectmon/
in branch "pin-bf", that it really works? The code there is completely
untested.
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.
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?
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.
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@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).
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
Hello Everyone,
I am struggling with this problem for almost two weeks now, please I need
help, could someone figure out what is wrong here?
http://dect.osmocom.org/trac/dect/ticket/6
Thanks,
Domonkos Tomcsanyi
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.
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.
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.
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!
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.
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
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).
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.