From laforge at gnumonks.org  Tue Dec  1 23:48:02 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 2 Dec 2015 00:48:02 +0100
Subject: mncc-python tool for talking to MNCC interface
Message-ID: <20151201234802.GE8430@nataraja>

Hi all,

I've been working on a small python tool that can be used to attach to
the MNCC interface of OsmoNITB.  It implements the 04.08 CC state
machine with our MNCC primitives, including support for RTP bridge mode
of the voice streams.

The immediate first use case for this was to be able to automatically,
reproducibly and quickly generate MT calls to a set of known MSISDNs and
load all 14 TCH/H channels of a single-TRX BTS.  It will connect the MT
calls in pairs, so you end up with 7 MS-to-MS calls.  Other use cases
are expected to be added shortly.

The first working version of the tool is available from
	http://git.osmocom.org/mncc-python/
or
	git clone git://git.osmocom.org/mncc-python

The code is pretty hacky in some places.  That's partially due to the
fact that I'm much more familiar in the C, Perl and Erlang world than in
python.  Still I thought it's a good idea to do it in python to enable
more people to use/edit/contribute to it.

I'm happy for review / cleanup suggestion by people with more Python-foo
than I have.

Architecturally, I decided to do things a bit erlang-like, where we have
finite state machines in an actor models, and message passing between
the actors.  This is what happens with the GsmCallFsm()'s, which are
created by the GsmCallConnector() representing both legs of a call and
the MnccActor() that wraps the MNCC socket towards OsmoNITB.

The actual encoding/decodng of MNCC messages is auto-generated from the
mncc header file #defines, enums and c-structures by means of ctypes
code generation.

mncc_test.py currently drops you into a python shell where you can e.g.
start more / new calls by calling functions like
	connect_call("7839", "3802")
from that shell.  Exiting the shell by quit() or Ctrl+C will terminate
all call FSMs and terminate.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Thu Dec  3 10:14:10 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 3 Dec 2015 11:14:10 +0100
Subject: bump: build question
In-Reply-To: <20151129181406.GB7847@dub5>
References: <569979521.10869842.1448714119383.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1456819885.10870106.1448714392116.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20151129181406.GB7847@dub5>
Message-ID: <20151203101410.GA1698@dub5>

bump.

Thx,
~Neels

On Sun, Nov 29, 2015 at 07:14:06PM +0100, Neels Hofmeyr wrote:
[without libc-ares]
> However, I've noticed that the gtphub shows as FAILED instead of skipped,
> just like the sgsn and oap tests. The cause is:
> openbsc/tests/atlocal.in:
>     enable_sgsn_test='@found_libgtp@'
>     enable_gtphub_test='@found_libgtp@'
> 
> It should be something like
> 
>     enable_sgsn_test='@found_libgtp@ and @found_libcares@'
> 
> I'm not sure how best to achieve that. Maybe like this?
> 
> [[[
> --- a/openbsc/configure.ac
> +++ b/openbsc/configure.ac
> @@ -84,6 +84,12 @@ PKG_CHECK_MODULES([LIBCARES], [libcares], [], [found_libcares=no])
>  AM_CONDITIONAL(HAVE_LIBCARES, test "$found_libcares" = yes)
>  AC_SUBST(found_libcares)
>  
> +found_libgtp_and_libcares=no
> +if test "$found_libgtp" = "yes" -a "$found_libcares" = "yes"; then
> +    found_libgtp_and_libcares=yes
> +fi
> +AC_SUBST(found_libgtp_and_libcares)
> +
>  dnl checks for header files
>  AC_HEADER_STDC
>  AC_CHECK_HEADERS(dahdi/user.h,,AC_MSG_WARN(DAHDI input driver will not be built))
> diff --git a/openbsc/tests/atlocal.in b/openbsc/tests/atlocal.in
> index 7475f63..362bfa9 100644
> --- a/openbsc/tests/atlocal.in
> +++ b/openbsc/tests/atlocal.in
> @@ -2,5 +2,6 @@ enable_nat_test='@osmo_ac_build_nat@'
>  enable_smpp_test='@osmo_ac_build_smpp@'
>  enable_bsc_test='@osmo_ac_build_bsc@'
>  enable_mgcp_transcoding_test='@osmo_ac_mgcp_transcoding@'
> -enable_sgsn_test='@found_libgtp@'
> -enable_gtphub_test='@found_libgtp@'
> +enable_sgsn_test='@found_libgtp_and_libcares@'
> +enable_oap_test='@found_libgtp_and_libcares@'
> +enable_gtphub_test='@found_libgtp_and_libcares@'
> ]]]
> 
> And also, the OAP tests don't depend on GTP nor c-ares, but OAP compilation is
> currently closely tied to the SGSN binary. Is it worthwhile to separate at this
> point?
> 
> Thanks!
> ~Neels
> 
> -- 
> - Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte



-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151203/1eab8bc7/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Dec  3 10:52:55 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 3 Dec 2015 11:52:55 +0100
Subject: FYI: gtphub merged
Message-ID: <20151203105255.GB1698@dub5>

Hi list,

after a code review session between Holger and me, I've now merged the
gtphub branch to master, completely. You can't miss the endless sequence
of commits that have just come in on master.

This is not to say that the code is glorified beyond doubt.
Please do review, if you can spare the time.

Thanks,

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151203/a726172c/attachment.bin>

From sipos.csaba at kvk.uni-obuda.hu  Thu Dec  3 12:38:21 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Thu, 3 Dec 2015 13:38:21 +0100 (CET)
Subject: FYI: gtphub merged
In-Reply-To: <20151203105255.GB1698@dub5>
References: <20151203105255.GB1698@dub5>
Message-ID: <1608075646.11725224.1449146301692.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Neels,

First of all, thank you for your work :-)

I have some suggestions and questions, maybe you can shed some light on them.

1. Maybe some minimalistic README or example config file (for example how to use GTPHUB between Osmo-SGSN and OpenGGSN) would be lovely.

2. Is it possible to use GTPHUB as a standalone utility for example to redirect GTP tunnels between an SGW and a PGW? I would love to try to redirect the GTP tunnels before they reach the OpenAIR SGW so we can finally test the Osmo-GTP-kernel implementation instead of the Polaris network one which keeps crashing over a certain amount of GTP-U traffic.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Neels Hofmeyr" <nhofmeyr at sysmocom.de>
C?mzett: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Cs?t?rt?k, 2015. December 3. 11:52:55
T?rgy: FYI: gtphub merged

Hi list,

after a code review session between Holger and me, I've now merged the
gtphub branch to master, completely. You can't miss the endless sequence
of commits that have just come in on master.

This is not to say that the code is glorified beyond doubt.
Please do review, if you can spare the time.

Thanks,

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte


From nhofmeyr at sysmocom.de  Thu Dec  3 13:40:42 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 3 Dec 2015 14:40:42 +0100
Subject: FYI: gtphub merged
In-Reply-To: <20151203105255.GB1698@dub5>
References: <20151203105255.GB1698@dub5>
Message-ID: <20151203134042.GC1698@dub5>

...and I just noticed that I kept working and committing on master for a
few new commits. That wasn't intended, but shouldn't be a problem...

Sorry about that.

~Neels

On Thu, Dec 03, 2015 at 11:52:55AM +0100, Neels Hofmeyr wrote:
> Hi list,
> 
> after a code review session between Holger and me, I've now merged the
> gtphub branch to master, completely. You can't miss the endless sequence
> of commits that have just come in on master.
> 
> This is not to say that the code is glorified beyond doubt.
> Please do review, if you can spare the time.
> 
> Thanks,
> 
> ~Neels
> 
> -- 
> - Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte



-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151203/e9c061d6/attachment.bin>

From axilirator at gmail.com  Sat Dec  5 12:32:45 2015
From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=)
Date: Sat, 5 Dec 2015 18:32:45 +0600
Subject: OpenBSC on CalypsoBTS without voice
Message-ID: <CAPEnp=aQ_o2LC-X189d8wgA6SXU9jO5ScfEWp4t=smKOV4FYvw@mail.gmail.com>

Hi all! Following wiki I am trying to launch OpenBSC on CalypsoBTS (two
OsmocomBB phones) with speech support.

I compiled libosmocore, libosmo-dsp, libosmo-abis and jolly/trx branch of
OsmocomBB with transceiver support. Then I compiled opencore-amr,
Sip-Sofia, oRTP for LCR. Then I compiled OpenBSC, OsmoBTS (with
osmobts-trx) and LCR.

OsmoBTS configured to use two timeslots only (*slotmask 1 1 0 0 0 0 0 0*)
and it uses *TS0 as CCCH+SDCCH4* and *TS1 as TCH/H*. Here is some strings
from my openbsc.cfg:

bts 0
>   codec-support fr hr amr
>   trx 0
>     timeslot 0
>       phys_chan_config CCCH+SDCCH4
>       hopping enabled 0
>     timeslot 1
>       phys_chan_config TCH/H
>       hopping enabled 0
>

When I use jolly/multi-trx branch of libosmo-abis, jolly/testing branch of
OpenBSC and jolly/trx branch of OsmoBTS my network works very unstable.
When I try to make voice call sometimes it falls with message "*No
resources for TCH/H*". Russian language in SMS is not supported. I think it
is because this branches are obsolete.

I tried to compile everything again but used master branches, and it worked
much better! Now everything works as well. But when I call to 995 or 993
numbers of LCR I hear nothing. :(

In OpenBSC console I see:

> <0004> abis_rsl.c:1465 (bts=0,trx=0,ts=1,ss=0) Activating ARFCN(806) SS(0)
> lctype TCH/F r=CALL ra=0x43 ta=1
> <0004> abis_rsl.c:1199 (bts=0,trx=0,ts=1,ss=0) CHANNEL ACTIVATE ACK
> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 ESTABLISH INDICATION
> <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=5
> <0002> gsm_04_08.c:958 <- CM SERVICE REQUEST serv_type=0x01
> MI(TMSI)=4286202573
> <0002> gsm_04_08_utils.c:692 -> CM SERVICE ACK
> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
> <0003> bsc_api.c:500 CLASSMARK CHANGE CM2(len=3) CM3(len=9)
> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
> <0003> bsc_api.c:586 GRPS SUSPEND REQUEST
> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
> <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=3
> <0001> gsm_04_08.c:3508 (bts 0 trx 0 ts 1 ti 8 sub 49643) Received 'SETUP'
> from MS in state 0 (NULL)
> <0001> gsm_04_08.c:3513 Unknown transaction ID 8, creating new trans.
> <0001> transaction.c:71 subscr=0x1d1de30, net=0x1d0bf00
> <0001> gsm_04_08.c:1296 new state NULL -> INITIATED
> <0001> gsm_04_08.c:1931 Subscriber 250013894508275 (49643) sends SETUP to
> 995
> <0001> gsm_04_08.c:1357 (bts 0 trx 0 ts 1 ti 8 sub 49643) Sending
> 'MNCC_SETUP_IND' to MNCC.
> <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received
> 'MNCC_LCHAN_MODIFY' from MNCC in state 1 (INITIATED)
> <000a> bsc_api.c:397 Sending ChanModify for speech 65 1
> <0003> gsm_04_08_utils.c:498 -> CHANNEL MODE MODIFY mode=0x41
> <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received
> 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED)
> <0001> gsm_04_08.c:1296 new state INITIATED -> MO_CALL_PROC
> <0001> gsm_04_08.c:139 (bts 0 trx 0 ts 1 ti 80) Sending 'CALL_PROC' to MS.
> <0001> gsm_04_08.c:1718 queue tch_recv_mncc request (1)
> <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received
> 'MNCC_SETUP_RSP' from MNCC in state 3 (MO_CALL_PROC)
> <0001> gsm_04_08.c:1853 starting timer T313 with 30 seconds
> <0001> gsm_04_08.c:1296 new state MO_CALL_PROC -> CONNECT_IND
> <0001> gsm_04_08.c:139 (bts 0 trx 0 ts 1 ti 80) Sending 'CONNECT' to MS.
> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
> <0003> gsm_04_08_utils.c:534 CHANNEL MODE MODIFY ACK
> <0004> abis_rsl.c:1867 (bts=0,trx=0,ts=1,ss=0) IPAC_BIND speech_mode=0x12
> RTP_PAYLOAD=98
> <0003> osmo_msc.c:72 MSC assign complete (do nothing).
> <0004> abis_rsl.c:1218 (bts=0,trx=0,ts=1,ss=0) CHANNEL MODE MODIFY ACK
> <0004> abis_rsl.c:2031 (bts=0,trx=0,ts=1,ss=0) IPAC_CRCX_ACK
> LOCAL_IP=127.0.0.1 LOCAL_PORT=34079 CON_ID=0 <0001> gsm_04_08.c:1570
> pending tch_recv_mncc request
> <0004> abis_rsl.c:1906 (bts=0,trx=0,ts=1,ss=0) IPAC_MDCX IP=127.0.0.1
> PORT=30000 RTP_PAYLOAD=98 RTP_PAYLOAD2=0 CONN_ID=0 speech_mode=0x02
> <0004> abis_rsl.c:2041 (bts=0,trx=0,ts=1,ss=0) IPAC_MDCX_ACK
> LOCAL_IP=127.0.0.1 LOCAL_PORT=34079 CON_ID=0
> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
> <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=3
> <0001> gsm_04_08.c:3508 (bts 0 trx 0 ts 1 ti 8 sub 49643) Received
> 'CONNECT_ACK' from MS in state 28 (CONNECT_IND)
> <0001> gsm_04_08.c:1337 stopping pending timer T313
> <0001> gsm_04_08.c:1296 new state CONNECT_IND -> ACTIVE
> <0001> gsm_04_08.c:1357 (bts 0 trx 0 ts 1 ti 8 sub 49643) Sending
> 'MNCC_SETUP_COMPL_IND' to MNCC.
>

In LCR console:

> ** LCR  Version 1.14
>
> 000000 DEBUG (in sip.cpp/sip_init() line 1987): SIP globals initialized
> LCR 1.14 started, waiting for calls...
> 000000 TRACE 05.12.15 14:45:48.414 --: LCR 1.14 started, waiting for
> calls...
> 000000 TRACE 05.12.15 14:50:15.063 CH(1): New call ref LCR<->BSC  callref
> new=0x80000001
> 000000 TRACE 05.12.15 14:50:15.063 CH(1): Codec negotiation LCR<->BSC
> bearer capa='given by MS'  speech version='AMR given' version='Full Rate
> given' version='AMR Half Rate given' ignored='Not TCH/H' version='Half Rate
> given' ignored='Not TCH/H'
> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_SETUP_IND LCR<->BSC
> calling number=49643 imsi=XXXXXXXXXXXXXXX  dialing number=995
> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_LCHAN_MODIFY LCR<->BSC
> speech version='AMR given'  mode 0x41
> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_CALL_PROC_REQ LCR<->BSC
> progress coding=3 location=1 descr=8
> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_FRAME_RECV LCR<->BSC
> 000000 TRACE 05.12.15 14:50:15.063 EP(1): SETUP  from CH(1)  interface
> from=gsm  caller id number=49643 present=allowed  dialing 995  complete true
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): TONE  to CH(1)  directory
> default  name dialing
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION (match)  action goto
> line 2
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION goto/menu (change to)
> ruleset gsm  dialing 995
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION (match)  action test
> line 6
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION test  test 'hold music'
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): CONNECT  to CH(1)  connect id
> number= present='not available'
> 000000 TRACE 05.12.15 14:50:15.064 EP(1): TONE  to CH(1)  directory
> default  name hold
> 000000 TRACE 05.12.15 14:50:15.064 CH(1): MNCC_SETUP_RSP LCR<->BSC
> connected type=0 plan=1 present=0 screen=3 number=
> 000000 TRACE 05.12.15 14:50:15.880 CH(1): MNCC_SETUP_COMPL_IND LCR<->BSC
>

I can even send DTMF, but there is no sound...

Transceiver logs (part):

> <0011> trx.c:590 TRX Data 914281:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914253, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914282:0:0:1500a8741832a5700a0bd5d609f850
> <0011> trx.c:590 TRX Data 914282:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914254, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914283:0:0:811d500a01fd40e845d40284155020
> <0011> trx.c:590 TRX Data 914283:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914255, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914284:0:0:abff40aafff4026bffd500aadd4080
> <0011> trx.c:590 TRX Data 914284:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914256, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914285:0:0:01f5508115d50a651f510801755020
> <0011> trx.c:590 TRX Data 914285:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914257, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914286:0:0:10aabdd500aefd7102ab75108bbd50
> <0011> trx.c:590 TRX Data 914286:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914258, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914287:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914259, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914288:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914260, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914289:0:0:a05f550a04dd106a017d008015d020
> <0011> trx.c:590 TRX Data 914289:1:0:e2985a4a90a51468a03d80e70dd060
> <0011> trx.c:608 TRX Data Indication (fn=914261, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914290:0:0:2ebf548abbf502eaadd548aeff4400
> <0011> trx.c:590 TRX Data 914290:1:0:000000000000000000000000000000
> <0011> trx.c:608 TRX Data Indication (fn=914262, tn=1, toa=0.00)
> <0011> trx.c:590 TRX Data 914291:0:0:047d148847740a6517554000754020
> <0011> trx.c:590 TRX Data 914291:1:0:000000000000000000000000000000
>

OsmoBTS logs (part):

> <0000> rsl.c:1733 (bts=0,trx=0,ts=1,ss=0) Handing RLL msg UNIT_DATA_IND
> from LAPDm to MEAS REP
> <0000> rsl.c:1683 (bts=0,trx=0,ts=1,ss=0) Tx MEAS RES valid(2)
> <0006> scheduler.c:1186 Received Access Burst on RACH fn=913629 toa=54.75
> <0006> scheduler.c:1192 Received bad AB frame at fn=913629 (15/51)
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913674 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913674
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913670 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
> fn=913677 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913677
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913679 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913679
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913674 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
> fn=913681 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913681
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913683 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913683
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913679 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913687 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913687
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913683 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913692 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913692
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913687 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913696 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913696
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913692 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913700 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913700
> ts=1 trx=0
> <0006> scheduler.c:3012 GSM clock jitter: -4
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913696 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913705 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913705
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913700 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913709 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913709
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913705 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913713 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913713
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913709 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00
> fn=913718 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=913718
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913718 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913718
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913713 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
> fn=913722 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913722
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913722 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913722
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913718 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913726 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913726
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913722 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
> fn=913728 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913728
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913731 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913731
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913726 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
> fn=913732 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913732
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913735 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913735
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913731 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913739 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913739
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913735 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913744 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913744
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913739 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913748 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913748
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913744 to transmit.
> <0006> scheduler.c:3012 GSM clock jitter: 99
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913752 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913752
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913748 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913757 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913757
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913752 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913761 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913761
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913757 to transmit.
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913765 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913765
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913761 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00
> fn=913769 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=913769
> ts=0 trx=0
> <0006> scheduler.c:339 PH-RTS.ind: chan=SACCH/TF chan_nr=0x09 link_id=0x40
> fn=913769 ts=1 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x40 fn=913769
> ts=1 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913770 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913770
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913765 to transmit.
> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
> fn=913773 ts=0 trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913773
> ts=0 trx=0
> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913774 ts=1
> trx=0
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913774
> ts=1 trx=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
> ts=1 at fn=913770 to transmit.
>

What does it mean "*TCH/F has not been served !! No prim for trx=0 ts=1 at
fn=913770 to transmit.*"?

I tried to make phone<->phone call with and without LCR. I tried to switch
between TCH/H and TCH/F and use different codecs: arm fr hr. But
unfortunately there is no sound.
Can anyone help me?

Thanks a lot!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151205/f80446f0/attachment.htm>

From sipos.csaba at kvk.uni-obuda.hu  Sat Dec  5 14:09:20 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 5 Dec 2015 15:09:20 +0100 (CET)
Subject: PCU <---> SGSN protocol trace
In-Reply-To: <2124546908.12053159.1449323991586.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <347757052.12053750.1449324560182.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear list,

I just appear to have a strange UE behavior where the UE tries to Attach (both CS and PS), the Osmo-SGSN sends an Attach accept, but the UE never responds with an Attach complete, instead after 10 seconds it tries to re-attach.

I had an issue quite similar like this earlies where the UE requests for some IEs or the SGSN sends soething the UE don't like.

The point is, I would like to do protocol trace between the SGSN and the PCU, and I managed to see the traffic with Wireshark, but it was not able to dissect/recognise the protocols over the UDP layer.

Can someone please help me how to configure Wireshark to be able to dissect the involved protocols?

Thanks!

Csaba


From sipos.csaba at kvk.uni-obuda.hu  Sat Dec  5 16:35:06 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 5 Dec 2015 17:35:06 +0100 (CET)
Subject: PCU <---> SGSN protocol trace
In-Reply-To: <347757052.12053750.1449324560182.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <347757052.12053750.1449324560182.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <539649932.12067450.1449333306253.JavaMail.zimbra@kvk.uni-obuda.hu>

Just to put an answer to this, the solution is to right click on the "data" part inside the UDP packet, and select "Decode as" and choose protocol "GPRS-NS", then click OK.

I also used filtering to limit the messaging to the PCU <--> SGSN part:

udp.srcport==23000 or udp.dstport==23000

Hope this will help others too.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
C?mzett: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szombat, 2015. December 5. 15:09:20
T?rgy: PCU <---> SGSN protocol trace

Dear list,

I just appear to have a strange UE behavior where the UE tries to Attach (both CS and PS), the Osmo-SGSN sends an Attach accept, but the UE never responds with an Attach complete, instead after 10 seconds it tries to re-attach.

I had an issue quite similar like this earlies where the UE requests for some IEs or the SGSN sends soething the UE don't like.

The point is, I would like to do protocol trace between the SGSN and the PCU, and I managed to see the traffic with Wireshark, but it was not able to dissect/recognise the protocols over the UDP layer.

Can someone please help me how to configure Wireshark to be able to dissect the involved protocols?

Thanks!

Csaba


From axilirator at gmail.com  Sat Dec  5 18:05:00 2015
From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=)
Date: Sun, 6 Dec 2015 00:05:00 +0600
Subject: OpenBSC on CalypsoBTS without voice
In-Reply-To: <CAPEnp=aQ_o2LC-X189d8wgA6SXU9jO5ScfEWp4t=smKOV4FYvw@mail.gmail.com>
References: <CAPEnp=aQ_o2LC-X189d8wgA6SXU9jO5ScfEWp4t=smKOV4FYvw@mail.gmail.com>
Message-ID: <CAPEnp=aCvJehkM1uFsuR=czBFbG_J6hFAo8H6OSX4-9tuUxQyQ@mail.gmail.com>

Sorry for this email, I found the answer here:
http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html
I reverted oRTP to 0.22.0, recompiled everything and now voice calls works
fine!

It would be cool if configuration scripts will check compatibility of the
oRTP.

Thank you a lot, Sipos Csaba!

2015-12-05 18:32 GMT+06:00 ????? ??????? <axilirator at gmail.com>:

