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
