linux-dect

linux-dect@lists.osmocom.org

80 discussions

libnl compile error: "usr/bin/ld: cannot find -lnl-route"
by komkon555 26 Jun '17

26 Jun '17

Hallo. So I experienced an issue with libnl-compilation. The error is: make[2]: Entering directory `/usr/src/libnl/src' CCLD nl-pktloc-lookup /usr/bin/ld: cannot find -lnl-route collect2: error: ld returned 1 exit status make[2]: *** [nl-pktloc-lookup] Error 1 make[2]: Leaving directory `/usr/src/libnl/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/libnl/src' make: *** [all-recursive] Error 1 The compilation is tried on Debian Wheezy. The osmocom-linux-kernel/headers (kernel:git://dect.osmocom.org/git/linux-2.6.git) are successfully compiled and installed as in manual. I have tried also all native libnl debian-packages with source. Unfortunately they are not suitable for libdect. Please help. Best regards.

1 1

Dect Kernel Stack for Kernel 4.9
by Newsy Paper 17 Mar '17

17 Mar '17

Hi! I tried to port the kernel stack provided by Patrick McHardy to Kernel 4.9 It is compiling for me and the module also loads, however I'm unable to getthe netlink device working. So there is still no way to get the dectmon working again using a modern linux kernel :( Anyone able to help? I put my patch here: https://paste2.org/F9CImF8x kind regards Newspaperman

1 0

osmocom dect PP-mode
by Pavel Nakonechny 09 May '16

09 May '16

Hello, I am currently playing with Osmocom DECT software stack using COM-ON-AIR PCI card. What I am trying to achieve is to configure test PC as portable part and connect it to DECT base station. I have cloned and successfully compiled the following repos: git://dect.osmocom.org/linux-2.6.git git://dect.osmocom.org/libnl.git git://dect.osmocom.org/libdect.git Following instructions on dect.osmocom.org/wiki/Configuration page I configured PP. However, the example app dect-llme-scan was able to work only after uncommenting line: //nl_dect_llme_mac_info_set_pari(lmsg, pari); With the line above uncommented, dect-llme-scan returns the list of available base stations. So I assume, that hardware and most part of software works. Then I tried to use example pp-access-rights to connect to the test base station. This app fails immediately after launch for the same reason as dect-llme-scan. Thus, I have added nl_dect_llme_mac_info_set_pari(lmsg, pari); with empty PARI to dect_netlink_mac_me_info_req(struct dect_handle *dh) function. With this modification, the example moves farther, but fails anyway with "No such file or directory" message on this line: if (connect(ddl->dfd->fd, (struct sockaddr *)&ddl->dlei, sizeof(ddl->dlei)) < 0 && errno != EAGAIN) goto err3; in file lce.c All in all. May I at first ask about how to properly configure portable part? Here I have to specify EMC and FPN of the base station? # dect-cluster-add --name cluster0 --mode fp --emc 0x1182 --fpn 0x0fac3 # dect-cell-add --name cell0 --cluster cluster0 # dect-transceiver-bind --transceiver trx0 --cell cell0 What should I use here as IPUI? Some random identifier of my PP? # pp-access-rights --cluster cluster0 --pin 0000 --ipui 0x11830fac4 And, in general, are the sources in repos I listed previously were tested in PP mode or they are not fully functional yet? Thanks in advance. :) -- WBR, Pavel

1 1

OsmocomDECT for Fritzbox router
by Thomas Schmiedl 13 Mar '15

13 Mar '15