> Hi all! Following wiki I am trying to launch OpenBSC on CalypsoBTS (two
> OsmocomBB phones) with speech support.
>
> I compiled libosmocore, libosmo-dsp, libosmo-abis and jolly/trx branch of
> OsmocomBB with transceiver support. Then I compiled opencore-amr,
> Sip-Sofia, oRTP for LCR. Then I compiled OpenBSC, OsmoBTS (with
> osmobts-trx) and LCR.
>
> OsmoBTS configured to use two timeslots only (*slotmask 1 1 0 0 0 0 0 0*)
> and it uses *TS0 as CCCH+SDCCH4* and *TS1 as TCH/H*. Here is some strings
> from my openbsc.cfg:
>
> bts 0
>>   codec-support fr hr amr
>>   trx 0
>>     timeslot 0
>>       phys_chan_config CCCH+SDCCH4
>>       hopping enabled 0
>>     timeslot 1
>>       phys_chan_config TCH/H
>>       hopping enabled 0
>>
>
> When I use jolly/multi-trx branch of libosmo-abis, jolly/testing branch of
> OpenBSC and jolly/trx branch of OsmoBTS my network works very unstable.
> When I try to make voice call sometimes it falls with message "*No
> resources for TCH/H*". Russian language in SMS is not supported. I think
> it is because this branches are obsolete.
>
> I tried to compile everything again but used master branches, and it
> worked much better! Now everything works as well. But when I call to 995 or
> 993 numbers of LCR I hear nothing. :(
>
> In OpenBSC console I see:
>
>> <0004> abis_rsl.c:1465 (bts=0,trx=0,ts=1,ss=0) Activating ARFCN(806)
>> SS(0) lctype TCH/F r=CALL ra=0x43 ta=1
>> <0004> abis_rsl.c:1199 (bts=0,trx=0,ts=1,ss=0) CHANNEL ACTIVATE ACK
>> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 ESTABLISH INDICATION
>> <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=5
>> <0002> gsm_04_08.c:958 <- CM SERVICE REQUEST serv_type=0x01
>> MI(TMSI)=4286202573
>> <0002> gsm_04_08_utils.c:692 -> CM SERVICE ACK
>> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
>> <0003> bsc_api.c:500 CLASSMARK CHANGE CM2(len=3) CM3(len=9)
>> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
>> <0003> bsc_api.c:586 GRPS SUSPEND REQUEST
>> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
>> <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=3
>> <0001> gsm_04_08.c:3508 (bts 0 trx 0 ts 1 ti 8 sub 49643) Received
>> 'SETUP' from MS in state 0 (NULL)
>> <0001> gsm_04_08.c:3513 Unknown transaction ID 8, creating new trans.
>> <0001> transaction.c:71 subscr=0x1d1de30, net=0x1d0bf00
>> <0001> gsm_04_08.c:1296 new state NULL -> INITIATED
>> <0001> gsm_04_08.c:1931 Subscriber 250013894508275 (49643) sends SETUP to
>> 995
>> <0001> gsm_04_08.c:1357 (bts 0 trx 0 ts 1 ti 8 sub 49643) Sending
>> 'MNCC_SETUP_IND' to MNCC.
>> <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received
>> 'MNCC_LCHAN_MODIFY' from MNCC in state 1 (INITIATED)
>> <000a> bsc_api.c:397 Sending ChanModify for speech 65 1
>> <0003> gsm_04_08_utils.c:498 -> CHANNEL MODE MODIFY mode=0x41
>> <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received
>> 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED)
>> <0001> gsm_04_08.c:1296 new state INITIATED -> MO_CALL_PROC
>> <0001> gsm_04_08.c:139 (bts 0 trx 0 ts 1 ti 80) Sending 'CALL_PROC' to MS.
>> <0001> gsm_04_08.c:1718 queue tch_recv_mncc request (1)
>> <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received
>> 'MNCC_SETUP_RSP' from MNCC in state 3 (MO_CALL_PROC)
>> <0001> gsm_04_08.c:1853 starting timer T313 with 30 seconds
>> <0001> gsm_04_08.c:1296 new state MO_CALL_PROC -> CONNECT_IND
>> <0001> gsm_04_08.c:139 (bts 0 trx 0 ts 1 ti 80) Sending 'CONNECT' to MS.
>> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
>> <0003> gsm_04_08_utils.c:534 CHANNEL MODE MODIFY ACK
>> <0004> abis_rsl.c:1867 (bts=0,trx=0,ts=1,ss=0) IPAC_BIND speech_mode=0x12
>> RTP_PAYLOAD=98
>> <0003> osmo_msc.c:72 MSC assign complete (do nothing).
>> <0004> abis_rsl.c:1218 (bts=0,trx=0,ts=1,ss=0) CHANNEL MODE MODIFY ACK
>> <0004> abis_rsl.c:2031 (bts=0,trx=0,ts=1,ss=0) IPAC_CRCX_ACK
>> LOCAL_IP=127.0.0.1 LOCAL_PORT=34079 CON_ID=0 <0001> gsm_04_08.c:1570
>> pending tch_recv_mncc request
>> <0004> abis_rsl.c:1906 (bts=0,trx=0,ts=1,ss=0) IPAC_MDCX IP=127.0.0.1
>> PORT=30000 RTP_PAYLOAD=98 RTP_PAYLOAD2=0 CONN_ID=0 speech_mode=0x02
>> <0004> abis_rsl.c:2041 (bts=0,trx=0,ts=1,ss=0) IPAC_MDCX_ACK
>> LOCAL_IP=127.0.0.1 LOCAL_PORT=34079 CON_ID=0
>> <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
>> <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=3
>> <0001> gsm_04_08.c:3508 (bts 0 trx 0 ts 1 ti 8 sub 49643) Received
>> 'CONNECT_ACK' from MS in state 28 (CONNECT_IND)
>> <0001> gsm_04_08.c:1337 stopping pending timer T313
>> <0001> gsm_04_08.c:1296 new state CONNECT_IND -> ACTIVE
>> <0001> gsm_04_08.c:1357 (bts 0 trx 0 ts 1 ti 8 sub 49643) Sending
>> 'MNCC_SETUP_COMPL_IND' to MNCC.
>>
>
> In LCR console:
>
>> ** LCR  Version 1.14
>>
>> 000000 DEBUG (in sip.cpp/sip_init() line 1987): SIP globals initialized
>> LCR 1.14 started, waiting for calls...
>> 000000 TRACE 05.12.15 14:45:48.414 --: LCR 1.14 started, waiting for
>> calls...
>> 000000 TRACE 05.12.15 14:50:15.063 CH(1): New call ref LCR<->BSC  callref
>> new=0x80000001
>> 000000 TRACE 05.12.15 14:50:15.063 CH(1): Codec negotiation LCR<->BSC
>> bearer capa='given by MS'  speech version='AMR given' version='Full Rate
>> given' version='AMR Half Rate given' ignored='Not TCH/H' version='Half Rate
>> given' ignored='Not TCH/H'
>> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_SETUP_IND LCR<->BSC
>> calling number=49643 imsi=XXXXXXXXXXXXXXX  dialing number=995
>> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_LCHAN_MODIFY LCR<->BSC
>> speech version='AMR given'  mode 0x41
>> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_CALL_PROC_REQ LCR<->BSC
>> progress coding=3 location=1 descr=8
>> 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_FRAME_RECV LCR<->BSC
>> 000000 TRACE 05.12.15 14:50:15.063 EP(1): SETUP  from CH(1)  interface
>> from=gsm  caller id number=49643 present=allowed  dialing 995  complete true
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): TONE  to CH(1)  directory
>> default  name dialing
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION (match)  action goto
>> line 2
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION goto/menu (change to)
>> ruleset gsm  dialing 995
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION (match)  action test
>> line 6
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION test  test 'hold music'
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): CONNECT  to CH(1)  connect id
>> number= present='not available'
>> 000000 TRACE 05.12.15 14:50:15.064 EP(1): TONE  to CH(1)  directory
>> default  name hold
>> 000000 TRACE 05.12.15 14:50:15.064 CH(1): MNCC_SETUP_RSP LCR<->BSC
>> connected type=0 plan=1 present=0 screen=3 number=
>> 000000 TRACE 05.12.15 14:50:15.880 CH(1): MNCC_SETUP_COMPL_IND LCR<->BSC
>>
>
> I can even send DTMF, but there is no sound...
>
> Transceiver logs (part):
>
>> <0011> trx.c:590 TRX Data 914281:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914253, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914282:0:0:1500a8741832a5700a0bd5d609f850
>> <0011> trx.c:590 TRX Data 914282:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914254, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914283:0:0:811d500a01fd40e845d40284155020
>> <0011> trx.c:590 TRX Data 914283:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914255, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914284:0:0:abff40aafff4026bffd500aadd4080
>> <0011> trx.c:590 TRX Data 914284:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914256, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914285:0:0:01f5508115d50a651f510801755020
>> <0011> trx.c:590 TRX Data 914285:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914257, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914286:0:0:10aabdd500aefd7102ab75108bbd50
>> <0011> trx.c:590 TRX Data 914286:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914258, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914287:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914259, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914288:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914260, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914289:0:0:a05f550a04dd106a017d008015d020
>> <0011> trx.c:590 TRX Data 914289:1:0:e2985a4a90a51468a03d80e70dd060
>> <0011> trx.c:608 TRX Data Indication (fn=914261, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914290:0:0:2ebf548abbf502eaadd548aeff4400
>> <0011> trx.c:590 TRX Data 914290:1:0:000000000000000000000000000000
>> <0011> trx.c:608 TRX Data Indication (fn=914262, tn=1, toa=0.00)
>> <0011> trx.c:590 TRX Data 914291:0:0:047d148847740a6517554000754020
>> <0011> trx.c:590 TRX Data 914291:1:0:000000000000000000000000000000
>>
>
> OsmoBTS logs (part):
>
>> <0000> rsl.c:1733 (bts=0,trx=0,ts=1,ss=0) Handing RLL msg UNIT_DATA_IND
>> from LAPDm to MEAS REP
>> <0000> rsl.c:1683 (bts=0,trx=0,ts=1,ss=0) Tx MEAS RES valid(2)
>> <0006> scheduler.c:1186 Received Access Burst on RACH fn=913629 toa=54.75
>> <0006> scheduler.c:1192 Received bad AB frame at fn=913629 (15/51)
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913674
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913674
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913670 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
>> fn=913677 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913677
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913679
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913679
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913674 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
>> fn=913681 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913681
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913683
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913683
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913679 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913687
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913687
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913683 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913692
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913692
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913687 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913696
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913696
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913692 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913700
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913700
>> ts=1 trx=0
>> <0006> scheduler.c:3012 GSM clock jitter: -4
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913696 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913705
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913705
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913700 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913709
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913709
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913705 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913713
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913713
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913709 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00
>> fn=913718 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=913718
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913718
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913718
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913713 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
>> fn=913722 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913722
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913722
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913722
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913718 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913726
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913726
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913722 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
>> fn=913728 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913728
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913731
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913731
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913726 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
>> fn=913732 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913732
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913735
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913735
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913731 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913739
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913739
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913735 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913744
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913744
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913739 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913748
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913748
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913744 to transmit.
>> <0006> scheduler.c:3012 GSM clock jitter: 99
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913752
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913752
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913748 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913757
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913757
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913752 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913761
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913761
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913757 to transmit.
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913765
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913765
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913761 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00
>> fn=913769 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=913769
>> ts=0 trx=0
>> <0006> scheduler.c:339 PH-RTS.ind: chan=SACCH/TF chan_nr=0x09
>> link_id=0x40 fn=913769 ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x40 fn=913769
>> ts=1 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913770
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913770
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913765 to transmit.
>> <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00
>> fn=913773 ts=0 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913773
>> ts=0 trx=0
>> <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913774
>> ts=1 trx=0
>> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913774
>> ts=1 trx=0
>> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0
>> ts=1 at fn=913770 to transmit.
>>
>
> What does it mean "*TCH/F has not been served !! No prim for trx=0 ts=1
> at fn=913770 to transmit.*"?
>
> I tried to make phone<->phone call with and without LCR. I tried to switch
> between TCH/H and TCH/F and use different codecs: arm fr hr. But
> unfortunately there is no sound.
> Can anyone help me?
>
> Thanks a lot!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151206/d168e453/attachment.htm>

From laforge at gnumonks.org  Sun Dec  6 12:14:53 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 6 Dec 2015 13:14:53 +0100
Subject: OpenBSC on CalypsoBTS without voice
In-Reply-To: <CAPEnp=aQ_o2LC-X189d8wgA6SXU9jO5ScfEWp4t=smKOV4FYvw@mail.gmail.com>
References: <CAPEnp=aQ_o2LC-X189d8wgA6SXU9jO5ScfEWp4t=smKOV4FYvw@mail.gmail.com>
Message-ID: <20151206121453.GB17730@nataraja>

Hi Vadim,

first of all, CalypsoBTS is not an active / maintained / stable solution
but more lik an (mindbogglingly amazing!) Hack.

On Sat, Dec 05, 2015 at 06:32:45PM +0600, ????? ??????? wrote:
> When I use jolly/multi-trx branch of libosmo-abis, jolly/testing branch of
> OpenBSC and jolly/trx branch of OsmoBTS my network works very unstable.

I'm sorry to say that none of the branches you refer to are maintained
by anyone at this point.  It would be great if somebody interested in
that code (i.e. using it) could forward-port it onto current master.
Now tat l1sap and osmo-bts-trx is in osmo-bts master, this should be
relatively straight forward.

It's really sad for us to see that people are continuing to use
old/outdated non-master, rather than rebasing + submitting their changes
for inclusion.  It always makes me tempte to remove some of those
branches from the repo, ort at least rename them to something like
'outdated'.

As you are the first person to report using the code to this list for
quite some time, it would be great if you had some time to re-base, test
and submit it.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ruben.undheim at gmail.com  Sun Dec  6 15:53:09 2015
From: ruben.undheim at gmail.com (Ruben Undheim)
Date: Sun, 6 Dec 2015 16:53:09 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
Message-ID: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>

Hi,

While building the package for Debian, apparently there is a problem
related to big-endian architectures.

Please see the logs here:
  https://buildd.debian.org/status/fetch.php?pkg=libosmocore&arch=powerpc&ver=0.9.0-1&stamp=1449330739
     and
  https://buildd.debian.org/status/package.php?p=libosmocore

It is related to the test case for smscb and the struct gsm341_ms_message:


+++ /?PKGBUILDDIR?/tests/testsuite.dir/at-groups/7/stdout 2015-12-05
15:51:53.463182812 +0000
@@ -1,4 +1,4 @@
-(srl) GS: 1 MSG_CODE: 1 UPDATE: 0
+(srl) GS: 0 MSG_CODE: 256 UPDATE: 1
 (msg) msg_id: 1293
-(dcs) group: 1 language: 0
+(dcs) group: 0 language: 1
 (pge) page total: 1 current: 1
7. testsuite.at:45: 7. smscb (testsuite.at:45): FAILED (testsuite.at:48)


Could you please suggest how we should fix this so that the package
also can build for powerpc and other big-endian architectures?

Thank you very much in advance.

Ruben


From laforge at gnumonks.org  Sun Dec  6 21:15:38 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 6 Dec 2015 22:15:38 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
Message-ID: <20151206211538.GK17730@nataraja>

Hi Ruben,

On Sun, Dec 06, 2015 at 04:53:09PM +0100, Ruben Undheim wrote:
> While building the package for Debian, apparently there is a problem
> related to big-endian architectures.

While I still own several PPC machines, I haven't booted any of them in
years, and don't have a build setup ready.  Please try the patch
below and report back if it works.  If yes, we can merge it.

>From 51ae645e220556bbeabce3ac57304639328e2164 Mon Sep 17 00:00:00 2001
From: Harald Welte <laforge at gnumonks.org>
Date: Sun, 6 Dec 2015 22:12:43 +0100
Subject: [PATCH] untested fix for gsm_03_41.h and big-endian machines

Our gsm_03_41 structs use bit-fields, but don't do the usual
little/big-endian jumping.
---
 include/osmocom/gsm/protocol/gsm_03_41.h | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h b/include/osmocom/gsm/protocol/gsm_03_41.h
index 0ece6cc..f007cc1 100644
--- a/include/osmocom/gsm/protocol/gsm_03_41.h
+++ b/include/osmocom/gsm/protocol/gsm_03_41.h
@@ -2,6 +2,7 @@
 
 #include <stdint.h>
 
+#include <osmocom/core/endian.h>
 #include <osmocom/gsm/protocol/gsm_04_12.h>
 
 /* GSM TS 03.41 definitions also TS 23.041*/
@@ -13,19 +14,36 @@
 /* Chapter 9.3.2 */
 struct gsm341_ms_message {
 	struct {
+#ifdef OSMO_IS_LITTLE_ENDIAN
 		uint8_t code_hi:6;
 		uint8_t gs:2;
 		uint8_t update:4;
 		uint8_t code_lo:4;
+#else
+		uint8_t code_lo:4;
+		uint8_t update:4;
+		uint8_t gs:2;
+		uint8_t code_hi:6;
+#endif
 	} serial;
 	uint16_t msg_id;
 	struct {
+#ifdef OSMO_IS_LITTLE_ENDIAN
 		uint8_t language:4;
 		uint8_t group:4;
+#else
+		uint8_t group:4;
+		uint8_t language:4;
+#endif
 	} dcs;
 	struct {
+#ifdef OSMO_IS_LITTLE_ENDIAN
 		uint8_t total:4;
 		uint8_t current:4;
+#else
+		uint8_t current:4;
+		uint8_t total:4;
+#endif
 	} page;
 	uint8_t data[0];
 } __attribute__((packed));
@@ -33,12 +51,21 @@ struct gsm341_ms_message {
 /* Chapter 9.4.1.3 */
 struct gsm341_etws_message {
 	struct {
+#ifdef OSMO_IS_LITTLE_ENDIAN
 		uint8_t code_hi:4;
 		uint8_t popup:1;
 		uint8_t alert:1;
 		uint8_t gs:2;
 		uint8_t update:4;
 		uint8_t code_lo:4;
+#else
+		uint8_t code_lo:4;
+		uint8_t update:4;
+		uint8_t gs:2;
+		uint8_t alert:1;
+		uint8_t popup:1;
+		uint8_t code_hi:4;
+#endif
 	} serial;
 	uint16_t msg_id;
 	uint16_t warning_type;
-- 
2.6.2

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Dec  7 08:12:33 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 Dec 2015 09:12:33 +0100
Subject: osmo-bts / osmo-pcu profiling results
Message-ID: <20151207081233.GC21423@nataraja>

Hi all,

I've been doing some profiling on osmo-bts recently (on sysmobts
hardware, which has only a relatively slow ARM926 CPU core), and the two
things that show up most are:

* msgb_alloc() -> talloc_zero() -> malloc
  this can be alleviated somewhat by using talloc pools.  For some
  reason the pools don't remove all of the malloc() calls.

* vfprintf() and friends, from logp() statements.  The sad part is that
  calls like gsm_lchan_name() are of course executed beefore the call
  into logp(), at which point the vfprintf/sprintf/... for arguments has
  already been executed, and only the last/final one hasn't happened
  yet.

  Here we can do two things: Calls like gsm_lchan_name() don't need to
  happen all the time, as the lchan name is static and can be generated
  once at the time gsm_lchan is created.  I implemented that in osmo-bts
  (and openbsc, as it's from gsm_data_shared).

  The second idea would be to expand the LOGP() macro a bit in a way to
  ensure the the checking whether the log line is enabled _before_ the
  arguments (and thus associated function calls) are evaluated.  Any
  ideas on that?

After a brief look at osmo-pcu profiling, it looks like in the
attached picture.  We cannot do much about the __copy_to_user_std,
do_select and core_sys_select, as those are kernel side.

However, there again we see vfprintf and friends, mostly via
gprs_rlcmac_tbf::name() - and of course the msgb_alloc() and msgb_free()
going through talloc and finally malloc.

So the same strategies as above could (and probably should) be applied
to osmo-pcu.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20151207-osmopcu-sysmobts-perf.png
Type: image/png
Size: 37704 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151207/773223e9/attachment.png>

From holger at freyther.de  Mon Dec  7 08:25:13 2015
From: holger at freyther.de (Holger Freyther)
Date: Mon, 7 Dec 2015 09:25:13 +0100
Subject: osmo-bts / osmo-pcu profiling results
In-Reply-To: <20151207081233.GC21423@nataraja>
References: <20151207081233.GC21423@nataraja>
Message-ID: <1B1D9E96-C40C-49F9-8434-8B214EE0EC55@freyther.de>


> On 07 Dec 2015, at 09:12, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi all,
> 
> 
> * vfprintf() and friends, from logp() statements.  The sad part is that
>  calls like gsm_lchan_name() are of course executed beefore the call
>  into logp(), at which point the vfprintf/sprintf/... for arguments has
>  already been executed, and only the last/final one hasn't happened
>  yet.

Jacob has proposed (and I think maybe included) a patch to check if
logging is enabled for any target before making the call (and passing
the arguments)


> After a brief look at osmo-pcu profiling, it looks like in the
> attached picture.  We cannot do much about the __copy_to_user_std,
> do_select and core_sys_select, as those are kernel side.

epoll. We avoid transferring FD set to the kernel all the time (and arming
them in the driver). But I assume the bigger cost of to user is the indications
we copy from the DSP to userspace.




From jerlbeck at sysmocom.de  Mon Dec  7 09:09:50 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon, 7 Dec 2015 10:09:50 +0100
Subject: osmo-bts / osmo-pcu profiling results
In-Reply-To: <1B1D9E96-C40C-49F9-8434-8B214EE0EC55@freyther.de>
References: <20151207081233.GC21423@nataraja>
 <1B1D9E96-C40C-49F9-8434-8B214EE0EC55@freyther.de>
Message-ID: <56654CDE.6090205@sysmocom.de>

Hi,

On 07.12.2015 09:25, Holger Freyther wrote:
> 
>> On 07 Dec 2015, at 09:12, Harald Welte <laforge at gnumonks.org> wrote:
>> * vfprintf() and friends, from logp() statements.  The sad part is that
>>  calls like gsm_lchan_name() are of course executed beefore the call
>>  into logp(), at which point the vfprintf/sprintf/... for arguments has
>>  already been executed, and only the last/final one hasn't happened
>>  yet.
> 
> Jacob has proposed (and I think maybe included) a patch to check if
> logging is enabled for any target before making the call (and passing
> the arguments)

This is contained in the "log: Add log_check_level function" series of
patches posted on Nov 17. In first tests it hast reduced the process
load by 10-20% (relative to PCU load).

Jacob


-- 
- Jacob Erlbeck <jerlbeck at 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 Directors: Holger Freyther, Harald Welte


From nhofmeyr at sysmocom.de  Mon Dec  7 10:12:19 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 7 Dec 2015 11:12:19 +0100
Subject: FYI: gtphub merged
In-Reply-To: <1608075646.11725224.1449146301692.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <20151203105255.GB1698@dub5>
 <1608075646.11725224.1449146301692.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20151207101219.GA2387@dub5>

On Thu, Dec 03, 2015 at 01:38:21PM +0100, Sipos Csaba wrote:
> First of all, thank you for your work :-)

And thanks to our sponsor! :)

> 1. Maybe some minimalistic README or example config file (for example how to use GTPHUB between Osmo-SGSN and OpenGGSN) would be lovely.

There's a config example in openbsc/doc/examples, but I agree: READMEs are
a Good Thing. I've just added openbsc/doc/examples/gtphub-example.txt,
hope it helps.

> 2. Is it possible to use GTPHUB as a standalone utility for example to redirect GTP tunnels between an SGW and a PGW? I would love to try to redirect the GTP tunnels before they reach the OpenAIR SGW so we can finally test the Osmo-GTP-kernel implementation instead of the Polaris network one which keeps crashing over a certain amount of GTP-U traffic.

I'm not sure how GTP is used between SGW and PGW, but if that works like
the SGSN <-> GGSN in GPRS land, it may just work...

So far, gtphub is intended/designed for comms between SGSN and GGSN, and
only for GTPv1 (v0 on port 3384 is so far omitted entirely). In detail,
gtphub only "knows" Path (7.2) and Tunnel (7.3) management:
- Echo,
- Create and
- Delete PDP Context messages (including peer restarts);
- Update PDP is so far still missing/may not be relevant for the use case in mind.
- None of the Location (7.4) and Mobility (7.5) messages are handled in
  any way.

If you try it, let us know of your experience with gtphub :)
I'd welcome any testing and bugs found.

~Neels

--
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151207/f34ee9a5/attachment.bin>

From suraev at alumni.ntnu.no  Mon Dec  7 15:38:38 2015
From: suraev at alumni.ntnu.no (Suraev)
Date: Mon, 7 Dec 2015 16:38:38 +0100
Subject: osmo-bts / osmo-pcu profiling results
In-Reply-To: <1B1D9E96-C40C-49F9-8434-8B214EE0EC55@freyther.de>
References: <20151207081233.GC21423@nataraja>
 <1B1D9E96-C40C-49F9-8434-8B214EE0EC55@freyther.de>
Message-ID: <5665A7FE.8090203@alumni.ntnu.no>

07.12.2015 09:25, Holger Freyther ?????:
> 
> epoll. We avoid transferring FD set to the kernel all the time (and arming
> them in the driver). But I assume the bigger cost of to user is the indications
> we copy from the DSP to userspace.
> 
> 

There's interestingly looking wrapper around epoll:

http://0pointer.net/blog/introducing-sd-event.html

Not sure if it would cover dsp2userspace transfers though.

cheers,
Max.



From ruben.undheim at gmail.com  Mon Dec  7 21:16:14 2015
From: ruben.undheim at gmail.com (Ruben Undheim)
Date: Mon, 7 Dec 2015 22:16:14 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <20151206211538.GK17730@nataraja>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
Message-ID: <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>

Hi,

Thanks!

Apparently it doesn't work correctly, but I'm now trying with:
  #if OSMO_IS_LITTLE_ENDIAN == 1

instead, and I have big hopes.

(OSMO_IS_LITTLE_ENDIAN is always defined, 1 for low-endian archs and 0
for big-endian archs.)

Cheers,
Ruben

