Hello,
I want to use the local sims having different MNC/MCC for implementing GPRS
using osmocoms with OpenBTS same as I have used them for GSM calls and sms
using only openBTS. But your site
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently
not possible". As it is long when posted on this site so I want to ask is
it possible *now* to use the local sims? Hope you have understood my
question. Waiting for your reply. Thanks.
Regards,
Saba Arshad
Hello All,
We have executed profiling test of two versions of algorithm for decoding compressed bitmap of EPDAN.
>From the results , we see that performance is better in Tree based decoding (Version2 as given below )
Version 1: Bitmap based decoding as present in current master branch ( Function name osmo_t4_decode )
Version 2: Tree based decoding ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> )
A sample bitmap taken from a real mobile log is used for the test.
Host execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -17 MAX -19 AVERAGE -17.9
Version 2 (tree based decoding): MIN -4 MAX -13 AVERAGE - 5.2
Target execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -277 MAX -583 AVERAGE - 353
Version 2 (tree based decoding): MIN -67 MAX -86 AVERAGE - 69.8
Regards
Prasad
I have a reproducable segfault in the SGSN, bisecting to below commit:
(To bisect, I rearranged the commits, see branches neels/sndcp_bisect and
neels/sndcp_bisect_bad in openbsc)
▶ git bisect bad
97991d56800fdc913e6fdf95cac68d598f66b498 is the first bad commit
commit 97991d56800fdc913e6fdf95cac68d598f66b498
Author: Philipp <pmaier(a)sysmocom.de>
Date: Fri Aug 26 17:00:21 2016 +0200
SNDCP: add RFC1144 header compression functionality
- Add module to handle compression entities
- Add module to control header compression
- Introduce VTY commands for heade compression configuration
- Add changes in sndcp and llc to integrate header compression
Change-Id: Ia00260dc09978844c2865957b4d43000b78b5e43
:040000 040000 de76aa0ab5dc11ad81666f9f4c933544eedcd4f1 c199c47cd19b5a1a334020a598dba3e0be922fe5 M openbsc
Reproduce: Have a 3G UE try to establish a PDP context. (basically just let it
subscribe to the network with mobile data enabled.) Yes, this is on the
sysmocom/iu branch.
Note: the N-DATA.ind shows the correct hexdump and data length, but the
backtrace shows that two lines below that a function is passed the values
ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310
So it looks like a stack corruption caused somewhere completely different. It's
very reproducable though, even after rearranging things with other library
states I always get the exact same place segfaulting:
20160927195152039 <001a> iu.c:755 N-DATA.ind(0, 60 00 00 1d 00 00 01 00 34 40 16 00 00 01 00 33 40 0f 60 28 dc 35 00 01 0a 09 01 0b 00 00 00 00 01 , len 33)
20160927195152039 <001a> iu.c:757 1msg 0x6d07a8 len 33
20160927195152039 <001a> iu.c:767 2msg 0x6d07a8 len 33
<RANAP_RAB-SetupOrModifiedList>
<raB-SetupOrModifiedList-ies>
<RANAP_IE>
<id>51</id>
<criticality><ignore/></criticality>
<value>60 28 DC 35 00 01 0A 09 01 0B 00 00 00 00 01</value>
</RANAP_IE>
</raB-SetupOrModifiedList-ies>
</RANAP_RAB-SetupOrModifiedList>
20160927195152039 <001a> iu.c:460 handle_co(dir=4, proc=0)
20160927195152039 <001a> iu.c:433 RAB Asignment Response:<RANAP_RAB-SetupOrModifiedItem>
<rAB-ID>
00000101
</rAB-ID>
<transportLayerAddress>
00110101000000000000000100001010000010010000000100001011
</transportLayerAddress>
<iuTransportAssociation>
<gTP-TEI>00 00 00 01</gTP-TEI>
</iuTransportAssociation>
</RANAP_RAB-SetupOrModifiedItem>
Setup: (5/35 00 01 0a 09 01 0b )20160927195152039 <001a> sgsn_libgtp.c:483 Updating TEID on RNC side from 0x00000001 to 0x00000001
20160927195152039 <000f> gprs_gmm.c:2031 PDP(901990000000038/0) <- ACTIVATE PDP CONTEXT ACK
20160927195152039 <001a> iu.c:398 Transmitting L3 Message as RANAP DT (SUA link 0x6ce280 conn_id 0)
<RANAP_IE>
<id>16</id>
<criticality><ignore/></criticality>
<value>
31 8A 42 03 0E 23 62 1F 72 99 3F 3F 11 43 FF FF
00 00 00 00 2B 06 01 21 0A 17 2A 02 27 14 80 80
21 10 02 00 00 10 81 06 08 08 08 08 83 06 00 00
00 00
</value>
</RANAP_IE>
<RANAP_IE>
<id>59</id>
<criticality><ignore/></criticality>
<value>00</value>
</RANAP_IE>
20160927195152039 <001b> sua.c:591 Received SCCP User Primitive (N-DATArequest)
20160927195152039 <001b> sua.c:245 sua_link_send(01 00 08 08 00 00 00 60 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 46 00 14 00 3e 00 00 02 00 10 40 32 31 8a 42 03 0e 23 62 1f 72 99 3f 3f 11 43 ff ff 00 00 00 00 2b 06 01 21 0a 17 2a 02 27 14 80 80 21 10 02 00 00 10 81 06 08 08 08 08 83 06 00 00 00 00 00 3b 40 01 00 00 00 )
Program received signal SIGSEGV, Segmentation fault.
sndcp_sn_xid_req (lle=0x340, nsapi=5 '\005') at gprs_sndcp.c:926
926 gprs_sndcp_comp_free(lle->llme->comp.proto);
(gdb) bt
#0 sndcp_sn_xid_req (lle=0x340, nsapi=5 '\005') at gprs_sndcp.c:926
#1 0x0000000000415681 in send_act_pdp_cont_acc (pctx=0x6d0290)
at sgsn_libgtp.c:346
#2 0x0000000000416ba6 in sgsn_ranap_rab_ass_resp (ctx=0x340, setup_ies=0x0)
at sgsn_libgtp.c:492
#3 0x0000000000422e28 in ranap_handle_co_rab_ass_resp (ies=<optimized out>,
ies=<optimized out>, ctx=<optimized out>) at iu.c:445
#4 cn_ranap_handle_co (ctx=0x6cf9d0, message=0x0) at iu.c:510
#5 0x00007ffff5909f60 in ranap_cn_rx_co (cb=0x422890 <cn_ranap_handle_co>,
ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310
#6 0x0000000000423d1c in sccp_sap_up (oph=0x6d06a8, link=0x6ce280) at iu.c:768
#7 0x00007ffff5be6c7f in sua_rx_codt (xua=<optimized out>,
link=<optimized out>) at sua.c:1164
#8 sua_rx_co (msg=<optimized out>, xua=<optimized out>, link=<optimized out>)
at sua.c:1196
#9 sua_rx_msg (link=0x0, msg=0x5) at sua.c:1232
#10 0x00007ffff5be7042 in sua_srv_conn_cb (conn=0x6cf300) at sua.c:1360
#11 0x00007ffff4c4c881 in osmo_stream_srv_read (conn=0x6ce1b0) at stream.c:512
#12 osmo_stream_srv_cb (ofd=<optimized out>, what=1) at stream.c:563
#13 0x00007ffff79bab82 in osmo_fd_disp_fds (_eset=0x7fffffffe360,
_wset=0x7fffffffe2e0, _rset=0x7fffffffe260) at select.c:149
#14 osmo_select_main (polling=0) at select.c:191
#15 0x0000000000404ee2 in main (argc=3, argv=0x0) at sgsn_main.c:448
(gdb)
How do we do this? Revert Philipps commits for now?
I need to go now, but next I'll take a short look whether I can reproduce with
other hardware / spot a bug anywhere. No idea yet whether it only happens for
3G.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
> On my side, I have no plans to add what you need, so patches are very
> welcome. I can help providing indications on how to get things done if you
> have time to work on this. So I would suggest you fire at one front at a time.
>
> I would start by adding the assymmetric tunnel ID allocation that you need,
> which should not be too complicated to add. You have to extend the netlink
> interface that we have on gtp to support this.
>
Thanks Pablo for the kind response, I will study the docs and the gtp module and try to propose some patches.
Rgds,
Vicent
Hi!
We are affiliated with Aalto University and conducting research in the area of mobile networks. We have been improving Amit Chawre's project NwEPC<https://sourceforge.net/projects/nwepc/>. I saw your implementation of the GTP-U kernel module and I started to check If I could integrate it to this project.
I couldn't find any roadmap of the GTP-U in your website. Do you have any future plans for it? I am interested in the following points:
- Creation, modification and removal of unidirectional tunnels, opposed to the creation of both tunnels without possibility of modification. In the real EPC nodes, the tunnels are never created at the same time. Also they can be removed due to the UE moving to Idle state (i.e. GTP downlink between the eNB and the S-GW).
- Possibility to send End Marker and direct and indirect forwarding tunnels.
- The S-GW receive from a GTP endpoint and sends it to a different one. What mechanisms do you have in mind to do this?
- Support of multiple EPS bearers for the same UE.
- Policy control, enforcement and statistics reporting (probably integrating it with netfilter).
How can I contribute to this project. Should I work on the whole kernel tree? I have no experience with kernel module development. If you want I could work on some API modification proposals and designs.
Kind Regards,
Vicent Ferrer Guasch
PhD candidate
Networking Technology
Department of Communications and Networking
Aalto University
Dear Members,
I have applied the GTP-U patch for OVS which was available online and it
was applied successfully. But now I realised that a GTP-U kernel space
implementation is available from you. I am not sure of the interplay of OVS
and linux kernel. The patch for the OVS works in the kernel space and if I
want to use the patched OVS with your linux kernel patch, should I do some
modifications to the patch?
Best Regards,
Ashish Kurian
For strncat, to obtain n, one must not subtract the length of what is appended,
but the length of what is already written from the buffer size.
Verified with this little test program:
#include <stdio.h>
#include <string.h>
int main() {
char buf[20];
strncpy(buf, "123", 10);
strncat(buf, "456789012345", 10 - strlen(buf));
printf("%s\n", buf);
return 0;
}
It prints "1234567890".
---
gtp/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index 12cb492..55a8ce4 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -650,7 +650,7 @@ static void log_restart(struct gsn_t *gsn)
filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */
strncpy(filename, gsn->statedir, NAMESIZE - 1);
- strncat(filename, RESTART_FILE, NAMESIZE - 1 - sizeof(RESTART_FILE));
+ strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename));
i = umask(022);
--
2.1.4
---
gtp/gtpie.c | 3 +++
gtp/gtpie.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/gtp/gtpie.c b/gtp/gtpie.c
index a45df1c..c8db449 100644
--- a/gtp/gtpie.c
+++ b/gtp/gtpie.c
@@ -243,6 +243,7 @@ int gtpie_decaps(union gtpie_member *ie[], int version,
void *pack,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
+ case GTPIE_BCM:
if (j < GTPIE_SIZE) {
ie[j] = (union gtpie_member *)p;
if (GTPIE_DEBUG)
@@ -457,6 +458,7 @@ int gtpie_encaps(union gtpie_member *ie[], void *pack,
unsigned *len)
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
+ case GTPIE_BCM:
iesize = 2;
break;
case GTPIE_FL_DI: /* TV GTPIE types with value length 2 */
@@ -558,6 +560,7 @@ int gtpie_encaps2(union gtpie_member ie[], unsigned int
size,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
+ case GTPIE_BCM:
iesize = 2;
break;
case GTPIE_PFI: /* TV GTPIE types with value length 2 */
diff --git a/gtp/gtpie.h b/gtp/gtpie.h
index 340a76c..fb8598e 100644
--- a/gtp/gtpie.h
+++ b/gtp/gtpie.h
@@ -106,6 +106,7 @@ static __inline uint64_t hton64(uint64_t q)
#define GTPIE_USER_LOC 152 /* User Location Information */
#define GTPIE_MS_TZ 153 /* MS Time Zone */
#define GTPIE_IMEI_SV 154 /* IMEI Software Version */
+#define GTPIE_BCM 184 /* Bearer control mode */
/* 239-250 Reserved for the GPRS charging protocol (see GTP' in GSM 12.15)
*/
#define GTPIE_CHARGING_ADDR 251 /* Charging Gateway Address */
/* 252-254 Reserved for the GPRS charging protocol (see GTP' in GSM 12.15)
*/
--
2.8.2.windows.1
Hello.
sgsnemu cannot establish PDP context with latest Cisco GGSN.
There is additional information element "Bearer control mode" sent by GGSN
in create PDP context response message (attachment).
This information element is not recognized by sgsnemu.
Here are the changes in libgtp to support this information element:
9 gtp/gtpie.c
@@ -243,7 +243,8 @@ int gtpie_decaps(union gtpie_member *ie[], int
version, void *pack,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
- if (j < GTPIE_SIZE) {
+ case GTPIE_BCM:
+ if (j < GTPIE_SIZE) {
ie[j] = (union gtpie_member *)p;
if (GTPIE_DEBUG)
printf
@@ -457,7 +458,8 @@ int gtpie_encaps(union gtpie_member *ie[], void *pack,
unsigned *len)
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
- iesize = 2;
+ case GTPIE_BCM:
+ iesize = 2;
break;
case GTPIE_FL_DI: /* TV GTPIE types with value length 2 */
case GTPIE_FL_C:
@@ -558,7 +560,8 @@ int gtpie_encaps2(union gtpie_member ie[], unsigned
int size,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
- iesize = 2;
+ case GTPIE_BCM:
+ iesize = 2;
break;
case GTPIE_PFI: /* TV GTPIE types with value length 2 */
case GTPIE_CHARGING_C:
1 gtp/gtpie.h
@@ -106,6 +106,7 @@ static __inline uint64_t hton64(uint64_t q)
#define GTPIE_USER_LOC 152 /* User Location Information */
#define GTPIE_MS_TZ 153 /* MS Time Zone */
#define GTPIE_IMEI_SV 154 /* IMEI Software Version */
+#define GTPIE_BCM 184 /* Bearer control mode */
/* 239-250 Reserved for the GPRS charging protocol (see GTP' in GSM
12.15) */
#define GTPIE_CHARGING_ADDR 251 /* Charging Gateway Address */
/* 252-254 Reserved for the GPRS charging protocol (see GTP' in GSM
12.15) */
--
Hi All,
Unit test execution of current master of osmo-pcu(9bbe1600cc02e1b538380393edb1dcdabe9247a2<https://git.osmocom.org/osmo-pcu/commit/?id=9bbe1600cc02e1b538380393edb1dcd…>) is getting failed with below description
regression tests
1: rlcmac ok
2: ts_alloc ok
3: tbf FAILED (testsuite.at:23)
4: edge ok
5: types ok
6: ms ok
7: llc ok
8: llist ok
9: codel ok
## ------------- ##
## Test results. ##
## ------------- ##
ERROR: All 9 tests were run,
1 failed unexpectedly.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##
Possible Reason being TbfTest.err is not updated
Thanks,
Aravind Sirsikar