Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
Hi all,
This patch set adds to libosmocore an optimized Viterbi decodeer for
architecture specific (Intel SSE) and non-specific cases. The
implementation covers codes with constraint lengths of K=5 and K=7 and
rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup
from the current implementation is in the range of 5 to 20 depending on
the processor and code type. API is unchanged.
Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes
from osmo-bts are included. Further tests for AWGN bit-error-rate
and benchmarks can be found in the following repository.
https://github.com/ttsou/osmo-conv-test
Here are some examples.
Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts.
$ ./conv_test -c 2 -e -r 5 -i 100000
=================================================
[+] Testing: GPRS CS2
[.] Specs: (N=2, K=5, non-recursive, flushed, not punctured)
[.] Input length : ret = 290 exp = 290 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] BER tests:
[..] Testing base:
[..] Input BER.......................... 0.042443
[..] Output BER......................... 0.000006
[..] Output FER......................... 0.001350 (135)
[..] Testing SIMD:
[..] Input BER.......................... 0.042460
[..] Output BER......................... 0.000005
[..] Output FER......................... 0.001240 (124)
Timed AFS benchmark with 8 threads and 100000 bursts per thread.
$ ./conv_test -b -c 10 -j 8 -i 100000
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
-TT
Hi Alexander,
Just wanted to thank you for the web version of meas_vis utility, and wanted to confirm that it works very well with Nokia Site family (E1 based) and the USRP B200 too :-)
If someone missed it, the web version can be found here:
https://github.com/fairwaves/meas_web
It would make life easier if the meas_json utility would make it to the master branch:
http://cgit.osmocom.org/openbsc/log/?h=achemeris/meas_json
Is there a reason it is not being merged?
Regards,
Csaba
This is the first patch of the series. The first two patches are
improvements of the log output and are independent of the 3rd patch in
terms of code - proposed logging improvements just make it easier to
debug issues with MNCC cause codes.
The code is also a part of the achemeris/mncc_cause_fixes_master branch.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Previously we were sending a generic "Resource unavailable" cause code making
it impossible to distinguish real error cases from a regular radio link failure.
This was the reason for many "unknown" call errors we've seen at Rhizomatica
installations. Now they are properly classified as non-erroneous call failures.
The code is also a part of the achemeris/mncc_cause_fixes_master branch.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
With phone attached to my configured EGPRS, sometimes it has a data rate around 200kbps (which is near optimal), while frequently it has a intolerablly slow data rate. Is it a common problem, or it's due to incorrect configrations or hardware problems? I run a gsm test system with nanobts, and the libosmocore, openbsc, openggsn codes are based on the version around end of April 2015. The configuration is made accorrding to the instruction from openbsc web. The correction in fc_queue_timer_cfg has also been made according to Jacob Erlbeck.
Hi,
This is the first series of my gtp kernel updates.
It contains mostly the removal of Linux version ifdefs. After this the
module builds only on 4.3+. The goal here is the preparation for main
line inclusion.
The other small change is a update to the Makefile for simpler out-of-tree
build
Andreas
--
Andreas Schultz (6):
build: update Makefile for simpler out of tree builds
gtp: remove genl_ops compat ifdef for Linux < 3.13
gtp: remove per cpu stats compat ifdef for Linux < 3.13
gtp: update for Linux > 4.1+, __ip_select_ident arguments have changed
gtp: update for Linux > 4.1+, genlmsg_end return should be ignored
gtp: update for Linux > 4.2+, set NO_QUEUE flag on gtp device
Makefile | 17 ++++++++++++-----
gtp.c | 11 +++++------
gtp.h | 4 ----
3 files changed, 17 insertions(+), 15 deletions(-)
--
2.5.0
Here is the fixed OAP patch set of those changes not merged yet.
For decode_big_endian(), see the new API comment and my mail from thursday
night/friday morning.
Thanks for the review!
~Neels
Here is another set of cosmetic improvements for openggsn
(branch: neels/refactor).
This prints the host address in human readable form and covers two more similar
occurences.
A new error log fix has been added (see 4/4).
A nonstandard curly brace change from the previous patch has been dropped, and
replaced by a blank line to increase readability.
~Neels
Hi,
Some time ago, Pablo Neira Ayuso wrote a GTP-U kernel module and OpenGGSN
support for it. The OpenGGSN side is easily available in the osmocom git [1].
The kernel part is somewhat harder to find, but it's at [2].
It seems that both sides are at 70% completion and only somewhat working.
I have played with the kernel module, changed a couple things and would
like to get some feedback on my changes.
It can be found at: https://github.com/RoadRunnr/osmo-ggsn
Things I've changed:
* requires kernel from net-next (or 4.3)
* convert to use the existing kernel iptunnel infrastructure
* fix GTP-u v1 TEI usage (we need one TEI for RX and another one
for TX)
* use UDP sockets passed from userland for sending (instead of
direct push to network interface)
* fix resource release on GTP-U socket shutdown
* release all resource on module removal
The module currently works with a proof-of-concept GGSN/PGW implemented
in Erlang (will post once the licensing is sorted). OpenGGSN will need
some small changes (will post soon).
Andreas
[1]: http://git.osmocom.org/openggsn/
[2]: http://git.sysmocom.de/osmo-ggsn
Hi all,
a remark / question about GTP, in the context of writing code for
gtphub...
So far I've tried to keep the GTP IP addresses and ports config general --
you never know what weird things one might want to do some day (different
IP addresses for User and Control? Nonstandard port numbers?).
But now I'm at the point where I've got a Control plane message from a
"control peer", and need to figure out the matching peer on the User
plane. How do I do that? By IP address, of course.
Thus it struck me that GTP *depends* on a setup where the User IP address
is identical to the IP of the sender of the Ctrl plane packet.
(view with a monospaced font)
SGSN GGSN (or gtphub)
1.2.3.4 5.6.7.8
Ctrl: 2123 <-------> 2123
User: 2152 <-------> 2152
So trying to stay general with IP addresses is an exercise in futility,
because it plainly doesn't work for GTP: I can't match up a peer's two
message planes unless the above standard is given.
Thinking of a nonstandard situation:
GGSN (or gtphub)
SGSN 5.6.7.8
Ctrl: 1.2.3.4:111 <-------> 2123
User: 4.3.2.1:222 X-------> 2152
The GGSN can record that there's a Ctrl peer at 1.2.3.4:111, from the
incoming GTP packet's sender address. Say it receives a Create PDP Context
Request, in which the nonstandard SGSN sends two TEIs it wants to use, on
the Ctrl *and* User plane. Now, the GGSN cannot possibly know that 4.3.2.1
is the User plane peer for which the TEI from the Create PDP Ctx Req
should be valid. One may think that the SGSN can just contact the GGSN
from 4.3.2.1:222 and send the TEI from the Create PDP, so the GGSN could
know that it's the same peer. But in fact a TEI is scoped *within* a comm
plane with a peer, meaning that any other peer could choose the exact same
TEI at any point, and the means to disambiguate is the peer's IP address.
So my wishful thinking to stay general there is thwarted by design. The
Ctrl and User IP addresses must be identical.
Still, the SGSN's port numbers could theoretically be chosen freely. The
GGSN knows the sender of the Ctrl packet(s), and as soon as a User packet
comes in from the same IP address, it also knows the User plane port. As
long as the IP address is the same and there are no other SGSNs using
different ports on the same IP address, the GGSN could figure out both
nonstandard Ctrl and User ports like this.
BTW, we've also thought about securing the GTP wire towards gtphub with
some kind of authentication (future). With identification sent on both
planes, the limitations discussed here would be void...
So I'll actually keep gtphub's config as general as it is, but will not
invest time, neither in implications of choosing nonstandard setups, nor
in prohibiting them (yet).
The nonstandard ports config capability actually comes in handy for unit
testing, where I can place some netcats and a gtphub on arbitrary port
numbers on the same IP address. (Since implicit creation of 127.0.0.N
interfaces is linux specific, using several local addresses without root
privilege is not portable).
If you spot any thinkos there, please let me know :)
~Neels
Hi all,
though promising GTP implementations are emerging from the shadows, current GTP
Hub development is still using OpenGGSN's kludgy GTP API. I'd love to switch,
but it's not the time for that yet.
To be able to query and manipulate IEs in the OpenGGSN way, I've taken the
liberty to commit below patch on openggsn.git/master, which publishes gtpie.h.
~Neels
commit 6c06d25667f7c46e179bfd1121c512234c98649f
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Tue Oct 27 14:57:18 2015 +0100
make install: also install gtpie.h
diff --git a/gtp/Makefile.am b/gtp/Makefile.am
index 4ad9f65..9586dfe 100644
--- a/gtp/Makefile.am
+++ b/gtp/Makefile.am
@@ -1,6 +1,6 @@
lib_LTLIBRARIES = libgtp.la
-include_HEADERS = gtp.h pdp.h
+include_HEADERS = gtp.h pdp.h gtpie.h
AM_CFLAGS = -O2 -fno-builtin -Wall -DSBINDIR='"$(sbindir)"' -ggdb $(LIBOSMOCORE_CFLAGS)
Hey all,
I am having some trouble in initializing osmo-nitb.
When i run osmo-nitb -c /etc/osmocom.openbsc.cfg -l /etc/osmocom.openbsc.cfg
P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNMi am receiving an error
DB: Failed to create connection.
DB: Failed to init database. Please check the option settings.
Can anyone please guide me how to proceed??
I have checked all the drivers required initialze database as per suggested in
http://openbsc.osmocom.org/trac/wiki/osmo-nitb
Still the issue is consistent.
Hi all!
This is the announcement for the re-incarnation of our bi-weekly
Osmocom Berlin Meeting.
Oct 21, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin
There is no formal presentation this time, but
* there will be SDR equipment in case more people are interested
to have a look at MPT1327 and/or Tetrapol signals that can be
received in Berlin
* Harald would like to discuss OpenBSC website / documentation
improvements
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(a)gnumonks.org>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> > +uint64_t decode_big_endian(const uint8_t *data, size_t data_len)
> > +uint8_t *encode_big_endian(uint64_t value, size_t data_len)
> have you looked at osmo_load64le_ext of libosmocore? I think you don't need
> these routines. and it applies to GSUP too.
Ah, nice. Hadn't seen those yet.
Oh well, I notice that the decode_big_endian() is more elegant to use than
osmo_load64be_ext(), since passing a length of less than 8 bytes to
decode_big_endian() writes the N least significant bytes, and allows this:
uint16_t val;
val = decode_big_endian(buf, sizeof(val));
It has the desired result. However this:
uint16_t val;
val = osmo_load64be_ext(buf, sizeof(val));
will write the bytes bound to the "wrong", most significant end of the
uint64_t, and only zero is written to val. So I would need to explicitly
use osmo_load16be().
Which is less elegant, isn't it? Is it about performance? Would changing
that behavior break anything besides bitrev_test.c? (It checks for exactly
this ordering)
I'd like to change only the osmo_loadXXbe_ext() function, so that it
writes the least significant bytes, like decode_big_endian() does. But
first, does it write the most significant end for a reason?
If it doesn't, we don't actually need to generate functions for each
integer size. Instead we can glorify the decode_big_endian() and
encode_big_endian(), made threadsafe, to become osmo_load/store*().
Right??
Except for bitrev_test.c, all callers I found (in my currently cloned few
source trees) use only the non-"_ext" functions, and would not be affected
by the change at all.
~Neels
P.S.: Holger, after I said to you that osmo_loadXXbe_ext is not less
elegant after all, I re-re-realized that it is indeed still less
elegant...
Dear Harald,
Now that the implementation of the IuH interface is on its way, can you please recommend any femtos which you think can probably be used with this implementation? I think in a previous conversation in this subject someone mentioned that probably Alcatel based units has the highest chance because of certain configuration and/or implementation options.
Anyway, if you can shed some light on this subject, that would be awsome.
Thanks!
Csaba
> On 18 Oct 2015, at 05:26, Marcin Starzyk <marcin.starzyk(a)gmail.com> wrote:
>
Hi!
> Is it acceptable for you?- if so - how should I start? (I've read section for developers on openbsc wiki but still things are not clear to me as to how to start)
0.) The first libdbi corruption has been fixed by a patch[1]. You might just
suffer from this one.
1.) In OpenBSC and when linking against libdbi 0.9 we get crashes on i386.
I have a first analysis here[2] you could see which part fails. E.g. you could
start compiling libdbi/libdi-drivers on your system with the address sanitizer
(ASAN) and see if crashes are already triggered by the builtin testsuite, if
not move on to OpenBSC
2.) Start looking into replacing libdbi calls with direct sqlite3 calls. To store
"BLOB" libdi was wrapping it and we either copy that code or we migrate
the data. E.g. have a look at how we migrate SMS on a schema change.
1st and 2nd are two alternatives, both of them have ups and downs and are
acceptable ways to move forward.
holger
[1] https://github.com/sysmocom/meta-telephony/blob/master/recipes-misc/libdbi/…
[2] http://sourceforge.net/p/libdbi/mailman/message/32607036/
Here is the part of the branch openbsc:neels/gtphub that I believe may be
merged to master at this point. (Holger: please go ahead with the merge, or
tell me to do so...)
The remaining bit is mostly a unit test netcat'ing to a gtphub instance. To do
that properly, gtphub must be configurable. Hence I'm starting to add VTY
config, which is not complete yet. Hence that part is still omitted here.
Neels Hofmeyr (15):
Add GTP hub stub, as simplistic UDP forwarder.
gtphub: add to build
gtphub: add skeletal gtphub.[hc]
gtphub: populate API impl from test prog
gtphub: add a todo comment
gtphub: add TEI map API.
gtphub: add gtphub_test.c (empty)
gtphub: add TEI map test
gtphub: add GTP header validation
gtphub: undup code: memset on a struct.
gtphub: tweak logging
gtphub: index IEs, decode and log a few.
gtphub: split gtp_relay() in r/w funcs
gtphub: map sequence numbers SGSNs<->GGSNs
gtphub: add signal handler to gtphub_main
openbsc/.gitignore | 2 +
openbsc/configure.ac | 1 +
openbsc/include/openbsc/Makefile.am | 3 +-
openbsc/include/openbsc/debug.h | 1 +
openbsc/include/openbsc/gtphub.h | 151 ++++++++
openbsc/src/gprs/Makefile.am | 4 +
openbsc/src/gprs/gtphub.c | 714 ++++++++++++++++++++++++++++++++++++
openbsc/src/gprs/gtphub_main.c | 256 +++++++++++++
openbsc/tests/Makefile.am | 2 +-
openbsc/tests/gtphub/Makefile.am | 15 +
openbsc/tests/gtphub/gtphub_test.c | 117 ++++++
openbsc/tests/gtphub/gtphub_test.ok | 1 +
openbsc/tests/testsuite.at | 7 +
13 files changed, 1272 insertions(+), 2 deletions(-)
create mode 100644 openbsc/include/openbsc/gtphub.h
create mode 100644 openbsc/src/gprs/gtphub.c
create mode 100644 openbsc/src/gprs/gtphub_main.c
create mode 100644 openbsc/tests/gtphub/Makefile.am
create mode 100644 openbsc/tests/gtphub/gtphub_test.c
create mode 100644 openbsc/tests/gtphub/gtphub_test.ok
--
2.1.4
Dear Sir
It's mentioned on the site that the non-secure authorization is feasible
with IMEI/IMSI. How can we authorize any MS using IMEI ??
I mean, the authorization field is in the Subscriber table of the database
so how is it possible to set authorization with IMEI number.
Regards.
From: Pablo Neira Ayuso <pablo(a)soleta.eu>
Holger reports that the bitmap that accounts for available Osmux circuit
IDs is limited to 128, when the maximum number of circuit IDs are
determined by the uint8_t field in the header (ie. 256 circuits).
---
@Holger: Will be revisiting libosmo-netif too, at quick glance I can see
insufficient validation of several functions there that take this
allocated ccid as input parameter.
openbsc/src/libmgcp/mgcp_osmux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/src/libmgcp/mgcp_osmux.c b/openbsc/src/libmgcp/mgcp_osmux.c
index 90b7368..d110f42 100644
--- a/openbsc/src/libmgcp/mgcp_osmux.c
+++ b/openbsc/src/libmgcp/mgcp_osmux.c
@@ -530,7 +530,7 @@ int osmux_send_dummy(struct mgcp_endpoint *endp)
}
/* bsc-nat allocates/releases the Osmux circuit ID */
-static uint8_t osmux_cid_bitmap[16];
+static uint8_t osmux_cid_bitmap[(OSMUX_CID_MAX + 1) / 8];
int osmux_get_cid(void)
{
--
2.1.4
Daniel,
your from address had triple l's in them. Just saying in case some config
needs fixing. I noticed because I was replying on a patch and got a
bounce from sysmocom.de.
~Neels
Hello list,
I have compiled OpenBSC stack following the link http://openbsc.osmocom.org/trac/wiki/network_from_scratch.
Everything has been compiled and configured smoothly except osmo-bts.For installing osmo-bts,i git cloned master branch from https://github.com/osmocom/osmo-bts.
Following the link, i did configure --enable-trx and when make osmo-bts, i am getting the following error:
l1_if.c: In function ‘bts_model_l1sap_down’:
l1_if.c:552:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:553:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:554:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:555:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:580:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:581:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:582:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
l1_if.c:583:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’
make: *** [l1_if.o] Error 1
I have tried it with the change branch: jolly/trx and also tried to make osmo-bts-trx in the src directory of osmo-bts but same error persisits.
Any help in this regard will be a worth.
Thanks
Best Regards
From: Daniel Willmann <dwillmann(a)sysmocom.de>
Hello,
the following patches should complete the usage of RAND_bytes() for
GPRS. Jacob improved the SGSN test case so it would extract the PTMSI
from the LLC frames and use those in the response.
This means the gprs_sgsn patch will not break the test anymore.
Furthermore, I changed the gbproxy implementation and test case to use
RAND_bytes() instead of rand_r(). The test case previously used rand_r()
to (re-)set the seed value for TLLI/PTMSI allocation in order to get
predictable results. With RAND_bytes() this is not possible. Instead the
tests overrides that function, replacing it with a predictable sequence
of random numbers.
Regards
Daniel
Daniel Willmann (3):
gprs: Use RAND_bytes for p-tmsi
gbproxy/test: Add and call cleanup_test function
gprs/gb_proxy: Use RAND_bytes for gbproxy TLLI/TMSI allocation
Jacob Erlbeck (2):
sgsn/test: Add and call cleanup_test function
sgsn/test: Really parse received DL LLC messages
openbsc/include/openbsc/gb_proxy.h | 4 -
openbsc/src/gprs/Makefile.am | 7 +-
openbsc/src/gprs/gb_proxy.c | 16 +-
openbsc/src/gprs/gprs_sgsn.c | 6 +-
openbsc/tests/gbproxy/Makefile.am | 4 +-
openbsc/tests/gbproxy/gbproxy_test.c | 110 +++++---
openbsc/tests/gbproxy/gbproxy_test.ok | 514 +++++++++++++++++-----------------
openbsc/tests/sgsn/Makefile.am | 2 +
openbsc/tests/sgsn/sgsn_test.c | 133 +++++++--
9 files changed, 464 insertions(+), 332 deletions(-)
--
2.1.4
From: Daniel Willmann <dwillmann(a)sysmocom.de>
The following patches uses RAND_bytes() from openssl instead of rand() to
generate TMSI/P-TMSI and auth tuples.
I didn't change the use of rand_r() in gb-proxy because the gbproxy test seems
to depend on predictable randomness.
Daniel Willmann (4):
libmsc: Use RAND_bytes when choosing a tmsi
gprs: Use RAND_bytes for p-tmsi
libmsc: Use RAND_bytes to choose auth tuple
libmsc: Use RAND_bytes to generate a token
openbsc/configure.ac | 2 +-
openbsc/src/gprs/gprs_sgsn.c | 4 +++-
openbsc/src/libmsc/Makefile.am | 2 +-
openbsc/src/libmsc/auth.c | 9 +++++++--
openbsc/src/libmsc/db.c | 12 ++++++++++--
openbsc/src/osmo-nitb/Makefile.am | 2 +-
openbsc/tests/channel/Makefile.am | 2 +-
openbsc/tests/db/Makefile.am | 2 +-
8 files changed, 25 insertions(+), 10 deletions(-)
--
2.1.4
---
gtp/gtp.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index e6a610d..de6a7b4 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -614,6 +614,15 @@ int gtp_notification(struct gsn_t *gsn, int version,
return 0;
}
+/* Look for a message in the response queue for the given peer and sequence
+ * number seq. If found, (re-)send the response message and return 0. Otherwise
+ * return nonzero. This allows catching duplicate messages.
+ * A response message stays in the response queue until it times out.
+ * So, for any number of identical requests within that timeout period, the
+ * same packet can be resent.
+ * TODO this only checks the peer and sequence number, and does not verify that
+ * the GTP request is identical to the previous one for this peer and sequence
+ * nr: a mere peer or seq glitch can cause leaks of previous responses. */
int gtp_duplicate(struct gsn_t *gsn, int version,
struct sockaddr_in *peer, uint16_t seq)
{
@@ -873,7 +882,7 @@ int gtp_echo_ind(struct gsn_t *gsn, int version, struct sockaddr_in *peer,
int fd, void *pack, unsigned len)
{
- /* Check if it was a duplicate request */
+ /* Repeat previous response in case of duplicate request */
if (!gtp_duplicate(gsn, 0, peer, get_seq(pack)))
return 0;
@@ -1258,7 +1267,7 @@ int gtp_create_pdp_ind(struct gsn_t *gsn, int version,
uint8_t linked_nsapi = 0;
struct pdp_t *linked_pdp = NULL;
- /* TODO describe what this is all about: */
+ /* Repeat previous response in case of duplicate request */
if (!gtp_duplicate(gsn, version, peer, seq))
return 0;
@@ -1955,10 +1964,9 @@ int gtp_update_pdp_ind(struct gsn_t *gsn, int version,
uint64_t imsi;
uint8_t nsapi;
- /* Is this a duplicate ? */
- if (!gtp_duplicate(gsn, version, peer, seq)) {
- return 0; /* We already sent of response once */
- }
+ /* Repeat previous response in case of duplicate request */
+ if (!gtp_duplicate(gsn, version, peer, seq))
+ return 0;
/* Decode information elements */
if (gtpie_decaps(ie, version, pack + hlen, len - hlen)) {
@@ -2432,10 +2440,9 @@ int gtp_delete_pdp_ind(struct gsn_t *gsn, int version,
int n;
int count = 0;
- /* Is this a duplicate ? */
- if (!gtp_duplicate(gsn, version, peer, seq)) {
- return 0; /* We already sent off response once */
- }
+ /* Repeat previous response in case of duplicate request */
+ if (!gtp_duplicate(gsn, version, peer, seq))
+ return 0;
/* Find the linked context in question */
if (pdp_getgtp1(&linked_pdp, get_tei(pack))) {
--
2.1.4
Hi,
I just noticed that the GGSN returns its IP address in a GTP packet about
PDP, in the "End User Address" IE (etsi/GSM/by_chapter/29.060.pdf 7.7.27).
I'm asking myself whether this needs to be mapped by gtphub.
127.0.0.3 127.0.0.2
SGSN <-------- GTPHUB <--------- GGSN
"127.0.0.2" "127.0.0.2"
map this? ^
This sounds almost like no mapping is required, as if it tells the MS
which IP address it has "as seen from outside":
"The PDP Address shall be the address that this PDP context of the MS is
identified with from the external packet data network."
But I have no idea, really. Does anyone else? If not, we'll just have to
see later...
Thanks!
~Neels
Hi openbsc,
here is my improved version of the OAP aka SGSN-ID patch series.
This series is pushed to the neels/sgsn-id-3 branch.
This version is substantially simpler, because I decided against factoring out
the IPA client. Instead, the gprs_gsup_client.c will directly call the OAP API
to handle OAP messages. Factoring out the IPA client was not a requirement and
taking too much time, and since the name will remain "GSUP client" (to avoid
changing the VTY configuration names among other things), it does after all
make sense to think of it as: "the GSUP client employs OAP to authenticate"
instead of "GSUP and OAP are two separate clients on the IPA wire".
The OAP spec has changed. Particularly instead of SRES and Kc, the challenge
response now sends XRES only; and the spec now includes an AUTS request (not
yet implemented).
Going through the changes, I've made a few fixes (like wrong file header
comments), and made some changes. The OAP API looks quite different, and now
merely returns struct msgb* and lets the caller take care of sending.
This time, OAP has its own separate testsuite tests/oap.
I have further OAP tests in mind to add; particularly the complete SGSN
registration test from the previous patch version is not yet included here.
Anyway, the OAP API test has become more comprehensive.
Some of the patch mods have come from comments by hfreyther and jerlbeck, other
changes were obvious from reviewing the code.
I think this time around the patch is much more mature. I hope you agree, if
not I'll gladly improve it further, of course :)
Thanks for your reviews!
~Neels
These patches fix some things that hurt my eyes. The renames from dublicate to
duplicate may theoretically break API compat, but I could find no affected
callers. These are not required, feel free to veto...
~Neels
Hi all!
This is an announcement for an "irregular" Berlin Osmocom User Group
event.
David Rupprecht of Ruhr-Uni Bochum has offered to give us a presentation
sharing his experience in Running OpenAirInterface.
OpenAirInterface (http://openairinterface.eurecom.fr/) is a project of
the Eurecom research institute in Sofia Antipoils / France. For many
years they have been working towards an open source SDR LTE
implementation.
The presentation will be held on
Oct 15, 8pm @ IN-Berlin, Lehrter Str. 53, 10557 Berlin
(yes, this is _NOT_ CCC Berlin where regular OSMUG meetings are held!)
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 about the venue can be found at
http://www.in-berlin.de/space/
The official event announcement website is
http://openbsc.osmocom.org/trac/blog/david-rub-openair-20151015
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi openbsc,
the following patch series adds a GTP hub program (maturity level:
proof-of-concept). Its aim is related to the recent addition of OAP: it will
allow routing multiple SGSNs through one GTP server hub (proxy).
The program so far forwards UDP packets to and from hardcoded ports, and logs
validity of GTP headers passing through. I think this a good time to do a
review cycle and merge to master, before adding the interesting stuff.
What will follow: decode GTP body, map/separate PDP contexts across clients and
servers, replace TEIs. To do that without reinventing the GTP wheel, I may need
to separate data parsing from send/recv in openggsn.
There are also some bits that should probably be moved out (to where I copied
it from) and the API there changed (so that I can use it here without copying).
Those are clearly marked with todo comments.
Thanks for your review!
~Neels
Hi Nico,
[responding to the openbsc list, as it is more applicable than
baseband-devel]
On Sun, Oct 04, 2015 at 01:59:41PM +0200, Nico Golde wrote:
> For those interested... is there any code for osmo-iuh already available
> somewhere? I don't see it on git.osmocom.org.
it is not yet published, I would like to do that at the date of the
event itself. It will be on git.osmocom.org.
The actual core HNBAP/RUA code is already there. Next is the plan on
how to integrate with the existing OsmoNITB. Somehow the A interface
code needs to be abstracted out, so that a subscriber_connection can
either be served by an A or by an IuCS interface.
Another step currently needed is UMTS AKA in the NITB.
Once the above two problem areas are adressed, we should have a solution
that works at least for signalling (LU, SMS, USSD,...).
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all!
This is the announcement for the re-incarnated Osmocom Berlin meeting:
Oct 7, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin
Harald will be presenting about the Iuh protocol stack of UMTS small
cells / femtocells and his work towards implementing it as part of
Osmocom.
Agenda:
20:00h Welcome
20:15h Presentation about Iuh / osmo-iuh
21:00h Informal meeting / chatting
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. There is no
registration required. The meeting is free as in "free beer", despite
no actual free beer being around.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
One of our BS-11 stations began to behave strangely. I see the following messages
during boot-up:
PHASE: 1 Load SMU Intended Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: No Load Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: No Load Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: Load BTSCAC Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: No Load Abis-link: Down
It looks like BS tries to load firmware on MBCCU1 and then gives up.
I tried to delete and re-create trx1 objects using bs11_config, no result.
Tried to reflash BS11, but got software load NACK, and when using —force option
the software download process finishes but the boot-up message is the same as above.
Does it mean that TRX1 is failed and cannot be used no more?
Best Regards,
Sergey.
Hello,
One of our BS-11 stations began to behave strangely. I see the following messages
during boot-up:
PHASE: 1 Load SMU Intended Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: No Load Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: No Load Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: Load BTSCAC Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: No Load Abis-link: Down
It looks like BS tries to load firmware on MBCCU1 and then gives up.
I tried to delete and re-create trx1 objects using bs11_config, no result.
Tried to reflash BS11, but got software load NACK, and when using —force option
the software download process finishes but the boot-up message is the same as above.
Does it mean that TRX1 is failed and cannot be used no more?
Best Regards,
Sergey.