Hello, would it be possible to use OsmocomDECT with the Fritzbox router? I try to extend my router Fritzbox 7312 with an application called "Callmonitor" (http://freetz.org/wiki/packages/callmonitor; sorry german only), which has a reverse-search (via internet-telephone-books) to query the name of the caller (query by caller's phone number). I want to transfer this name to my DECT cordless phone. Unfortunately, the manufacturer of the router, AVM in Berlin, does not provide any information about DECT (closed-source). Or could someone help me tracing the software dect_manager (http://www.wehavemorefun.de/fritzbox/Dect_manager) or libdect (http://www.wehavemorefun.de/fritzbox/Libdect.so), because I am not a developer. Best regards, Thomas

1 0

OsmocomDECT for Fritzbox router
by Thomas Schmiedl 11 Mar '15

11 Mar '15

1 0

Announcing OsmoDevCon 2015
by Harald Welte 13 Feb '15

13 Feb '15

Dear Osmocom.org project members, I'm happy to be able to announce the annual incarnation of OsmoDevCon. The Date is set for March 27 through 30. Venue: As usual, IN-Berlin e.V. in Berlin, Germany. Further details can be obtained from http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2015 Attendance, as usual, is restricted to people with an active history in the Project by contributions in terms of code, patches, discussions, documentation or in other form. = Registration = If you have wiki access, please add yourself to the #Requested section. Alternatively, you can send me private e-mail about it. After review, your (nick)name will be listed in the #Confirmed section. Looking forward to meeting all of you again soon! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

DECT MitM Attack
by Tobias XY 09 Jan '15

09 Jan '15

Hello, how can i start a "Man in the middle attack", to decrypt encrypted phone calls of the DECT standard? I read something about it on the internet. Here, however, I lack the software and I do not know what hardware do I need to do so. The normal DECT Sniff attack I have already stated. However, one can hereby decode only unencrypted packets. Anyone have an idea? Greetings. Tobi

1 0

error trying to make module under kernel 3.11.7 / gcc-4.7.3
by Atom2 10 Mar '14

10 Mar '14

Hi List, I am trying to compile the kernel driver module for 3.11.7 (gentoo hardened sources) using gcc-4.7.3. The card I am planning to use is a Dosch&Amnand Com-On-Air PCI. So far I have been able to change the patch file provided for the 3.0 kernels (http://dect.osmocom.org/attachment/wiki/Patches/linux-3.0.diff) to apply to my kernel sources. There were a few changes required, but nothing too drastic. However, when I start the 'make' for the kernel the compiler issues an error as follows: [... snip ...] CC kernel/module.o In file included from include/net/dect/mac_ccf.h:12:0, from include/net/dect/dect.h:148, from drivers/dect/coa/sc1442x.c:19: include/net/dect/mac.h:622:8: error: duplicate member ‘lbn’ include/net/dect/mac.h:624:9: error: duplicate member ‘pmid’ CC arch/x86/pci/bus_numa.o CC fs/ext4/super.o CC arch/x86/pci/amd_bus.o make[3]: *** [drivers/dect/coa/sc1442x.o] Error 1 make[2]: *** [drivers/dect/coa] Error 2 make[1]: *** [drivers/dect] Error 2 make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs.... CC arch/x86/power/cpu.o [... snip ...] Given that the related code within include/net/dect/mac.h looks as follows (comments added by me), this seems to be a valid complaint of the compiler: [... snip ...] struct dect_cctrl { enum dect_cctrl_cmds cmd; union { struct { u16 fmid; u32 pmid; /* <=== pmid */ }; struct { u8 lbn; /* <=== lbn */ u8 ecn; u8 type; u8 service; u8 slot; bool cf; u8 a_mod; u8 bz_mod; u8 bz_ext_mod; u8 acr; }; struct { u8 lbn; /* <=== lbn */ u8 reason; u32 pmid; /* <=== pmid */ }; }; }; [... snip ...] lbn and pmid are indeed defined twice. A research on the internet for similar errors suggested that those constructs were tolerated (I don't know how) by gcc versions prior to 4.5, but are no longer valid. Is there any patch available or a suggestion on what I need to change in order to successfully compile the driver. Many thanks and regards, KK

1 0

dect.osmocom.org back up
by Patrick McHardy 08 Mar '14

08 Mar '14

Just FYI: thanks to Holger dect.osmocom.org is back up again (and hopefully will stay up). I might merge the code with the 3.13 kernel during the next days.

1 0

[RFC] [ADMIN] Making lists subscriber-only?
by Harald Welte 12 Jan '14

12 Jan '14

Dear all, so far the osmocom.org mailing lists have always been in a 'non-members are manually moderated' mode. This has created a lot of work for manual list moderation, where a lot of the messages caught are simply spam, and only the occasional valid message is being received. I'd like to thank the list moderators for taking care of this. However, in more recent discussions, we were considering to move the lists to a completely closed mode, i.e. postings would automatically be rejected from non-members. The automatic response would contain a description of how to subscribe in 'nomail' mode, i.e. to subscribe in a way to be able to post to the list, while still not receiving any incoming traffic. The latter should be fine for occasional posters who don't want the bulk e-mail that goes with a full/regular subscription. Please provide feedback in case you disagree with that change. Unless there is major opposition, we will likely transition to the 'closed' mode within one month. Thanks, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linux-dect