2015-12-06 22:15 GMT+01:00 Harald Welte <laforge at gnumonks.org>:
> Hi Ruben,
>
> On Sun, Dec 06, 2015 at 04:53:09PM +0100, Ruben Undheim wrote:
>> While building the package for Debian, apparently there is a problem
>> related to big-endian architectures.
>
> While I still own several PPC machines, I haven't booted any of them in
> years, and don't have a build setup ready.  Please try the patch
> below and report back if it works.  If yes, we can merge it.
>
> From 51ae645e220556bbeabce3ac57304639328e2164 Mon Sep 17 00:00:00 2001
> From: Harald Welte <laforge at gnumonks.org>
> Date: Sun, 6 Dec 2015 22:12:43 +0100
> Subject: [PATCH] untested fix for gsm_03_41.h and big-endian machines
>
> Our gsm_03_41 structs use bit-fields, but don't do the usual
> little/big-endian jumping.
> ---
>  include/osmocom/gsm/protocol/gsm_03_41.h | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h b/include/osmocom/gsm/protocol/gsm_03_41.h
> index 0ece6cc..f007cc1 100644
> --- a/include/osmocom/gsm/protocol/gsm_03_41.h
> +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
> @@ -2,6 +2,7 @@
>
>  #include <stdint.h>
>
> +#include <osmocom/core/endian.h>
>  #include <osmocom/gsm/protocol/gsm_04_12.h>
>
>  /* GSM TS 03.41 definitions also TS 23.041*/
> @@ -13,19 +14,36 @@
>  /* Chapter 9.3.2 */
>  struct gsm341_ms_message {
>         struct {
> +#ifdef OSMO_IS_LITTLE_ENDIAN
>                 uint8_t code_hi:6;
>                 uint8_t gs:2;
>                 uint8_t update:4;
>                 uint8_t code_lo:4;
> +#else
> +               uint8_t code_lo:4;
> +               uint8_t update:4;
> +               uint8_t gs:2;
> +               uint8_t code_hi:6;
> +#endif
>         } serial;
>         uint16_t msg_id;
>         struct {
> +#ifdef OSMO_IS_LITTLE_ENDIAN
>                 uint8_t language:4;
>                 uint8_t group:4;
> +#else
> +               uint8_t group:4;
> +               uint8_t language:4;
> +#endif
>         } dcs;
>         struct {
> +#ifdef OSMO_IS_LITTLE_ENDIAN
>                 uint8_t total:4;
>                 uint8_t current:4;
> +#else
> +               uint8_t current:4;
> +               uint8_t total:4;
> +#endif
>         } page;
>         uint8_t data[0];
>  } __attribute__((packed));
> @@ -33,12 +51,21 @@ struct gsm341_ms_message {
>  /* Chapter 9.4.1.3 */
>  struct gsm341_etws_message {
>         struct {
> +#ifdef OSMO_IS_LITTLE_ENDIAN
>                 uint8_t code_hi:4;
>                 uint8_t popup:1;
>                 uint8_t alert:1;
>                 uint8_t gs:2;
>                 uint8_t update:4;
>                 uint8_t code_lo:4;
> +#else
> +               uint8_t code_lo:4;
> +               uint8_t update:4;
> +               uint8_t gs:2;
> +               uint8_t alert:1;
> +               uint8_t popup:1;
> +               uint8_t code_hi:4;
> +#endif
>         } serial;
>         uint16_t msg_id;
>         uint16_t warning_type;
> --
> 2.6.2
>
> --
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Tue Dec  8 11:31:37 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 8 Dec 2015 12:31:37 +0100
Subject: FYI: merge of gtphub
Message-ID: <20151208113137.GA12075@dub5>

Hi list,

I'm merging the last commits from the neels/gtphub branch to master
(Holger agrees). I will direct my attention to other topics for the time
being -- we're waiting for a live testing setup.

ATM, I would see gtphub's maturity as "alpha": I believe it works as
intended, but all testing so far, even though done with real equipment,
was in a controlled test environment.

If anyone would like to give it a spin, we'd appreciate any feedback.

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151208/c47d91b2/attachment.bin>

From jskarvad at redhat.com  Wed Dec  9 08:30:25 2015
From: jskarvad at redhat.com (Jaroslav Skarvada)
Date: Wed, 9 Dec 2015 03:30:25 -0500 (EST)
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
Message-ID: <1778239584.33530323.1449649825010.JavaMail.zimbra@redhat.com>

Hi,

thanks, I encountered the same in Fedora on ppc machines.
Unfortunately, the patch even with '#if OSMO_IS_LITTLE_ENDIAN == 1'
doesn't seem to resolve the problem for me, the test is still
failing. I am going to check this deeper

thanks & regards

Jaroslav

----- Original Message -----
> Hi,
> 
> Thanks!
> 
> Apparently it doesn't work correctly, but I'm now trying with:
>   #if OSMO_IS_LITTLE_ENDIAN == 1
> 
> instead, and I have big hopes.
> 
> (OSMO_IS_LITTLE_ENDIAN is always defined, 1 for low-endian archs and 0
> for big-endian archs.)
> 
> Cheers,
> Ruben
> 
> 2015-12-06 22:15 GMT+01:00 Harald Welte <laforge at gnumonks.org>:
> > Hi Ruben,
> >
> > On Sun, Dec 06, 2015 at 04:53:09PM +0100, Ruben Undheim wrote:
> >> While building the package for Debian, apparently there is a problem
> >> related to big-endian architectures.
> >
> > While I still own several PPC machines, I haven't booted any of them in
> > years, and don't have a build setup ready.  Please try the patch
> > below and report back if it works.  If yes, we can merge it.
> >
> > From 51ae645e220556bbeabce3ac57304639328e2164 Mon Sep 17 00:00:00 2001
> > From: Harald Welte <laforge at gnumonks.org>
> > Date: Sun, 6 Dec 2015 22:12:43 +0100
> > Subject: [PATCH] untested fix for gsm_03_41.h and big-endian machines
> >
> > Our gsm_03_41 structs use bit-fields, but don't do the usual
> > little/big-endian jumping.
> > ---
> >  include/osmocom/gsm/protocol/gsm_03_41.h | 27 +++++++++++++++++++++++++++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h
> > b/include/osmocom/gsm/protocol/gsm_03_41.h
> > index 0ece6cc..f007cc1 100644
> > --- a/include/osmocom/gsm/protocol/gsm_03_41.h
> > +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
> > @@ -2,6 +2,7 @@
> >
> >  #include <stdint.h>
> >
> > +#include <osmocom/core/endian.h>
> >  #include <osmocom/gsm/protocol/gsm_04_12.h>
> >
> >  /* GSM TS 03.41 definitions also TS 23.041*/
> > @@ -13,19 +14,36 @@
> >  /* Chapter 9.3.2 */
> >  struct gsm341_ms_message {
> >         struct {
> > +#ifdef OSMO_IS_LITTLE_ENDIAN
> >                 uint8_t code_hi:6;
> >                 uint8_t gs:2;
> >                 uint8_t update:4;
> >                 uint8_t code_lo:4;
> > +#else
> > +               uint8_t code_lo:4;
> > +               uint8_t update:4;
> > +               uint8_t gs:2;
> > +               uint8_t code_hi:6;
> > +#endif
> >         } serial;
> >         uint16_t msg_id;
> >         struct {
> > +#ifdef OSMO_IS_LITTLE_ENDIAN
> >                 uint8_t language:4;
> >                 uint8_t group:4;
> > +#else
> > +               uint8_t group:4;
> > +               uint8_t language:4;
> > +#endif
> >         } dcs;
> >         struct {
> > +#ifdef OSMO_IS_LITTLE_ENDIAN
> >                 uint8_t total:4;
> >                 uint8_t current:4;
> > +#else
> > +               uint8_t current:4;
> > +               uint8_t total:4;
> > +#endif
> >         } page;
> >         uint8_t data[0];
> >  } __attribute__((packed));
> > @@ -33,12 +51,21 @@ struct gsm341_ms_message {
> >  /* Chapter 9.4.1.3 */
> >  struct gsm341_etws_message {
> >         struct {
> > +#ifdef OSMO_IS_LITTLE_ENDIAN
> >                 uint8_t code_hi:4;
> >                 uint8_t popup:1;
> >                 uint8_t alert:1;
> >                 uint8_t gs:2;
> >                 uint8_t update:4;
> >                 uint8_t code_lo:4;
> > +#else
> > +               uint8_t code_lo:4;
> > +               uint8_t update:4;
> > +               uint8_t gs:2;
> > +               uint8_t alert:1;
> > +               uint8_t popup:1;
> > +               uint8_t code_hi:4;
> > +#endif
> >         } serial;
> >         uint16_t msg_id;
> >         uint16_t warning_type;
> > --
> > 2.6.2
> >
> > --
> > - Harald Welte <laforge at gnumonks.org>
> > http://laforge.gnumonks.org/
> > ============================================================================
> > "Privacy in residential applications is a desirable marketing option."
> >                                                   (ETSI EN 300 175-7 Ch.
> >                                                   A6)
> 


From laforge at gnumonks.org  Wed Dec  9 14:55:16 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Dec 2015 15:55:16 +0100
Subject: DEc 9, 8pm / Osmocom Berlin Meeting
Message-ID: <20151209145516.GS21423@nataraja>

Hi all!

This is the announcement for the re-incarnation of our bi-weekly
Osmocom Berlin Meeting.

	Dec 09, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin

There is no formal presentation this time, but
* there will be SIMtrace equipment in case somebody wants to play with
  it there will be a sysmoBTS with OsmoBTS, OsmoPCU, OsmoNITB, OsmoSGSN
  and OpenGGSN if somebody wants to play with it
* there will be Huawei Femtocells to play with

The meeting is open to anyone interested in mobile communications. You
do not have to be involved with the Osmocom projects in order to attend.

Anyone interested in mobile communications protocols is welcome.

If you are interested to show up, feel free to do so.  The meeting is
"free as in free beer", despite no actual free beer being around ;)

More information can be found at
http://openbsc.osmocom.org/trac/wiki/OsmocomMeeting/Berlin

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Wed Dec  9 16:19:51 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 9 Dec 2015 17:19:51 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <1778239584.33530323.1449649825010.JavaMail.zimbra@redhat.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <1778239584.33530323.1449649825010.JavaMail.zimbra@redhat.com>
Message-ID: <20151209161951.GB3533@dub5>

On Wed, Dec 09, 2015 at 03:30:25AM -0500, Jaroslav Skarvada wrote:
> Hi,
> 
> thanks, I encountered the same in Fedora on ppc machines.
> Unfortunately, the patch even with '#if OSMO_IS_LITTLE_ENDIAN == 1'

Has the status changed with the patch? According to
 https://buildd.debian.org/status/fetch.php?pkg=libosmocore&arch=powerpc&ver=0.9.0-3&stamp=1449648141
from
 https://buildd.debian.org/status/package.php?p=libosmocore
the test suite has succeeded on powerpc. Does that mean the problem is
resolved?  (Previously, the test smscb failed, now it says "smscb ok")

If not, I could try it, too; asking my fellow geeky neighbor for a BE
machine...


As a side note, even though the above "#if" should work, to me it looks
unusual to explicitly write "== 1". It suffices to remove the "def" from
"#ifdef":

  #if OSMO_IS_LITTLE_ENDIAN
  ...
  #endif

which is skipped when OSMO_IS_LITTLE_ENDIAN == 0 and is run when
OSMO_IS_LITTLE_ENDIAN != 0, more like your typical int-as-boolean logic,
and would also work as expected if OSMO_IS_LITTLE_ENDIAN were 2 ;)

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151209/a2810b89/attachment.bin>

From jskarvad at redhat.com  Wed Dec  9 16:46:25 2015
From: jskarvad at redhat.com (Jaroslav Skarvada)
Date: Wed, 9 Dec 2015 11:46:25 -0500 (EST)
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <20151209161951.GB3533@dub5>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <1778239584.33530323.1449649825010.JavaMail.zimbra@redhat.com>
 <20151209161951.GB3533@dub5>
Message-ID: <356221403.33763602.1449679585204.JavaMail.zimbra@redhat.com>


----- Original Message -----
> On Wed, Dec 09, 2015 at 03:30:25AM -0500, Jaroslav Skarvada wrote:
> > Hi,
> > 
> > thanks, I encountered the same in Fedora on ppc machines.
> > Unfortunately, the patch even with '#if OSMO_IS_LITTLE_ENDIAN == 1'
> 
> Has the status changed with the patch? According to
>  https://buildd.debian.org/status/fetch.php?pkg=libosmocore&arch=powerpc&ver=0.9.0-3&stamp=1449648141
> from
>  https://buildd.debian.org/status/package.php?p=libosmocore
> the test suite has succeeded on powerpc. Does that mean the problem is
> resolved?  (Previously, the test smscb failed, now it says "smscb ok")
> 
The output of the test changed, so it differs now only in one line on ppc64,
but it still means failure:

--- ./smscb_test.fail	2015-12-09 11:29:22.143808034 -0500
+++ ./smscb_test.ok	2015-12-08 11:10:37.480795985 -0500
@@ -1,4 +1,4 @@
-(srl) GS: 0 MSG_CODE: 260 UPDATE: 0
+(srl) GS: 1 MSG_CODE: 1 UPDATE: 0
 (msg) msg_id: 1293
 (dcs) group: 1 language: 0
 (pge) page total: 1 current: 1

Patch used:
http://fpaste.org/299159/49679080/

Fedora build system log:
https://kojipkgs.fedoraproject.org//work/tasks/6119/12126119/build.log

Fedora secondary arch bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1289940

thanks & regards

Jaroslav


From nhofmeyr at sysmocom.de  Wed Dec  9 16:49:17 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 9 Dec 2015 17:49:17 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <20151209161951.GB3533@dub5>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <1778239584.33530323.1449649825010.JavaMail.zimbra@redhat.com>
 <20151209161951.GB3533@dub5>
Message-ID: <20151209164917.GC3533@dub5>

Two more failures seen on
  https://buildd.debian.org/status/package.php?p=libosmocore


For FreeBSD, both i386 and amd64:

    macaddr.c: In function 'osmo_get_macaddr':
    macaddr.c:106:17: error: 'SIOCGIFHWADDR' undeclared (first use in this function)
      rc = ioctl(fd, SIOCGIFHWADDR, &ifr);
                     ^

The code in question has an explicit FreeBSD alternative which seems to not
have been entered as intended, libosmocore/src/macaddr.c line 50:

"
#if defined(__FreeBSD__) || defined(__APPLE__)
[...]
#else
[...] <-- error is in this block
#endif
"

The same #if appears in numerous places in the osmo code base, so it seems to
be correct ... ? Or all of them are wrong??


Another error on sparc64: three tests fail with a "Bus error" message, which I don't understand:

"
## ------------------------ ##
## Summary of the failures. ##
## ------------------------ ##
Failed tests:
libosmocore 0.9.0 test suite test groups:

 NUM: FILE-NAME:LINE     TEST-GROUP-NAME
      KEYWORDS

   3: testsuite.at:18    bits
      bits
  19: testsuite.at:121   gprs-bssgp
      gprs-bssgp
  20: testsuite.at:127   gprs-ns
      gprs-ns

## ---------------------- ##
## Detailed failed tests. ##
## ---------------------- ##

#                             -*- compilation -*-
3. testsuite.at:18: testing bits ...
./testsuite.at:21: $abs_top_builddir/tests/bits/bitrev_test
--- /dev/null 2011-03-04 11:53:52.000000000 +0000
+++ /?PKGBUILDDIR?/tests/testsuite.dir/at-groups/3/stderr 2015-12-09 08:07:05.318729809 +0000
@@ -0,0 +1 @@
+/?PKGBUILDDIR?/tests/testsuite.dir/at-groups/3/test-source: line 25: 14139 Bus error               $abs_top_builddir/tests/bits/bitrev_test
--- expout  2015-12-09 08:07:05.018702966 +0000
+++ /?PKGBUILDDIR?/tests/testsuite.dir/at-groups/3/stdout 2015-12-09 08:07:05.022703325 +0000
@@ -1,55 +0,0 @@
-INORDER:  01 02 04 08 10 20 40 80 
-REVERSED: 80 40 20 10 08 04 02 01 
-
-INORDER:  02 04 08 10 20 40 80 
-REVERSED: 40 20 10 08 04 02 01 
[...]
"
(many expected output lines missing)

Could it be a sporadic HW failure on the machine itself, or something?
The "bitrev_test" doesn't really look like something that would fail because of
a bus.

~Neels


-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151209/52fef962/attachment.bin>

From ruben.undheim at gmail.com  Wed Dec  9 17:20:58 2015
From: ruben.undheim at gmail.com (Ruben Undheim)
Date: Wed, 9 Dec 2015 18:20:58 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
Message-ID: <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>

Hi,

In the end, I ended up with the following patch that works:

diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h
b/include/osmocom/gsm/protocol/gsm_03_41.h
index 0ece6cc..40051cd 100644
--- a/include/osmocom/gsm/protocol/gsm_03_41.h
+++ b/include/osmocom/gsm/protocol/gsm_03_41.h
@@ -2,8 +2,13 @@

 #include <stdint.h>

+#include <osmocom/core/endian.h>
 #include <osmocom/gsm/protocol/gsm_04_12.h>

+#ifndef OSMO_IS_LITTLE_ENDIAN
+ #define OSMO_IS_LITTLE_ENDIAN 0
+#endif
+
 /* GSM TS 03.41 definitions also TS 23.041*/

 #define GSM341_MAX_PAYLOAD (GSM412_MSG_LEN-sizeof(struct gsm341_ms_message))
@@ -13,19 +18,36 @@
 /* Chapter 9.3.2 */
 struct gsm341_ms_message {
  struct {
+#if OSMO_IS_LITTLE_ENDIAN == 1
  uint8_t code_hi:6;
  uint8_t gs:2;
  uint8_t update:4;
  uint8_t code_lo:4;
+#else
+ uint8_t gs:2;
+ uint8_t code_hi:6;
+ uint8_t code_lo:4;
+ uint8_t update:4;
+#endif
  } serial;
  uint16_t msg_id;
  struct {
+#if OSMO_IS_LITTLE_ENDIAN == 1
  uint8_t language:4;
  uint8_t group:4;
+#else
+ uint8_t group:4;
+ uint8_t language:4;
+#endif
  } dcs;
  struct {
+#if OSMO_IS_LITTLE_ENDIAN == 1
  uint8_t total:4;
  uint8_t current:4;
+#else
+ uint8_t current:4;
+ uint8_t total:4;
+#endif
  } page;
  uint8_t data[0];
 } __attribute__((packed));
@@ -33,12 +55,21 @@ struct gsm341_ms_message {
 /* Chapter 9.4.1.3 */
 struct gsm341_etws_message {
  struct {
+#if OSMO_IS_LITTLE_ENDIAN == 1
  uint8_t code_hi:4;
  uint8_t popup:1;
  uint8_t alert:1;
  uint8_t gs:2;
  uint8_t update:4;
  uint8_t code_lo:4;
+#else
+ uint8_t gs:2;
+ uint8_t alert:1;
+ uint8_t popup:1;
+ uint8_t code_hi:4;
+ uint8_t code_lo:4;
+ uint8_t update:4;
+#endif
  } serial;
  uint16_t msg_id;
  uint16_t warning_type;


Note that the order of the fields is a bit different than your proposal.

I also, interestingly enough, found this:
  http://lists.osmocom.org/pipermail/baseband-devel/2015-February/000021.html

It's from Februrary, and already a suggestion for a patch for this
problem. I don't think however that patch
will work with other big-endian architectures.

Cheers,
Ruben


2015-12-07 22:16 GMT+01:00 Ruben Undheim <ruben.undheim at gmail.com>:
> Hi,
>
> Thanks!
>
> Apparently it doesn't work correctly, but I'm now trying with:
>   #if OSMO_IS_LITTLE_ENDIAN == 1
>
> instead, and I have big hopes.
>
> (OSMO_IS_LITTLE_ENDIAN is always defined, 1 for low-endian archs and 0
> for big-endian archs.)
>
> Cheers,
> Ruben
>
> 2015-12-06 22:15 GMT+01:00 Harald Welte <laforge at gnumonks.org>:
>> Hi Ruben,
>>
>> On Sun, Dec 06, 2015 at 04:53:09PM +0100, Ruben Undheim wrote:
>>> While building the package for Debian, apparently there is a problem
>>> related to big-endian architectures.
>>
>> While I still own several PPC machines, I haven't booted any of them in
>> years, and don't have a build setup ready.  Please try the patch
>> below and report back if it works.  If yes, we can merge it.
>>
>> From 51ae645e220556bbeabce3ac57304639328e2164 Mon Sep 17 00:00:00 2001
>> From: Harald Welte <laforge at gnumonks.org>
>> Date: Sun, 6 Dec 2015 22:12:43 +0100
>> Subject: [PATCH] untested fix for gsm_03_41.h and big-endian machines
>>
>> Our gsm_03_41 structs use bit-fields, but don't do the usual
>> little/big-endian jumping.
>> ---
>>  include/osmocom/gsm/protocol/gsm_03_41.h | 27 +++++++++++++++++++++++++++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h b/include/osmocom/gsm/protocol/gsm_03_41.h
>> index 0ece6cc..f007cc1 100644
>> --- a/include/osmocom/gsm/protocol/gsm_03_41.h
>> +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
>> @@ -2,6 +2,7 @@
>>
>>  #include <stdint.h>
>>
>> +#include <osmocom/core/endian.h>
>>  #include <osmocom/gsm/protocol/gsm_04_12.h>
>>
>>  /* GSM TS 03.41 definitions also TS 23.041*/
>> @@ -13,19 +14,36 @@
>>  /* Chapter 9.3.2 */
>>  struct gsm341_ms_message {
>>         struct {
>> +#ifdef OSMO_IS_LITTLE_ENDIAN
>>                 uint8_t code_hi:6;
>>                 uint8_t gs:2;
>>                 uint8_t update:4;
>>                 uint8_t code_lo:4;
>> +#else
>> +               uint8_t code_lo:4;
>> +               uint8_t update:4;
>> +               uint8_t gs:2;
>> +               uint8_t code_hi:6;
>> +#endif
>>         } serial;
>>         uint16_t msg_id;
>>         struct {
>> +#ifdef OSMO_IS_LITTLE_ENDIAN
>>                 uint8_t language:4;
>>                 uint8_t group:4;
>> +#else
>> +               uint8_t group:4;
>> +               uint8_t language:4;
>> +#endif
>>         } dcs;
>>         struct {
>> +#ifdef OSMO_IS_LITTLE_ENDIAN
>>                 uint8_t total:4;
>>                 uint8_t current:4;
>> +#else
>> +               uint8_t current:4;
>> +               uint8_t total:4;
>> +#endif
>>         } page;
>>         uint8_t data[0];
>>  } __attribute__((packed));
>> @@ -33,12 +51,21 @@ struct gsm341_ms_message {
>>  /* Chapter 9.4.1.3 */
>>  struct gsm341_etws_message {
>>         struct {
>> +#ifdef OSMO_IS_LITTLE_ENDIAN
>>                 uint8_t code_hi:4;
>>                 uint8_t popup:1;
>>                 uint8_t alert:1;
>>                 uint8_t gs:2;
>>                 uint8_t update:4;
>>                 uint8_t code_lo:4;
>> +#else
>> +               uint8_t code_lo:4;
>> +               uint8_t update:4;
>> +               uint8_t gs:2;
>> +               uint8_t alert:1;
>> +               uint8_t popup:1;
>> +               uint8_t code_hi:4;
>> +#endif
>>         } serial;
>>         uint16_t msg_id;
>>         uint16_t warning_type;
>> --
>> 2.6.2
>>
>> --
>> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
>> ============================================================================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                   (ETSI EN 300 175-7 Ch. A6)


From jskarvad at redhat.com  Wed Dec  9 17:41:33 2015
From: jskarvad at redhat.com (Jaroslav Skarvada)
Date: Wed, 9 Dec 2015 12:41:33 -0500 (EST)
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
Message-ID: <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>

Thanks,

this works for me, but I still don't understand why, the ordering
of bitfields looks quite strange to me :)

Jaroslav

----- Original Message -----
> Hi,
> 
> In the end, I ended up with the following patch that works:
> 
> diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h
> b/include/osmocom/gsm/protocol/gsm_03_41.h
> index 0ece6cc..40051cd 100644
> --- a/include/osmocom/gsm/protocol/gsm_03_41.h
> +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
> @@ -2,8 +2,13 @@
> 
>  #include <stdint.h>
> 
> +#include <osmocom/core/endian.h>
>  #include <osmocom/gsm/protocol/gsm_04_12.h>
> 
> +#ifndef OSMO_IS_LITTLE_ENDIAN
> + #define OSMO_IS_LITTLE_ENDIAN 0
> +#endif
> +
>  /* GSM TS 03.41 definitions also TS 23.041*/
> 
>  #define GSM341_MAX_PAYLOAD (GSM412_MSG_LEN-sizeof(struct gsm341_ms_message))
> @@ -13,19 +18,36 @@
>  /* Chapter 9.3.2 */
>  struct gsm341_ms_message {
>   struct {
> +#if OSMO_IS_LITTLE_ENDIAN == 1
>   uint8_t code_hi:6;
>   uint8_t gs:2;
>   uint8_t update:4;
>   uint8_t code_lo:4;
> +#else
> + uint8_t gs:2;
> + uint8_t code_hi:6;
> + uint8_t code_lo:4;
> + uint8_t update:4;
> +#endif
>   } serial;
>   uint16_t msg_id;
>   struct {
> +#if OSMO_IS_LITTLE_ENDIAN == 1
>   uint8_t language:4;
>   uint8_t group:4;
> +#else
> + uint8_t group:4;
> + uint8_t language:4;
> +#endif
>   } dcs;
>   struct {
> +#if OSMO_IS_LITTLE_ENDIAN == 1
>   uint8_t total:4;
>   uint8_t current:4;
> +#else
> + uint8_t current:4;
> + uint8_t total:4;
> +#endif
>   } page;
>   uint8_t data[0];
>  } __attribute__((packed));
> @@ -33,12 +55,21 @@ struct gsm341_ms_message {
>  /* Chapter 9.4.1.3 */
>  struct gsm341_etws_message {
>   struct {
> +#if OSMO_IS_LITTLE_ENDIAN == 1
>   uint8_t code_hi:4;
>   uint8_t popup:1;
>   uint8_t alert:1;
>   uint8_t gs:2;
>   uint8_t update:4;
>   uint8_t code_lo:4;
> +#else
> + uint8_t gs:2;
> + uint8_t alert:1;
> + uint8_t popup:1;
> + uint8_t code_hi:4;
> + uint8_t code_lo:4;
> + uint8_t update:4;
> +#endif
>   } serial;
>   uint16_t msg_id;
>   uint16_t warning_type;
> 
> 
> Note that the order of the fields is a bit different than your proposal.
> 
> I also, interestingly enough, found this:
>   http://lists.osmocom.org/pipermail/baseband-devel/2015-February/000021.html
> 
> It's from Februrary, and already a suggestion for a patch for this
> problem. I don't think however that patch
> will work with other big-endian architectures.
> 
> Cheers,
> Ruben
> 
> 
> 2015-12-07 22:16 GMT+01:00 Ruben Undheim <ruben.undheim at gmail.com>:
> > Hi,
> >
> > Thanks!
> >
> > Apparently it doesn't work correctly, but I'm now trying with:
> >   #if OSMO_IS_LITTLE_ENDIAN == 1
> >
> > instead, and I have big hopes.
> >
> > (OSMO_IS_LITTLE_ENDIAN is always defined, 1 for low-endian archs and 0
> > for big-endian archs.)
> >
> > Cheers,
> > Ruben
> >
> > 2015-12-06 22:15 GMT+01:00 Harald Welte <laforge at gnumonks.org>:
> >> Hi Ruben,
> >>
> >> On Sun, Dec 06, 2015 at 04:53:09PM +0100, Ruben Undheim wrote:
> >>> While building the package for Debian, apparently there is a problem
> >>> related to big-endian architectures.
> >>
> >> While I still own several PPC machines, I haven't booted any of them in
> >> years, and don't have a build setup ready.  Please try the patch
> >> below and report back if it works.  If yes, we can merge it.
> >>
> >> From 51ae645e220556bbeabce3ac57304639328e2164 Mon Sep 17 00:00:00 2001
> >> From: Harald Welte <laforge at gnumonks.org>
> >> Date: Sun, 6 Dec 2015 22:12:43 +0100
> >> Subject: [PATCH] untested fix for gsm_03_41.h and big-endian machines
> >>
> >> Our gsm_03_41 structs use bit-fields, but don't do the usual
> >> little/big-endian jumping.
> >> ---
> >>  include/osmocom/gsm/protocol/gsm_03_41.h | 27 +++++++++++++++++++++++++++
> >>  1 file changed, 27 insertions(+)
> >>
> >> diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h
> >> b/include/osmocom/gsm/protocol/gsm_03_41.h
> >> index 0ece6cc..f007cc1 100644
> >> --- a/include/osmocom/gsm/protocol/gsm_03_41.h
> >> +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
> >> @@ -2,6 +2,7 @@
> >>
> >>  #include <stdint.h>
> >>
> >> +#include <osmocom/core/endian.h>
> >>  #include <osmocom/gsm/protocol/gsm_04_12.h>
> >>
> >>  /* GSM TS 03.41 definitions also TS 23.041*/
> >> @@ -13,19 +14,36 @@
> >>  /* Chapter 9.3.2 */
> >>  struct gsm341_ms_message {
> >>         struct {
> >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> >>                 uint8_t code_hi:6;
> >>                 uint8_t gs:2;
> >>                 uint8_t update:4;
> >>                 uint8_t code_lo:4;
> >> +#else
> >> +               uint8_t code_lo:4;
> >> +               uint8_t update:4;
> >> +               uint8_t gs:2;
> >> +               uint8_t code_hi:6;
> >> +#endif
> >>         } serial;
> >>         uint16_t msg_id;
> >>         struct {
> >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> >>                 uint8_t language:4;
> >>                 uint8_t group:4;
> >> +#else
> >> +               uint8_t group:4;
> >> +               uint8_t language:4;
> >> +#endif
> >>         } dcs;
> >>         struct {
> >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> >>                 uint8_t total:4;
> >>                 uint8_t current:4;
> >> +#else
> >> +               uint8_t current:4;
> >> +               uint8_t total:4;
> >> +#endif
> >>         } page;
> >>         uint8_t data[0];
> >>  } __attribute__((packed));
> >> @@ -33,12 +51,21 @@ struct gsm341_ms_message {
> >>  /* Chapter 9.4.1.3 */
> >>  struct gsm341_etws_message {
> >>         struct {
> >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> >>                 uint8_t code_hi:4;
> >>                 uint8_t popup:1;
> >>                 uint8_t alert:1;
> >>                 uint8_t gs:2;
> >>                 uint8_t update:4;
> >>                 uint8_t code_lo:4;
> >> +#else
> >> +               uint8_t code_lo:4;
> >> +               uint8_t update:4;
> >> +               uint8_t gs:2;
> >> +               uint8_t alert:1;
> >> +               uint8_t popup:1;
> >> +               uint8_t code_hi:4;
> >> +#endif
> >>         } serial;
> >>         uint16_t msg_id;
> >>         uint16_t warning_type;
> >> --
> >> 2.6.2
> >>
> >> --
> >> - Harald Welte <laforge at gnumonks.org>
> >> http://laforge.gnumonks.org/
> >> ============================================================================
> >> "Privacy in residential applications is a desirable marketing option."
> >>                                                   (ETSI EN 300 175-7 Ch.
> >>                                                   A6)
> 


From jskarvad at redhat.com  Wed Dec  9 18:26:41 2015
From: jskarvad at redhat.com (Jaroslav Skarvada)
Date: Wed, 9 Dec 2015 13:26:41 -0500 (EST)
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
 <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>
Message-ID: <1294972825.33823513.1449685601924.JavaMail.zimbra@redhat.com>

I am afraid using bitfields is not portable and bits ordering
may differ between architectures and compilers (it's not only
about endianess, IMHO it's not defined by the standard).
I think correct portable implementation should use macros and
bitmasks, maybe something to consider for future updates

thanks & regards

Jaroslav

----- Original Message -----
> Thanks,
> 
> this works for me, but I still don't understand why, the ordering
> of bitfields looks quite strange to me :)
> 
> Jaroslav
> 
> ----- Original Message -----
> > Hi,
> > 
> > In the end, I ended up with the following patch that works:
> > 
> > diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h
> > b/include/osmocom/gsm/protocol/gsm_03_41.h
> > index 0ece6cc..40051cd 100644
> > --- a/include/osmocom/gsm/protocol/gsm_03_41.h
> > +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
> > @@ -2,8 +2,13 @@
> > 
> >  #include <stdint.h>
> > 
> > +#include <osmocom/core/endian.h>
> >  #include <osmocom/gsm/protocol/gsm_04_12.h>
> > 
> > +#ifndef OSMO_IS_LITTLE_ENDIAN
> > + #define OSMO_IS_LITTLE_ENDIAN 0
> > +#endif
> > +
> >  /* GSM TS 03.41 definitions also TS 23.041*/
> > 
> >  #define GSM341_MAX_PAYLOAD (GSM412_MSG_LEN-sizeof(struct
> >  gsm341_ms_message))
> > @@ -13,19 +18,36 @@
> >  /* Chapter 9.3.2 */
> >  struct gsm341_ms_message {
> >   struct {
> > +#if OSMO_IS_LITTLE_ENDIAN == 1
> >   uint8_t code_hi:6;
> >   uint8_t gs:2;
> >   uint8_t update:4;
> >   uint8_t code_lo:4;
> > +#else
> > + uint8_t gs:2;
> > + uint8_t code_hi:6;
> > + uint8_t code_lo:4;
> > + uint8_t update:4;
> > +#endif
> >   } serial;
> >   uint16_t msg_id;
> >   struct {
> > +#if OSMO_IS_LITTLE_ENDIAN == 1
> >   uint8_t language:4;
> >   uint8_t group:4;
> > +#else
> > + uint8_t group:4;
> > + uint8_t language:4;
> > +#endif
> >   } dcs;
> >   struct {
> > +#if OSMO_IS_LITTLE_ENDIAN == 1
> >   uint8_t total:4;
> >   uint8_t current:4;
> > +#else
> > + uint8_t current:4;
> > + uint8_t total:4;
> > +#endif
> >   } page;
> >   uint8_t data[0];
> >  } __attribute__((packed));
> > @@ -33,12 +55,21 @@ struct gsm341_ms_message {
> >  /* Chapter 9.4.1.3 */
> >  struct gsm341_etws_message {
> >   struct {
> > +#if OSMO_IS_LITTLE_ENDIAN == 1
> >   uint8_t code_hi:4;
> >   uint8_t popup:1;
> >   uint8_t alert:1;
> >   uint8_t gs:2;
> >   uint8_t update:4;
> >   uint8_t code_lo:4;
> > +#else
> > + uint8_t gs:2;
> > + uint8_t alert:1;
> > + uint8_t popup:1;
> > + uint8_t code_hi:4;
> > + uint8_t code_lo:4;
> > + uint8_t update:4;
> > +#endif
> >   } serial;
> >   uint16_t msg_id;
> >   uint16_t warning_type;
> > 
> > 
> > Note that the order of the fields is a bit different than your proposal.
> > 
> > I also, interestingly enough, found this:
> >   http://lists.osmocom.org/pipermail/baseband-devel/2015-February/000021.html
> > 
> > It's from Februrary, and already a suggestion for a patch for this
> > problem. I don't think however that patch
> > will work with other big-endian architectures.
> > 
> > Cheers,
> > Ruben
> > 
> > 
> > 2015-12-07 22:16 GMT+01:00 Ruben Undheim <ruben.undheim at gmail.com>:
> > > Hi,
> > >
> > > Thanks!
> > >
> > > Apparently it doesn't work correctly, but I'm now trying with:
> > >   #if OSMO_IS_LITTLE_ENDIAN == 1
> > >
> > > instead, and I have big hopes.
> > >
> > > (OSMO_IS_LITTLE_ENDIAN is always defined, 1 for low-endian archs and 0
> > > for big-endian archs.)
> > >
> > > Cheers,
> > > Ruben
> > >
> > > 2015-12-06 22:15 GMT+01:00 Harald Welte <laforge at gnumonks.org>:
> > >> Hi Ruben,
> > >>
> > >> On Sun, Dec 06, 2015 at 04:53:09PM +0100, Ruben Undheim wrote:
> > >>> While building the package for Debian, apparently there is a problem
> > >>> related to big-endian architectures.
> > >>
> > >> While I still own several PPC machines, I haven't booted any of them in
> > >> years, and don't have a build setup ready.  Please try the patch
> > >> below and report back if it works.  If yes, we can merge it.
> > >>
> > >> From 51ae645e220556bbeabce3ac57304639328e2164 Mon Sep 17 00:00:00 2001
> > >> From: Harald Welte <laforge at gnumonks.org>
> > >> Date: Sun, 6 Dec 2015 22:12:43 +0100
> > >> Subject: [PATCH] untested fix for gsm_03_41.h and big-endian machines
> > >>
> > >> Our gsm_03_41 structs use bit-fields, but don't do the usual
> > >> little/big-endian jumping.
> > >> ---
> > >>  include/osmocom/gsm/protocol/gsm_03_41.h | 27
> > >>  +++++++++++++++++++++++++++
> > >>  1 file changed, 27 insertions(+)
> > >>
> > >> diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h
> > >> b/include/osmocom/gsm/protocol/gsm_03_41.h
> > >> index 0ece6cc..f007cc1 100644
> > >> --- a/include/osmocom/gsm/protocol/gsm_03_41.h
> > >> +++ b/include/osmocom/gsm/protocol/gsm_03_41.h
> > >> @@ -2,6 +2,7 @@
> > >>
> > >>  #include <stdint.h>
> > >>
> > >> +#include <osmocom/core/endian.h>
> > >>  #include <osmocom/gsm/protocol/gsm_04_12.h>
> > >>
> > >>  /* GSM TS 03.41 definitions also TS 23.041*/
> > >> @@ -13,19 +14,36 @@
> > >>  /* Chapter 9.3.2 */
> > >>  struct gsm341_ms_message {
> > >>         struct {
> > >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> > >>                 uint8_t code_hi:6;
> > >>                 uint8_t gs:2;
> > >>                 uint8_t update:4;
> > >>                 uint8_t code_lo:4;
> > >> +#else
> > >> +               uint8_t code_lo:4;
> > >> +               uint8_t update:4;
> > >> +               uint8_t gs:2;
> > >> +               uint8_t code_hi:6;
> > >> +#endif
> > >>         } serial;
> > >>         uint16_t msg_id;
> > >>         struct {
> > >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> > >>                 uint8_t language:4;
> > >>                 uint8_t group:4;
> > >> +#else
> > >> +               uint8_t group:4;
> > >> +               uint8_t language:4;
> > >> +#endif
> > >>         } dcs;
> > >>         struct {
> > >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> > >>                 uint8_t total:4;
> > >>                 uint8_t current:4;
> > >> +#else
> > >> +               uint8_t current:4;
> > >> +               uint8_t total:4;
> > >> +#endif
> > >>         } page;
> > >>         uint8_t data[0];
> > >>  } __attribute__((packed));
> > >> @@ -33,12 +51,21 @@ struct gsm341_ms_message {
> > >>  /* Chapter 9.4.1.3 */
> > >>  struct gsm341_etws_message {
> > >>         struct {
> > >> +#ifdef OSMO_IS_LITTLE_ENDIAN
> > >>                 uint8_t code_hi:4;
> > >>                 uint8_t popup:1;
> > >>                 uint8_t alert:1;
> > >>                 uint8_t gs:2;
> > >>                 uint8_t update:4;
> > >>                 uint8_t code_lo:4;
> > >> +#else
> > >> +               uint8_t code_lo:4;
> > >> +               uint8_t update:4;
> > >> +               uint8_t gs:2;
> > >> +               uint8_t alert:1;
> > >> +               uint8_t popup:1;
> > >> +               uint8_t code_hi:4;
> > >> +#endif
> > >>         } serial;
> > >>         uint16_t msg_id;
> > >>         uint16_t warning_type;
> > >> --
> > >> 2.6.2
> > >>
> > >> --
> > >> - Harald Welte <laforge at gnumonks.org>
> > >> http://laforge.gnumonks.org/
> > >> ============================================================================
> > >> "Privacy in residential applications is a desirable marketing option."
> > >>                                                   (ETSI EN 300 175-7 Ch.
> > >>                                                   A6)
> > 
> 


From laforge at gnumonks.org  Wed Dec  9 19:24:52 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Dec 2015 20:24:52 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
Message-ID: <20151209192452.GA16251@nataraja>

Hi Ruben,

On Wed, Dec 09, 2015 at 06:20:58PM +0100, Ruben Undheim wrote:
> In the end, I ended up with the following patch that works:

Thansk.  Your e-mail client mangled the whitespaces/tabs, but I fixed it
up manually. Now pushed to master.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Wed Dec  9 22:13:30 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 9 Dec 2015 23:13:30 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
 <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>
Message-ID: <20151209221330.GB4641@dub5>

On Wed, Dec 09, 2015 at 12:41:33PM -0500, Jaroslav Skarvada wrote:
> this works for me, but I still don't understand why, the ordering
> of bitfields looks quite strange to me :)

The reversal needs to be done byte-wise. So in this example:

> > +#if OSMO_IS_LITTLE_ENDIAN == 1
> >   uint8_t code_hi:6;
> >   uint8_t gs:2;
> >   uint8_t update:4;
> >   uint8_t code_lo:4;

The first byte is code_hi and gs, reverse those:

> > +#else
> > + uint8_t gs:2;
> > + uint8_t code_hi:6;

Next byte is update and code_lo, reversed:

> > + uint8_t code_lo:4;
> > + uint8_t update:4;
> > +#endif

I hope that helps :)

~Neels

> > +#if OSMO_IS_LITTLE_ENDIAN == 1
> >   uint8_t code_hi:4;
> >   uint8_t popup:1;
> >   uint8_t alert:1;
> >   uint8_t gs:2;
> >   uint8_t update:4;
> >   uint8_t code_lo:4;
> > +#else
> > + uint8_t gs:2;
> > + uint8_t alert:1;
> > + uint8_t popup:1;
> > + uint8_t code_hi:4;
> > + uint8_t code_lo:4;
> > + uint8_t update:4;
> > +#endif

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151209/94e0413b/attachment.bin>

From laforge at gnumonks.org  Thu Dec 10 08:51:14 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 10 Dec 2015 09:51:14 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <1294972825.33823513.1449685601924.JavaMail.zimbra@redhat.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
 <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>
 <1294972825.33823513.1449685601924.JavaMail.zimbra@redhat.com>
Message-ID: <20151210085114.GJ16251@nataraja>

On Wed, Dec 09, 2015 at 01:26:41PM -0500, Jaroslav Skarvada wrote:
> I think correct portable implementation should use macros and
> bitmasks, maybe something to consider for future updates

IP headers and TCP headers are always defined as bit filds, look at the
netinet/ip.h and netinet/tcp.h.  We're in the best of traditions here ;)

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Dec 10 08:55:18 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 10 Dec 2015 09:55:18 +0100
Subject: osmo-bts / osmo-pcu profiling results
In-Reply-To: <5665A7FE.8090203@alumni.ntnu.no>
References: <20151207081233.GC21423@nataraja>
 <1B1D9E96-C40C-49F9-8434-8B214EE0EC55@freyther.de>
 <5665A7FE.8090203@alumni.ntnu.no>
Message-ID: <20151210085518.GK16251@nataraja>

On Mon, Dec 07, 2015 at 04:38:38PM +0100, Suraev wrote:
> There's interestingly looking wrapper around epoll:
> 
> http://0pointer.net/blog/introducing-sd-event.html

I don't think we'd need a wrapper, a we don't need the timerfd and
signalfd integration, child process state change events, unix process
events, etc.

So the wrapper only adds a layer of abstraction and lots of features we
don't need.  The fundamental issue here is that both select() are quite
epxensive (due to the large FD array copying/checking/zeroing), and the
fact that obviously all data has to be always copied between kernel
memory and userspace memory.

> Not sure if it would cover dsp2userspace transfers though.

>From the userspace point of view, is just a character device that you
open and read/write on, nothing fancy.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From openbsc at flocom.net  Thu Dec 10 16:13:13 2015
From: openbsc at flocom.net (Florian)
Date: Thu, 10 Dec 2015 17:13:13 +0100
Subject: PySIM: SW match failed
Message-ID: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>

On Thu Nov 5 09:05:15 UTC 2015, Harald Welte wrote:

>> RuntimeError: SW match failed ! Expected 9000 and got 6a86.

> According to ISO 7816-4, this 6a86 means 'incorrect P1 or P2 
> parameter'.

>> At this point I don't have any more ideas what to try, if anyone would 
>> have any suggestions I would apreciate it.

> Please activate (or hack some code for) tracing the actual APDUs that
> pySim excahnges with the card.  IIRC, pySim already has that option.

> Once you see the raw APDUs, you can compare their encoding 
> (particularly
> P1/P2) with those described in the relevant ETSI/3GPP (U)SIM 
> specifications.

I enhanced my local copy of pySim (zecke/tmp) to show the raw PDUs.
And I added a method to check the Status of the PIN and ADM register.
On one card I messed up the ADM, so pySim-prog.py shows

whey query for SIM 1:

> send_apdu_raw -> 00200001
< received status word 63c3

So that is SW1='63' with SW2='CX': Counter (verification failed: 'X' 
indicates the number of further allowed retries
Which means I have three more attempts for the PIN1, but

> send_apdu_raw -> 0020000A
< received status word 63c0

Ahhrg, I do not have any additional attempt to verify the ADM-Key. 
Trying to verify ADM results in

> send_apdu_raw -> 0020000A083132333435363738
< received status word 6983

an ugly SW1='69' with SW2='83': Authentication method blocked.
So I can no longer verify the ADM-Key on that card.

--> Is there any way to unblock the card?

On the second card I was able to successfully verify the ADM and change 
the IMSI...

Cheers,

Flo




From holger at freyther.de  Thu Dec 10 16:25:48 2015
From: holger at freyther.de (Holger Freyther)
Date: Thu, 10 Dec 2015 17:25:48 +0100
Subject: PySIM: SW match failed
In-Reply-To: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>
References: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>
Message-ID: <363E178C-DD1D-4679-88BD-C628876FB8EC@freyther.de>


> On 10 Dec 2015, at 17:13, Florian <openbsc at flocom.net> wrote:
> 
> 
> 
> --> Is there any way to unblock the card?

I am not aware of it.

holger


From holger at freyther.de  Thu Dec 10 20:02:49 2015
From: holger at freyther.de (Holger Freyther)
Date: Thu, 10 Dec 2015 21:02:49 +0100
Subject: [PATCH] gtphub: add to debian build
In-Reply-To: <20151130114747.GA1394@dub5>
References: <1448368818-21121-1-git-send-email-nhofmeyr@sysmocom.de>
 <FE57C498-8F10-4A3D-9C69-2D4B67BB788E@freyther.de>
 <20151130114747.GA1394@dub5>
Message-ID: <BCE0B2E9-0F08-474E-B7A4-DE8E1A1581A3@freyther.de>


> On 30 Nov 2015, at 12:47, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

Good Evening Neels,


> Added awareness of it (in my head), added gtphub (in osmoappdesc.py) and
> merged to master.

we need to revert or extend the gtphub vty to make it work on our CI platform. You
can not bind to 127.0.0.1 and 127.0.0.2 on the CI infrastructure so the default config
can't be execute. We could add VTY commands to specify the ports to be used and
multiplex it then.

The other issue is the position of the gtphub. At the bottom we have this:

vty_command = ["./src/osmo-nitb/osmo-nitb", "-c",
               "doc/examples/osmo-nitb/nanobts/openbsc.cfg"]

vty_app = apps[-1]

So we run the nitb but try to connect to port 4253 which of course fails and explains
why the OpenBSC build failed the last couple of times. :)

holger

From sipos.csaba at kvk.uni-obuda.hu  Thu Dec 10 20:28:02 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Thu, 10 Dec 2015 21:28:02 +0100 (CET)
Subject: PySIM: SW match failed
In-Reply-To: <363E178C-DD1D-4679-88BD-C628876FB8EC@freyther.de>
References: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>
 <363E178C-DD1D-4679-88BD-C628876FB8EC@freyther.de>
Message-ID: <1934070631.13050245.1449779282767.JavaMail.zimbra@kvk.uni-obuda.hu>

Maybe I am wrong but the ADM2 key is not there for this reason? Can we use it to unlock a failed ADM1 usim?

Regards,
Csaba

----- Original Message -----
From: Holger Freyther <holger at freyther.de>
To: Florian <openbsc at flocom.net>
Cc: openbsc at lists.osmocom.org
Sent: Thu, 10 Dec 2015 17:25:48 +0100 (CET)
Subject: Re: PySIM: SW match failed


> On 10 Dec 2015, at 17:13, Florian <openbsc at flocom.net> wrote:
> 
> 
> 
> --> Is there any way to unblock the card?

I am not aware of it.

holger



From ruben.undheim at gmail.com  Thu Dec 10 20:57:27 2015
From: ruben.undheim at gmail.com (Ruben Undheim)
Date: Thu, 10 Dec 2015 21:57:27 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <20151209192452.GA16251@nataraja>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
 <20151209192452.GA16251@nataraja>
Message-ID: <20151210205727.GA6246@macbookair>


> Your e-mail client mangled the whitespaces/tabs, but I fixed it
> up manually. 

Sorry about that. Next time I won't use the gmail web client for
that kind of stuff. :)

Thanks to Neels for making things clear !


Cheers,
Ruben



From nhofmeyr at sysmocom.de  Fri Dec 11 04:05:31 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 11 Dec 2015 05:05:31 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <20151210085114.GJ16251@nataraja>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
 <1530221876.33802515.1449682893812.JavaMail.zimbra@redhat.com>
 <1294972825.33823513.1449685601924.JavaMail.zimbra@redhat.com>
 <20151210085114.GJ16251@nataraja>
Message-ID: <20151211040531.GC1948@dub5>

On Thu, Dec 10, 2015 at 09:51:14AM +0100, Harald Welte wrote:
> On Wed, Dec 09, 2015 at 01:26:41PM -0500, Jaroslav Skarvada wrote:
> > I think correct portable implementation should use macros and
> > bitmasks, maybe something to consider for future updates
> 
> IP headers and TCP headers are always defined as bit filds, look at the
> netinet/ip.h and netinet/tcp.h.  We're in the best of traditions here ;)

...not that it would win a code beauty contest though :)
Maybe a consolation prize for the most widely used redundancy...

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151211/39dfdfe5/attachment.bin>

From holger at freyther.de  Fri Dec 11 08:24:07 2015
From: holger at freyther.de (Holger Freyther)
Date: Fri, 11 Dec 2015 09:24:07 +0100
Subject: The test suite for libosmocore fails on big-endian architectures
In-Reply-To: <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
References: <CA+ChNyWHwnnG4YgOmRzMmjMqy8HeRYL6k6EPxKwsy1aa2xSHNA@mail.gmail.com>
 <20151206211538.GK17730@nataraja>
 <CA+ChNyV-N6GUCwfBcWz-oVvW1A9NSNr7fw3VGCyRvNinu9uMag@mail.gmail.com>
 <CA+ChNyXo96QfgoXd9PPSL0jeP+kNO+r4_Myepgsq3q9+Jm0i=A@mail.gmail.com>
Message-ID: <64C3453C-BBEF-4E0B-AC7F-FD32859ECC74@freyther.de>


> On 09 Dec 2015, at 18:20, Ruben Undheim <ruben.undheim at gmail.com> wrote:
> 
> Hi,
> 
> 
> +#ifndef OSMO_IS_LITTLE_ENDIAN
> + #define OSMO_IS_LITTLE_ENDIAN 0
> +#endif

I am surprised by this hunk. Our endian.h should define both macros. I think I used
the vim search to search for a typo in one of the branches (BSD vs. Linux, LE vs. BE)
but it looks good. Do you remember why this was needed?

holger

From axilirator at gmail.com  Fri Dec 11 15:02:36 2015
From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=)
Date: Fri, 11 Dec 2015 21:02:36 +0600
Subject: OpenBSC on CalypsoBTS without voice
Message-ID: <CAPEnp=awr6GxnUtZre4wZ=q1U6feKTJFNdKjvnbUkADjMVVwQg@mail.gmail.com>

Hello, Harald, thanks for the answer.

first of all, CalypsoBTS is not an active / maintained / stable solution
> but more lik an (mindbogglingly amazing!) Hack.


Yes, I know that CalypsoBTS is not stable solution. But currently I am a
student and I have no so much money to buy anything more powerful.
Furthermore, I am interested in this for research purposes only, not for
creating public land mobile networks.

As you are the first person to report using the code to this list for
> quite some time, it would be great if you had some time to re-base, test
> and submit it.


As I previously said, I also tested master branches. Here are the results:
* When I start OsmoBTS I often see this message in OpenBSC log: "Lost some
E1 TEI link: X X" from bsc_init.c. In this case my MS can not connect to
the test network and I have to restart OsmoBTS until this message will no
hide.
* When the Location Update process I always see this error:
"input/ipaccess.c:277 Bad signalling message,sign_link returned error". But
a phone successfully registers in the network.
* SMS, USSD and Silent SMS works fine.
* When TS1 assigned TCH/H I can call to another ms or LCR. DTMF works.
* When TS1 assigned TCH/F I can use FR codec and call to LCR.
* PDCH does not work on this BTS.
* RRLP works.
* ISMI detach works but as in case of Location Update I see "Bad signalling
message..." error.
* It seems, the network works more stable when battery capacity is 100% and
backlight is disabled.

If I understood correctly, osmobts-trx was just moved from obsolete
repository to the master. Now I am reading the source code and trying to
fix this bugs.

I have one thing in my mind for a long time. Is it possible to serve a PDCH
lchan on TS1 instead of TCH (in case of this "powerful" BTS)? I have tested
OsmoSGSN+OpenGGSN with one PDCH channel on TS1, but it did not work.

With best regards,
??????? ?????.

2015-12-06 18:14 GMT+06:00 Harald Welte <laforge at gnumonks.org>:

> Hi Vadim,
>>
>> first of all, CalypsoBTS is not an active / maintained / stable solution
>> but more lik an (mindbogglingly amazing!) Hack.
>>
>> On Sat, Dec 05, 2015 at 06:32:45PM +0600, ????? ??????? wrote:
>> > When I use jolly/multi-trx branch of libosmo-abis, jolly/testing branch
>> of
>> > OpenBSC and jolly/trx branch of OsmoBTS my network works very unstable.
>>
>> I'm sorry to say that none of the branches you refer to are maintained
>> by anyone at this point.  It would be great if somebody interested in
>> that code (i.e. using it) could forward-port it onto current master.
>> Now tat l1sap and osmo-bts-trx is in osmo-bts master, this should be
>> relatively straight forward.
>>
>> It's really sad for us to see that people are continuing to use
>> old/outdated non-master, rather than rebasing + submitting their changes
>> for inclusion.  It always makes me tempte to remove some of those
>> branches from the repo, ort at least rename them to something like
>> 'outdated'.
>>
>> As you are the first person to report using the code to this list for
>> quite some time, it would be great if you had some time to re-base, test
>> and submit it.
>>
>> --
>> - Harald Welte <laforge at gnumonks.org>
>> http://laforge.gnumonks.org/
>>
>> ============================================================================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                   (ETSI EN 300 175-7 Ch.
>> A6)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151211/15cdd43b/attachment.htm>

From ruben.undheim at gmail.com  Fri Dec 11 18:49:30 2015
From: ruben.undheim at gmail.com (Ruben Undheim)
Date: Fri, 11 Dec 2015 18:49:30 +0000
Subject: The test suite for libosmocore fails on big-endian architectures
Message-ID: <CA+ChNyUdcV8VGG5ZDxmRxcm-7MiziOWrn4sAKo6Jxz22qzjC_Q@mail.gmail.com>

>> +#ifndef OSMO_IS_LITTLE_ENDIAN
>> + #define OSMO_IS_LITTLE_ENDIAN 0
>> +#endif
>
> I am surprised by this hunk. Our endian.h should define both macros. I think I used
> the vim search to search for a typo in one of the branches (BSD vs. Linux, LE vs. BE)
> but it looks good. Do you remember why this was needed?

It isn't needed. It was just added out of habit to make sure it is defined when
it is being checked further down.

You can remove it, it won't make any difference.

Ruben


From sipos.csaba at kvk.uni-obuda.hu  Sat Dec 12 13:20:26 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 12 Dec 2015 14:20:26 +0100 (CET)
Subject: mncc-python tool for talking to MNCC interface
In-Reply-To: <20151201234802.GE8430@nataraja>
References: <20151201234802.GE8430@nataraja>
Message-ID: <828268944.13341544.1449926426380.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Harald,

I decided to try the mncc-python tool. I managed to compile it, but when I actually trying to connect to calls, I get this:

>>>
>>> connect_call("7839", "3802")
DEBUG:pykka:Registered GsmCallFsm (urn:uuid:c61985e6-3ec8-47fd-a70f-02bb71af23f8)
DEBUG:pykka:Starting GsmCallFsm(15/None->None/NULL)
DEBUG:pykka:Registered GsmCallFsm (urn:uuid:7f8c6b86-6093-4826-8864-52baf0a5304a)
DEBUG:pykka:Starting GsmCallFsm(16/None->None/NULL)
DEBUG:pykka:Registered GsmCallConnector (urn:uuid:c020e5ae-56e5-4a8b-89af-a09587abc52f)
DEBUG:pykka:Starting GsmCallConnector (urn:uuid:c020e5ae-56e5-4a8b-89af-a09587abc52f)
<ActorProxy for GsmCallConnector (urn:uuid:c020e5ae-56e5-4a8b-89af-a09587abc52f), attr_path=()>
GsmCallFsm(15/3802->7839/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT
 GsmCallFsm(16/7839->3802/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT>>>
 MnccActor TxMNCC mncc_msg(type=0x0101, callref=15, fields=0x0006)CallConnector:leg_state_change(7839) NULL -> CALL_PRESENT

CallConnector:leg_state_change(3802) NULL -> CALL_PRESENT MnccActor RxMNCC mncc_msg(type=0x0111, callref=15, fields=0x0020), broadcasting to Call FSMsMnccActor TxMNCC mncc_msg(type=0x0101, callref=16, fields=0x0006)


GsmCallFsm(15/3802->7839/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=15, fields=0x0020))
GsmCallFsm(15/3802->7839/NULL): event: mncc_rel_ind, CALL_PRESENT -> NULL
DEBUG:pykka:Unregistered GsmCallFsm (urn:uuid:c61985e6-3ec8-47fd-a70f-02bb71af23f8)
DEBUG:pykka:Stopped GsmCallFsm(15/3802->7839/NULL)
CallConnector:leg_state_change(7839) CALL_PRESENT -> NULL
MnccActor RxMNCC mncc_msg(type=0x0111, callref=16, fields=0x0020), broadcasting to Call FSMs
GsmCallFsm(16/7839->3802/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=16, fields=0x0020))
GsmCallFsm(16/7839->3802/NULL): event: mncc_rel_ind, CALL_PRESENT -> NULL
DEBUG:pykka:Unregistered GsmCallFsm (urn:uuid:7f8c6b86-6093-4826-8864-52baf0a5304a)
CallConnector:leg_state_change(3802) CALL_PRESENT -> NULL
DEBUG:pykka:Stopped GsmCallFsm(16/7839->3802/NULL)
Both A and B in state NULL -> Terminating
DEBUG:pykka:Unregistered GsmCallConnector (urn:uuid:c020e5ae-56e5-4a8b-89af-a09587abc52f)
DEBUG:pykka:Stopped GsmCallConnector (urn:uuid:c020e5ae-56e5-4a8b-89af-a09587abc52f)

The MNCC socket is connected according to the BSC, but when I gave the command, nothing happens on the BSC nor the BTS side.

Maybe I miss some more configuration steps. I have both half rate and full rate TCHs enabled on the BTS, the first two TS is half rate. But again, nothing seems to happen on the BSC nor the BTS log.

Can you please shed some light what can be the problem?

For the README can you please add these informations:

-------------------------------------

Dependencies for Ubuntu (14.04 LTS):

sudo apt-get install python-pykka python-pip

sudo pip install fysom

-------------------------------------

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Szerda, 2015. December 2. 0:48:02
T?rgy: mncc-python tool for talking to MNCC interface

Hi all,

I've been working on a small python tool that can be used to attach to
the MNCC interface of OsmoNITB.  It implements the 04.08 CC state
machine with our MNCC primitives, including support for RTP bridge mode
of the voice streams.

The immediate first use case for this was to be able to automatically,
reproducibly and quickly generate MT calls to a set of known MSISDNs and
load all 14 TCH/H channels of a single-TRX BTS.  It will connect the MT
calls in pairs, so you end up with 7 MS-to-MS calls.  Other use cases
are expected to be added shortly.

The first working version of the tool is available from
	http://git.osmocom.org/mncc-python/
or
	git clone git://git.osmocom.org/mncc-python

The code is pretty hacky in some places.  That's partially due to the
fact that I'm much more familiar in the C, Perl and Erlang world than in
python.  Still I thought it's a good idea to do it in python to enable
more people to use/edit/contribute to it.

I'm happy for review / cleanup suggestion by people with more Python-foo
than I have.

Architecturally, I decided to do things a bit erlang-like, where we have
finite state machines in an actor models, and message passing between
the actors.  This is what happens with the GsmCallFsm()'s, which are
created by the GsmCallConnector() representing both legs of a call and
the MnccActor() that wraps the MNCC socket towards OsmoNITB.

The actual encoding/decodng of MNCC messages is auto-generated from the
mncc header file #defines, enums and c-structures by means of ctypes
code generation.

mncc_test.py currently drops you into a python shell where you can e.g.
start more / new calls by calling functions like
	connect_call("7839", "3802")
from that shell.  Exiting the shell by quit() or Ctrl+C will terminate
all call FSMs and terminate.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Sat Dec 12 14:01:19 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 12 Dec 2015 15:01:19 +0100 (CET)
Subject: Mergin meas_json to master
In-Reply-To: <2057100178.13343865.1449928662056.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <939529872.13344034.1449928879544.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Alexander,

I started to write the Wiki page for Meas_web.

During this I just realized that because of some outstanding merges the installation of this tool is painfully complicated.

In order to make things easier, I suggest to merge the meas_json part into OpenBSC master:

http://cgit.osmocom.org/openbsc/log/?h=achemeris/meas_json

Regards,
Csaba


From alexander.chemeris at gmail.com  Sat Dec 12 14:44:16 2015
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 12 Dec 2015 09:44:16 -0500
Subject: [PATCH 1/2] utils: 'meas_json' utility to convert measurement feed
 into a JSON feed.
Message-ID: <1449931457-6446-1-git-send-email-Alexander.Chemeris@gmail.com>

---
 openbsc/src/utils/Makefile.am |   6 +-
 openbsc/src/utils/meas_json.c | 169 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 174 insertions(+), 1 deletion(-)
 create mode 100644 openbsc/src/utils/meas_json.c

diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am
index f6255a0..89f2dfb 100644
--- a/openbsc/src/utils/Makefile.am
+++ b/openbsc/src/utils/Makefile.am
@@ -4,7 +4,7 @@ AM_LDFLAGS = $(COVERAGE_LDFLAGS)
 
 noinst_HEADERS = meas_db.h
 
-bin_PROGRAMS = bs11_config isdnsync
+bin_PROGRAMS = bs11_config isdnsync meas_json
 if HAVE_SQLITE3
 bin_PROGRAMS += osmo-meas-pcap2db osmo-meas-udp2db
 endif
@@ -32,6 +32,10 @@ meas_vis_SOURCES = meas_vis.c
 meas_vis_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) -lcdk -lncurses
 meas_vis_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS)
 
+meas_json_SOURCES = meas_json.c
+meas_json_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS)
+meas_json_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS)
+
 osmo_meas_pcap2db_SOURCES = meas_pcap2db.c meas_db.c
 osmo_meas_pcap2db_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) -lpcap $(SQLITE3_LIBS)
 osmo_meas_pcap2db_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS)
