Hi,
libasan reports heap overflow in tetra-rx
To reproduce:
checkout latest osmo-tetra
optionally modify Makefile to add -DDEBUG to CFLAGS
make debug (compiling this on debian 12 using the prepackaged
libosmocore)
dd if=/dev/zero of=testbits.bin bs=1k count=4
mkdir r
./tetra-rx -d r testbits.bin
[...]
burst_sync_in: 64 bits, state 0
-> trying to find training sequence between bit 0 and 4032
burst_sync_in: 64 bits, state 0
-> trying to find training sequence between bit 0 and 4096
=================================================================
==169038==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x621000001178 at pc 0x55e8c5b1acd0 bp 0x7ffee4666cf0 sp 0x7ffee4666ce8
READ of size 1 at 0x621000001178 thread T0
#0 0x55e8c5b1accf in tetra_find_train_seq phy/tetra_burst.c:294
#1 0x55e8c5b19d30 in tetra_burst_sync_in phy/tetra_burst_sync.c:75
#2 0x55e8c5b19917 in main
/home/sq5bpf/tetra2/osmo-tetra-orig/src/tetra-rx.c:94
#3 0x7fc9714461c9 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#4 0x7fc971446284 in __libc_start_main_impl ../csu/libc-start.c:360
#5 0x55e8c5b19540 in _start
(/home/sq5bpf/tetra2/osmo-tetra-orig/src/tetra-rx+0xc540)
0x621000001178 is located 0 bytes to the right of 4216-byte region
[0x621000000100,0x621000001178)
allocated by thread T0 here:
#0 0x7fc9716b89cf in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fc971cb0d53 (/lib/x86_64-linux-gnu/libtalloc.so.2+0x5d53)
SUMMARY: AddressSanitizer: heap-buffer-overflow phy/tetra_burst.c:294 in
tetra_find_train_seq
Shadow bytes around the buggy address:
0x0c427fff81d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c427fff81e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c427fff81f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c427fff8200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c427fff8210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c427fff8220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]
0x0c427fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c427fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c427fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c427fff8260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c427fff8270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
This is some off-by-one bug but not obvious to me while looking at the
code.
Jacek
hello everyone, I installed osmo-tetra, along with telive, and audio codec, but when I open telive and receiver1udp everything seems to be working ok, but telive doesn't display anything as if there is no connection, and if I have the tetra key, the -k function where it should be, a tutorial would help many of us, thank you very much
hello everyone, I recently installed osmo-tetra, and I saw that it has the function of adding -k key, but I don't know where to put -k, if I have the key available, Thank you very much
Hi
I've published a receiver and demodulator using gnuradio 3.10 for
osmo-tetra (and maybe other python3 gnuradio versions, but this was not
tested).
The pull request was sent to https://github.com/osmocom/osmo-tetra, which
i now know won't work.
I will figure out how to send the patch, when i get some time to read the
docs, but in the meantime, maybe you would just like to grab the files
from here:
https://github.com/sq5bpf/osmo-tetra-temporary-fork
73
Jacek / SQ5BPF
Good evening Sir/Mam
Myself Avinash and I'm currently working on a project wherein I am required
to implement TETRA using SDRs.
It will be a great help for me to have your guidance for the same.
Looking forward to hear from you.
Regards
Hi all!
[please follow-up-to the openbsc(a)lists.osmocom.org mailing list, if
there is any discussion, we don't want to drag it over tons of mailing
lists in parallel]
Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody
noticed the ticket or had any comments to it.
So let me post this as RFC here on the mailing list:
In the past, we had a gitolite/gitosis setup, which was fine in the
early days of git, but it means that people cannot easily create new
repositories, see who has permissions, and we cannot delegate ownership.
Even updating SSH keys requires manual interaction of a sysadmin like
me.
I would therefore suggest to migrate git.osmocom.org to gitea[1]
This would allow the following features:
* users can self-create any number of personal repositories (like gitlab/github)
* we can create 'organizations' along the line of reasonably independent
osmocom member projects like op25, who can then manage their own
repos/permissions/...
* gitea can link to redmine wiki and redmine issue trackers (rather than
using its own built-in)
For those repositories hosted in gerrit (mainly CNI), we would still
keep git.osmocom.org a read-only mirror, like we do it right now.
For those repositories not hosted in gerrit, users/projects could then
accept merge requests in gitea. Coupling this with 3rd party
authentication via github/gitlab/etc should make it easier for the
occasional contributor to submit changes.
There is a downside, of course; A lot of repo URLs have to change. Most
of our current repositories are at git.osmocom.org/project.git while
gitea follows a git.osmocom.org/organization/project.git scheme. I'm not
sure there is any way to help to mitigate this...
Any thoughts, comments?
[1] https://gitea.io/
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear fellow Osmocom developers,
as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021,
trying to compensate it at least to some extent with our OsmoDevCall
every two weeks.
The COVID-19 pandemic is far from over, and we don't know what the
upcoming winter season will bring.
Nevertheless, I think it would be a good idea to start a discussion of
whether we should plan for an OsmoDevCon in 2022.
I personally would say let's plan for the usual late April 2022 time frame,
and if the pandemic situation deteriorates, we can still cancel it with
something like one month lead time.
I would also personally suggest to limit attendance to people who are fully
vaccinated, and in addition do a self-test for all participants every
morning.
In terms of venue, we might also consider to move to a venue that allows better
ventilation. Irrespective of the above we can also bring the air filters from
the sysmocom office.
So with that as an input statement, I would like to hear your opinion
on the above proposals. Who would want to attend? Any complaints against
the "vaccinated only plus daily self-tests in the morning" approach?
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
today our mailing list server lists.osmocom.org has finally been migrated
from mailman2-on-freebsd to mailman3-on-linux. This also included a variety
of changes to DNS. I'll spare you the details, but everything _should_ be up
and running now.
* The List-Id headers should not have changed.
* all list subscriptions + user accounts have been converted.
* old 'static html' archives are still available (read only) at URLs like
https://lists.osmocom.org/pipermail/baseband-devel/
* old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel
are redirected to their respective modern counterparts
In case you notice any mailing list related problem, please don't hesitate to
contact me.
Happy hacking,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
would permit try transmitting.<br><br>So if you either find a legal way to =
include the ETSI code at build time, or<br>preferable write a GPL compatibl=
e audio decoder, I think we would be happy to<br>include it in the git repo=
sitory.<br><br>cheers<br> holger<br><br><br>Hello
Pepijn,<br><br>On Sat, 24 Sep 2011 15:49:37 +0200, "Pepijn van den Berkhof=
" <<a ymailto=3D"mailto:vandenberkhof.pepijn@gmail.com" href=3D"mailto:v=
andenberkhof.pepijn(a)gmail.com">vandenberkhof.pepijn(a)gmail.com</a>> wrote=
:<br>> <br>> But do you actually hear output from a real life network=
? Because I<br>> tried the examples attached to the ETSI document regard=
ing the testing<br>> of the codec. They work very nicely, but no luck on=
real life networks<br>> so far. (yes, no encryption)<br><br>I know that=
others have used the current code to decode speech, maybe<br>someone can c=
onfirm it.<br><br>I haven't worked with the code for a while and so can't c=
onfirm it,<br>but it has worked for me in the past.<br><br>Maybe I find the=
time to try it within the next few weeks, if possible<br>I will also try t=
o provide a sample capture from a test TETRA network<br>so everyone can try=
the sample. "Test TETRA Network" means from a<br>network under our
control run in a faraday cage so that there are<br>no legal issues providi=
ng the capture.<br><br>Best regards,<br> Dieter<br>-- <br>Dieter Spaa=
r, Germany &n=
bsp; <a ymailto=3D"mailto:spaar@mirider.augusta.de" h=
ref=3D"mailto:spaar@mirider.augusta.de">spaar(a)mirider.augusta.de</a><br><br=
><br><div id=3D"yiv1108789824">is that could help us for voice decoding : ?=
<br><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.joys99.com=
/d-4784.html">http://www.joys99.com/d-4784.html</a><br clear=3D"all"><br>--=
<br><br>=0A</div><br>_______________________________________________<br>te=
tra mailing list<br><a ymailto=3D"mailto:tetra@lists.osmocom.org" href=3D"m=
ailto:tetra@lists.osmocom.org">tetra(a)lists.osmocom.org</a><br><a href=3D"ht=
tps://lists.osmocom.org/mailman/listinfo/tetra" target=3D"_blank">https://l=ists.osmocom.org/mailman/listinfo/tetra</a><br><br><br></div></div></div></=
body></html>
--1668814050-976982791-1316890565=:17022--
=========
The BCCH is used for two types of broadcast control channel:
* BSCH (broadcast sync channel)
* Broadcast Network Chanenl (BNCH)
These channels, whcih are present only on the downlink, transmit information
about the serving base station. The BSCH transmits the SYNC message. This
provides physical layer synchronization information, including an
extended training sequence for synchronisation and slot alignment, frequency
correction bits to set the carrier frequency, along with MAC layer information
on frame timing (i.e. the number of the current slot, frame and multiframe) as
well as network layer information. Due to the physical layer synchronisation,
the BSCH is transmitted on a synchronisation burst rather than a normal
downlink burst.
The BNCH either carries the ACCESS-DEFINE message or the SYSINFO message.
The SYSINFO message fives the main carrier frequency so that mobiles can tune
to it after picking up any SYSINFO message infromation on any secondary control
channels, power information and network layer information.
The broadcast control channels are normally transmitted in frame 18. Each takes
up to one block of 216 bits, leaving the other block withing the burst for the
corresponding assigned channel or for the base station to send signalling to
other mobiles. O each slot, the sequence shon win figure 7.45 is used, and the
sequence is offset b yone for each slot in the frame, so that every frame 18
has one BSCH and one BNCH. However, transmitting the network information takes
several half-slot BNCH instances, and it will take some time therefore for a
mobile to acquire all the information it needs. This is not normally a concern
since mobiles will be switched on before they are used and an initial delay can
be tolerated. The standards allow the option of transmitting the BNCH in other
physical control channels (indicated by the AACH) as neccessary. Mobiles
continue to monitor the BCCH after they are switched on and also during
transmissions so as to ensure that they receive network information and remain
synchronised.
Multiframe number 1 2 3 4
DL Frame 18, first half slot BSCH*
DL Frame 18, second half slot * BNCH
* = Transmitted on a Synchronisation Burst
Figure 7.45 BSCH and BNCH transmission sequence.
==============
--
- 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)
Hi Kevin,
On Fri, Nov 05, 2021 at 02:18:14PM +0100, Kévin Redon wrote:
> I'm also happy to help with the recording and streaming of the public talks for those not able to join on site.
thanks for that, as usual.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I have worked on several satellite projects, such as SATCOM. Based on my
past experience, satellite signals usually have high SNRs (or LOS signals)
compared to cellular signals in the city environment, The received
satellite signal's SNR would be approximately 10dB ~ 20dB, or even higher.
I am currently working on a TETRA project, which would be some low earth
orbit signals (terrestrial signals). What could be the range of TETRA
signal SNRs? The received signal's SNR plays a very important role on the
receiver structure design.
Hi, I'm just getting started with the osmo-tetra, and following the wiki (https://osmocom.org/projects/tetra/wiki/Osmo-tetra).
However, I do not see the python scripts in the git source code.
For example, I cannot find:
src/demod/python/tetra-demod.py
* call demodulator on a 'cfile' containing complex baseband samples
src/demod/python/usrp1-tetra_demod.py
* use demodulator in realtime with a USRP1 SDR
src/demod/python/usrp2-tetra_demod.py
* use demodulator in realtime with a USRP2 SDR
Jeff
Dear fellow Osmocom developers,
as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year. At the time, we discussed to re-visit the situation
in October 2020.
While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.
Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.
I'm not 100% in favour and not 100% against. Hence, I would like to get
your input. Should we
a) try to get an event organized on-site in Berlin? We'd have to move
to a larger venue than IN-Berlin with proper ventilation and sufficient
space so we can keep physical distance, but I think that's
manageable for sysmocom as organizer.
b) simply postpone to 2021? I'm convinced the situation will not change
significantly (in a positive way) until late April 2021, so it's not
really a "solution" as it will likely mean we have to think of late
2021 or 2022.
c) plan some kind of online conference? To be honest, I think this
model works fine for events where a single speaker wants to give
lectures to hundreds or thousands of participants. But OsmoDevCon
is much more interactive. We could record or live-stream some talks
or screencasts from home, sure. But that only captures one part of
the event. We could also try to set a date for a collaborative
mumble, or the like - for the "hallway track".
What are your thoughts? Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on openbsc(a)lists.osmocom.org.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
There is an urgent need to migrate our most important public
infrastructure to a new server, and I will be doing that on
*Sunday, July 19 2020*, starting about 9am CEST.
The migration involves redmine (main osmocom.org website), jenkins, gerrit,
git, and cgit.
In theory, the migration should be quick. I would expect (significantly)
less than one hour of downtime. However, we all know Murphys law.
Services not affected are mail (including mailman lists), ftp, dns. So in case
of doubt, we can still use mailing lists to communicate.
In case anyone urgently needs osmocom source code on Sunday morning
during the downtime: There are public mirrors available on github.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
Thanks for the add, I have been hinted this place, and im looking forward
to digging deeper into the realm of TETRA / DQPSK.
What im trying to do is write a C# program for demodulation of TETRA. and
have come so far as to be able to view the IQ vector run around on the
unity circle, but it appears a bit distorted. I think its due to a crude
low pass filter i used on the I/Q signal causing this. From reading books
and sites i find that I should probably used a raised cosine filter to keep
the signal form beeing distorted (ISI). am i correct in my assumption? and
do you have the open source code i can inspect, regardless if programming
language.
I know there is tons of programs out there that can decode and even produce
audio from TETRA DQPSK signals, and I have one installed, but i want to
have an edge to this, i need to understand and learn first hand. It may
take time, but thats how it is.
I have what is required regarding programming skills and radio knowledge -
I am radio Amateur, and 20 years ago i did have Digital communication
classes at Engineering college - But thats 20 years ago, and the equations
in the books are kind of far away in my head.. but the theory sticks.
Please help me get up to speed in decoding DQPSK, im not expecting to do
this quickly, but will be in steps when i have time, and will lead to
questions. But at some point i could be on your frontier digging into TETRA
as a whole.
Best Regards
Kim Mortensen
Dear fellow Osmocom developers,
I would like to invite all developers and contributors to Osmocom [sub]projects
to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin).
For details known so far, please check
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2020.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I was interested in getting involved in some open source development. With
a signal processing background, I thought osmo-tetra might be a good
project. Looking at some data from the New Jersey Transit Authority I
noticed something odd though. Some of the Broadcast PDUs had a type of 3,
which in the spec is only listed as "Reserved." What's more, the control
channels there seem to be missing SYSINFO messages. I'm guessing that
somehow their system does a modified SYSINFO (which is normally broadcast
type 0) and labels it 3? Is anyone familiar with the format they use for
that message? Thanks.
Dear fellow Osmocom developers,
I'm a bit surprised to notice that not more people have signed up for
OsmoDevCon 2019. I guess it was mostly an oversight when the date was
originally announced, and not a lack of interest? ;)
All details about the event are available at the related wiki page at:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2019.
Regards,
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)
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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)
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.
Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.
== When, Who, Where ==
I propose the following date for OsmoDevCon 2018:
April 20 - April 23rd, 2018
* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)
Please let me know ASAP if that proposed date works for everyone who'd
want to attend. We can still change it now, but I would want to nail
down the date pretty soon.
== Format ==
After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.
However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.
We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc
Regards, and looking forward to meeting you [again] in 2018,
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)
Hi,
As we got our first ham radio TETRA BTS in TMO (maybe the first in the
world, who knows?!) I wonder if there is any ongoing work creating a TETRA
BS that is based on some SDR, like USRP or bladeRF?
Would be a quite interesting playground, and TETRA should be documented
enough...
With best regards
Ralph.
Dear Osmocom community,
I would like to point out that at sysmocom, we're currently (again)
hiring [1]. If you happen to have an interest in open source cellular
communications and are fluent in C language development, we would
love to hear from you.
sysmocom probably doesn't need any introduction here, but just in case:
The company was founded by Holger Freyther and Harald Welte, two of the
leading OpenBSC and Osmocom developers from the very early days of the
project. Today we are responsible for by far the largest number of commits
to the Osmocom GSM/3G infrastructure related git repositories.
Among our current priorities are automatic testing for the GPRS PCU,
generalization of the OsmoMGW media gateway, support for load-based hand-over,
inter-BSC hand-over as well as various improvements on the lower layers
of the GPRS protocol stack.
We're very dedicated to the cause in furthering the capabilities of
open source cellular infrastructure from 2G to 4G. We believe in
working upstream, no open core or dual licensing.
If you have an interest working with an enthusiastic, strong technical
and dedicated team of Osmocom hackers, please don't hesitate to let me know,
best by e-mail to jobs(a)sysmocom.de
Thanks,
Harald
p.s.: I hope this kind of message is not disturbing to anyone. I think
it is important to the Osmocom project to have more paid people working
on the stack, so it is justified. The positions we are seeking to fill
will work [almost exclusively] on Osmocom, so it's not a random job ad
but in the very interest of Osmocom, and hence on-topic for this list.
[1] https://www.sysmocom.de/jobs/
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org]
Dear all,
time is flying, and I would like to start early with discussions and planning
about OsmoCon and OsmoDevCon in 2018. It helps to start early.
Side note: We have some pending issues about the events from last year at
http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them
in the text below.
== OsmoDevCon ==
For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as
every year, which means:
* same venue, same catering options
* same concept of 'anyone contributing to Osmocom can apply for
registration until all seats are taken'
* same idea of inviting some few speaker[s] doing other FOSS mobile
communications work to join us
The parts that we need to change, IMHO:
* don't reduce from 4 to 3 days like last year. Have full 4 days again
* sort topics per day / half-day, i.e. have "GSM/UMTS Cellular
Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co,
but then have other days for other projects. This would enable people
not interested in the [continued evolvement] of the cellular projects
be able to skip those days, or to simply meet in an adjacent room for
parallel hacking sessions/discussions
* try to be a bit more structured with the schedule in general. The
existing approach works for people who attend all the event all day
long, but not so well for people with other plans / limited time
Any further change requests or topics to discuss?
Please note that Pablo Neira has offered to kindly host an OsmoDevCon in
Seville (Spain). I've attended a number of netfilter workshops he
organized there, and he's doing a great job! However, given the large
number of attendees from Berlin (and Germany in general), I think this
would make things more complicated, and more expensive for most
attendees. If you disagree with that assessment: I'm open for having
the discussion, I just thought it's more practical/economic to do it in
Berlin.
=== 10 year Anniversary Party ===
Given that 2018 marks the 10 year anniversary of Dieter and me hacking
with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves
some special celebration of some form. I have no concrete idea yet, but
for sure we should so something, and it should be at/around
OsmoDevCon. And for sure we should have a BS-11 around :)
== OsmoCon ==
The public OsmoCon was welcomed and was a success. However,
let's start this discussion with a review of last years event.
=== Registration ===
* Registrations came in way too late. Two weeks ahead of the event, we were
considering to cancel it. And then within the last few days, we had
to turn people down due to limited seating capacity
* To make planning more reliable, we see on other option but to
significantly raise the registration fee combined with an equally
significant discount for early booking
=== Duration ===
* Many people requested multiple days rather than just one, in order to
make more out of (long distance) travels. This is obvious, but as we
had no idea how many people would attend at all (or if we have to
cancel due to lack of attendance), planning multiple days in the first
incarnation would have been high risk and a multitude of work
* I would suggest to expand to two or even three days this week,
possibly one days with tutorials and the other day with tech talks
* Slightly less crammed schedule due to multiple days
=== Venue ===
We recognize this yearso venue was not the best option, due to
* Bad ventilation in the basemenet
* Difficult to find
* No space next to the conference room where people can meet / hang out
in parallel to talks (not everyone attends every talk)
I still like the "understatement" of the venue. I'd prefer any hostel /
non-profit / hackerspace / university over luxurious hotels any time.
Going to an expensive venue means more or less automatically more
expensive ticket fees, which again is more likely to exclude pure
community members without a commercial activity related to Osmocom.
So any future venue would ideally:
* be able to hold slightly more people than this year
* have a second room or large lobby in which people can meet for
extended coffee breaks in parallel to some talks, as needed
* be slightly easier to find (and we have to put up some signs outside
and in the lobby)
* have better WiFi and/or wired connectivity
=== Programme / Format ===
* less crammed over multiple days
* some more "interactive" formats were requested, for users to provide
feedback to developers
* there was some discussion about topics / speakers in redmine last
year, but not too much participation [until it was too late].
* I'd suggest a more formal CfP process with a submission deadline that
allows us to publish a preliminary schedule long ahead of the event
=== Video Recordings ===
I think they were a big success, and it was a very big surprise that the
CCC Video Operations Center was volunteering to help such a small and
niche-interest event like OsmoCon. We should make sure that we can
repeat this for 2018.
== Dates / Frequency ==
Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at
a full week for those of you who would like to attend both events. But
then, I think the number of people attending both events is actually not
all that big. Without checking the details, I think not more than half
of the OsmoDevCon attendees were attending OsmoCon. I would expect that
tendency to remain or even increase.
I still think it's good to keep them back-to-back.
In terms of frequency, I would actually suggest we move to a 6-month
cycle rather than a 12-month cycle. There's a lot of development going
on at all time. I understand that not everyone is able to attend two
events just on Osmocom, especially if it's a spare time / hobby type
activity. That's ok, I think there's no problem with attending either
of the two only, and catching up by video recordings and/or mail on the
other.
The qeustion is: Should that second event be developer-oriented or
user-oriented? Or again both? Any comments here?
Ok, that was a somewhat lengthy e-mail. Please make sure to provide any
feedback you may have as early as possible, to increase the chances of
your feedback being reflected in the planning.
Happy hacking,
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)
Hi all,
today I've deployed some cgit improvements on https://git.osmocom.org/,
in the hope that it makes this tool even more useful:
1) syntax highlighting of source code (requested by Hoernchen)
The source code is now highlighted by pygments. I don't really
understand why somebody would want to look at source code a lot in a
browser, but well, it was as easy as to enable the existing pygments
based filter plugin.
2) rendering of "about" page from README.md
As you might have noticed, I've introduced a README.md in a number of
repositoires, and cgit is now rendering an about page for every
repository, e.g. at http://git.osmocom.org/libosmo-abis/about/
3) gerrit change-ID hyperlink generation
All gerrit Change-IDs in commit messages are now automatically converted
to hyperlinks to the respective gerrit change, see e.g. the below
example:
http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44…
Please note that this works for the "Change-Id" line of the actual
change, but also for change-ids in the free text (e.g. "this depends on
change-id ... in libosmocore")
4) Osmocom ticket/issue hyperlink generation
Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
scanned for occurrences of "OS#(\d+)" which are then amended with
hyperlinks to the respective issue on osmocom.org
Please note the OS# prefix is mandatory, so things like "OS#1614, 1615"
will not work, as can be seen at
http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5…
Please format your commit messages accordingly.
Regards,
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)
Hello,
as already announced here is a first DMO patch for the sq5bpf rebase
branch. I currently only modified the physical and lower mac layer. I
added a new SAP: dp_sap_udata_ind but decided to forward the data to the
TMO SAP because otherwise there would be a lot duplicate code.
Best regards
Jannik
Dear Osmocom Community,
I currently writing my masterthesis about TETRA. For this, I am
currently writing my master thesis on TETRA. For this the support of DMO
is necessary. Another student had already implemented a rudimentary DMO
receiver (based on the Osmocom code) in his thesis, which I now develop
further. I would like to add this code to the Osmocom project as a new
branch so that other people can participate.
I was unsure, based on which branch I should develop the code, but I
decide for the laforge / sq5bpf-rebase-20161218 branch, because this is
most useful for my purpose. I hope this is okay and doesn't lead to
chaos. When trying to create a new branch and commit this, however I get
an error message:
$ Git push origin jj / dmo
Error: no DAV locking support at https://git.osmocom.org/osmo-tetra/
Fatal: git-http-push failed Error: Error sending some references to
'https://git.osmocom.org/osmo-tetra'
Unfortunately, I have not found instructions, who is at Osmocom allowed
to commit code or how the process works. Can you help me with this or
send me a link, where I find the appropriate information?
Best regards,
Jannik
Dear all,
osmo-tetra has been without much progress (or the much needed gnuradio
3.7 support) for way too long time. I would like to see the project
move forward. There was a lot of good work by sq5bpf, but unfortunately
that work has happened in a fork outside osmocom.org.
Also, the code has various coding style issues and the commit messages
never consist out of a very short single line. To the benefit of other
reders and developers, that needs to be expanded a bit.
I would like to invite sq5bpf to become part of the Osmocom TETRA
proejct and would love to see a lot of that code go "mainline". Also, I
am open to eventual co-maintainership.
In order to facilitate this, I have moved osmo-tetra into
gerrit.osmocom.org. This allows us to have a structured community
review process (which I hope some of you will participate, particularly
our friend horiz0n) and vote on patches before merging them.
sq5bpf: I hope you have some time and energy to go the extra mile and
get your code merged and work together on a better osmo-tetra for
everyone.
I've started with a re-base of the sq5bpf/master branch on top of the
osmocom/master branch and pushed that to laforge/sq5bpf-rebase-20161218
>From a review through the patches, I believe we should create several
feature branches:
1) minor fixes and extensions
2) SDS related
3) voice related
Looking through the commits, I have several comments and questions
(mostly a result of the very terse commit logs, which is exactly a
reason why they should become more verbose):
* ppm support. Is this about some specific hardware / gnuardio source?
Do you expect it to break other receivers? How can this be
generalized?
edb7fce4ac8496ae1fe0a920bd49d7affcdd83c8 (simdemod2)
* simdemod2: should just be merged
cae3e848751d746431300dc65f7fc178f5e1bf35 (simdemod shellscript fixes)
* should be squashed in the above
e7be1e8672d48aebd1b6595a13c8bdd7a9037407 (codec tweaks)
* This neesd to be re-split into a patch series like the original, and
simply modify those original patches + README rather than adding a
separate set of those
6587739eb074741e64ad46777383a2257b28ea7e (correct tetra_upper_mac.c)
* what does it correct
* remove all the whitespace changes!
* adopt osmocom coding style throughout the code
* replace magic numbers with explanatiosn and/or #defines
* split into individual bug fixes and extension patches
593b9821e1267e19db9922fdd74525cc0f7c73c5 (fix sds crash)
* squash in whatever commit it fixes
8acfc998f0b7463f7ca3a303061611b5edbd072b (LIP / location system)
* remove all the whitespace changes!
* adopt osmocom coding style throughout the code
948ca3ebdde088ff68a8479364c12f24d8c91099 (add missing break)
* squash in whatever commit it fixes
538e8485637276a95216823770ede1e137279ae1 (better lip parsing)
* remove all the whitespace changes!
* adopt osmocom coding style throughout the code
* explain what exactly is better/extended in commitlog
bdf8c371b1d1b5662b031fdad0a3568129b90db7 (var fix)
* squash in whatever commit it fixes
a1fb5c348e6fb1102185131f38df8a8459a0cd83 (codec 64bit compilation)
* modify on top of cleaned up e7be1e8672d48aebd1b6595a13c8bdd7a9037407
4eeb3340ba75ad1a823dba8eb66031f80a5d5019 (gr 3.6 and 3.7 versions)
* copy+paste style development is rather ugly, is there no way to share
at least parts of the code and create a module that works with
multiple versions?
* if that's not possible, we should simply abandon all old code and
require 3.7 or higher.
a6b961a7554222dc3d9ce4ae25d859a645bbf109 (float2bits inside tetra-rx)
* the proper way is to have the related code once and use it in multiple
executables, rather than copying it around
6733e6c6edc2091b5e5c700cb26d7635dc08fac5 (move sds parsing to tetra_sds.c)
* should be squashed with original commits to avoid adding it to
tetra_upper_mac.c in the first place
72008e4418cd222cfe1846513cb8345709cdab78 (company-assigned tetra IDs)
* great, but avoid mixing whitespace change with functional changes
7145d09d5b236881edec659883f595f40fe38b88 (remove fifo)
* if the FIFO is no longer needed, this commit should be squashed with
those that introduce the FIFO support in the first place
59b036f59550a6d082b3d51635e381c4ef7e700b (add includes)
* squash with whatever commit that requires those #includes
6d38669f055b0355a71683a4b10fe3fea852b868 (fix d-setup parser)
* squash into commit that introduces the to-be-fixed code
Looking forward to getting this cleaned up and merged :)
Regards,
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)
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
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)
Hello
I've added a very crude pseudo AFC to float_to_bits. It uses an averaging
filter on the input values, and compensates for any fixed offset it finds
in the input data (if all bit combinations are equally likely to appear in
the input stream, then a long-term average should be 0).
This helps a bit when decoding a mistuned signal (due to receiver
frequency drift etc). From a quick test yesterday normally the receiver
works when the signal is mistuned from -1.6 to 1.3kHz, with the -a option
the receiver works when the signal is mistuned from -2.8 to 2kHz.
Diff included, or source here:
https://github.com/sq5bpf/osmo-tetra-sq5bpf/blob/master/src/float_to_bits.c
Jacek
Hello,
i want to ask why there is a mix of python and c code with lots of pipes
in between.
It is a design decision? Or was it some kind of easyer?
Greetings
Martin
Hello, I'm trying to receive tetra signal from rtl_sdr by tetra-demod.py, but I got this error:
rtl_sdr -s 195312 -f 392.1M -|demod/python/tetra-demod.py -s 195312 -i /dev/stdin -o /dev/stdout|./float_to_bits /dev/stdin /dev/stdout|./tetra-rx /dev/stdin
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 000000xx
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
>>> gr_fir_ccc: using SSE
sample rate: 195312
>>> gr_fir_ccf: using SSE
Invalid sample rate: 195312 Hz
WARNING: Failed to set sample rate.
Tuned to 392100000 Hz.
Tuner gain set to automatic.
Reading samples in async mode...
Signal caught, exiting!
Signal caught, exiting!
Short write, samples lost, exiting!
EOF
User cancel, exiting...
FAQ:
Q: Why don't you use osmosdr-tetra_demod_fft.py instead tetra-demod.py?
A: osmosdr-tetra_demod_fft.py is a nightmare for tuning, I've never got to center a signal successfully, so I want to modify rtl_sdr for tunning with mouse wheel.
Q: Why don't you modify osmosdr-tetra_demod_fft.py?
A: Well, I have a large experience programming c, not idea of programming python.
Q: Why don't you learn python?
A: That's the last bullet in my belt, but i wanna try something faster :)
Now a question for you all. Why is not there a C version of tetra demodulator?
Thanks and regards.
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)
Hi,
is there a fixed PLU interval for TETRA systems, or is it somewhere
announced in the MCCH? I have seen a clear 4 hour interval and wonder who is
responsible for it :)
Ralph.
Hi,
is there a fixed PLU interval for TETRA systems, or is it somewhere
announced in the MCCH? I have seen a clear 4 hour interval and wonder who is
responsible for it :)
Ralph.
Hello, where are the old messages of this list?
I'm looking for a 2011 August message talking about a patch for
float_to_bits that uses fread instead of read.
Best regards.
Jesús.
i've written a small patch to osmocom-tetra to send data via udp (i didn't
want to use gsmtap), and a crappy program to display/log/record/listen
live
the only interesting part for people on this list would probably be crude
d-setup, d-release and sds decoding. also the demodulator is stripped from
the gui, so that it can receive baseband via a unix pipe from some
receiver (gnuradio, but could use rtl_fm probably too).
https://github.com/sq5bpf/osmo-tetra-sq5bpf - patched osmocom-tetra
https://github.com/sq5bpf/telive - crappy ncurses gui
jacek
I have download one sample from osmocom speech codec
http://tetra.osmocom.org/trac/wiki/Speech_Codec. I have compiled it
sucesssfully then the output "ccoder.exe"
and "cdecoder.exe" have been built. When i try to run the sample exe file
using the command line, it show Segmentation fault (core dumped).
This is the how i'm running the sample
"./ccoder.exe sample.wav sample2.wav".
I'm very confusing about the input and the output file. What is the correct
type file for input and the output.
Thank you for any respond
So i decided i lift the cat on the table again and start poking around with
some tetra signals.
first i had to use dos2unix on the python files (odd i know)
once it finally found python
i get this
Traceback (most recent call last):
File "./170913/src/demod/python/fcdp-tetra_demod.py", line 5, in <module>
from gnuradio import gr, gru, audio, eng_notation, blks2, optfir
ImportError: cannot import name blks2
i poked around some with the code but i ended up causing more damage then i
was fixing so i thought i ask if there will be an update anytime soon?
if i understood correctly blks2 is moved into 'gr-digital'
Janne Lukkarinen
OH2-EKO
JLxSolutions
Hi all
Doing some work on channel decoded audio frames.
any advice on skipping 1st bit (bad frame indicator bit) (channel decoded frame) 1(bfi)+137bits(16bit-samples)
to work on last 137 bits of frame 1 & frame 2.
Thanks.
Graham.
Dear all,
Time has come to fill out the "Talks/Discussions/Workshop / Hacking"
section of the wiki page.
If you have something you'd like to present, talk about or hack on,
add it there. A simple descriptive title along with an estimated
duration is enough.
I guess we'll collect those for 2/3 weeks and then start making the schedule.
Cheers,
Sylvain
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)
Il 13/01/2014 12:00, tetra-request(a)lists.osmocom.org ha scritto:
> Send tetra mailing list submissions to
> tetra(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/tetra
> or, via email, send a message with subject or body 'help' to
> tetra-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> tetra-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tetra digest..."
>
>
> Today's Topics:
>
> 1. [RFC] [ADMIN] Making lists subscriber-only? (Harald Welte)
>
>
> _______________________________________________
> tetra mailing list
> tetra(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/tetra
OK I fully agree.
Hi all,
time is moving fast, and I want to start some initial discussion and
planning for OsmoDevCon 2014.
There are basically four questions which I'm raising below. Please
provide your feedback to the osmocom-event-orga mailing list only, to
avoid cross-posting over all the project lists.
= Who? =
My intention is to keep it an 'active developer/contributer only' event,
like we had it before. I would also want to keep the group relatively
small, to keep the 'Osmocom family' atmosphere.
If desired, we could have one half or full day of public prsentations in
a larger auditorium, but the developer meeting should be a close group,
as known so far.
= Where? =
If we keep the number of attendees within the same range as this year,
then I'm sure we could again hold it at the same venue. I know it is
not perfect, but it is a place that we have access to, 24 hours per day,
and free of cost for community projects like osmocom.org.
If the community wants a larger event, then this is something that would
require more funds and much more time organizing. And that is something
that I personally could not offer to take care of, sorry. I'm happy to
attend and support any larger events, but I'm unable to take care of
fundraising and venue research.
= When? =
Q1/2014. In January, I'm not aware of any 'blocker' events. February,
there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In
March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg
March 17-21). Did I miss any other FOSS / mobile event that might clash
in Q1?
So my preference woudl be to do it either late January (23-26) or in
February (6-9 or 13-16). Any preferences regarding preferred schedule?
Once we have some concencus here on the list [and we want to do it in
the same size / venue], I'll talk to IN-Berlin.
= What? =
I think that question is easy to answer, if we have the above three
figured out... There's no shortage of topics, I suppose.
You can start adding your suggestions to
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014
Regards,
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)