> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote:
>
Hi all,
> After looking at the code, I don't think reusing table implementation
> would be easy - the approaches are too different as well as underlying
> data structures.
okay. then we will need to use the tree based version and from my point of view we should do it the following way:
* Remove osmo_t4_decode (and related routines) from libosmocore (last step)
* Make the tree based decoder ready in terms of the surrounding style
* Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU)
@Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore
@Radisys:
I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here.
In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU.
Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them.
The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests.
Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same.
Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions.
kind regards
holger
Hi!
I've asked about it before but this seems to have been lost in
communication.
The question is basically how to enable multi-TRX support for
osmo-bts-trx using phy/instance infrastructure similar to other bts?
What I've tried so far is documented in
http://projects.osmocom.org/issues/1648 but it did not result in working
setup yet.
In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
missing to make this actually work are greatly appreciated.
--
Max Suraev <msuraev(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
Hi Max,
Thanks for your reply!
> I think extending utils/conv_gen.py is the way to go because it will
> allow us to have concise description of the convolutional codes in one
> place and as close to the description in standards as possible.
Ok, I will keep your opinion in my mind.
> Could you specify which files exactly are you referring to? Also you can
> use 'git blame' to clarify authorship.
No problem, they are:
- gsm0503_conv.c
- gsm0503_interleaving.c
- gsm0503_mapping.c
- gsm0503_parity.c
- gsm0503_tables.c
Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
Thank you for this hint, this command is very usable! :)
> I don't think library functions should do any sort of logging by itself
> (unless it's a logging functions of course :)
> Instead they should return clearly distinguishable values and let caller
> do the logging as they see fit.
I am agree with you. It's time to use return codes.
Have a nice day!
With best regards,
Vadim Yanitskiy.
Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Dear all,
We recently discussed with Harald, that there is a lot of code related to
GSM L1 should be migrated from OsmoBTS to libosmogsm. The reason is that
it would be better to have one shared implementation of the convolutional
codes, mapping, interleaving, etc., because then in near future it can be
used not only from OsmoBTS, but also from OsmocomBB and even from foreign
projects, such as GR-GSM.
I just started to work on this direction, and found that there is already
some code, related to the conventional codes, in libosmogsm. But unlike
OsmoBTS, where all the tables can be found within the single file named
'gsm0503_conv.c', these tables appears in separate files during building
process. So, I have several questions:
1) Which approach is better to use? To store everything in a single file
or to use auto generation (utils/conv_gen.py)?
2) What about the copyright? I have not seen any license/author info at
the top pf these files. Who is the author?
Also, there is the 'gsm0503_coding.c' file, which uses the following
external dependences:
* The DL1C logging category, which isn't defined in libosmocore;
* The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h'
as well.
So, there is regarding questions:
3) Which logging category it would be better to use after migration?
4) What to do with the 'osmo-bts/gsm_data.h'?
5) I don't think, that it's a good way to require something from the
OpenBSC sources during OsmoBTS build... How can we change it?
With best regards,
Vadim Yanitskiy.
On Wed, Jul 13, 2016 at 07:42:39PM +0200, Juan Antonio Barea Lopez wrote:
> Well, the commands i used were:
> ./configure --disable-pcsc (this is for not installing the chipcard library
Hi Juan,
today a patch for Mac OSX showed up that looks like it fixes exactly your
problem:
https://gerrit.osmocom.org/#/c/802/1/src/codec/Makefile.am
It will probably be merged to master soon, but until then you could fix up that
line in you Makefile.am manually.
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hi,
I have a Siemens BS11 outdoor casing lying around, still in the original
box that is taking up space.
It is available free of charge, shipping costs have to paid though.
In case you are interested, contact me. First come, first serve.
It will otherwise be thrown away coming Friday.
Kind regards,
-Alex
Hi all,
I've expected this before and now it has actually happened: a patch that was
verified by jenkins caused a build failure after being merged by gerrit.
Let's be aware of the possibility of this happening:
Commit [1] changed the rcv_rach() signature and correctly fixed all callers.
Commit [2] added a new caller of rcv_rach(), with the correct, old arguments.
Both tested successfully on their own, and were accepted for merge. [2] was
merged first, thus [1] no longer edited all callers as would have been
necessary.
One way to catch this: gerrit could run another jenkins build every time when
we hit the Submit button and 'master' has already moved on. Not sure if this
is easily achievable.
The other way to catch this are the regular (non-gerrit) jenkins builds on
http://jenkins.osmocom.org/jenkins . Maybe selected jobs could send failure
reports to the noisy gerrit mailing list...
Another way we would see this is as soon as another patch is rebased onto
master, or when testing locally, obviously.
Thanks for your attention,
~Neels
[1] "Change interface in osmo-pcu for 11 bit RACH"
959d1dee67e1c6fcfc57b347be2fb7a2ed099b2d
[2] "EGPRS: PUAN encoding: add test case to show wrong urbb_len issue"
02352b487ac6808b6adb8e8623f0921aad7f02d7
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Dear all,
Does the Silent-call feature provide the same features of testcall from openbts ? Is there a way to use the fuzzer code with it ?
Best regards,
Sami,
For strncat, to obtain n, one must not subtract the length of what is appended,
but the length of what is already written from the buffer size.
Verified with this little test program:
#include <stdio.h>
#include <string.h>
int main() {
char buf[20];
strncpy(buf, "123", 10);
strncat(buf, "456789012345", 10 - strlen(buf));
printf("%s\n", buf);
return 0;
}
It prints "1234567890".
---
gtp/gtp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index 12cb492..34e1dc6 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -648,9 +648,10 @@ static void log_restart(struct gsn_t *gsn)
int counter = 0;
char filename[NAMESIZE];
- filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */
+ /* guarantee nul term, strncpy might omit if too long */
+ filename[NAMESIZE - 1] = 0;
strncpy(filename, gsn->statedir, NAMESIZE - 1);
- strncat(filename, RESTART_FILE, NAMESIZE - 1 - sizeof(RESTART_FILE));
+ strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename));
i = umask(022);
--
2.1.4
Hi all
In some communities we are using 5Ghz wifi links between the box running
openBSC and the sbts2050.
In often works well for some time, but then we get plagued with
BROKEN_UNUSABLE channels:
I cannot say exactly why, probably rain, solar radiation, aliens,
goblins.. etc.
I have yet to actually be able to watch it happen. I usually just
discover the problem, correct it and then it works fine until I get
bored watching.
BTS 1, TRX 0, Timeslot 1, Lchan 2: Type NONE
Connection: 0, State: BROKEN UNUSABLE Error reason: activation timeout
This requires then either
A) use the drop command in the vty
B) restart the osmo-bts process on the 2050 (same thing as A really)
C) restart osmo-nitb
All these things are ugly, as they will drop other calls on the BTS at
the time.
The question is, would somebody help make this more robust, as in have
it self repair?
Initial questions:
Why does the broken unusable channel stay as such until manual intervention,
Is is just because the code has not been written to monitor and recover,
or is there some other reason?
I am thinking that nobody ever did this, probably all testing and
installation has been done using nice reliable cabled ethernet and not
ugly nasty packet dropping 3km wifi links. :-)
Thanks!
Hi list,
I'd like to gauge your opinions on how to handle reverts:
On the one hand, it is good to keep the revert as an exact reverse of the
original commit.
On the other hand, it may be good to include an in-code comment in the revert
to clarify the details for future readers. If both the revert and the comment
happen in the same commit, 'git blame' nicely shows that they are related.
I would tend towards keeping the revert "clean" and adding comments in a
separate commit -- how would you handle this?
Thanks,
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hi list,
I've now heard two conflicting instructions on multi-line comments in osmocom
code; I'd like this clarified, which is the preferred multiline comment style?
From Holger, first hand:
/*
* multi
* line
*/
vs. from Harald (?), via hearsay:
/* multi
* line */
The first is easier to edit, while the last takes up less space...
I always used the shorter one until Holger told me to expand.
Thanks,
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
On Wed, Aug 10, 2016 at 06:16:22PM +0100, Abdulghafar Shabaneh wrote:
> Hi Neels
>
> I did build everything again and got the same error, I use git version
> 2.1.4
> there is no PROJECT in the git link you provided but I use the normal ones
> from
As with common shell scripting lingo, the "$PROJECT" was intended to be
replaced with the separate project names following below, and actually you've
done this correctly:
> git clone git://git.osmocom.org/libosmocore.git
> git clone git://git.osmocom.org/libosmo-abis.git
> git clone git://git.osmocom.org/libosmo-netif.git
> git clone git://git.osmocom.org/libosmo-sccp.git
> git clone git://git.osmocom.org/openggsn.git
> git clone git://git.osmocom.org/libsmpp34.git
> git clone git://git.osmocom.org/openbsc.git
I have verified that the build works on my raspberry. I must say it takes
impossibly long to build :)
My pi hasn't been upgraded in a long time (because that also takes impossibly
long). It is still on Debian 7.5.
Here are the things I did for a working build:
# make /usr/local owned by me, so I can install there without sudo
sudo chown -R $USER /usr/local
# install dependencies
sudo apt-get install automake build-essential gcc pkg-config libc-ares-dev libdbi-dev libpcap-dev libpcsclite-dev libsctp-dev libssl-dev libtalloc-dev libtool make libortp-dev libdbd-sqlite3
# make sure all the libraries will be found -- raspberry pi seems to not
# include /usr/local by default. Without this I get an error for openbsc's make
# check that the libosmo-abis.so.5 it not found, in the testsuite.log:
# (note that you have to do this in every shell you open, or include in your
# ~/.profile or something similar.)
export LD_LIBRARY_PATH=/usr/local/lib
# finally clone and build all projects as listed above.
git clone xxx
cd xxx
autoreconf -fi
./configure
make
make check
make install
cd ..
# For openbsc, you need to build in openbsc/openbsc, and I passed these config
# options:
./configure --enable-smpp --enable-osmo-bsc --enable-nat
Thus osmo-nitb works:
neels@raspberrypi ~/osmo/openbsc/openbsc/src/osmo-nitb $ ./osmo-nitb -c ../../doc/examples/osmo-nitb/sysmobts/openbsc.cfg
<0005> bsc_init.c:498 VTY at 127.0.0.1 4242
<001d> input/ipaccess.c:838 enabling ipaccess BSC mode
<0016> smpp_smsc.c:978 SMPP at 0.0.0.0 2775
<0005> bsc_hack.c:318 CTRL at 127.0.0.1 4249
DB: Database initialized.
DB: Database prepared.
> I have a text file for each of the terminal output but this is too long.
> Should I send them separately or in one long email. I'll ask in the list
> once you tell me.
If the above instructions still don't resolve the issue:
It would be sufficient to provide all the commands you have issued and the
(final) error message(s) produced. But to make sure that the juicy interesting
bits aren't missing, it's easiest to post it all.
Posting build output should not harm much; last time you posted a screenshot
image file of a small portion of build output, which easily exceeds the file
size of your complete build output in plain text format :)
You can also opt for using services like http://paste.lisp.org
Make sure you don't forget to include the commands you ran to start the build!
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hi All,
A few weeks ago, I wrote to the list about a handset that was opening
and holding an lchan after doing IMSI attach.
After some investigation I see this phone is querying the network for
call forwarding status. This phone then cannot send any more USSD codes,
or make calls, although it can receive, but for some reason insists on
doing the query again after call termination.
Doing the same from other handsets, by dialling such codes as *#21# in
each case gives the same result of eternal lchan usage, although some
(more modern) phones seem to eventually timeout, releasing the channel
while others do not.
I connected numerous phones and did the same on each one and pretty soon
I have a kind of DOS situation on the network in that SDCCH is at capacity.
The last log message resulting from the request is
/openbsc/openbsc/src/libmsc/gsm_04_08.c:3586 Dispatching 04.08 message,
pdisc=11
although strangely with one phone, this is followed shortly by:
libosmocore/src/gsm/gsm0480.c:219 USSD Request is too short.
openbsc/openbsc/src/libmsc/ussd.c:55 Unhandled SS
so for that one phone, it would seem handle_rcv_ussd() is being called
from gsm0408_dispatch()
I have been going through the code, basically adding more debug output
to try to verify what is being called from where, and I also found the
functionality in libosmocore such as gsm0480_decode_ss_request(),
although this is not called at anytime from the nitb.
This is an enormous project!
I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in
gsm48_rx_mm_serv_req()
/* we will send a MM message soon */
conn->expire_timer_stopped = 1;
It would seem that we don't ever send this MM message.
It's not clear to me where I might try to check again on the status of
this MM request, or if the problem is a lack of full implementation of
these supplementary service requests.
Would anybody be interested in working on this with me?
Keith.
Today I've solved the recent weird mixup in gerrit of my main sysmocom account
"nhofmeyr" and my private mail address account "neels_test_account".
For some time now I've been marking my commits as neels(a)hofmeyr.de, which
should have been nhofmeyr(a)sysmocom.de. The config is now fixed in my various
git repositories and my future commits should be authored as nhofmeyr.
If you spot another neels(a)hofmeyr.de, that's a bug :)
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
I'd just like to draw attention to an issue that I've just reported:
osmo-bts-trx: fails to assign second lchan on TCH/H TS
http://osmocom.org/issues/1795
Comments and supplementary facts are welcome!
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hi,
the CI infrastructure exists because I found it import to have all Osmocom software compile and I set-up the Jenkins on my personal infrastructure. Since the adoption of gerrit having a stable build infrastructure is crucial though and my set-up was too flawed.
In the past the VirtualBox running the Linux node got stuck and needed manual intervention. As it was running on my private system I was the only one capable of doing that. Sysmocom has offered to rent a dedicated build system and I have used some of my freelancing time to do the migration.
* The Jenkins UI/Server jail has been migrated to the system that runs most of the other Osmocom infrastructure. DNS should be updated soon and then TLS will be enabled for the login.
* OsmocomBuild1 is a Debian8.0/amd64 build slave with plenty of RAM and running on a SSD. All Linux builds should have been migrated away from the Ubuntu-1504-64 system to it.
* rtl-sdr has some funny issue with make uninstall and Doxygen. If someone wants to fix it please go ahead, otherwise I will probably disable doxygen for this build.
* I tried to have OpenBSC/OpenBSC-gerrit run in docker[1] so we can run all configurations at the same time but Jenkins is stepping on itself (and removing files from one label and impacting the other). At least we seem to have a benefit if two people upload changes at the same time.
kind regards
holger
[1] I would prefer something without a server (as aborting a build doesn't abort the container) but still convenient enough to just create a new network namespace and remove it on exit
[2] We are only executing the four configurations in parallel as the "build concurrently" option is stepping on each other (files vanish, etc).
From: Neels Hofmeyr <neels(a)hofmeyr.de>
The INSTALL file is being overwritten by autoreconf, but it is committed
as empty file. As a result, the INSTALL file always shows as modified.
Instead, remove INSTALL from git and ignore it.
---
.gitignore | 1 +
INSTALL | 0
2 files changed, 1 insertion(+)
delete mode 100644 INSTALL
diff --git a/.gitignore b/.gitignore
index e15c19b..d1a0b33 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,7 @@ libtool
ltmain.sh
missing
stamp-h1
+INSTALL
# vim
*.sw?
diff --git a/INSTALL b/INSTALL
deleted file mode 100644
index e69de29..0000000
--
2.1.4
Hello,
I am trying to install Openbsc on the raspberry pi. I get this error (in
the attachment ) when I use make. After ./configure) .
Is there a problem in ipaccess.nano? Recently. If it is optional . Is it
safe to remove it entirely since I am using USRP ?
Thanks
Abdulghafar
Hi everyone,
The osmocom's version of rtl-sdr driver seems to be the main one.
Osmocom's repository is used by distributions to build rtl-sdr packages
and it is source of the code for compilation with use of GNU Radio's
Pybombs.
Is there someone in the Osmocom who is maintaining it? There were some
important developments regarding this driver and it would be great to
add this patches in the Osmocom's repo.
For example one that interests me is turning off dithering so multiple
dongles sharing the same clock generate the same LO frequency.Currently
there is always little frequency offset that makes coherent of the
receivers operation much harder.
Such changes of course have to be done carefully so nothing gets broken
in the process. In case of turning off dithering it results with worse
tuning granularity, so for example turning it off can be made optional.
--
Best Regards,
Piotr Krysik
Hi.
I'm working on http://projects.osmocom.org/issues/1616 and wonder about
$subj.
In case of sysmobts, osmo-pcu obtain this data directly from DSP:
* RSSI (dBm)
* burst timing (in quarter of bits)
* link quality (in dB)
* BER
The first and last value seems to be easy from what I see in
src/osmo-bts-trx/scheduler_trx.c What about burst timing (necessary to
compute TA in the absence of PTCCH) and link quality (measure of C / I
where C is carrier and I is interference power) - how can I compute
those or some estimator to those values?
--
Max Suraev <msuraev(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
Hi.
It's nitpicking time :)
I've noticed that variables exposed over control interface (see
osmobsc-usermanual.pdf for example) are named differently - some use _
(e. g. bts_connection_status) others use - (e. g. short-name). Which
variant is preferred if any?
--
Max Suraev <msuraev(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
Hi.
A little heads-up - I've noticed that certificate on gerrit server has
expired:
gerrit.osmocom.org uses an invalid security certificate. The certificate
expired on 08/01/2016 12:24 PM. The current time is 08/01/2016 12:33 PM.
--
Max Suraev <msuraev(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