diff --git a/openbsc/src/utils/meas_json.c b/openbsc/src/utils/meas_json.c
new file mode 100644
index 0000000..940e5e7
--- /dev/null
+++ b/openbsc/src/utils/meas_json.c
@@ -0,0 +1,169 @@
+/* Convert measurement report feed into JSON feed printed to stdout.
+ * Each measurement report is printed as a separae JSON root entry.
+ * All measurement reports are separated by a new line.
+ */
+
+/* (C) 2015 by Alexander Chemeris <Alexander.Chemeris at fairwaves.co>
+ * With parts of code adopted from different places in OpenBSC.
+ *
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License as published by
+ * the Free Software Foundation; either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include <string.h>
+#include <errno.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+
+#include <netinet/in.h>
+
+#include <osmocom/core/socket.h>
+#include <osmocom/core/msgb.h>
+#include <osmocom/core/select.h>
+
+#include <osmocom/gsm/gsm_utils.h>
+
+#include <openbsc/meas_feed.h>
+
+static void print_meas_rep_uni_json(struct gsm_meas_rep_unidir *mru)
+{
+	printf("\"RXL-FULL\":%d, \"RXL-SUB\":%d, ",
+		rxlev2dbm(mru->full.rx_lev),
+		rxlev2dbm(mru->sub.rx_lev));
+	printf("\"RXQ-FULL\":%d, \"RXQ-SUB\":%d",
+		mru->full.rx_qual, mru->sub.rx_qual);
+}
+
+static void print_meas_rep_json(struct gsm_meas_rep *mr)
+{
+	int i;
+
+	printf("\"NR\":%d", mr->nr);
+
+	if (mr->flags & MEAS_REP_F_DL_DTX)
+		printf(", \"DTXd\":true");
+
+	printf(", \"UL_MEAS\":{");
+	print_meas_rep_uni_json(&mr->ul);
+	printf("}");
+	printf(", \"BS_POWER\":%d", mr->bs_power);
+	if (mr->flags & MEAS_REP_F_MS_TO)
+		printf(", \"MS_TO\":%d", mr->ms_timing_offset);
+
+	if (mr->flags & MEAS_REP_F_MS_L1) {
+		printf(", \"L1_MS_PWR\":%d", mr->ms_l1.pwr);
+		printf(", \"L1_FPC\":%s",
+			mr->flags & MEAS_REP_F_FPC ? "true" : "false");
+		printf(", \"L1_TA\":%u", mr->ms_l1.ta);
+	}
+
+	if (mr->flags & MEAS_REP_F_UL_DTX)
+		printf(", \"DTXu\":true");
+	if (mr->flags & MEAS_REP_F_BA1)
+		printf(", \"BA1\":true");
+	if (mr->flags & MEAS_REP_F_DL_VALID) {
+		printf(", \"DL_MEAS\":{");
+		print_meas_rep_uni_json(&mr->dl);
+		printf("}");
+	}
+
+	if (mr->num_cell == 7)
+		return;
+	printf(", \"NUM_NEIGH\":%u, \"NEIGH\":[", mr->num_cell);
+	for (i = 0; i < mr->num_cell; i++) {
+		struct gsm_meas_rep_cell *mrc = &mr->cell[i];
+		if (i!=0) printf(", ");
+		printf("\"IDX\":%u, \"ARFCN\":%u, \"BSIC\":%u, \"POWER\":%d",
+			mrc->neigh_idx, mrc->arfcn, mrc->bsic, rxlev2dbm(mrc->rxlev));
+	}
+	printf("]");
+}
+
+static void print_meas_feed_json(struct meas_feed_meas *mfm)
+{
+	time_t now = time(NULL);
+
+	printf("{");
+	printf("\"time\":%ld, \"imsi\":\"%s\", \"name\":\"%s\", \"scenario\":\"%s\", ",
+		now, mfm->imsi, mfm->name, mfm->scenario);
+
+	printf("\"meas_rep\":{");
+	print_meas_rep_json(&mfm->mr);
+	printf("}");
+
+	printf("}\n");
+
+}
+
+static int handle_meas(struct msgb *msg)
+{
+	struct meas_feed_meas *mfm = (struct meas_feed_meas *) msgb_data(msg);
+
+	print_meas_feed_json(mfm);
+
+	return 0;
+}
+
+static int handle_msg(struct msgb *msg)
+{
+	struct meas_feed_hdr *mfh = (struct meas_feed_hdr *) msgb_data(msg);
+
+	if (mfh->version != MEAS_FEED_VERSION)
+		return -EINVAL;
+
+	switch (mfh->msg_type) {
+	case MEAS_FEED_MEAS:
+		handle_meas(msg);
+		break;
+	default:
+		break;
+	}
+}
+
+static int udp_fd_cb(struct osmo_fd *ofd, unsigned int what)
+{
+	int rc;
+
+	if (what & BSC_FD_READ) {
+		struct msgb *msg = msgb_alloc(1024, "UDP Rx");
+
+		rc = read(ofd->fd, msgb_data(msg), msgb_tailroom(msg));
+		if (rc < 0)
+			return rc;
+		msgb_put(msg, rc);
+		handle_msg(msg);
+		msgb_free(msg);
+	}
+
+	return 0;
+}
+
+int main(int argc, char **argv)
+{
+	int rc;
+	struct osmo_fd udp_ofd;
+
+	udp_ofd.cb = udp_fd_cb;
+	rc =  osmo_sock_init_ofd(&udp_ofd, AF_INET, SOCK_DGRAM, IPPROTO_UDP, NULL, 8888, OSMO_SOCK_F_BIND);
+	if (rc < 0)
+		exit(1);
+
+	while (1) {
+		osmo_select_main(0);
+	};
+
+	exit(0);
+}
-- 
1.9.1



From alexander.chemeris at gmail.com  Sat Dec 12 14:44:17 2015
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 12 Dec 2015 09:44:17 -0500
Subject: [PATCH 2/2] utils: Support new fields in the v1 of meas_feed in
 meas_json.
In-Reply-To: <1449931457-6446-1-git-send-email-Alexander.Chemeris@gmail.com>
References: <1449931457-6446-1-git-send-email-Alexander.Chemeris@gmail.com>
Message-ID: <1449931457-6446-2-git-send-email-Alexander.Chemeris@gmail.com>

---
 openbsc/src/utils/Makefile.am |  3 ++-
 openbsc/src/utils/meas_json.c | 25 ++++++++++++++++++++++---
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am
index 89f2dfb..681d074 100644
--- a/openbsc/src/utils/Makefile.am
+++ b/openbsc/src/utils/Makefile.am
@@ -33,7 +33,8 @@ meas_vis_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) -lcdk -lncurses
 meas_vis_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS)
 
 meas_json_SOURCES = meas_json.c
-meas_json_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS)
+meas_json_LDADD = $(top_builddir)/src/libcommon/libcommon.a \
+		  $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS)
 meas_json_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS)
 
 osmo_meas_pcap2db_SOURCES = meas_pcap2db.c meas_db.c
diff --git a/openbsc/src/utils/meas_json.c b/openbsc/src/utils/meas_json.c
index 940e5e7..88d713b 100644
--- a/openbsc/src/utils/meas_json.c
+++ b/openbsc/src/utils/meas_json.c
@@ -36,6 +36,8 @@
 
 #include <osmocom/gsm/gsm_utils.h>
 
+#include <openbsc/gsm_data.h>
+#include <openbsc/gsm_data_shared.h>
 #include <openbsc/meas_feed.h>
 
 static void print_meas_rep_uni_json(struct gsm_meas_rep_unidir *mru)
@@ -92,6 +94,14 @@ static void print_meas_rep_json(struct gsm_meas_rep *mr)
 	printf("]");
 }
 
+static void print_chan_info_json(struct meas_feed_meas *mfm)
+{
+	printf("\"lchan_type\":\"%s\", \"pchan_type\":\"%s\", "
+		   "\"bts_nr\":%d, \"trx_nr\":%d, \"ts_nr\":%d, \"ss_nr\":%d",
+	gsm_lchant_name(mfm->lchan_type), gsm_pchan_name(mfm->pchan_type),
+	mfm->bts_nr, mfm->trx_nr, mfm->ts_nr, mfm->ss_nr);
+}
+
 static void print_meas_feed_json(struct meas_feed_meas *mfm)
 {
 	time_t now = time(NULL);
@@ -100,9 +110,18 @@ static void print_meas_feed_json(struct meas_feed_meas *mfm)
 	printf("\"time\":%ld, \"imsi\":\"%s\", \"name\":\"%s\", \"scenario\":\"%s\", ",
 		now, mfm->imsi, mfm->name, mfm->scenario);
 
-	printf("\"meas_rep\":{");
-	print_meas_rep_json(&mfm->mr);
-	printf("}");
+	switch (mfm->hdr.version) {
+	case 1:
+		printf("\"chan_info\":{");
+		print_chan_info_json(mfm);
+		printf("}, ");
+		/* no break, fall to version 0 */
+	case 0:
+		printf("\"meas_rep\":{");
+		print_meas_rep_json(&mfm->mr);
+		printf("}");
+		break;
+	}
 
 	printf("}\n");
 
-- 
1.9.1



From alexander.chemeris at gmail.com  Sat Dec 12 14:47:22 2015
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 12 Dec 2015 09:47:22 -0500
Subject: Mergin meas_json to master
In-Reply-To: <939529872.13344034.1449928879544.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <2057100178.13343865.1449928662056.JavaMail.zimbra@kvk.uni-obuda.hu>
 <939529872.13344034.1449928879544.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <CABmJbFULXET7Vq8cssJ_MovuhjZPUYmgX=i7UOnWdECosZYnkw@mail.gmail.com>

HI Csaba,

On Sat, Dec 12, 2015 at 9:01 AM, Sipos Csaba
<sipos.csaba at kvk.uni-obuda.hu> wrote:
> I started to write the Wiki page for Meas_web.

That's great! Do not hesitate to share a link here.

> During this I just realized that because of some outstanding merges the installation of this tool is painfully complicated.
>
> In order to make things easier, I suggest to merge the meas_json part into OpenBSC master:
>
> http://cgit.osmocom.org/openbsc/log/?h=achemeris/meas_json

That's a good idea. Thank you for reminding me. I've just rebased it
to master and sent the patches for review.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

 


From alexander.chemeris at gmail.com  Sat Dec 12 14:49:44 2015
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 12 Dec 2015 09:49:44 -0500
Subject: [PATCH 1/3] mncc: Implement helper functions to convert MNCC
 cause to a string.
In-Reply-To: <1448483466-10556-1-git-send-email-Alexander.Chemeris@gmail.com>
References: <1448483466-10556-1-git-send-email-Alexander.Chemeris@gmail.com>
Message-ID: <CABmJbFVGHO-n168HXd9EguQoko=vqaRNPP8CY172dCpgRxGE3g@mail.gmail.com>

bump. Still hope to get this merged.

