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.
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
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.gitgit://dect.osmocom.org/libnl.gitgit://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
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
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). Thanks for the reply.
Best regards,
Thomas
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)
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
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
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.
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)