On Wed, Nov 25, 2015 at 3:31 PM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
> ---
>  openbsc/include/openbsc/mncc.h |   5 +-
>  openbsc/src/libmsc/mncc.c      | 103 ++++++++++++++++++++++++++++++++++++++---
>  2 files changed, 100 insertions(+), 8 deletions(-)
>
> diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h
> index 46ba237..92389c2 100644
> --- a/openbsc/include/openbsc/mncc.h
> +++ b/openbsc/include/openbsc/mncc.h
> @@ -191,8 +191,11 @@ struct gsm_mncc_rtp {
>         uint32_t        payload_msg_type;
>  };
>
> -char *get_mncc_name(int value);
> +const char *get_mncc_name(int value);
>  void mncc_set_cause(struct gsm_mncc *data, int loc, int val);
> +int mncc_has_cause(struct gsm_mncc *data);
> +const char *get_mncc_location(int value);
> +const char *get_mncc_cause(int value);
>  void cc_tx_to_mncc(struct gsm_network *net, struct msgb *msg);
>
>  /* input from CC code into mncc_builtin */
> diff --git a/openbsc/src/libmsc/mncc.c b/openbsc/src/libmsc/mncc.c
> index 2767faa..e8bd9ba 100644
> --- a/openbsc/src/libmsc/mncc.c
> +++ b/openbsc/src/libmsc/mncc.c
> @@ -34,10 +34,12 @@
>  #include <openbsc/transaction.h>
>  #include <openbsc/rtp_proxy.h>
>
> -static struct mncc_names {
> +struct name_value {
>         char *name;
>         int value;
> -} mncc_names[] = {
> +};
> +
> +static struct name_value mncc_names[] = {
>         {"MNCC_SETUP_REQ",      0x0101},
>         {"MNCC_SETUP_IND",      0x0102},
>         {"MNCC_SETUP_RSP",      0x0103},
> @@ -95,16 +97,103 @@ static struct mncc_names {
>
>         {NULL, 0} };
>
> -char *get_mncc_name(int value)
> +static struct name_value mncc_locations[] = {
> +       {"GSM48_CAUSE_LOC_USER",                0x00},
> +       {"GSM48_CAUSE_LOC_PRN_S_LU",    0x01},
> +       {"GSM48_CAUSE_LOC_PUN_S_LU",    0x02},
> +       {"GSM48_CAUSE_LOC_TRANS_NET",   0x03},
> +       {"GSM48_CAUSE_LOC_PUN_S_RU",    0x04},
> +       {"GSM48_CAUSE_LOC_PRN_S_RU",    0x05},
> +       /* not defined */
> +       {"GSM48_CAUSE_LOC_INN_NET",             0x07},
> +       {"GSM48_CAUSE_LOC_NET_BEYOND",  0x0a},
> +
> +       {NULL, 0} };
> +
> +static struct name_value mncc_causes[] = {
> +       {"GSM48_CC_CAUSE_UNASSIGNED_NR",        1},
> +       {"GSM48_CC_CAUSE_NO_ROUTE",     3},
> +       {"GSM48_CC_CAUSE_CHAN_UNACCEPT",        6},
> +       {"GSM48_CC_CAUSE_OP_DET_BARRING",       8},
> +       {"GSM48_CC_CAUSE_NORM_CALL_CLEAR",      16},
> +       {"GSM48_CC_CAUSE_USER_BUSY",    17},
> +       {"GSM48_CC_CAUSE_USER_NOTRESPOND",      18},
> +       {"GSM48_CC_CAUSE_USER_ALERTING_NA",     19},
> +       {"GSM48_CC_CAUSE_CALL_REJECTED",        21},
> +       {"GSM48_CC_CAUSE_NUMBER_CHANGED",       22},
> +       {"GSM48_CC_CAUSE_PRE_EMPTION",  25},
> +       {"GSM48_CC_CAUSE_NONSE_USER_CLR",       26},
> +       {"GSM48_CC_CAUSE_DEST_OOO",     27},
> +       {"GSM48_CC_CAUSE_INV_NR_FORMAT",        28},
> +       {"GSM48_CC_CAUSE_FACILITY_REJ", 29},
> +       {"GSM48_CC_CAUSE_RESP_STATUS_INQ",      30},
> +       {"GSM48_CC_CAUSE_NORMAL_UNSPEC",        31},
> +       {"GSM48_CC_CAUSE_NO_CIRCUIT_CHAN",      34},
> +       {"GSM48_CC_CAUSE_NETWORK_OOO",  38},
> +       {"GSM48_CC_CAUSE_TEMP_FAILURE", 41},
> +       {"GSM48_CC_CAUSE_SWITCH_CONG",  42},
> +       {"GSM48_CC_CAUSE_ACC_INF_DISCARD",      43},
> +       {"GSM48_CC_CAUSE_REQ_CHAN_UNAVAIL",     44},
> +       {"GSM48_CC_CAUSE_RESOURCE_UNAVAIL",     47},
> +       {"GSM48_CC_CAUSE_QOS_UNAVAIL",  49},
> +       {"GSM48_CC_CAUSE_REQ_FAC_NOT_SUBSC",    50},
> +       {"GSM48_CC_CAUSE_INC_BARRED_CUG",       55},
> +       {"GSM48_CC_CAUSE_BEARER_CAP_UNAUTH",    57},
> +       {"GSM48_CC_CAUSE_BEARER_CA_UNAVAIL",    58},
> +       {"GSM48_CC_CAUSE_SERV_OPT_UNAVAIL",     63},
> +       {"GSM48_CC_CAUSE_BEARERSERV_UNIMPL",    65},
> +       {"GSM48_CC_CAUSE_ACM_GE_ACM_MAX",       68},
> +       {"GSM48_CC_CAUSE_REQ_FAC_NOTIMPL",      69},
> +       {"GSM48_CC_CAUSE_RESTR_BCAP_AVAIL",     70},
> +       {"GSM48_CC_CAUSE_SERV_OPT_UNIMPL",      79},
> +       {"GSM48_CC_CAUSE_INVAL_TRANS_ID",       81},
> +       {"GSM48_CC_CAUSE_USER_NOT_IN_CUG",      87},
> +       {"GSM48_CC_CAUSE_INCOMPAT_DEST",        88},
> +       {"GSM48_CC_CAUSE_INVAL_TRANS_NET",      91},
> +       {"GSM48_CC_CAUSE_SEMANTIC_INCORR",      95},
> +       {"GSM48_CC_CAUSE_INVAL_MAND_INF",       96},
> +       {"GSM48_CC_CAUSE_MSGTYPE_NOTEXIST",     97},
> +       {"GSM48_CC_CAUSE_MSGTYPE_INCOMPAT",     98},
> +       {"GSM48_CC_CAUSE_IE_NOTEXIST",  99},
> +       {"GSM48_CC_CAUSE_COND_IE_ERR",  100},
> +       {"GSM48_CC_CAUSE_MSG_INCOMP_STATE",     101},
> +       {"GSM48_CC_CAUSE_RECOVERY_TIMER",       102},
> +       {"GSM48_CC_CAUSE_PROTO_ERR",    111},
> +       {"GSM48_CC_CAUSE_INTERWORKING", 127},
> +
> +       {NULL, 0} };
> +
> +const char *get_name_by_value(struct name_value *pairs, int value, const char *default_val)
>  {
>         int i;
>
> -       for (i = 0; mncc_names[i].name; i++) {
> -               if (mncc_names[i].value == value)
> -                       return mncc_names[i].name;
> +       for (i = 0; pairs[i].name; i++) {
> +               if (pairs[i].value == value)
> +                       return pairs[i].name;
>         }
>
> -       return "MNCC_Unknown";
> +       return default_val;
> +}
> +
> +
> +const char *get_mncc_name(int value)
> +{
> +       return get_name_by_value(mncc_names, value, "MNCC_Unknown");
> +}
> +
> +const char *get_mncc_location(int value)
> +{
> +       return get_name_by_value(mncc_locations, value, "GSM48_CAUSE_LOC_Unknown");
> +}
> +
> +const char *get_mncc_cause(int value)
> +{
> +       return get_name_by_value(mncc_causes, value, "GSM48_CC_CAUSE_Unknown");
> +}
> +
> +int mncc_has_cause(struct gsm_mncc *data)
> +{
> +       return data->fields & MNCC_F_CAUSE;
>  }
>
>  void mncc_set_cause(struct gsm_mncc *data, int loc, int val)
> --
> 1.9.1
>



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

 


From sipos.csaba at kvk.uni-obuda.hu  Sat Dec 12 15:00:59 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 12 Dec 2015 16:00:59 +0100 (CET)
Subject: Mergin meas_json to master
In-Reply-To: <CABmJbFULXET7Vq8cssJ_MovuhjZPUYmgX=i7UOnWdECosZYnkw@mail.gmail.com>
References: <2057100178.13343865.1449928662056.JavaMail.zimbra@kvk.uni-obuda.hu>
 <939529872.13344034.1449928879544.JavaMail.zimbra@kvk.uni-obuda.hu>
 <CABmJbFULXET7Vq8cssJ_MovuhjZPUYmgX=i7UOnWdECosZYnkw@mail.gmail.com>
Message-ID: <991211304.13347726.1449932459115.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Alexander,

The link is here:

http://openbsc.osmocom.org/trac/wiki/meas_web

Will wait until the outstanding parts get merged, then I will finish it.

After this only one outstanding part is there: the Osmo-BTS code. To be more precise, the reason why the master is not working with usrp and the fairwaves-rebase do.

Have you seen my previous mail in this topic? This was the subject:

<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0xf

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Alexander Chemeris" <alexander.chemeris at gmail.com>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "Harald Welte" <laforge at gnumonks.org>, "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szombat, 2015. December 12. 15:47:22
T?rgy: Re: Mergin meas_json to master

HI Csaba,

On Sat, Dec 12, 2015 at 9:01 AM, Sipos Csaba
<sipos.csaba at kvk.uni-obuda.hu> wrote:
> I started to write the Wiki page for Meas_web.

That's great! Do not hesitate to share a link here.

> During this I just realized that because of some outstanding merges the installation of this tool is painfully complicated.
>
> In order to make things easier, I suggest to merge the meas_json part into OpenBSC master:
>
> http://cgit.osmocom.org/openbsc/log/?h=achemeris/meas_json

That's a good idea. Thank you for reminding me. I've just rebased it
to master and sent the patches for review.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

 


From alexander.chemeris at gmail.com  Sat Dec 12 15:26:09 2015
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 12 Dec 2015 10:26:09 -0500
Subject: Mergin meas_json to master
In-Reply-To: <991211304.13347726.1449932459115.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <2057100178.13343865.1449928662056.JavaMail.zimbra@kvk.uni-obuda.hu>
 <939529872.13344034.1449928879544.JavaMail.zimbra@kvk.uni-obuda.hu>
 <CABmJbFULXET7Vq8cssJ_MovuhjZPUYmgX=i7UOnWdECosZYnkw@mail.gmail.com>
 <991211304.13347726.1449932459115.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <CABmJbFVFN__LewbbS4pVf5C4JFEZr+Xbn3ri+LFvnDC4jumkAg@mail.gmail.com>

Hi Csaba,

On Sat, Dec 12, 2015 at 10:00 AM, Sipos Csaba
<sipos.csaba at kvk.uni-obuda.hu> wrote:
> The link is here:
>
> http://openbsc.osmocom.org/trac/wiki/meas_web

Thanks. As a note - meas_vis is not required for meas_web, so you
don't need to install ncurses, etc. It's a nice tool on it's own
merits, but it's weird to see it as a requirement for meas_web.

> After this only one outstanding part is there: the Osmo-BTS code. To be more precise, the reason why the master is not working with usrp and the fairwaves-rebase do.
>
> Have you seen my previous mail in this topic? This was the subject:
>
> <0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0xf

Sure, I saw it and I had a hope may be someone except fairwaves will
step up and resolve the issue? :)
We're currently busy working at the different layers of code, so it'll
be a while before we get back to osmo-bts. Given how long it took to
merge it to master, I don't think little more delay is a problem.
We'll get there, just be patient or submit patches.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

 


From holger at freyther.de  Sat Dec 12 16:16:48 2015
From: holger at freyther.de (Holger Freyther)
Date: Sat, 12 Dec 2015 17:16:48 +0100
Subject: [PATCH 1/3] mncc: Implement helper functions to convert MNCC
 cause to a string.
In-Reply-To: <CABmJbFVGHO-n168HXd9EguQoko=vqaRNPP8CY172dCpgRxGE3g@mail.gmail.com>
References: <1448483466-10556-1-git-send-email-Alexander.Chemeris@gmail.com>
 <CABmJbFVGHO-n168HXd9EguQoko=vqaRNPP8CY172dCpgRxGE3g@mail.gmail.com>
Message-ID: <0FD16EB0-D7EA-4FE4-B62E-874502169A5B@freyther.de>


> On 12 Dec 2015, at 15:49, Alexander Chemeris <alexander.chemeris at gmail.com> wrote:
> 
> bump. Still hope to get this merged.
> 

on my list. but will probably be after christmas. Do you have an idea why patchwork is not
picking up your patches?

holger



From laforge at gnumonks.org  Sat Dec 12 22:04:58 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 12 Dec 2015 23:04:58 +0100
Subject: mncc-python tool for talking to MNCC interface
In-Reply-To: <828268944.13341544.1449926426380.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <20151201234802.GE8430@nataraja>
 <828268944.13341544.1449926426380.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20151212220458.GY28681@nataraja>

Hi Sipos,

On Sat, Dec 12, 2015 at 02:20:26PM +0100, Sipos Csaba wrote:
> GsmCallFsm(15/3802->7839/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT
>  GsmCallFsm(16/7839->3802/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT>>>

great, you have two call actors, and they both send their setup request.

> GsmCallFsm(15/3802->7839/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=15, fields=0x0020))
> [ ... ]
> GsmCallFsm(16/7839->3802/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=16, fields=0x0020))

Those above two lines mean msg_type=0x0111 = MNCC_REL_IND.  So OsmoNITB
is sending you a release indication for both calls.

Please use the usual way for debugging / analyzing problems (like
'logging level cc' on OsmoNITB) to see what's happening.  For some
reason the NIBT is releasing the calls.  Could be that the subscriber
extension (phone) numbers 3802 / 7839 are not existing or cannot be
reached at this point.

> The MNCC socket is connected according to the BSC, but when I gave the
> command, nothing happens on the BSC nor the BTS side.

I'm sure plenty is happening, you just need to look at the right
logging (cc and mncc subsytems).

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From alexander.chemeris at gmail.com  Sat Dec 12 23:51:16 2015
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 12 Dec 2015 18:51:16 -0500
Subject: [PATCH 1/3] mncc: Implement helper functions to convert MNCC
 cause to a string.
In-Reply-To: <0FD16EB0-D7EA-4FE4-B62E-874502169A5B@freyther.de>
References: <1448483466-10556-1-git-send-email-Alexander.Chemeris@gmail.com>
 <CABmJbFVGHO-n168HXd9EguQoko=vqaRNPP8CY172dCpgRxGE3g@mail.gmail.com>
 <0FD16EB0-D7EA-4FE4-B62E-874502169A5B@freyther.de>
Message-ID: <CABmJbFV0411OhBoQzXe0QT_5+f5T99-j6j5FtjC2-CaU-DOQEQ@mail.gmail.com>

On Sat, Dec 12, 2015 at 11:16 AM, Holger Freyther <holger at freyther.de> wrote:
>> On 12 Dec 2015, at 15:49, Alexander Chemeris <alexander.chemeris at gmail.com> wrote:
>>
>> bump. Still hope to get this merged.
>
> on my list. but will probably be after christmas.

Thanks!
No pressure, I just wanted to make sure it's not lost again.

> Do you have an idea why patchwork is not picking up your patches?

Not really :\
It seems like we're not the only ones affected, but there is no
solution offered:
https://lists.ozlabs.org/pipermail/patchwork/2015-October/001888.html

I'm happy to do more testing if needed, as it seems my patches get
lost routinely.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

 


From sipos.csaba at kvk.uni-obuda.hu  Sun Dec 13 11:07:08 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sun, 13 Dec 2015 12:07:08 +0100 (CET)
Subject: mncc-python tool for talking to MNCC interface
In-Reply-To: <20151212220458.GY28681@nataraja>
References: <20151201234802.GE8430@nataraja>
 <828268944.13341544.1449926426380.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20151212220458.GY28681@nataraja>
Message-ID: <1736132429.13396966.1450004828706.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Harald,

Sorry, my mistake, will do that.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Szombat, 2015. December 12. 23:04:58
T?rgy: Re: mncc-python tool for talking to MNCC interface

Hi Sipos,

On Sat, Dec 12, 2015 at 02:20:26PM +0100, Sipos Csaba wrote:
> GsmCallFsm(15/3802->7839/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT
>  GsmCallFsm(16/7839->3802/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT>>>

great, you have two call actors, and they both send their setup request.

> GsmCallFsm(15/3802->7839/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=15, fields=0x0020))
> [ ... ]
> GsmCallFsm(16/7839->3802/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=16, fields=0x0020))

Those above two lines mean msg_type=0x0111 = MNCC_REL_IND.  So OsmoNITB
is sending you a release indication for both calls.

Please use the usual way for debugging / analyzing problems (like
'logging level cc' on OsmoNITB) to see what's happening.  For some
reason the NIBT is releasing the calls.  Could be that the subscriber
extension (phone) numbers 3802 / 7839 are not existing or cannot be
reached at this point.

> The MNCC socket is connected according to the BSC, but when I gave the
> command, nothing happens on the BSC nor the BTS side.

I'm sure plenty is happening, you just need to look at the right
logging (cc and mncc subsytems).

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Dec 13 11:09:23 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Dec 2015 12:09:23 +0100
Subject: [PATCH 1/3] mncc: Implement helper functions to convert MNCC
 cause to a string.
In-Reply-To: <1448483466-10556-1-git-send-email-Alexander.Chemeris@gmail.com>
References: <1448483466-10556-1-git-send-email-Alexander.Chemeris@gmail.com>
Message-ID: <20151213110923.GA15870@nataraja>

Hi Alexander,

I may just have broken your patch-set accidentially by converting
mncc_names to value_string, sorry for that :/

Regarding your patch, I have to disagree about several topics:

On Wed, Nov 25, 2015 at 03:31:04PM -0500, Alexander Chemeris wrote:
> -static struct mncc_names {
> +struct name_value {
>  	char *name;
>  	int value;
> -} mncc_names[] = {
> +};

Is there a specific reason to introduce a new structure rather than use
struct value_string from libosmocore, which is used all over the Osmo*
code for this kind of name-value mapping?  All code should use that
infrastructure, and the occasional separate implementation should bec
converted to value_string.

> +static struct name_value mncc_locations[] = {
> +	{"GSM48_CAUSE_LOC_USER",		0x00},

1) The cause values and cause locations are GSM 04.08, not MNCC
   specific.  As such, they belong into libosmogsm, not OsmoNITB.  Also,
   they shouldn't be called 'mncc_locations' if in fact they are GSM
   04.08 locations.

2) Also, rather than introducing magic numbers, the defnitions from
   <osmocmo/gsm/protocol/gsm_04_08.h> should be used, making the above an

struct value_string gsm48_cause_loc_names[] = {
	{ GSM48_CAUSE_LOC_USER, "GSM48_CAUSE_LOC_USER" },

3) And finally, the string should be more user-readable than the cryptic
   #define/enum value, i.e.

struct value_string gsm48_cause_loc_names[] = {
	{ GSM48_CAUSE_LOC_USER, "User" },

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Sun Dec 13 14:17:32 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 13 Dec 2015 15:17:32 +0100
Subject: [PATCH] gtphub: add to debian build
In-Reply-To: <BCE0B2E9-0F08-474E-B7A4-DE8E1A1581A3@freyther.de>
References: <1448368818-21121-1-git-send-email-nhofmeyr@sysmocom.de>
 <FE57C498-8F10-4A3D-9C69-2D4B67BB788E@freyther.de>
 <20151130114747.GA1394@dub5>
 <BCE0B2E9-0F08-474E-B7A4-DE8E1A1581A3@freyther.de>
Message-ID: <20151213141732.GA1831@dub5>

On Thu, Dec 10, 2015 at 09:02:49PM +0100, Holger Freyther wrote:
> 
> > On 30 Nov 2015, at 12:47, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> Good Evening Neels,
> 
> 
> > Added awareness of it (in my head), added gtphub (in osmoappdesc.py) and
> > merged to master.
> 
> we need to revert or extend the gtphub vty to make it work on our CI platform. You
> can not bind to 127.0.0.1 and 127.0.0.2 on the CI infrastructure so the default config
> can't be execute. We could add VTY commands to specify the ports to be used and
> multiplex it then.

There is no "default" config, but gtphub requires a config file...

VTY for port numbers already exists: there is a short version using
standard ports and a longer one where you can issue ports.

short:

  gtphub
  bind-to-sgsns 127.0.0.1
  bind-to-ggsns 127.0.0.2

long, with ports:

  bind-to-sgsns ctrl 127.0.0.1 12123 user 127.0.0.1 12152
  bind-to-ggsns crtl 127.0.0.1 22123 user 127.0.0.1 22152

> The other issue is the position of the gtphub. At the bottom we have this:
> 
> vty_command = ["./src/osmo-nitb/osmo-nitb", "-c",
>                "doc/examples/osmo-nitb/nanobts/openbsc.cfg"]
> 
> vty_app = apps[-1]
> 
> So we run the nitb but try to connect to port 4253 which of course fails and explains
> why the OpenBSC build failed the last couple of times. :)

Those python structures are a bit sneaky ... they seem so simple, but
they'll bite your ankles ;)

vty_app looks weird. is vty_app only used for osmo-nitb?  IMHO it could
make sense to clarify the python, but for the time being we could simply
fix with

  vty_app = apps[-2]

??

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151213/c6526e9d/attachment.bin>

From nhofmeyr at sysmocom.de  Sun Dec 13 14:24:39 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 13 Dec 2015 15:24:39 +0100
Subject: [PATCH] gtphub: add to debian build
In-Reply-To: <20151213141732.GA1831@dub5>
References: <1448368818-21121-1-git-send-email-nhofmeyr@sysmocom.de>
 <FE57C498-8F10-4A3D-9C69-2D4B67BB788E@freyther.de>
 <20151130114747.GA1394@dub5>
 <BCE0B2E9-0F08-474E-B7A4-DE8E1A1581A3@freyther.de>
 <20151213141732.GA1831@dub5>
Message-ID: <20151213142439.GB1831@dub5>

On Sun, Dec 13, 2015 at 03:17:32PM +0100, Neels Hofmeyr wrote:
> > The other issue is the position of the gtphub. At the bottom we have this:
> > 
> > vty_command = ["./src/osmo-nitb/osmo-nitb", "-c",
> >                "doc/examples/osmo-nitb/nanobts/openbsc.cfg"]
> > 
> > vty_app = apps[-1]
> > 
> > So we run the nitb but try to connect to port 4253 which of course fails and explains
> > why the OpenBSC build failed the last couple of times. :)

I've changed the index in 4adca4e.

~Neels


-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151213/67e8e207/attachment.bin>

From holger at freyther.de  Sun Dec 13 15:29:20 2015
From: holger at freyther.de (Holger Freyther)
Date: Sun, 13 Dec 2015 16:29:20 +0100
Subject: [PATCH] gtphub: add to debian build
In-Reply-To: <20151213142439.GB1831@dub5>
References: <1448368818-21121-1-git-send-email-nhofmeyr@sysmocom.de>
 <FE57C498-8F10-4A3D-9C69-2D4B67BB788E@freyther.de>
 <20151130114747.GA1394@dub5>
 <BCE0B2E9-0F08-474E-B7A4-DE8E1A1581A3@freyther.de>
 <20151213141732.GA1831@dub5> <20151213142439.GB1831@dub5>
Message-ID: <9A88C17C-C4F2-4704-B3F9-CE03DD3DC3EA@freyther.de>


> On 13 Dec 2015, at 15:24, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> 
> I've changed the index in 4adca4e.

better. but unless you have a config that only uses 127.0.0.1 as ip address the build
will stay broken on our CI infrastructure. Please adjust the config to use 127.0.0.1 but
different ports.

thanks
	holger

From nhofmeyr at sysmocom.de  Mon Dec 14 08:33:46 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 14 Dec 2015 09:33:46 +0100
Subject: [PATCH] gtphub: add to debian build
In-Reply-To: <9A88C17C-C4F2-4704-B3F9-CE03DD3DC3EA@freyther.de>
References: <1448368818-21121-1-git-send-email-nhofmeyr@sysmocom.de>
 <FE57C498-8F10-4A3D-9C69-2D4B67BB788E@freyther.de>
 <20151130114747.GA1394@dub5>
 <BCE0B2E9-0F08-474E-B7A4-DE8E1A1581A3@freyther.de>
 <20151213141732.GA1831@dub5> <20151213142439.GB1831@dub5>
 <9A88C17C-C4F2-4704-B3F9-CE03DD3DC3EA@freyther.de>
Message-ID: <20151214083346.GA12617@dub5>

On Sun, Dec 13, 2015 at 04:29:20PM +0100, Holger Freyther wrote:
> 
> > On 13 Dec 2015, at 15:24, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> > 
> > 
> > I've changed the index in 4adca4e.
> 
> better. but unless you have a config that only uses 127.0.0.1 as ip address the build
> will stay broken on our CI infrastructure. Please adjust the config to use 127.0.0.1 but
> different ports.

Ah of course, the doc/examples file is used in the test... will fix.

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151214/c5a60551/attachment.bin>

From suraev at alumni.ntnu.no  Mon Dec 14 11:45:57 2015
From: suraev at alumni.ntnu.no (Suraev)
Date: Mon, 14 Dec 2015 12:45:57 +0100
Subject: FYI: gtphub merged
In-Reply-To: <20151207101219.GA2387@dub5>
References: <20151203105255.GB1698@dub5>
 <1608075646.11725224.1449146301692.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20151207101219.GA2387@dub5>
Message-ID: <566EABF5.4010405@alumni.ntnu.no>

Hi.

Could be also nice if you add couple of lines to
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS

so people could see how gtphub fits into bigger picture.

cheers,
Max.



From sipos.csaba at kvk.uni-obuda.hu  Tue Dec 15 12:04:41 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Tue, 15 Dec 2015 13:04:41 +0100 (CET)
Subject: PySIM: SW match failed
In-Reply-To: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>
References: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>
Message-ID: <1268804460.13763676.1450181081308.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Florian,

I can confirm that the "zecke/tmp" branch is working for programming.

Can you please share your modifications with Harald and the list so these modifications can get into the code?

Until we find a way to program these cards again, at least an indicator and warning system should be in place to warn the users how many tries are left for the ADM.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Florian" <openbsc at flocom.net>
C?mzett: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Cs?t?rt?k, 2015. December 10. 17:13:13
T?rgy: Re: PySIM: SW match failed

On Thu Nov 5 09:05:15 UTC 2015, Harald Welte wrote:

>> RuntimeError: SW match failed ! Expected 9000 and got 6a86.

> According to ISO 7816-4, this 6a86 means 'incorrect P1 or P2 
> parameter'.

>> At this point I don't have any more ideas what to try, if anyone would 
>> have any suggestions I would apreciate it.

> Please activate (or hack some code for) tracing the actual APDUs that
> pySim excahnges with the card.  IIRC, pySim already has that option.

> Once you see the raw APDUs, you can compare their encoding 
> (particularly
> P1/P2) with those described in the relevant ETSI/3GPP (U)SIM 
> specifications.

I enhanced my local copy of pySim (zecke/tmp) to show the raw PDUs.
And I added a method to check the Status of the PIN and ADM register.
On one card I messed up the ADM, so pySim-prog.py shows

whey query for SIM 1:

> send_apdu_raw -> 00200001
< received status word 63c3

So that is SW1='63' with SW2='CX': Counter (verification failed: 'X' 
indicates the number of further allowed retries
Which means I have three more attempts for the PIN1, but

> send_apdu_raw -> 0020000A
< received status word 63c0

Ahhrg, I do not have any additional attempt to verify the ADM-Key. 
Trying to verify ADM results in

> send_apdu_raw -> 0020000A083132333435363738
< received status word 6983

an ugly SW1='69' with SW2='83': Authentication method blocked.
So I can no longer verify the ADM-Key on that card.

--> Is there any way to unblock the card?

On the second card I was able to successfully verify the ADM and change 
the IMSI...

Cheers,

Flo




From nhofmeyr at sysmocom.de  Tue Dec 15 12:26:31 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 15 Dec 2015 13:26:31 +0100
Subject: FYI: gtphub merged
In-Reply-To: <566EABF5.4010405@alumni.ntnu.no>
References: <20151203105255.GB1698@dub5>
 <1608075646.11725224.1449146301692.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20151207101219.GA2387@dub5> <566EABF5.4010405@alumni.ntnu.no>
Message-ID: <20151215122631.GC13429@dub5>

On Mon, Dec 14, 2015 at 12:45:57PM +0100, Suraev wrote:
> Hi.
> 
> Could be also nice if you add couple of lines to
> http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS

Thanks for the hint! There had also been plans for an SVG to provide an
overview. Will probably follow next week or so.

~Neels

--
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151215/61030b5a/attachment.bin>

From laforge at gnumonks.org  Tue Dec 15 15:44:55 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 Dec 2015 16:44:55 +0100
Subject: PySIM: SW match failed
In-Reply-To: <1268804460.13763676.1450181081308.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <ea62d3c065a2af6fd228b0205eeaee3f@flocom.de>
 <1268804460.13763676.1450181081308.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20151215154455.GF12023@nataraja>

Hi Sipos,

On Tue, Dec 15, 2015 at 01:04:41PM +0100, Sipos Csaba wrote:
> I can confirm that the "zecke/tmp" branch is working for programming.

Great.  Now the question is if Sylvain wants to merge zecke/tmp
(basically only one small patch disabling the FCI-reading)?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Mon Dec 21 07:30:08 2015
From: holger at freyther.de (Holger Freyther)
Date: Mon, 21 Dec 2015 08:30:08 +0100
Subject: [PATCH openggsn 4/4] ggsn: add network namespace support
In-Reply-To: <1447759365-24099-5-git-send-email-aschultz@tpip.net>
References: <1447759365-24099-1-git-send-email-aschultz@tpip.net>
 <1447759365-24099-5-git-send-email-aschultz@tpip.net>
Message-ID: <E2C28DF5-056B-4023-8674-C25B9A28620C@freyther.de>


> On 17 Nov 2015, at 12:22, Andreas Schultz <aschultz at tpip.net> wrote:
> 

> + * Copyright (C) 2014, 2015 Travelping GmbH
> + *
> + * The contents of this file may be used under the terms of the GNU
> + * General Public License Version 2, provided that the above copyright
> + * notice and this permission notice is included in all copies or
> + * substantial portions of the software.

Do you think you could license this GPLv2 or later? Even if most of OpenGGSN
is currently stuck at V2 it would be nice if new code doesn't need to be replaced.


> 
> +int open_ns(int nsfd, const char *pathname, int flags)
> +{
> +	sigset_t intmask, oldmask;
> +	int fd;
> +	int errsv;
> +
> +	sigfillset(&intmask);
> +	sigprocmask(SIG_BLOCK, &intmask, &oldmask);
> +
> +	setns(nsfd, CLONE_NEWNET);
> +	fd = open(pathname, flags);
> +	errsv = errno;
> +	setns(default_nsfd, CLONE_NEWNET);
> +
> +	sigprocmask(SIG_SETMASK, &oldmask, NULL);
> +
> +	errno = errsv;
> +	return fd;


Do you want to add error handling here?


> +#ifndef __NETNS_H
> +#define __NETNS_H

__ is reserved for system headers/system code. We should not use it. #pragma once solves the
issue in a very nice way for us.




From jerlbeck at sysmocom.de  Mon Dec 21 10:26:28 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon, 21 Dec 2015 11:26:28 +0100
Subject: [PATCH 2/2] bitvec: Add comment about bit ordering
In-Reply-To: <1450693588-21461-1-git-send-email-jerlbeck@sysmocom.de>
References: <1450693588-21461-1-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <1450693588-21461-2-git-send-email-jerlbeck@sysmocom.de>

The bitvec implementation expects an MSB first encoded bitstream,
which is not mentioned anywhere explicitly.

This commits adds a comment to the bitvec header file.

Sponsored-by: On-Waves ehf
---
 include/osmocom/core/bitvec.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/osmocom/core/bitvec.h b/include/osmocom/core/bitvec.h
index 445730e..89eb784 100644
--- a/include/osmocom/core/bitvec.h
+++ b/include/osmocom/core/bitvec.h
@@ -28,6 +28,14 @@
 
 /*! \file bitvec.h
  *  \brief Osmocom bit vector abstraction
+ *
+ *  These functions assume a MSB (most significant bit) first layout of the
+ *  bits, so that for instance the 5 bit number abcde (a is MSB) can be
+ *  embedded into a byte sequence like in xxxxxxab cdexxxxx. The bit count
+ *  starts with the MSB, so the bits in a byte are numbered (MSB) 01234567 (LSB).
+ *  Note that there are other incompatible encodings, like it is used
+ *  for the EGPRS RLC data block headers (there the bits are numbered from LSB
+ *  to MSB).
  */
 
 #include <stdint.h>
-- 
1.9.1



From jerlbeck at sysmocom.de  Mon Dec 21 10:26:27 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon, 21 Dec 2015 11:26:27 +0100
Subject: [PATCH 1/2] bitvec: Add get/set byte sequences
Message-ID: <1450693588-21461-1-git-send-email-jerlbeck@sysmocom.de>

The new functions bitvec_get_bytes and bitvec_set_bytes copy
byte sequences from bitvecs to uint8_t arrays and vice versa.
While the bytes in the bitvecs do not need to be aligned, the uint8_t
arrays always are. In case the bytes in the bitvec are aligned, the
implementation uses memcpy.

Note that the implementation like the other existing functions assume
MSB first encoding.

Sponsored-by: On-Waves ehf
---
 include/osmocom/core/bitvec.h |  2 ++
 src/bitvec.c                  | 75 +++++++++++++++++++++++++++++++++++++++++++
 tests/Makefile.am             |  9 ++++--
 tests/testsuite.at            |  6 ++++
 4 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/include/osmocom/core/bitvec.h b/include/osmocom/core/bitvec.h
index 62e2e7b..445730e 100644
--- a/include/osmocom/core/bitvec.h
+++ b/include/osmocom/core/bitvec.h
@@ -63,5 +63,7 @@ int bitvec_set_uint(struct bitvec *bv, unsigned int in, int count);
 int bitvec_get_uint(struct bitvec *bv, int num_bits);
 int bitvec_find_bit_pos(const struct bitvec *bv, unsigned int n, enum bit_value val);
 int bitvec_spare_padding(struct bitvec *bv, unsigned int up_to_bit);
+int bitvec_get_bytes(struct bitvec *bv, uint8_t *bytes, int count);
+int bitvec_set_bytes(struct bitvec *bv, const uint8_t *bytes, int count);
 
 /*! @} */
diff --git a/src/bitvec.c b/src/bitvec.c
index 8da5a48..726a768 100644
--- a/src/bitvec.c
+++ b/src/bitvec.c
@@ -1,6 +1,7 @@
 /* bit vector utility routines */
 
 /* (C) 2009 by Harald Welte <laforge at gnumonks.org>
+ * (C) 2015 by Sysmocom s.f.m.c. GmbH
  *
  * All Rights Reserved
  *
@@ -30,6 +31,7 @@
 
 #include <errno.h>
 #include <stdint.h>
+#include <string.h>
 
 #include <osmocom/core/bitvec.h>
 
@@ -261,4 +263,77 @@ int bitvec_find_bit_pos(const struct bitvec *bv, unsigned int n,
 	return -1;
 }
 
+/*! \brief get multiple bytes from current pos
+ *  Assumes MSB first encoding.
+ *  \param[in] bv bit vector
+ *  \param[in] bytes array
+ *  \param[in] count number of bytes to copy
+ */
+int bitvec_get_bytes(struct bitvec *bv, uint8_t *bytes, int count)
+{
+	int byte_offs = bytenum_from_bitnum(bv->cur_bit);
+	int bit_offs = bv->cur_bit % 8;
+	uint8_t c, last_c;
+	int i;
+	uint8_t *src;
+
+	if (byte_offs + count + (bit_offs ? 1 : 0) > bv->data_len)
+		return -EINVAL;
+
+	if (bit_offs == 0) {
+		memcpy(bytes, bv->data + byte_offs, count);
+	} else {
+		src = bv->data + byte_offs;
+		last_c = *(src++);
+		for (i = count; i > 0; i--) {
+			c = *(src++);
+			*(bytes++) =
+				(last_c << bit_offs) |
+				(c >> (8 - bit_offs));
+			last_c = c;
+		}
+	}
+
+	bv->cur_bit += count * 8;
+	return 0;
+}
+
+/*! \brief set multiple bytes at current pos
+ *  Assumes MSB first encoding.
+ *  \param[in] bv bit vector
+ *  \param[in] bytes array
+ *  \param[in] count number of bytes to copy
+ */
+int bitvec_set_bytes(struct bitvec *bv, const uint8_t *bytes, int count)
+{
+	int byte_offs = bytenum_from_bitnum(bv->cur_bit);
+	int bit_offs = bv->cur_bit % 8;
+	uint8_t c, last_c;
+	int i;
+	uint8_t *dst;
+
+	if (byte_offs + count + (bit_offs ? 1 : 0) > bv->data_len)
+		return -EINVAL;
+
+	if (bit_offs == 0) {
+		memcpy(bv->data + byte_offs, bytes, count);
+	} else if (count > 0) {
+		dst = bv->data + byte_offs;
+		/* Get lower bits of first dst byte */
+		last_c = *dst >> (8 - bit_offs);
+		for (i = count; i > 0; i--) {
+			c = *(bytes++);
+			*(dst++) =
+				(last_c << (8 - bit_offs)) |
+				(c >> bit_offs);
+			last_c = c;
+		}
+		/* Overwrite lower bits of N+1 dst byte */
+		*dst = (*dst & ((1 << (8 - bit_offs)) - 1)) |
+			(last_c << (8 - bit_offs));
+	}
+
+	bv->cur_bit += count * 8;
+	return 0;
+}
 /*! @} */
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 3dc9bd9..0d220e8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -10,7 +10,8 @@ check_PROGRAMS = timer/timer_test sms/sms_test ussd/ussd_test		\
 		 kasumi/kasumi_test logging/logging_test fr/fr_test	\
 		 loggingrb/loggingrb_test strrb/strrb_test              \
 		 vty/vty_test comp128/comp128_test utils/utils_test	\
-		 smscb/gsm0341_test stats/stats_test
+		 smscb/gsm0341_test stats/stats_test			\
+		 bitvec/bitvec_test
 
 if ENABLE_MSGFILE
 check_PROGRAMS += msgfile/msgfile_test
@@ -37,6 +38,9 @@ auth_milenage_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/sr
 bits_bitrev_test_SOURCES = bits/bitrev_test.c
 bits_bitrev_test_LDADD = $(top_builddir)/src/libosmocore.la
 
+bitvec_bitvec_test_SOURCES = bitvec/bitvec_test.c
+bitvec_bitvec_test_LDADD = $(top_builddir)/src/libosmocore.la
+
 conv_conv_test_SOURCES = conv/conv_test.c
 conv_conv_test_LDADD = $(top_builddir)/src/libosmocore.la
 
@@ -124,7 +128,8 @@ EXTRA_DIST = testsuite.at $(srcdir)/package.m4 $(TESTSUITE)		\
              fr/fr_test.ok loggingrb/logging_test.ok			\
              loggingrb/logging_test.err	strrb/strrb_test.ok		\
 	     vty/vty_test.ok comp128/comp128_test.ok			\
-	     utils/utils_test.ok stats/stats_test.ok
+	     utils/utils_test.ok stats/stats_test.ok			\
+	     bitvec/bitvec_test.ok
 
 DISTCLEANFILES = atconfig
 
diff --git a/tests/testsuite.at b/tests/testsuite.at
index a542798..4a3fc0d 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -21,6 +21,12 @@ cat $abs_srcdir/bits/bitrev_test.ok > expout
 AT_CHECK([$abs_top_builddir/tests/bits/bitrev_test], [0], [expout])
 AT_CLEANUP
 
+AT_SETUP([bitvec])
+AT_KEYWORDS([bitvec])
+cat $abs_srcdir/bitvec/bitvec_test.ok > expout
+AT_CHECK([$abs_top_builddir/tests/bitvec/bitvec_test], [0], [expout], [ignore])
+AT_CLEANUP
+
 AT_SETUP([conv])
 AT_KEYWORDS([conv])
 cat $abs_srcdir/conv/conv_test.ok > expout
-- 
1.9.1



From holger at freyther.de  Mon Dec 21 13:17:59 2015
From: holger at freyther.de (Holger Freyther)
Date: Mon, 21 Dec 2015 14:17:59 +0100
Subject: [PATCH 1/3] log: Add log_check_level function
In-Reply-To: <1447757546-31341-1-git-send-email-jerlbeck@sysmocom.de>
References: <1447757546-31341-1-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <B3423ACB-C788-4935-865B-BB44894E7BA6@freyther.de>


> On 17 Nov 2015, at 11:52, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote:

Hi Jacob,

I am in favour of such a patch to prevent doing work (formatting arguments)
when it will not be used.


> 
> +		/* This might get logged (ignoring filters) */

What is the reasoning for this part?


The below does not work yet but shows the general idea. If the check routine
already finds the first target that will generate an output, then let us use it? This
is why I have put an output parameter in there and pass it a long.

The thing that is not pretty is how to print "tar" and everything that follows it,
naturally I would like to use a do {} while() loop but not roll the llist_entry by
hand (or maybe I do).

It is no look-up table but we avoid to duplicate the selection criteria and to
iterate over targets (the one or two) we already have looked at?


diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index e51487b..ed21e57 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -11,6 +11,8 @@
 #include <stdarg.h>
 #include <osmocom/core/linuxlist.h>
 
+struct log_target;
+
 /*! \brief Maximum number of logging contexts */
 #define LOG_MAX_CTX		8
 /*! \brief Maximum number of logging filters */
@@ -18,17 +20,23 @@
 
 #define DEBUG
 
+
+
 #ifdef DEBUG
 #define DEBUGP(ss, fmt, args...) \
 	do { \
-		if (log_check_level(ss, LOGL_DEBUG)) \
-			logp(ss, __FILE__, __LINE__, 0, fmt, ## args); \
+		/* potentially shadow things */	\
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, LOGL_DEBUG, &osmo_log_tgt)) \
+			logp(ss, __FILE__, __LINE__, 0, osmo_log_tgt, fmt, ## args); \
 	} while(0)
 
 #define DEBUGPC(ss, fmt, args...) \
 	do { \
-		if (log_check_level(ss, LOGL_DEBUG)) \
-			logp(ss, __FILE__, __LINE__, 1, fmt, ## args); \
+		/* potentially shadow things */	\
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, LOGL_DEBUG, &osmo_log_tgt)) \
+			logp(ss, __FILE__, __LINE__, 1, osmo_log_tgt, fmt, ## args); \
 	} while(0)
 
 #else
@@ -38,9 +46,10 @@
 
 
 void osmo_vlogp(int subsys, int level, const char *file, int line,
-		int cont, const char *format, va_list ap);
+		int cont, struct log_target *initial_target,
+		const char *format, va_list ap);
 
-void logp(int subsys, const char *file, int line, int cont, const char *format, ...) __attribute__ ((format (printf, 5, 6)));
+void logp(int subsys, const char *file, int line, int cont, struct log_target *initial_target, const char *format, ...) __attribute__ ((format (printf, 6, 7)));
 
 /*! \brief Log a new message through the Osmocom logging framework
  *  \param[in] ss logging subsystem (e.g. \ref DLGLOBAL)
@@ -50,8 +59,10 @@ void logp(int subsys, const char *file, int line, int cont, const char *format,
  */
 #define LOGP(ss, level, fmt, args...) \
 	do { \
-		if (log_check_level(ss, level)) \
-			logp2(ss, level, __FILE__, __LINE__, 0, fmt, ##args); \
+		/* potentially shadow things */	\
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, level, &osmo_log_tgt)) \
+			logp2(ss, level, __FILE__, __LINE__, 0, osmo_log_tgt, fmt, ##args); \
 	} while(0)
 
 /*! \brief Continue a log message through the Osmocom logging framework
@@ -62,8 +73,10 @@ void logp(int subsys, const char *file, int line, int cont, const char *format,
  */
 #define LOGPC(ss, level, fmt, args...) \
 	do { \
-		if (log_check_level(ss, level)) \
-			logp2(ss, level, __FILE__, __LINE__, 1, fmt, ##args); \
+		/* potentially shadow things */	\
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, level, &osmo_log_tgt)) \
+			logp2(ss, level, __FILE__, __LINE__, 1, osmo_log_tgt, fmt, ##args); \
 	} while(0)
 
 /*! \brief different log levels */
@@ -107,8 +120,6 @@ struct log_context {
 	void *ctx[LOG_MAX_CTX+1];
 };
 
-struct log_target;
-
 /*! \brief Log filter function */
 typedef int log_filter(const struct log_context *ctx,
 		       struct log_target *target);
@@ -211,10 +222,11 @@ struct log_target {
 
 /* use the above macros */
 void logp2(int subsys, unsigned int level, const char *file,
-	   int line, int cont, const char *format, ...)
-				__attribute__ ((format (printf, 6, 7)));
+	   int line, int cont, struct log_target *iniial_target,
+	   const char *format, ...)
+				__attribute__ ((format (printf, 7, 8)));
 int log_init(const struct log_info *inf, void *talloc_ctx);
-int log_check_level(int subsys, unsigned int level);
+int log_check_level(int subsys, unsigned int level, struct log_target **out_tar);
 
 /* context management */
 void log_reset_context(void);
diff --git a/src/logging.c b/src/logging.c
index c7b1999..952b52e 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -310,35 +310,64 @@ err:
 	target->output(target, level, buf);
 }
 
-/*! \brief vararg version of logging function */
-void osmo_vlogp(int subsys, int level, const char *file, int line,
-		int cont, const char *format, va_list ap)
+static inline int map_subsys(int subsys)
 {
-	struct log_target *tar;
-
 	if (subsys < 0)
 		subsys = subsys_lib2index(subsys);
 
 	if (subsys > osmo_log_info->num_cat)
 		subsys = DLGLOBAL;
+	return subsys;
+}
 
-	llist_for_each_entry(tar, &osmo_log_target_list, entry) {
-		struct log_category *category;
-		int output = 0;
-		va_list bp;
+static inline int check_log_to_target(struct log_target *tar, int subsys, int level)
+{
+	struct log_category *category;
 
-		category = &tar->categories[subsys];
-		/* subsystem is not supposed to be logged */
-		if (!category->enabled)
-			continue;
+	category = &tar->categories[subsys];
 
-		/* Check the global log level */
-		if (tar->loglevel != 0 && level < tar->loglevel)
-			continue;
+	/* subsystem is not supposed to be logged */
+	if (!category->enabled)
+		return 0;
 
-		/* Check the category log level */
-		if (tar->loglevel == 0 && category->loglevel != 0 &&
-		    level < category->loglevel)
+	/* Check the global log level */
+	if (tar->loglevel != 0 && level < tar->loglevel)
+		return 0;
+
+	/* Check the category log level */
+	if (tar->loglevel == 0 && category->loglevel != 0 &&
+	    level < category->loglevel)
+		return 0;
+
+	/* TODO: Check the filter/selector too? */
+	return 1;
+}
+
+/*! \brief vararg version of logging function */
+void osmo_vlogp(int subsys, int level, const char *file, int line,
+		int cont, struct log_target *ini_tar, const char *format, va_list ap)
+{
+	struct log_target *tar = ini_tar;
+
+	subsys = map_subsys(subsys);
+
+
+	if ((tar->filter_map & LOG_FILTER_ALL) == 0
+		|| (osmo_log_info->filter_fn && osmo_log_info->filter_fn(&log_context, tar))) {
+		va_list bp;
+		/* According to the manpage, vsnprintf leaves the value of ap
+		 * in undefined state. Since _output uses vsnprintf and it may
+		 * be called several times, we have to pass a copy of ap. */
+		va_copy(bp, ap);
+		_output(tar, subsys, level, file, line, cont, format, bp);
+		va_end(bp);
+	}
+
+	llist_for_each_entry_continue(tar, &osmo_log_target_list, entry) {
+		int output = 0;
+		va_list bp;
+
+		if (!check_log_to_target(tar, subsys, level))
 			continue;
 
 		/* Apply filters here... if that becomes messy we will
@@ -363,22 +392,23 @@ void osmo_vlogp(int subsys, int level, const char *file, int line,
 
 /*! \brief logging function used by DEBUGP() macro */
 void logp(int subsys, const char *file, int line, int cont,
-	  const char *format, ...)
+	  struct log_target *ini_tar, const char *format, ...)
 {
 	va_list ap;
 
 	va_start(ap, format);
-	osmo_vlogp(subsys, LOGL_DEBUG, file, line, cont, format, ap);
+	osmo_vlogp(subsys, LOGL_DEBUG, file, line, cont, ini_tar, format, ap);
 	va_end(ap);
 }
 
 /*! \brief logging function used by LOGP() macro */
-void logp2(int subsys, unsigned int level, const char *file, int line, int cont, const char *format, ...)
+void logp2(int subsys, unsigned int level, const char *file, int line, int cont,
+		struct log_target *ini_tar, const char *format, ...)
 {
 	va_list ap;
 
 	va_start(ap, format);
-	osmo_vlogp(subsys, level, file, line, cont, format, ap);
+	osmo_vlogp(subsys, level, file, line, cont, ini_tar, format, ap);
 	va_end(ap);
 }
 
@@ -867,40 +897,26 @@ int log_init(const struct log_info *inf, void *ctx)
 
 /*! \brief Check whether a log entry will be generated.
  *  \returns != 0 if a log entry might get generated by at least one target */
-int log_check_level(int subsys, unsigned int level)
+int log_check_level(int subsys, unsigned int level, struct log_target **out_tar)
 {
 	struct log_target *tar;
 
-	if (subsys < 0)
-		subsys = subsys_lib2index(subsys);
-
-	if (subsys > osmo_log_info->num_cat)
-		subsys = DLGLOBAL;
+	subsys = map_subsys(subsys);
 
 	/* TODO: The following could/should be cached (update on config) */
 
 	llist_for_each_entry(tar, &osmo_log_target_list, entry) {
-		struct log_category *category;
-
-		category = &tar->categories[subsys];
-		/* subsystem is not supposed to be logged */
-		if (!category->enabled)
-			continue;
-
-		/* Check the global log level */
-		if (tar->loglevel != 0 && level < tar->loglevel)
-			continue;
-
-		/* Check the category log level */
-		if (tar->loglevel == 0 && category->loglevel != 0 &&
-		    level < category->loglevel)
+		if (!check_log_to_target(tar, subsys, level))
 			continue;
 
 		/* This might get logged (ignoring filters) */
+		/* HHPF: Why? */
+		*out_tar = tar;
 		return 1;
 	}
 
 	/* We are sure, that this will not be logged. */
+	*out_tar = NULL;
 	return 0;
 }
 
diff --git a/tests/logging/logging_test.c b/tests/logging/logging_test.c
index 3c8bac4..7d0ba6b 100644
--- a/tests/logging/logging_test.c
+++ b/tests/logging/logging_test.c
@@ -68,6 +68,7 @@ const struct log_info log_info = {
 int main(int argc, char **argv)
 {
 	struct log_target *stderr_target;
+	struct log_target *select_target;
 
 	log_init(&log_info, NULL);
 	stderr_target = log_target_create_stderr();
@@ -78,24 +79,31 @@ int main(int argc, char **argv)
 	log_parse_category_mask(stderr_target, "DRLL:DCC");
 	log_parse_category_mask(stderr_target, "DRLL");
 	DEBUGP(DCC, "You should not see this\n");
-	if (log_check_level(DMM, LOGL_DEBUG) != 0)
+	if (log_check_level(DMM, LOGL_DEBUG, &select_target) != 0)
 		fprintf(stderr, "log_check_level did not catch this case\n");
+	OSMO_ASSERT(select_target == stderr_target);
 
 	log_parse_category_mask(stderr_target, "DRLL:DCC");
 	DEBUGP(DRLL, "You should see this\n");
-	OSMO_ASSERT(log_check_level(DRLL, LOGL_DEBUG) != 0);
+	select_target = NULL;
+	OSMO_ASSERT(log_check_level(DRLL, LOGL_DEBUG, &select_target) != 0);
+	OSMO_ASSERT(select_target == stderr_target);
 	DEBUGP(DCC, "You should see this\n");
-	OSMO_ASSERT(log_check_level(DCC, LOGL_DEBUG) != 0);
+	select_target = NULL;
+	OSMO_ASSERT(log_check_level(DCC, LOGL_DEBUG, &select_target) != 0);
+	OSMO_ASSERT(select_target == stderr_target);
 	DEBUGP(DMM, "You should not see this\n");
-	if (log_check_level(DMM, LOGL_DEBUG) != 0)
+	select_target = NULL;
+	if (log_check_level(DMM, LOGL_DEBUG, &select_target) != 0)
 		fprintf(stderr, "log_check_level did not catch this case\n");
+	OSMO_ASSERT(select_target == stderr_target);
 
 	OSMO_ASSERT(filter_called == 0);
 
 	log_set_all_filter(stderr_target, 0);
 	DEBUGP(DRLL, "You should not see this and filter is called\n");
 	OSMO_ASSERT(filter_called == 1);
-	if (log_check_level(DRLL, LOGL_DEBUG) != 0)
+	if (log_check_level(DRLL, LOGL_DEBUG, &select_target) != 0)
 		fprintf(stderr,
 			"log_check_level did not catch this case (filter)\n");
 




From jerlbeck at sysmocom.de  Mon Dec 21 14:13:31 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon, 21 Dec 2015 15:13:31 +0100
Subject: [PATCH 1/3] log: Add log_check_level function
In-Reply-To: <B3423ACB-C788-4935-865B-BB44894E7BA6@freyther.de>
References: <1447757546-31341-1-git-send-email-jerlbeck@sysmocom.de>
 <B3423ACB-C788-4935-865B-BB44894E7BA6@freyther.de>
Message-ID: <5678090B.5060805@sysmocom.de>

Hi Holger,

On 21.12.2015 14:17, Holger Freyther wrote:
> 
>> On 17 Nov 2015, at 11:52, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote:

>> +		/* This might get logged (ignoring filters) */
> 
> What is the reasoning for this part?

I wanted to have a weaker criterion than 'return true if and only if
something would be logged' to be more flexible when it comes to
optimization. I had lookup tables in mind which cache the max level per
facility, and which get updated when e.g. log_set_log_level is called.
This would be O(1) consuming just a few CPU cycles per log, but would
not help when filtering is used.

And I didn't really understand filters when I wrote that commit.
Including them into the log_check_level decision definitely makes sense
if I want to use log DEBUG level stuff on an embedded or high load system.


> 
> 
> The below does not work yet but shows the general idea. If the check routine
> already finds the first target that will generate an output, then let us use it? This
> is why I have put an output parameter in there and pass it a long.
> 

Reusing the target pointer for logging seems like a nice feature, but it
bloats the API and only gains anything, if something gets actually
logged which is probably much more expensive than rescanning the
probably very few targets that came in front and are in the CPU cache
already anyway. So I wouldn't do that optimization unless profiling
would tell me to do so.

I thought of using log_check_level explicitly in user code, too. E.g. if
a log statement would require some preparation that can be done at
argument position. That gets a little clumsy with that additional parameter.

I did some profiling with the CPU and the current log_check_level was
way below the few remaining calls to logp.



> The thing that is not pretty is how to print "tar" and everything that follows it,
> naturally I would like to use a do {} while() loop but not roll the llist_entry by
> hand (or maybe I do).
> 
> It is no look-up table but we avoid to duplicate the selection criteria and to
> iterate over targets (the one or two) we already have looked at?

I guess that a) not ignoring the filter and b) doing a O(1) pre-check
(possibly inlined) will gain us more.


Jacob

-- 
- Jacob Erlbeck <jerlbeck at 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 Directors: Holger Freyther, Harald Welte


From holger at freyther.de  Mon Dec 21 14:39:39 2015
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 21 Dec 2015 15:39:39 +0100
Subject: [PATCH 1/2] logging: Remove some code duplication
Message-ID: <1450708780-9785-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at moiji-mobile.com>

Extract the mapping of the subsystem number and the checking for
the loglevel to a inline method that is shared between the new
and old.
---
 src/logging.c | 74 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/src/logging.c b/src/logging.c
index c7b1999..7db7101 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -310,35 +310,52 @@ err:
 	target->output(target, level, buf);
 }
 
-/*! \brief vararg version of logging function */
-void osmo_vlogp(int subsys, int level, const char *file, int line,
-		int cont, const char *format, va_list ap)
+static inline int map_subsys(int subsys)
 {
-	struct log_target *tar;
-
 	if (subsys < 0)
 		subsys = subsys_lib2index(subsys);
 
 	if (subsys > osmo_log_info->num_cat)
 		subsys = DLGLOBAL;
+	return subsys;
+}
+
+static inline int check_log_to_target(struct log_target *tar, int subsys, int level)
+{
+	struct log_category *category;
+
+	category = &tar->categories[subsys];
+
+	/* subsystem is not supposed to be logged */
+	if (!category->enabled)
+		return 0;
+
+	/* Check the global log level */
+	if (tar->loglevel != 0 && level < tar->loglevel)
+		return 0;
+
+	/* Check the category log level */
+	if (tar->loglevel == 0 && category->loglevel != 0 &&
+	    level < category->loglevel)
+		return 0;
+
+	/* TODO: Check the filter/selector too? */
+	return 1;
+}
+
+/*! \brief vararg version of logging function */
+void osmo_vlogp(int subsys, int level, const char *file, int line,
+		int cont, const char *format, va_list ap)
+{
+	struct log_target *tar;
+
+	subsys = map_subsys(subsys);
 
 	llist_for_each_entry(tar, &osmo_log_target_list, entry) {
-		struct log_category *category;
 		int output = 0;
 		va_list bp;
 
-		category = &tar->categories[subsys];
-		/* subsystem is not supposed to be logged */
-		if (!category->enabled)
-			continue;
-
-		/* Check the global log level */
-		if (tar->loglevel != 0 && level < tar->loglevel)
-			continue;
-
-		/* Check the category log level */
-		if (tar->loglevel == 0 && category->loglevel != 0 &&
-		    level < category->loglevel)
+		if (!check_log_to_target(tar, subsys, level))
 			continue;
 
 		/* Apply filters here... if that becomes messy we will
@@ -871,29 +888,12 @@ int log_check_level(int subsys, unsigned int level)
 {
 	struct log_target *tar;
 
-	if (subsys < 0)
-		subsys = subsys_lib2index(subsys);
-
-	if (subsys > osmo_log_info->num_cat)
-		subsys = DLGLOBAL;
+	subsys = map_subsys(subsys);
 
 	/* TODO: The following could/should be cached (update on config) */
 
 	llist_for_each_entry(tar, &osmo_log_target_list, entry) {
-		struct log_category *category;
-
-		category = &tar->categories[subsys];
-		/* subsystem is not supposed to be logged */
-		if (!category->enabled)
-			continue;
-
-		/* Check the global log level */
-		if (tar->loglevel != 0 && level < tar->loglevel)
-			continue;
-
-		/* Check the category log level */
-		if (tar->loglevel == 0 && category->loglevel != 0 &&
-		    level < category->loglevel)
+		if (!check_log_to_target(tar, subsys, level))
 			continue;
 
 		/* This might get logged (ignoring filters) */
-- 
2.6.3



From holger at freyther.de  Mon Dec 21 14:39:40 2015
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 21 Dec 2015 15:39:40 +0100
Subject: [PATCH 2/2] logging: Remember the target we found
In-Reply-To: <1450708780-9785-1-git-send-email-holger@freyther.de>
References: <1450708780-9785-1-git-send-email-holger@freyther.de>
Message-ID: <1450708780-9785-2-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at moiji-mobile.com>

log_check_level and osmo_vlogp share the responsibility for the
output of a log message. Once check_level has identified the first
target that might have an output osmo_vlogp will continue from this
place.

In practice we have one (stderr/syslog) or two (stderr+VTY) log
outputs so avoiding to re-iterate is not that important but as
we have found the right place we can just use it.
---
 include/osmocom/core/logging.h | 38 +++++++++++++++++++++++---------------
 src/logging.c                  | 21 ++++++++++++---------
 tests/logging/logging_test.c   | 18 +++++++++++++-----
 3 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index e51487b..3f58ddb 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -11,6 +11,8 @@
 #include <stdarg.h>
 #include <osmocom/core/linuxlist.h>
 
+struct log_target;
+
 /*! \brief Maximum number of logging contexts */
 #define LOG_MAX_CTX		8
 /*! \brief Maximum number of logging filters */
@@ -18,17 +20,21 @@
 
 #define DEBUG
 
+
+
 #ifdef DEBUG
 #define DEBUGP(ss, fmt, args...) \
 	do { \
-		if (log_check_level(ss, LOGL_DEBUG)) \
-			logp(ss, __FILE__, __LINE__, 0, fmt, ## args); \
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, LOGL_DEBUG, &osmo_log_tgt)) \
+			logp(ss, __FILE__, __LINE__, 0, osmo_log_tgt, fmt, ## args); \
 	} while(0)
 
 #define DEBUGPC(ss, fmt, args...) \
 	do { \
-		if (log_check_level(ss, LOGL_DEBUG)) \
-			logp(ss, __FILE__, __LINE__, 1, fmt, ## args); \
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, LOGL_DEBUG, &osmo_log_tgt)) \
+			logp(ss, __FILE__, __LINE__, 1, osmo_log_tgt, fmt, ## args); \
 	} while(0)
 
 #else
@@ -38,9 +44,10 @@
 
 
 void osmo_vlogp(int subsys, int level, const char *file, int line,
-		int cont, const char *format, va_list ap);
+		int cont, struct log_target *initial_target,
+		const char *format, va_list ap);
 
-void logp(int subsys, const char *file, int line, int cont, const char *format, ...) __attribute__ ((format (printf, 5, 6)));
+void logp(int subsys, const char *file, int line, int cont, struct log_target *initial_target, const char *format, ...) __attribute__ ((format (printf, 6, 7)));
 
 /*! \brief Log a new message through the Osmocom logging framework
  *  \param[in] ss logging subsystem (e.g. \ref DLGLOBAL)
@@ -50,8 +57,9 @@ void logp(int subsys, const char *file, int line, int cont, const char *format,
  */
 #define LOGP(ss, level, fmt, args...) \
 	do { \
-		if (log_check_level(ss, level)) \
-			logp2(ss, level, __FILE__, __LINE__, 0, fmt, ##args); \
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, level, &osmo_log_tgt)) \
+			logp2(ss, level, __FILE__, __LINE__, 0, osmo_log_tgt, fmt, ##args); \
 	} while(0)
 
 /*! \brief Continue a log message through the Osmocom logging framework
@@ -62,8 +70,9 @@ void logp(int subsys, const char *file, int line, int cont, const char *format,
  */
 #define LOGPC(ss, level, fmt, args...) \
 	do { \
-		if (log_check_level(ss, level)) \
-			logp2(ss, level, __FILE__, __LINE__, 1, fmt, ##args); \
+		struct log_target *osmo_log_tgt; \
+		if (log_check_level(ss, level, &osmo_log_tgt)) \
+			logp2(ss, level, __FILE__, __LINE__, 1, osmo_log_tgt, fmt, ##args); \
 	} while(0)
 
 /*! \brief different log levels */
@@ -107,8 +116,6 @@ struct log_context {
 	void *ctx[LOG_MAX_CTX+1];
 };
 
-struct log_target;
-
 /*! \brief Log filter function */
 typedef int log_filter(const struct log_context *ctx,
 		       struct log_target *target);
@@ -211,10 +218,11 @@ struct log_target {
 
 /* use the above macros */
 void logp2(int subsys, unsigned int level, const char *file,
-	   int line, int cont, const char *format, ...)
-				__attribute__ ((format (printf, 6, 7)));
+	   int line, int cont, struct log_target *iniial_target,
+	   const char *format, ...)
+				__attribute__ ((format (printf, 7, 8)));
 int log_init(const struct log_info *inf, void *talloc_ctx);
-int log_check_level(int subsys, unsigned int level);
+int log_check_level(int subsys, unsigned int level, struct log_target **out_tar);
 
 /* context management */
 void log_reset_context(void);
diff --git a/src/logging.c b/src/logging.c
index 7db7101..c8a16f8 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -345,13 +345,13 @@ static inline int check_log_to_target(struct log_target *tar, int subsys, int le
 
 /*! \brief vararg version of logging function */
 void osmo_vlogp(int subsys, int level, const char *file, int line,
-		int cont, const char *format, va_list ap)
+		int cont, struct log_target *ini_tar, const char *format, va_list ap)
 {
-	struct log_target *tar;
+	struct log_target *tar = ini_tar;
 
 	subsys = map_subsys(subsys);
 
-	llist_for_each_entry(tar, &osmo_log_target_list, entry) {
+	do {
 		int output = 0;
 		va_list bp;
 
@@ -375,27 +375,28 @@ void osmo_vlogp(int subsys, int level, const char *file, int line,
 		va_copy(bp, ap);
 		_output(tar, subsys, level, file, line, cont, format, bp);
 		va_end(bp);
-	}
+	} while (tar->entry.next != &osmo_log_target_list && (tar = llist_entry(tar->entry.next, typeof(*tar), entry)));
 }
 
 /*! \brief logging function used by DEBUGP() macro */
 void logp(int subsys, const char *file, int line, int cont,
-	  const char *format, ...)
+	  struct log_target *ini_tar, const char *format, ...)
 {
 	va_list ap;
 
 	va_start(ap, format);
-	osmo_vlogp(subsys, LOGL_DEBUG, file, line, cont, format, ap);
+	osmo_vlogp(subsys, LOGL_DEBUG, file, line, cont, ini_tar, format, ap);
 	va_end(ap);
 }
 
 /*! \brief logging function used by LOGP() macro */
-void logp2(int subsys, unsigned int level, const char *file, int line, int cont, const char *format, ...)
+void logp2(int subsys, unsigned int level, const char *file, int line, int cont,
+		struct log_target *ini_tar, const char *format, ...)
 {
 	va_list ap;
 
 	va_start(ap, format);
-	osmo_vlogp(subsys, level, file, line, cont, format, ap);
+	osmo_vlogp(subsys, level, file, line, cont, ini_tar, format, ap);
 	va_end(ap);
 }
 
@@ -884,7 +885,7 @@ int log_init(const struct log_info *inf, void *ctx)
 
 /*! \brief Check whether a log entry will be generated.
  *  \returns != 0 if a log entry might get generated by at least one target */
-int log_check_level(int subsys, unsigned int level)
+int log_check_level(int subsys, unsigned int level, struct log_target **out_tar)
 {
 	struct log_target *tar;
 
@@ -897,10 +898,12 @@ int log_check_level(int subsys, unsigned int level)
 			continue;
 
 		/* This might get logged (ignoring filters) */
+		*out_tar = tar;
 		return 1;
 	}
 
 	/* We are sure, that this will not be logged. */
+	*out_tar = NULL;
 	return 0;
 }
 
diff --git a/tests/logging/logging_test.c b/tests/logging/logging_test.c
index 3c8bac4..023a526 100644
--- a/tests/logging/logging_test.c
+++ b/tests/logging/logging_test.c
@@ -68,6 +68,7 @@ const struct log_info log_info = {
 int main(int argc, char **argv)
 {
 	struct log_target *stderr_target;
+	struct log_target *select_target;
 
 	log_init(&log_info, NULL);
 	stderr_target = log_target_create_stderr();
@@ -78,24 +79,31 @@ int main(int argc, char **argv)
 	log_parse_category_mask(stderr_target, "DRLL:DCC");
 	log_parse_category_mask(stderr_target, "DRLL");
 	DEBUGP(DCC, "You should not see this\n");
-	if (log_check_level(DMM, LOGL_DEBUG) != 0)
+	if (log_check_level(DMM, LOGL_DEBUG, &select_target) != 0)
 		fprintf(stderr, "log_check_level did not catch this case\n");
+	OSMO_ASSERT(select_target == NULL);
 
 	log_parse_category_mask(stderr_target, "DRLL:DCC");
 	DEBUGP(DRLL, "You should see this\n");
-	OSMO_ASSERT(log_check_level(DRLL, LOGL_DEBUG) != 0);
+	select_target = NULL;
+	OSMO_ASSERT(log_check_level(DRLL, LOGL_DEBUG, &select_target) != 0);
+	OSMO_ASSERT(select_target == stderr_target);
 	DEBUGP(DCC, "You should see this\n");
-	OSMO_ASSERT(log_check_level(DCC, LOGL_DEBUG) != 0);
+	select_target = NULL;
+	OSMO_ASSERT(log_check_level(DCC, LOGL_DEBUG, &select_target) != 0);
+	OSMO_ASSERT(select_target == stderr_target);
 	DEBUGP(DMM, "You should not see this\n");
-	if (log_check_level(DMM, LOGL_DEBUG) != 0)
+	select_target = NULL;
+	if (log_check_level(DMM, LOGL_DEBUG, &select_target) != 0)
 		fprintf(stderr, "log_check_level did not catch this case\n");
+	OSMO_ASSERT(select_target == NULL);
 
 	OSMO_ASSERT(filter_called == 0);
 
 	log_set_all_filter(stderr_target, 0);
 	DEBUGP(DRLL, "You should not see this and filter is called\n");
 	OSMO_ASSERT(filter_called == 1);
-	if (log_check_level(DRLL, LOGL_DEBUG) != 0)
+	if (log_check_level(DRLL, LOGL_DEBUG, &select_target) != 0)
 		fprintf(stderr,
 			"log_check_level did not catch this case (filter)\n");
 
-- 
2.6.3



From holger at freyther.de  Mon Dec 21 14:52:48 2015
From: holger at freyther.de (Holger Freyther)
Date: Mon, 21 Dec 2015 15:52:48 +0100
Subject: [PATCH 1/3] log: Add log_check_level function
In-Reply-To: <5678090B.5060805@sysmocom.de>
References: <1447757546-31341-1-git-send-email-jerlbeck@sysmocom.de>
 <B3423ACB-C788-4935-865B-BB44894E7BA6@freyther.de>
 <5678090B.5060805@sysmocom.de>
Message-ID: <0B6768C7-B56F-487E-ACEF-7B969F013ED3@freyther.de>


> On 21 Dec 2015, at 15:13, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote:
> 
> Hi Holger,
> 
> On 21.12.2015 14:17, Holger Freyther wrote:
>> 
>>> On 17 Nov 2015, at 11:52, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote:
> 
>>> +		/* This might get logged (ignoring filters) */
>> 
>> What is the reasoning for this part?
> 
> I wanted to have a weaker criterion than 'return true if and only if
> something would be logged' to be more flexible when it comes to
> optimization. I had lookup tables in mind which cache the max level per
> facility, and which get updated when e.g. log_set_log_level is called.
> This would be O(1) consuming just a few CPU cycles per log, but would
> not help when filtering is used.
> 
> And I didn't really understand filters when I wrote that commit.
> Including them into the log_check_level decision definitely makes sense
> if I want to use log DEBUG level stuff on an embedded or high load system.

Okay maybe I am missing a case here but it feels like we don't save anything
by not calling it. So if the log level is good for output we return 1 and then do
the full work. It doesn't really matter which function we do this work in.

And as this doesn't matter we can leave it out. I posted a patch that removes
the selection criteria and subsys code clone.



>> The below does not work yet but shows the general idea. If the check routine
>> already finds the first target that will generate an output, then let us use it? This
>> is why I have put an output parameter in there and pass it a long.
>> 
> 
> Reusing the target pointer for logging seems like a nice feature, but it
> bloats the API and only gains anything, if something gets actually
> logged which is probably much more expensive than rescanning the
> probably very few targets that came in front and are in the CPU cache
> already anyway. So I wouldn't do that optimization unless profiling
> would tell me to do so.

I consider LOGP, LOGPC, DEBUGP, DEBUGPC as the API. I don't think we have
any direct callers of osmo_vlogp, logp, logp2. The change to start from the target
that has been found is trivial and if we can avoid doing work without increasing the
memory usage then we should do it.

We do not have a libsomocore.map but if we do I would not export logp, logp2,
osmo_vlogp and the log_check_level functions.


> I thought of using log_check_level explicitly in user code, too. E.g. if
> a log statement would require some preparation that can be done at
> argument position. That gets a little clumsy with that additional parameter.
> 
> I did some profiling with the CPU and the current log_check_level was
> way below the few remaining calls to logp.
> 
> 
> 
>> The thing that is not pretty is how to print "tar" and everything that follows it,
>> naturally I would like to use a do {} while() loop but not roll the llist_entry by
>> hand (or maybe I do).
>> 
>> It is no look-up table but we avoid to duplicate the selection criteria and to
>> iterate over targets (the one or two) we already have looked at?
> 
> I guess that a) not ignoring the filter and b) doing a O(1) pre-check
> (possibly inlined) will gain us more.

I don't think we want to inline all pre-checks (list traversal). Your patch helps
to avoid calling osmo_hexdump, gsm_lchan_name and others. I remove the
code clones and continue (yeah redo the integer compares and a load) from
where log_check_level stopped. It is a sound approach.

cheers
	holger



From jerlbeck at sysmocom.de  Mon Dec 21 15:04:03 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon, 21 Dec 2015 16:04:03 +0100
Subject: [PATCH] bitvec: Add get/set byte sequences
In-Reply-To: <1450693588-21461-1-git-send-email-jerlbeck@sysmocom.de>
References: <1450693588-21461-1-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <1450710243-30050-1-git-send-email-jerlbeck@sysmocom.de>

The new functions bitvec_get_bytes and bitvec_set_bytes copy
byte sequences from bitvecs to uint8_t arrays and vice versa.
While the bytes in the bitvecs do not need to be aligned, the uint8_t
arrays always are. In case the bytes in the bitvec are aligned, the
implementation uses memcpy.

Note that the implementation like the other existing functions assume
MSB first encoding.

Sponsored-by: On-Waves ehf
---
 include/osmocom/core/bitvec.h |  2 ++
 src/bitvec.c                  | 75 +++++++++++++++++++++++++++++++++++++++++++
 tests/Makefile.am             |  9 ++++--
 tests/bitvec/bitvec_test.c    | 62 +++++++++++++++++++++++++++++++++++
 tests/bitvec/bitvec_test.ok   |  2 ++
 tests/testsuite.at            |  6 ++++
 6 files changed, 154 insertions(+), 2 deletions(-)
 create mode 100644 tests/bitvec/bitvec_test.c
 create mode 100644 tests/bitvec/bitvec_test.ok

diff --git a/include/osmocom/core/bitvec.h b/include/osmocom/core/bitvec.h
index 62e2e7b..445730e 100644
--- a/include/osmocom/core/bitvec.h
+++ b/include/osmocom/core/bitvec.h
@@ -63,5 +63,7 @@ int bitvec_set_uint(struct bitvec *bv, unsigned int in, int count);
 int bitvec_get_uint(struct bitvec *bv, int num_bits);
 int bitvec_find_bit_pos(const struct bitvec *bv, unsigned int n, enum bit_value val);
 int bitvec_spare_padding(struct bitvec *bv, unsigned int up_to_bit);
+int bitvec_get_bytes(struct bitvec *bv, uint8_t *bytes, int count);
+int bitvec_set_bytes(struct bitvec *bv, const uint8_t *bytes, int count);
 
 /*! @} */
diff --git a/src/bitvec.c b/src/bitvec.c
index 8da5a48..726a768 100644
--- a/src/bitvec.c
+++ b/src/bitvec.c
@@ -1,6 +1,7 @@
 /* bit vector utility routines */
 
 /* (C) 2009 by Harald Welte <laforge at gnumonks.org>
+ * (C) 2015 by Sysmocom s.f.m.c. GmbH
  *
  * All Rights Reserved
  *
@@ -30,6 +31,7 @@
 
 #include <errno.h>
 #include <stdint.h>
+#include <string.h>
 
 #include <osmocom/core/bitvec.h>
 
@@ -261,4 +263,77 @@ int bitvec_find_bit_pos(const struct bitvec *bv, unsigned int n,
 	return -1;
 }
 
+/*! \brief get multiple bytes from current pos
+ *  Assumes MSB first encoding.
+ *  \param[in] bv bit vector
+ *  \param[in] bytes array
+ *  \param[in] count number of bytes to copy
+ */
+int bitvec_get_bytes(struct bitvec *bv, uint8_t *bytes, int count)
+{
+	int byte_offs = bytenum_from_bitnum(bv->cur_bit);
+	int bit_offs = bv->cur_bit % 8;
+	uint8_t c, last_c;
+	int i;
+	uint8_t *src;
+
+	if (byte_offs + count + (bit_offs ? 1 : 0) > bv->data_len)
+		return -EINVAL;
+
+	if (bit_offs == 0) {
+		memcpy(bytes, bv->data + byte_offs, count);
+	} else {
+		src = bv->data + byte_offs;
+		last_c = *(src++);
+		for (i = count; i > 0; i--) {
+			c = *(src++);
+			*(bytes++) =
+				(last_c << bit_offs) |
+				(c >> (8 - bit_offs));
+			last_c = c;
+		}
+	}
+
+	bv->cur_bit += count * 8;
+	return 0;
+}
+
+/*! \brief set multiple bytes at current pos
+ *  Assumes MSB first encoding.
+ *  \param[in] bv bit vector
+ *  \param[in] bytes array
+ *  \param[in] count number of bytes to copy
+ */
+int bitvec_set_bytes(struct bitvec *bv, const uint8_t *bytes, int count)
+{
+	int byte_offs = bytenum_from_bitnum(bv->cur_bit);
+	int bit_offs = bv->cur_bit % 8;
+	uint8_t c, last_c;
+	int i;
+	uint8_t *dst;
+
+	if (byte_offs + count + (bit_offs ? 1 : 0) > bv->data_len)
+		return -EINVAL;
+
+	if (bit_offs == 0) {
+		memcpy(bv->data + byte_offs, bytes, count);
+	} else if (count > 0) {
+		dst = bv->data + byte_offs;
+		/* Get lower bits of first dst byte */
+		last_c = *dst >> (8 - bit_offs);
+		for (i = count; i > 0; i--) {
+			c = *(bytes++);
+			*(dst++) =
+				(last_c << (8 - bit_offs)) |
+				(c >> bit_offs);
+			last_c = c;
+		}
+		/* Overwrite lower bits of N+1 dst byte */
+		*dst = (*dst & ((1 << (8 - bit_offs)) - 1)) |
+			(last_c << (8 - bit_offs));
+	}
+
+	bv->cur_bit += count * 8;
+	return 0;
+}
 /*! @} */
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 3dc9bd9..0d220e8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -10,7 +10,8 @@ check_PROGRAMS = timer/timer_test sms/sms_test ussd/ussd_test		\
 		 kasumi/kasumi_test logging/logging_test fr/fr_test	\
 		 loggingrb/loggingrb_test strrb/strrb_test              \
 		 vty/vty_test comp128/comp128_test utils/utils_test	\
-		 smscb/gsm0341_test stats/stats_test
+		 smscb/gsm0341_test stats/stats_test			\
+		 bitvec/bitvec_test
 
 if ENABLE_MSGFILE
 check_PROGRAMS += msgfile/msgfile_test
@@ -37,6 +38,9 @@ auth_milenage_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/sr
 bits_bitrev_test_SOURCES = bits/bitrev_test.c
 bits_bitrev_test_LDADD = $(top_builddir)/src/libosmocore.la
 
+bitvec_bitvec_test_SOURCES = bitvec/bitvec_test.c
+bitvec_bitvec_test_LDADD = $(top_builddir)/src/libosmocore.la
+
 conv_conv_test_SOURCES = conv/conv_test.c
 conv_conv_test_LDADD = $(top_builddir)/src/libosmocore.la
 
@@ -124,7 +128,8 @@ EXTRA_DIST = testsuite.at $(srcdir)/package.m4 $(TESTSUITE)		\
              fr/fr_test.ok loggingrb/logging_test.ok			\
              loggingrb/logging_test.err	strrb/strrb_test.ok		\
 	     vty/vty_test.ok comp128/comp128_test.ok			\
-	     utils/utils_test.ok stats/stats_test.ok
+	     utils/utils_test.ok stats/stats_test.ok			\
+	     bitvec/bitvec_test.ok
 
 DISTCLEANFILES = atconfig
 
diff --git a/tests/bitvec/bitvec_test.c b/tests/bitvec/bitvec_test.c
new file mode 100644
index 0000000..624e334
--- /dev/null
+++ b/tests/bitvec/bitvec_test.c
@@ -0,0 +1,62 @@
+#include <inttypes.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+
+#include <osmocom/core/utils.h>
+#include <osmocom/core/bitvec.h>
+
+static void test_byte_ops()
+{
+	struct bitvec bv;
+	const uint8_t *in = (const uint8_t *)"ABCDEFGHIJKLMNOPQRSTUVWXYZ";
+	uint8_t out[26 + 2];
+	uint8_t data[64];
+	int i;
+	int rc;
+	int in_size = strlen((const char *)in);
+
+	printf("=== start %s ===\n", __func__);
+
+	bv.data = data;
+	bv.data_len = sizeof(data);
+
+	for (i = 0; i < 32; i++) {
+		/* Write to bitvec */
+		memset(data, 0x00, sizeof(data));
+		bv.cur_bit = i;
+		rc = bitvec_set_uint(&bv, 0x7e, 8);
+		OSMO_ASSERT(rc >= 0);
+		rc = bitvec_set_bytes(&bv, in, in_size);
+		OSMO_ASSERT(rc >= 0);
+		rc = bitvec_set_uint(&bv, 0x7e, 8);
+		OSMO_ASSERT(rc >= 0);
+
+		fprintf(stderr, "bitvec: %s\n", osmo_hexdump(bv.data, bv.data_len));
+
+		/* Read from bitvec */
+		memset(out, 0xff, sizeof(out));
+		bv.cur_bit = i;
+		rc = bitvec_get_uint(&bv, 8);
+		OSMO_ASSERT(rc == 0x7e);
+		rc = bitvec_get_bytes(&bv, out + 1, in_size);
+		OSMO_ASSERT(rc >= 0);
+		rc = bitvec_get_uint(&bv, 8);
+		OSMO_ASSERT(rc == 0x7e);
+
+		fprintf(stderr, "out: %s\n", osmo_hexdump(out, sizeof(out)));
+
+		OSMO_ASSERT(out[0] == 0xff);
+		OSMO_ASSERT(out[in_size+1] == 0xff);
+		OSMO_ASSERT(memcmp(in, out + 1, in_size) == 0);
+	}
+
+	printf("=== end %s ===\n", __func__);
+}
+
+int main(int argc, char **argv)
+{
+	test_byte_ops();
+	return 0;
+}
diff --git a/tests/bitvec/bitvec_test.ok b/tests/bitvec/bitvec_test.ok
new file mode 100644
index 0000000..1f329af
--- /dev/null
+++ b/tests/bitvec/bitvec_test.ok
@@ -0,0 +1,2 @@
+=== start test_byte_ops ===
+=== end test_byte_ops ===
diff --git a/tests/testsuite.at b/tests/testsuite.at
index a542798..4a3fc0d 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -21,6 +21,12 @@ cat $abs_srcdir/bits/bitrev_test.ok > expout
 AT_CHECK([$abs_top_builddir/tests/bits/bitrev_test], [0], [expout])
 AT_CLEANUP
 
+AT_SETUP([bitvec])
+AT_KEYWORDS([bitvec])
+cat $abs_srcdir/bitvec/bitvec_test.ok > expout
+AT_CHECK([$abs_top_builddir/tests/bitvec/bitvec_test], [0], [expout], [ignore])
+AT_CLEANUP
+
 AT_SETUP([conv])
 AT_KEYWORDS([conv])
 cat $abs_srcdir/conv/conv_test.ok > expout
-- 
1.9.1



From jerlbeck at sysmocom.de  Mon Dec 21 15:23:11 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon, 21 Dec 2015 16:23:11 +0100
Subject: [PATCH 1/3] log: Add log_check_level function
In-Reply-To: <0B6768C7-B56F-487E-ACEF-7B969F013ED3@freyther.de>
References: <1447757546-31341-1-git-send-email-jerlbeck@sysmocom.de>
 <B3423ACB-C788-4935-865B-BB44894E7BA6@freyther.de>
 <5678090B.5060805@sysmocom.de>
 <0B6768C7-B56F-487E-ACEF-7B969F013ED3@freyther.de>
Message-ID: <5678195F.9030204@sysmocom.de>

On 21.12.2015 15:52, Holger Freyther wrote:
> 
>> On 21 Dec 2015, at 15:13, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote:
>>
>> Hi Holger,
>>
>> On 21.12.2015 14:17, Holger Freyther wrote:
>>>
>>>> On 17 Nov 2015, at 11:52, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote:
>>
>>>> +		/* This might get logged (ignoring filters) */
>>>
>>> What is the reasoning for this part?
>>
>> I wanted to have a weaker criterion than 'return true if and only if
>> something would be logged' to be more flexible when it comes to
>> optimization. I had lookup tables in mind which cache the max level per
>> facility, and which get updated when e.g. log_set_log_level is called.
>> This would be O(1) consuming just a few CPU cycles per log, but would
>> not help when filtering is used.
>>
>> And I didn't really understand filters when I wrote that commit.
>> Including them into the log_check_level decision definitely makes sense
>> if I want to use log DEBUG level stuff on an embedded or high load system.
> 
> Okay maybe I am missing a case here but it feels like we don't save anything
> by not calling it. So if the log level is good for output we return 1 and then do
> the full work. It doesn't really matter which function we do this work in.
> 
> And as this doesn't matter we can leave it out. I posted a patch that removes
> the selection criteria and subsys code clone.

Hmm, there seems to be some misunderstanding. While thinking about the
filter stuff again, I liked the idea to include the filter test into
log_check_level. It would made it possible to DEBUG-log e.g. single
subscribers or MS without rendering the application unusable if the load
were high (and filters really supported). So please don't remove it from
your patch.

Jacob

-- 
- Jacob Erlbeck <jerlbeck at 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 Directors: Holger Freyther, Harald Welte


From nhofmeyr at sysmocom.de  Mon Dec 21 15:52:14 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 21 Dec 2015 16:52:14 +0100
Subject: ffasn1c in osmo-iuh?
Message-ID: <20151221155214.GC27599@dub5>

Hi,

so in osmo-iuh, we're using the libre asn1c, the generated sources found
in e.g. src/hnbap/. But I do find the dirs:
    ./asn1/rua/ffasn1c
    ./asn1/ranap/ffasn1c
    ./asn1/hnbap/ffasn1c
that kind of look like we were using the ffasn1c compiler.
Those are obsolete, right? Remove?

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151221/bdbc7a42/attachment.bin>

From alexander.huemer at xx.vu  Mon Dec 21 19:44:34 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Mon, 21 Dec 2015 20:44:34 +0100
Subject: osmo-iuh: fix Makefile.am
Message-ID: <1450727075-29364-1-git-send-email-alexander.huemer@xx.vu>


This patch fixes the build at least for me after $ git clean -xfd


From alexander.huemer at xx.vu  Mon Dec 21 19:44:35 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Mon, 21 Dec 2015 20:44:35 +0100
Subject: [PATCH] fix Makefile.am
In-Reply-To: <1450727075-29364-1-git-send-email-alexander.huemer@xx.vu>
References: <1450727075-29364-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1450727075-29364-2-git-send-email-alexander.huemer@xx.vu>

---
 src/Makefile.am | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 73b3987..48c861d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -11,20 +11,11 @@ bin_PROGRAMS = hnbgw
 hnbgw_SOURCES = hnbap_encoder.c hnbap_decoder.c rua_encoder.c rua_decoder.c ranap_common.c rua_common.c hnbap_common.c iu_helpers.c asn1helpers.c hnbgw.c hnbgw_hnbap.c hnbgw_rua.c hnbgw_ranap.c ranap_decoder.c ranap_encoder.c ranap_msg_factory.c
 hnbgw_LDADD = $(OSMOCORE_LIBS) $(OSMOVTY_LIBS) $(OSMOGSM_LIBS) $(ASN1C_LIBS) $(COMMON_LDADD) hnbap/libosmo-asn1-hnbap.a rua/libosmo-asn1-rua.a ranap/libosmo-asn1-ranap.a
 
-ranap_ies_defs.h: ranap_encoder.c
-ranap_decoder.c: ranap_encoder.c
-
-rua_ies_defs.h: rua_encoder.c
-rua_decoder.c: rua_encoder.c
-
 hnbap_encoder.c hnbap_decoder.c hnbap_ies_defs.h: $(ASN1_ROOT)/hnbap/HNBAP-PDU-Contents.asn
-hnbap_encoder.c : $(ASN1_ROOT)/hnbap/HNBAP-PDU-Contents.asn
 	$(ASN1TOSTRUCT) -f $<
 
 rua_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
-rua_encoder.c : $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
 	$(ASN1TOSTRUCT) -p RUA_ -f $<
 
 ranap_encoder.c rua_decoder.c rua_ies_defs.h : $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
-ranap_encoder.c : $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
 	$(ASN1TOSTRUCT) -p RANAP_ -f $<
-- 
2.6.2



From laforge at gnumonks.org  Tue Dec 22 07:23:34 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 Dec 2015 08:23:34 +0100
Subject: ffasn1c in osmo-iuh?
In-Reply-To: <20151221155214.GC27599@dub5>
References: <20151221155214.GC27599@dub5>
Message-ID: <20151222072334.GF32185@nataraja>

Hi Neels,

On Mon, Dec 21, 2015 at 04:52:14PM +0100, Neels Hofmeyr wrote:

> so in osmo-iuh, we're using the libre asn1c, the generated sources found
> in e.g. src/hnbap/. But I do find the dirs:
>     ./asn1/rua/ffasn1c
>     ./asn1/ranap/ffasn1c
>     ./asn1/hnbap/ffasn1c
> that kind of look like we were using the ffasn1c compiler.
> Those are obsolete, right? Remove?

yes, they are related to early trials and can/should be removed.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Tue Dec 22 11:20:47 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 Dec 2015 12:20:47 +0100
Subject: [PATCH] fix Makefile.am
In-Reply-To: <1450727075-29364-2-git-send-email-alexander.huemer@xx.vu>
References: <1450727075-29364-1-git-send-email-alexander.huemer@xx.vu>
 <1450727075-29364-2-git-send-email-alexander.huemer@xx.vu>
Message-ID: <20151222112047.GA1542@dub5>

Hi Alexander,

thanks for your patch submission! I ran into the same problem just
yesterday.

It is true that the lines your patch removes can be removed. However, the patch
alone does not solve the build problem for me. In a clean checkout with the
patch applied, I do still get the error:

  hnbgw_ranap.c:36:28: fatal error: ranap_ies_defs.h: No such file or directory
   #include "ranap_ies_defs.h"

It first appears that the problem is related to the fact that asn1tostruct.py
creates all of the *_ies_defs.h, *_decoder.c and *_encoder.c files in one step.
However, taking a closer look, the root cause for the missing ranap_ies_defs.h
is: automake seems unaware that the ranap sources need to be built. Having them
in hnbgw_SOURCES alone is not enough, apparently. Looking at a verbose build
log revealed that the asn1tostruct.py was never called on the RANAP asn. I'm
still not sure why the hnbap and rua were generated and the ranap was omitted
(there seems to be no difference to ranap), but adding a BUILT_SOURCES to
Makefile.am solves the problem for me.

The fact that multiple files are built from one step should actually not be a
problem: all three files get generated from the first dependency, after which
the remaining files are already newer than the asn file -> "nothing to be done".

So I'm committing your patch to remove extraneous lines, and am adding a
BUILT_SOURCES directive in a separate commit.

~Neels


On Mon, Dec 21, 2015 at 08:44:35PM +0100, Alexander Huemer wrote:
> ---
>  src/Makefile.am | 9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 73b3987..48c861d 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -11,20 +11,11 @@ bin_PROGRAMS = hnbgw
>  hnbgw_SOURCES = hnbap_encoder.c hnbap_decoder.c rua_encoder.c rua_decoder.c ranap_common.c rua_common.c hnbap_common.c iu_helpers.c asn1helpers.c hnbgw.c hnbgw_hnbap.c hnbgw_rua.c hnbgw_ranap.c ranap_decoder.c ranap_encoder.c ranap_msg_factory.c
>  hnbgw_LDADD = $(OSMOCORE_LIBS) $(OSMOVTY_LIBS) $(OSMOGSM_LIBS) $(ASN1C_LIBS) $(COMMON_LDADD) hnbap/libosmo-asn1-hnbap.a rua/libosmo-asn1-rua.a ranap/libosmo-asn1-ranap.a
>  
> -ranap_ies_defs.h: ranap_encoder.c
> -ranap_decoder.c: ranap_encoder.c
> -
> -rua_ies_defs.h: rua_encoder.c
> -rua_decoder.c: rua_encoder.c
> -
>  hnbap_encoder.c hnbap_decoder.c hnbap_ies_defs.h: $(ASN1_ROOT)/hnbap/HNBAP-PDU-Contents.asn
> -hnbap_encoder.c : $(ASN1_ROOT)/hnbap/HNBAP-PDU-Contents.asn
>  	$(ASN1TOSTRUCT) -f $<
>  
>  rua_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
> -rua_encoder.c : $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
>  	$(ASN1TOSTRUCT) -p RUA_ -f $<
>  
>  ranap_encoder.c rua_decoder.c rua_ies_defs.h : $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
> -ranap_encoder.c : $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
>  	$(ASN1TOSTRUCT) -p RANAP_ -f $<
> -- 
> 2.6.2
> 

-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151222/7c0f0774/attachment.bin>

From alexander.huemer at xx.vu  Tue Dec 22 13:59:07 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Tue, 22 Dec 2015 14:59:07 +0100
Subject: [PATCH] fix copy/paste mistake in src/Makefile.am
In-Reply-To: <1450792747-22186-1-git-send-email-alexander.huemer@xx.vu>
References: <20151222112047.GA1542@dub5>
 <1450792747-22186-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1450792747-22186-2-git-send-email-alexander.huemer@xx.vu>

---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index ec7250b..9d45a5a 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -19,5 +19,5 @@ hnbap_encoder.c hnbap_decoder.c hnbap_ies_defs.h: $(ASN1_ROOT)/hnbap/HNBAP-PDU-C
 rua_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/rua/RUA-PDU-Contents.asn
 	$(ASN1TOSTRUCT) -p RUA_ -f $<
 
-ranap_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
+ranap_encoder.c ranap_decoder.c ranap_ies_defs.h: $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
 	$(ASN1TOSTRUCT) -p RANAP_ -f $<
-- 
2.6.2



From alexander.huemer at xx.vu  Tue Dec 22 13:59:06 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Tue, 22 Dec 2015 14:59:06 +0100
Subject: No subject
In-Reply-To: <20151222112047.GA1542@dub5>
References: <20151222112047.GA1542@dub5>
Message-ID: <1450792747-22186-1-git-send-email-alexander.huemer@xx.vu>


Hi Neels.

Yes, my fix did only work for parallel make jobs, it fails with -j1, I should
have checked that.
Unfortunately the current HEAD does not build for me either. Make output (-j2):

> Making all in src
> make[1]: Entering directory '/home/blackbit/src/telco/osmo/osmo-iuh/src'
> Makefile:732: warning: overriding recipe for target 'rua_decoder.c'
> Makefile:729: warning: ignoring old recipe for target 'rua_decoder.c'
> Makefile:732: warning: overriding recipe for target 'rua_ies_defs.h'
> Makefile:729: warning: ignoring old recipe for target 'rua_ies_defs.h'
> ../asn1//utils/asn1tostruct.py -f ../asn1//hnbap/HNBAP-PDU-Contents.asn
> ../asn1//utils/asn1tostruct.py -f ../asn1//hnbap/HNBAP-PDU-Contents.asn
> Didn't find any information element for message: PrivateMessage-IEs
> Didn't find any information element for message: PrivateMessage-IEs
> ../asn1//utils/asn1tostruct.py -p RANAP_ -f ../asn1//ranap/RANAP-PDU-Contents.asn
> ../asn1//utils/asn1tostruct.py -p RUA_ -f ../asn1//rua/RUA-PDU-Contents.asn
> make[1]: *** No rule to make target 'ranap_decoder.c', needed by 'all'.  Stop.
> make[1]: *** Waiting for unfinished jobs....
> Didn't find any information element for message: PrivateMessage-IEs
> Didn't find any information element for message: RelocationDetectIEs
> Didn't find any information element for message: RelocationCompleteIEs
> Didn't find any information element for message: RAB-SetupOrModifyItem-IEs
> Didn't find any information element for message: PrivateMessage-IEs
> Didn't find any information element for message: DirectTransferInformationItemIEs-RANAP-RelocInf
> Didn't find any information element for message: SRVCC-CSKeysRequestIEs
> Didn't find any information element for message: UeRadioCapabilityMatchRequestIEs
> make[1]: Leaving directory '/home/blackbit/src/telco/osmo/osmo-iuh/src'
> Makefile:345: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1

When looking at src/Makefile.am again I noticed something that I think is a
copy/paste mistake. When I correct it with the following patch the build works
for me with -j[1234].
Maybe that's the last patch needed for this issue, this really should not be
so difficult.


From hwelte at sysmocom.de  Wed Dec 23 11:05:45 2015
From: hwelte at sysmocom.de (Harald Welte)
Date: Wed, 23 Dec 2015 12:05:45 +0100
Subject: osmo-iuh update
Message-ID: <20151223110545.GG31126@nataraja>

FYI: Last night I

a) merged the SCTP support for libosmo-netif to master

b) moved the sua code from osmo-iuh into the libosmo-sccp repository,
   where we now build a shared libosmo-sigtran.so, which will be linked by
   the MSC, SGSN and HNB-GW code for the IuCS/IuPS interface.

Unlike the spec demands, we will not use SCCP in M3UA in SCTP here, but
will use SUA in SCTP as a simplification.

Furthermore, the SUA code in libosmo-sigtran does not yet
a) fully implement all the correct state machine transitions and
   inactivity timers (this is to be done)
b) implement the ASP management state machines

This is done as a short-cut as we initially only want to communicate
between our own network elements.  What's important is that we can use
wireshark for decoding the protocol stacking that we use, and that the
SCCP USER SAP is specified in a way that will enable us to put SCCP+M3UA
or other sigtran dialects underneath the RANAP code in the future, as
needed.

Regards,
	Harald
-- 
- Harald Welte <hwelte at 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 Directors: Holger Freyther, Harald Welte


From nhofmeyr at sysmocom.de  Wed Dec 23 12:54:22 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 Dec 2015 13:54:22 +0100
Subject: your mail
In-Reply-To: <1450792747-22186-1-git-send-email-alexander.huemer@xx.vu>
References: <20151222112047.GA1542@dub5>
 <1450792747-22186-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <20151223125422.GA2340@dub5>

On Tue, Dec 22, 2015 at 02:59:06PM +0100, Alexander Huemer wrote:
> Yes, my fix did only work for parallel make jobs, it fails with -j1, I should
> have checked that.
> Unfortunately the current HEAD does not build for me either. Make output (-j2):

There seem to be some odd situations where the build works coincidentally
when the order of dependencies fall into lucky places, which is probably
why I didn't get this last error...

> > make[1]: *** No rule to make target 'ranap_decoder.c', needed by 'all'.  Stop.
> > make[1]: *** Waiting for unfinished jobs....

> When looking at src/Makefile.am again I noticed something that I think is a
> copy/paste mistake.

[[[
-ranap_encoder.c rua_decoder.c rua_ies_defs.h: $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
+ranap_encoder.c ranap_decoder.c ranap_ies_defs.h: $(ASN1_ROOT)/ranap/RANAP-PDU-Contents.asn
]]]

wow, how did we miss that...
Thanks! Will commit.

> Maybe that's the last patch needed for this issue, this really should not be
> so difficult.

Hehe, indeed.

~Neels


-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151223/27555130/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Dec 23 14:12:39 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 Dec 2015 15:12:39 +0100
Subject: [PATCH] fix format warnings added by 86ec3118
Message-ID: <1450879960-22267-1-git-send-email-nhofmeyr@sysmocom.de>

Commit 86ec3118 ("msgb: Let msgb_hexdump be more tolerant") added new format
warnings to my 64bit build of libosmocore.

It's not a pressing matter, really, but the libosmocore build is otherwise
clean of such warnings so it'd be nice to keep it that way.

This patch fixes the warnings by using PRIdPTR. That seems to be the Correct
Way to fix it, but I'm a bit unsure.

Thanks for any thoughts!

Neels Hofmeyr (1):
  Fix some recently added formats on 64bit

 src/msgb.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

-- 
2.1.4


From nhofmeyr at sysmocom.de  Wed Dec 23 14:12:40 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 Dec 2015 15:12:40 +0100
Subject: [PATCH] Fix some recently added formats on 64bit
In-Reply-To: <1450879960-22267-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1450879960-22267-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <1450879960-22267-2-git-send-email-nhofmeyr@sysmocom.de>

86ec311896dd5d4 adds compiler warnings on 64bit. The build is clean otherwise,
so let's keep it that way.
---
 src/msgb.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/msgb.c b/src/msgb.c
index 4b108a4..6361913 100644
--- a/src/msgb.c
+++ b/src/msgb.c
@@ -28,6 +28,7 @@
 #include <unistd.h>
 #include <string.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #include <osmocom/core/msgb.h>
 //#include <openbsc/gsm_data.h>
@@ -274,14 +275,15 @@ const char *msgb_hexdump(const struct msgb *msg)
 			continue;
 		if (lxhs[i] < msg->data || lxhs[i] > msg->tail) {
 			nchars = snprintf(buf + buf_offs, sizeof(buf) - buf_offs,
-					  "(L%d=data%+d) ",
+					  "(L%d=data%+" PRIdPTR ") ",
 					  i+1, lxhs[i] - msg->data);
 			buf_offs += nchars;
 			continue;
 		}
 		if (lxhs[i] < start) {
 			nchars = snprintf(buf + buf_offs, sizeof(buf) - buf_offs,
-					  "(L%d%+d) ", i+1, start - lxhs[i]);
+					  "(L%d%+" PRIdPTR ") ", i+1,
+					  start - lxhs[i]);
 			buf_offs += nchars;
 			continue;
 		}
@@ -312,7 +314,7 @@ const char *msgb_hexdump(const struct msgb *msg)
 		} else if (lxhs[i] <= msg->data + msg->data_len &&
 			   lxhs[i] > msg->tail) {
 			nchars = snprintf(buf + buf_offs, sizeof(buf) - buf_offs,
-					  "(L%d=tail%+d) ",
+					  "(L%d=tail%+" PRIdPTR ") ",
 					  i+1, lxhs[i] - msg->tail);
 		} else
 			continue;
-- 
2.1.4



From nhofmeyr at sysmocom.de  Wed Dec 23 14:37:44 2015
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 Dec 2015 15:37:44 +0100
Subject: osmo-iuh update
In-Reply-To: <20151223110545.GG31126@nataraja>
References: <20151223110545.GG31126@nataraja>
Message-ID: <20151223143744.GB2340@dub5>

On Wed, Dec 23, 2015 at 12:05:45PM +0100, Harald Welte wrote:
> FYI: Last night I
> 
> a) merged the SCTP support for libosmo-netif to master
> 
> b) moved the sua code from osmo-iuh into the libosmo-sccp repository,
>    where we now build a shared libosmo-sigtran.so, which will be linked by
>    the MSC, SGSN and HNB-GW code for the IuCS/IuPS interface.
> 
> Unlike the spec demands, we will not use SCCP in M3UA in SCTP here, but
> will use SUA in SCTP as a simplification.
> 
> Furthermore, the SUA code in libosmo-sigtran does not yet

Just to clarify beyond doubt, "the sua code" == libosmo-sigtran, since
recently part of libosmo-sccp.git (which also depends on a recent addition
to libosmocore master; and, yesterday, I was using one of Harald's
branches of libosmo-sccp, but today master works).

Actually, why is the SUA code called libosmo-sigtran, and not libosmo-sua?
Is that just keeping up the ancient tradition of confusing naming? ;)

> or other sigtran dialects underneath the RANAP code

Ah, so, SUA and its alternatives (SCCP in M3UA, etc) together are called
"sigtran", correct?

~Neels


-- 
- Neels Hofmeyr <nhofmeyr at 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151223/10f7ee42/attachment.bin>

From holger at freyther.de  Wed Dec 23 15:09:11 2015
From: holger at freyther.de (Holger Freyther)
Date: Wed, 23 Dec 2015 16:09:11 +0100
Subject: osmo-iuh update
In-Reply-To: <20151223143744.GB2340@dub5>
References: <20151223110545.GG31126@nataraja> <20151223143744.GB2340@dub5>
Message-ID: <8F3FFADB-925F-4F6A-B85E-ABA675F6655B@freyther.de>


> On 23 Dec 2015, at 15:37, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> 
> Actually, why is the SUA code called libosmo-sigtran, and not libosmo-sua?
> Is that just keeping up the ancient tradition of confusing naming? ;)


sure. libosmo-sccp included SCCP codec/connection code, M2UA/M3UA codec code
and now SUA code. M2UA/M3UA/SUA is part of "SIGTRAN" and "SCCP" is spoken on
top of M2UA/M3UA. So somehow everything in this repo is related to SIGTRAN.

holger


From alexander.huemer at xx.vu  Wed Dec 23 21:21:19 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Dec 2015 22:21:19 +0100
Subject: [PATCH] fix build if depenedencies are in distinct directories
In-Reply-To: <1450905679-7583-1-git-send-email-alexander.huemer@xx.vu>
References: <1450905679-7583-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1450905679-7583-2-git-send-email-alexander.huemer@xx.vu>

---
 configure.ac          | 1 +
 src/Makefile.am       | 2 +-
 src/hnbap/Makefile.am | 2 +-
 src/ranap/Makefile.am | 2 +-
 src/rua/Makefile.am   | 2 +-
 src/tests/Makefile.am | 2 +-
 6 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0b77531..018aa17 100644
--- a/configure.ac
+++ b/configure.ac
@@ -18,6 +18,7 @@ AC_PROG_RANLIB
 PKG_CHECK_MODULES(OSMOCORE, libosmocore)
 PKG_CHECK_MODULES(OSMOGSM, libosmogsm)
 PKG_CHECK_MODULES(OSMOVTY, libosmovty)
+PKG_CHECK_MODULES(OSMONETIF, libosmo-netif)
 PKG_CHECK_MODULES(OSMOSIGTRAN, libosmo-sigtran)
 PKG_CHECK_MODULES(ASN1C, libasn1c)
 
diff --git a/src/Makefile.am b/src/Makefile.am
index d609445..5ac0907 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -3,7 +3,7 @@ SUBDIRS = hnbap rua ranap tests
 ASN1_ROOT = $(top_builddir)/asn1/
 ASN1TOSTRUCT = $(ASN1_ROOT)/utils/asn1tostruct.py
 
-AM_CFLAGS = $(OSMOCORE_CFLAGS) $(OSMOVTY_CFLAGS) $(OSMOGSM_CFLAGS) $(ASN1C_CFLAGS) $(OSMOSIGTRAN_CFLAGS) -Ihnbap/
+AM_CFLAGS = $(OSMOCORE_CFLAGS) $(OSMOVTY_CFLAGS) $(OSMOGSM_CFLAGS) $(OSMONETIF_CFLAGS) $(ASN1C_CFLAGS) $(OSMOSIGTRAN_CFLAGS) -Ihnbap/
 COMMON_LDADD = -lsctp
 
 bin_PROGRAMS = hnbgw
diff --git a/src/hnbap/Makefile.am b/src/hnbap/Makefile.am
index a9e8163..e152587 100644
--- a/src/hnbap/Makefile.am
+++ b/src/hnbap/Makefile.am
@@ -232,7 +232,7 @@ ASN_MODULE_INC=	\
 	PrivateMessage.h	\
 	IE.h
 
-AM_CFLAGS = $(ASN1C_CFLAGS) -I.
+AM_CFLAGS = $(ASN1C_CFLAGS) $(OSMOCORE_CFLAGS) -I.
 
 noinst_LIBRARIES=libosmo-asn1-hnbap.a
 libosmo_asn1_hnbap_a_SOURCES=$(ASN_MODULE_SOURCES)
diff --git a/src/ranap/Makefile.am b/src/ranap/Makefile.am
index d3071e8..6abe7ef 100644
--- a/src/ranap/Makefile.am
+++ b/src/ranap/Makefile.am
@@ -1160,7 +1160,7 @@ ASN_MODULE_INC=	\
 	RANAP_LeftMBMSBearerService-IEs.h	\
 	RANAP_UnsuccessfulLinking-IEs.h
 
-AM_CFLAGS = $(ASN1C_CFLAGS) -I.
+AM_CFLAGS = $(ASN1C_CFLAGS) $(OSMOCORE_CFLAGS) -I.
 
 noinst_LIBRARIES=libosmo-asn1-ranap.a
 libosmo_asn1_ranap_a_SOURCES=$(ASN_MODULE_SRC)
diff --git a/src/rua/Makefile.am b/src/rua/Makefile.am
index c93b801..cb13a1c 100644
--- a/src/rua/Makefile.am
+++ b/src/rua/Makefile.am
@@ -72,7 +72,7 @@ ASN_MODULE_INC=	\
 	RUA_PrivateMessage.h	\
 	RUA_IE.h
 
-AM_CFLAGS = $(ASN1C_CFLAGS) -I.
+AM_CFLAGS = $(ASN1C_CFLAGS) $(OSMOCORE_CFLAGS) -I.
 
 noinst_LIBRARIES=libosmo-asn1-rua.a
 libosmo_asn1_rua_a_SOURCES=$(ASN_MODULE_SOURCES)
diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am
index a44ad2c..8335057 100644
--- a/src/tests/Makefile.am
+++ b/src/tests/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS = $(OSMOVTY_CFLAGS) $(OSMOCORE_CFLAGS) $(OSMOGSM_CFLAGS) $(ASN1C_CFLAGS) -g -I$(top_builddir)/src -I$(top_builddir)/src/hnbap/
+AM_CFLAGS = $(OSMOVTY_CFLAGS) $(OSMOCORE_CFLAGS) $(OSMOGSM_CFLAGS) $(OSMONETIF_CFLAGS) $(ASN1C_CFLAGS) -g -I$(top_builddir)/src -I$(top_builddir)/src/hnbap/
 
 COMMON_LIBS = $(OSMOVTY_LIBS) $(OSMOCORE_LIBS) $(OSMOGSM_LIBS) $(ASN1C_LIBS) -lsctp
 
-- 
2.6.2



From alexander.huemer at xx.vu  Wed Dec 23 21:21:18 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Dec 2015 22:21:18 +0100
Subject: No subject
Message-ID: <1450905679-7583-1-git-send-email-alexander.huemer@xx.vu>


Hi.

This patch is for osmo-iuh.
Without it the build only works on machines that have the needed headers in
the default search path for includes.
Otherwise the build fails like this:

> gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.0\" -DPACKAGE_STRING=\"osmo-iuh\ 0.0\" -DPACKAGE_BUGREPORT=\"\	openbsc at lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.0\" -DSTDC_HEADERS=1 -I.    -I/home/blackbit/usr/stow/libasn1c/include/ -I/home/blackbit/usr/stow/libasn1c/include/asn1c -I. -g -O2 -MT Criticality.o -MD -MP -MF $depbase.Tpo -c -o Criticality.o Criticality.c &&\
> mv -f $depbase.Tpo $depbase.Po
> In file included from Criticality.h:50:0,
>                  from Criticality.c:8:
> /home/blackbit/usr/stow/libasn1c/include/asn1c/asn_internal.h:18:33: fatal error: osmocom/core/talloc.h: No such file or directory
> compilation terminated.

Kind regards,
-Alex


From alexander.huemer at xx.vu  Wed Dec 23 21:28:47 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Dec 2015 22:28:47 +0100
Subject: [PATCH] fix build if depenedencies are in distinct directories
Message-ID: <1450906128-15005-1-git-send-email-alexander.huemer@xx.vu>

Hi.

This patch is for libosmo-sccp.
Without it the build only works on machines that have the needed headers in
the default search path for includes.
Otherwise the build fails like this:

> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"libosmo-sccp\" -DPACKAGE_TARNAME=\"libosmo-sccp\" -DPACKAGE_VERSION=\"0.0.6.3.33-8209\" -DPACKAGE_STRING=\"libosmo-sccp\ 0.0.6.3.33-8209\" -DPACKAGE_BUGREPORT=\"openbsc at lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libosmo-sccp\" -DVERSION=\"0.0.6.3.33-8209\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.   -I../include -I..  -Wall -I/home/blackbit/usr/stow/libosmocore/include/ -g -O2 -MT sua.lo -MD -MP -MF .deps/sua.Tpo -c -o sua.lo sua.c
> libtool: compile:  gcc -DPACKAGE_NAME=\"libosmo-sccp\" -DPACKAGE_TARNAME=\"libosmo-sccp\" -DPACKAGE_VERSION=\"0.0.6.3.33-8209\" "-DPACKAGE_STRING=\"libosmo-sccp 0.0.6.3.33-8209\"" -DPACKAGE_BUGREPORT=\"openbsc at lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libosmo-sccp\" -DVERSION=\"0.0.6.3.33-8209\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I../include -I.. -Wall -I/home/blackbit/usr/stow/libosmocore/include/ -g -O2 -MT sua.lo -MD -MP -MF .deps/sua.Tpo -c sua.c  -fPIC -DPIC -o .libs/sua.o
> sua.c:32:34: fatal error: osmocom/netif/stream.h: No such file or directory
> compilation terminated.

Kind regards,
-Alex


From alexander.huemer at xx.vu  Wed Dec 23 21:28:48 2015
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Dec 2015 22:28:48 +0100
Subject: [PATCH] fix build if depenedencies are in distinct directories
In-Reply-To: <1450906128-15005-1-git-send-email-alexander.huemer@xx.vu>
References: <1450906128-15005-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1450906128-15005-2-git-send-email-alexander.huemer@xx.vu>

---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index ba55162..238a840 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,5 +1,5 @@
 AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)
-AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS)
+AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMONETIF_CFLAGS)
 
 # Legacy static libs
 
-- 
2.6.2



From stanley.lary at gmail.com  Thu Dec 24 09:57:01 2015
From: stanley.lary at gmail.com (stanley lary)
Date: Thu, 24 Dec 2015 11:57:01 +0200
Subject: osmobts multiple bts
Message-ID: <CANgauH7unkHtZJWJ4rkWo0jStWxUf_se0kH8u6=5ZSq2t1aXHA@mail.gmail.com>

Hi,
I have followed the steps as in Multi-BTS with Osmocom and a single UmTRX
<http://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/> but I wasn't
able to get the right results. I was able to get both TX transmitting the
broadcast channel but when I try to connect my phone, only BTS0 works fine.
When I try to change the BTS unit_id, I noticed that only the BTS having
the lower unit_id would work while the other one only transmits broadcast
signals (ex: unit_id 1801 works if I have 1801 and 1802).

Any ideas what could be the problem ?

Thank you,
<http://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151224/911302a3/attachment.htm>

From laforge at gnumonks.org  Thu Dec 24 15:14:11 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Dec 2015 16:14:11 +0100
Subject: [PATCH] fix build if depenedencies are in distinct directories
In-Reply-To: <1450906128-15005-2-git-send-email-alexander.huemer@xx.vu>
References: <1450906128-15005-1-git-send-email-alexander.huemer@xx.vu>
 <1450906128-15005-2-git-send-email-alexander.huemer@xx.vu>
Message-ID: <20151224151411.GB31126@nataraja>

On Wed, Dec 23, 2015 at 10:28:48PM +0100, Alexander Huemer wrote:
> -AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS)
> +AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMONETIF_CFLAGS)

thanks, merged.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Dec 24 15:16:54 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Dec 2015 16:16:54 +0100
Subject: [PATCH] fix build if depenedencies are in distinct directories
In-Reply-To: <1450905679-7583-2-git-send-email-alexander.huemer@xx.vu>
References: <1450905679-7583-1-git-send-email-alexander.huemer@xx.vu>
 <1450905679-7583-2-git-send-email-alexander.huemer@xx.vu>
Message-ID: <20151224151654.GC31126@nataraja>

Hi Alexander,

On Wed, Dec 23, 2015 at 10:21:19PM +0100, Alexander Huemer wrote:
> +PKG_CHECK_MODULES(OSMONETIF, libosmo-netif)

thanks, applied to my laforge/wip branch, which I'll merge to master
once I have the full chain working and cleaned up some of the internal
API re-shuffling.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Dec 24 15:18:03 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Dec 2015 16:18:03 +0100
Subject: [PATCH] Fix some recently added formats on 64bit
In-Reply-To: <1450879960-22267-2-git-send-email-nhofmeyr@sysmocom.de>
References: <1450879960-22267-1-git-send-email-nhofmeyr@sysmocom.de>
 <1450879960-22267-2-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <20151224151803.GD31126@nataraja>

Hi Neels,

On Wed, Dec 23, 2015 at 03:12:40PM +0100, Neels Hofmeyr wrote:
> 86ec311896dd5d4 adds compiler warnings on 64bit. The build is clean otherwise,
> so let's keep it that way.

looks fine, merged, thanks.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Fri Dec 25 14:50:45 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Fri, 25 Dec 2015 15:50:45 +0100 (CET)
Subject: Osmo-PCU: make error
In-Reply-To: <855747125.15111379.1451054763725.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <635575092.15111507.1451055045594.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Jacob,

Today I started to update my setup to latest master for all the Osmocom projects and hit a compile error with Osmo-PCU:

root at D6420:~/newer_osmocom/osmo-pcu# make
Making all in src
make[1]: Entering directory `/root/newer_osmocom/osmo-pcu/src'
  CXX      gprs_debug.lo
  CXX      csn1.lo
  CXX      gsm_rlcmac.lo
  CXX      gprs_bssgp_pcu.lo
In file included from /usr/local/include/osmocom/gsm/prim.h:3:0,
                 from /usr/local/include/osmocom/gprs/gprs_bssgp.h:8,
                 from ./gprs_bssgp_pcu.h:32,
                 from gprs_bssgp_pcu.cpp:22:
/usr/local/include/osmocom/core/prim.h:23:27: error: uninitialized const 'osmo_prim_op_names' [-fpermissive]
 const struct value_string osmo_prim_op_names[5];
                           ^
In file included from /usr/local/include/osmocom/core/msgb.h:24:0,
                 from /usr/local/include/osmocom/gprs/gprs_ns.h:8,
                 from ./gprs_bssgp_pcu.h:31,
                 from gprs_bssgp_pcu.cpp:22:
/usr/local/include/osmocom/core/utils.h:22:8: note: 'const struct value_string' has no user-provided default constructor
 struct value_string {
        ^
/usr/local/include/osmocom/core/utils.h:23:15: note: and the implicitly-defined constructor does not initialize 'unsigned int value_string::value'
  unsigned int value; /*!< \brief numeric value */
               ^
make[1]: *** [gprs_bssgp_pcu.lo] Error 1
make[1]: Leaving directory `/root/newer_osmocom/osmo-pcu/src'
make: *** [all-recursive] Error 1

I can see that you moving some parts from openbsc to the core library, probably that process is not yet finsihed (or merged to master) and that is causing this problem.

Just wanted to give some feedback and notify the list about this.

Regards,
Csaba



From laforge at gnumonks.org  Fri Dec 25 16:15:51 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 Dec 2015 17:15:51 +0100
Subject: Osmo-PCU: make error
In-Reply-To: <635575092.15111507.1451055045594.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <855747125.15111379.1451054763725.JavaMail.zimbra@kvk.uni-obuda.hu>
 <635575092.15111507.1451055045594.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20151225161551.GG31126@nataraja>

Hi Sipos,

On Fri, Dec 25, 2015 at 03:50:45PM +0100, Sipos Csaba wrote:
> /usr/local/include/osmocom/core/prim.h:23:27: error: uninitialized const 'osmo_prim_op_names' [-fpermissive]
>  const struct value_string osmo_prim_op_names[5];

This was introduced by one of my recent libosmocore changes, sorry.

The patch below (just pushed to libosmocore master) should fix it.

>From c959afdcd9d8f227f4a72a915ac2e3f79d1d1d3b Mon Sep 17 00:00:00 2001
From: Harald Welte <laforge at gnumonks.org>
Date: Fri, 25 Dec 2015 17:14:07 +0100
Subject: [PATCH] osmo_prim_op_names should be extern

---
 include/osmocom/core/prim.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/osmocom/core/prim.h b/include/osmocom/core/prim.h
index e920eb8..9e71007 100644
--- a/include/osmocom/core/prim.h
+++ b/include/osmocom/core/prim.h
@@ -20,7 +20,7 @@ enum osmo_prim_operation {
 	PRIM_OP_CONFIRM,	/*!< \brief cofirm */
 };
 
-const struct value_string osmo_prim_op_names[5];
+extern const struct value_string osmo_prim_op_names[5];
 
 #define _SAP_GSM_SHIFT	24
 
-- 
2.6.4

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Fri Dec 25 16:17:28 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Fri, 25 Dec 2015 17:17:28 +0100 (CET)
Subject: Osmo-PCU: make error
In-Reply-To: <20151225161551.GG31126@nataraja>
References: <855747125.15111379.1451054763725.JavaMail.zimbra@kvk.uni-obuda.hu>
 <635575092.15111507.1451055045594.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20151225161551.GG31126@nataraja>
Message-ID: <1379316116.15113412.1451060248657.JavaMail.zimbra@kvk.uni-obuda.hu>

Thx Harald, will test it and report back.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "Jacob Erlbeck" <jerlbeck at sysmocom.de>, "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: P?ntek, 2015. December 25. 17:15:51
T?rgy: Re: Osmo-PCU: make error

Hi Sipos,

On Fri, Dec 25, 2015 at 03:50:45PM +0100, Sipos Csaba wrote:
> /usr/local/include/osmocom/core/prim.h:23:27: error: uninitialized const 'osmo_prim_op_names' [-fpermissive]
>  const struct value_string osmo_prim_op_names[5];

This was introduced by one of my recent libosmocore changes, sorry.

The patch below (just pushed to libosmocore master) should fix it.

>From c959afdcd9d8f227f4a72a915ac2e3f79d1d1d3b Mon Sep 17 00:00:00 2001
From: Harald Welte <laforge at gnumonks.org>
Date: Fri, 25 Dec 2015 17:14:07 +0100
Subject: [PATCH] osmo_prim_op_names should be extern

---
 include/osmocom/core/prim.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/osmocom/core/prim.h b/include/osmocom/core/prim.h
index e920eb8..9e71007 100644
--- a/include/osmocom/core/prim.h
+++ b/include/osmocom/core/prim.h
@@ -20,7 +20,7 @@ enum osmo_prim_operation {
 	PRIM_OP_CONFIRM,	/*!< \brief cofirm */
 };
 
-const struct value_string osmo_prim_op_names[5];
+extern const struct value_string osmo_prim_op_names[5];
 
 #define _SAP_GSM_SHIFT	24
 
-- 
2.6.4

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Sat Dec 26 11:27:10 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 26 Dec 2015 12:27:10 +0100 (CET)
Subject: Osmo-PCU: make error
In-Reply-To: <1379316116.15113412.1451060248657.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <855747125.15111379.1451054763725.JavaMail.zimbra@kvk.uni-obuda.hu>
 <635575092.15111507.1451055045594.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20151225161551.GG31126@nataraja>
 <1379316116.15113412.1451060248657.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <1314663197.15142938.1451129230317.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Harald,

It all compiles fine now. Thx for the fix :-)

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
C?mzett: "Harald Welte" <laforge at gnumonks.org>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: P?ntek, 2015. December 25. 17:17:28
T?rgy: Re: Osmo-PCU: make error

Thx Harald, will test it and report back.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "Jacob Erlbeck" <jerlbeck at sysmocom.de>, "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: P?ntek, 2015. December 25. 17:15:51
T?rgy: Re: Osmo-PCU: make error

Hi Sipos,

On Fri, Dec 25, 2015 at 03:50:45PM +0100, Sipos Csaba wrote:
> /usr/local/include/osmocom/core/prim.h:23:27: error: uninitialized const 'osmo_prim_op_names' [-fpermissive]
>  const struct value_string osmo_prim_op_names[5];

This was introduced by one of my recent libosmocore changes, sorry.

The patch below (just pushed to libosmocore master) should fix it.

>From c959afdcd9d8f227f4a72a915ac2e3f79d1d1d3b Mon Sep 17 00:00:00 2001
From: Harald Welte <laforge at gnumonks.org>
Date: Fri, 25 Dec 2015 17:14:07 +0100
Subject: [PATCH] osmo_prim_op_names should be extern

---
 include/osmocom/core/prim.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/osmocom/core/prim.h b/include/osmocom/core/prim.h
index e920eb8..9e71007 100644
--- a/include/osmocom/core/prim.h
+++ b/include/osmocom/core/prim.h
@@ -20,7 +20,7 @@ enum osmo_prim_operation {
 	PRIM_OP_CONFIRM,	/*!< \brief cofirm */
 };
 
-const struct value_string osmo_prim_op_names[5];
+extern const struct value_string osmo_prim_op_names[5];
 
 #define _SAP_GSM_SHIFT	24
 
-- 
2.6.4

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From sipos.csaba at kvk.uni-obuda.hu  Sat Dec 26 13:08:42 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 26 Dec 2015 14:08:42 +0100 (CET)
Subject: Wiki update for B2x0 series
In-Reply-To: <2018634401.15144733.1451134723528.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <896228474.15144878.1451135322275.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear list,

As of today, I revised and updated the Wiki page for Ettus SDRs.

https://openbsc.osmocom.org/trac/wiki/Ettus_USRP_B2xx_family

What is tested:

- Voice calls (MO and MT with full rate)
- Interconnect with Asterisk (voice call routing and interconnecting GSM calls to SIP or other telephony technologies)
- SMS (MO and MT)
- GPRS

What needs to be tested:

- Voice calls with half rate and AMR

If someone can go through it and revise it, that would be nice.

Regards,
Csaba


From jerlbeck at sysmocom.de  Sat Dec 26 20:09:21 2015
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Sat, 26 Dec 2015 21:09:21 +0100
Subject: PCU-Testing at CCC
Message-ID: <567EF3F1.6030208@sysmocom.de>

Hi,

it would be great to do some PCU testing at the congress.

Branch: jerlbeck/master
PCU Configuration: example config
NITB/BSC Configuration: At least 2 adjacent PDCH

Interesting VTY commands
 - show tbf all
 - show ms all
 - show ms imsi SOME_IMSI

Other things to look at:
 - PCU load (CPU)

Please keep me informed on how it works. I'll be able to investigate or
fix things on Mon and Tue (and maybe on Sun).

Thanks and have fun

Jacob
-- 
- Jacob Erlbeck <jerlbeck at 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 Directors: Holger Freyther, Harald Welte


From agmagor+osmo at agmagor.be  Mon Dec 28 13:35:50 2015
From: agmagor+osmo at agmagor.be (Pierre Baudry)
Date: Mon, 28 Dec 2015 14:35:50 +0100
Subject: [PATCH 1/3] log: Add log_check_level function
In-Reply-To: <5678195F.9030204@sysmocom.de>
References: <1447757546-31341-1-git-send-email-jerlbeck@sysmocom.de>
 <B3423ACB-C788-4935-865B-BB44894E7BA6@freyther.de>
 <5678090B.5060805@sysmocom.de>
 <0B6768C7-B56F-487E-ACEF-7B969F013ED3@freyther.de>
 <5678195F.9030204@sysmocom.de>
Message-ID: <CAAQ8q1gAsZKBh2KAEFt4zLt4x3QRNeLSSKOZKosfbH_HbYvkGg@mail.gmail.com>

Hello list,
Is this patch still considered for a merge ?

It seems that embedded systems will largely benefit from this early
check. It may improve osmo-pcu performance, as discussed in "osmo-bts
/ osmo-pcu profiling results" thread but also all binaries running on
low resources systems.

I have not received new test equipment yet, but I can give this patch
a try as soon as possible if it helps.

Thanks.


From diegoferalonso at gmail.com  Mon Dec 28 19:34:50 2015
From: diegoferalonso at gmail.com (Diego Fernandez Alonso)
Date: Mon, 28 Dec 2015 20:34:50 +0100
Subject: Problem with RF and states of sysmoBTS
Message-ID: <CADVYdC+1qOCiHNU4g6FoYmXd+BKwq+AzhsW1JiR++6u0YpvfPw@mail.gmail.com>

Hi,

I have a problem with my sysmoBTS.I restored the system using a
sysmocom-recovery.ubi and executing a sysmocom-restore from a backup file
.tar. Everything was apparently ok but the RF Active led is switched off,
without transmision, and the state of the BTS is not normal.

First of all with a serial conexion I received this message:
fpgadl: Error: INIT_B LOW during programming

and checking the state I get the parameters:

OpenBSC> show bts 0
BTS 0 is of nanobts type in band DCS1800, has CI 0 LAC 1, BSIC 63, TSC 7
and 1 TRX
Description: (null)
MS Max power: 15 dBm
Minimum Rx Level for Access: -110 dBm
Cell Reselection Hysteresis: 4 dBm
RACH TX-Integer: 9
RACH Max transmissions: 7
Channel Description Attachment: yes
Channel Description BS-PA-MFRMS: 5
Channel Description BS-AG_BLKS-RES: 1
System Information present: 0x00000000, static: 0x00000000
  Unit ID: 1801/0/0, OML Stream ID 0xff
  NM State: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
  Site Mgr NM State: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
  GPRS NSE: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
  GPRS CELL: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
  GPRS NSVC0: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
  GPRS NSVC1: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
  Paging: 0 pending requests, 20 free slots
  OML Link state: disconnected.
  Current Channel Load:
OpenBSC>



OpenBSC> show trx 0 0
TRX 0 of BTS 0 is on ARFCN 514
Description: (null)
  RF Nominal Power: 23 dBm, reduced by 20 dB, resulting BS power: 3 dBm
  NM State: Oper 'NULL', Admin 'Unlocked', Avail 'Power off'
  Baseband Transceiver NM State: Oper 'NULL', Admin 'unknown 0x0', Avail
'Power off'
  ip.access stream ID: 0x00
OpenBSC>


I would be very grateful for some idea for recovering the states to 'Enable'

Thanks so much.
Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151228/5a7f0d82/attachment.htm>

From holger at freyther.de  Mon Dec 28 20:02:56 2015
From: holger at freyther.de (Holger Freyther)
Date: Mon, 28 Dec 2015 21:02:56 +0100
Subject: Problem with RF and states of sysmoBTS
In-Reply-To: <CADVYdC+1qOCiHNU4g6FoYmXd+BKwq+AzhsW1JiR++6u0YpvfPw@mail.gmail.com>
References: <CADVYdC+1qOCiHNU4g6FoYmXd+BKwq+AzhsW1JiR++6u0YpvfPw@mail.gmail.com>
Message-ID: <7EC403A8-B46C-4FC4-84EB-4091BA358F78@freyther.de>


> On 28 Dec 2015, at 20:34, Diego Fernandez Alonso <diegoferalonso at gmail.com> wrote:
> 
> Hi,
> 
> I have a problem with my sysmoBTS.I restored the system using a sysmocom-recovery.ubi and executing a sysmocom-restore from a backup file .tar. Everything was apparently ok but the RF Active led is switched off, without transmision, and the state of the BTS is not normal.
> 
> First of all with a serial conexion I received this message:
> fpgadl: Error: INIT_B LOW during programming

that is "normal" if that is not the final message. Could you do show running config?
I assume you have a rf locked for your trx, the only other option I see is that your
BTS is reconnecting repeatingly but that doesn't sound like your symptoms.

holger







From ptrkrysik at gmail.com  Thu Dec 31 07:27:17 2015
From: ptrkrysik at gmail.com (Piotr Krysik)
Date: Thu, 31 Dec 2015 08:27:17 +0100
Subject: libosmocore: broken pybombs installation because of talloc
Message-ID: <5684D8D5.9060308@gmail.com>


Hi all,

libosmocore can't be installed with GNU Radio's pybombs currently. The
reason is that libosmocore requires libtalloc which isn't installed
automatically by pybombs. Manually the problem can be solved by
installing libtalloc-dev package. It would be good to fix the pybombs
recipe however. I would do this simply by adding libtalloc-dev to
dependencies but I don't know if this is proper solution from your point
of view.

Can you (libosmocore developers) fix the recipe or tell me how to fix it
appropriately?

Best Regards,
Piotr Krysik


From holger at freyther.de  Thu Dec 31 08:34:14 2015
From: holger at freyther.de (Holger Freyther)
Date: Thu, 31 Dec 2015 09:34:14 +0100
Subject: libosmocore: broken pybombs installation because of talloc
In-Reply-To: <5684D8D5.9060308@gmail.com>
References: <5684D8D5.9060308@gmail.com>
Message-ID: <E067F268-D12D-452F-AC0B-185AB2FF358C@freyther.de>


> On 31 Dec 2015, at 08:27, Piotr Krysik <ptrkrysik at gmail.com> wrote:
> 
> 
> Hi all,
> 
> libosmocore can't be installed with GNU Radio's pybombs currently. The
> reason is that libosmocore requires libtalloc which isn't installed
> automatically by pybombs. Manually the problem can be solved by
> installing libtalloc-dev package. It would be good to fix the pybombs
> recipe however. I would do this simply by adding libtalloc-dev to
> dependencies but I don't know if this is proper solution from your point
> of view.

Yes sounds right.


> Can you (libosmocore developers) fix the recipe or tell me how to fix it
> appropriately?

pybombs is not maintained by us but adding libtalloc-dev looks like a good
idea. Do you know who is maintaining it?

holger