osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

482 discussions

[PATCH net-next v3 0/8] gtp: misc improvements

by Andreas Schultz

Hi Pablo, This is v3 of the GTP improvements. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlaping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. There was also some length off-list conversation about why the netdevice to socket relation needs to be changed at all. Harald did already agree to this but Pablo had some questions. I've tried to address that with a bit of dokumentation for the GTP module. Hopefully this will explain the need for the change sufficiently. This series does have conflicts with the SGSN side tunnel work done by Jonas Bonn. The unification of the tunnel Rx code touches the same places he changed. v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (8): gtp: add documentation gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context Documentation/networking/gtp.txt | 112 ++++++++ drivers/net/gtp.c | 548 +++++++++++++++++++-------------------- 2 files changed, 386 insertions(+), 274 deletions(-) create mode 100644 Documentation/networking/gtp.txt -- 2.10.2

8 years, 5 months

Roaming allowed for using local sims

by Saba Arshad

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

8 years, 5 months

osmocom Kernel GTPU module - Support for incoming DL packets for idle mode users in S-GW /SGSN

by Anoop Singh Tomar

Hi , Posting question related to capability to implement user plane (GTP tunnel) for S1-U and Iu-PS interface between S-GW & eNB and SGSN & RNC respectively via osmocom kernel GTP-U module. At present it seems if TE-ID is not valid packet is dropped in kernel GTP-U module. So in order to use this for S1-U/Iu-PS interface it is required to add support for following use-case: * Down link packet arrival in S-GW /SGSN for UE which is in idle mode - Buffer the packet and trigger paging to move the UE to connected. a. When UE moves to idle mode - S1-U or IuPS bearer is released. In this case IP address and TE-ID of eNB/RNC becomes invalid. b. DL Packet is received for the idle mode UE in S-GW/SGSN - In this case , kernel GTP-U module should deliver packet to user-space application (SGW/osmoSGSN) so that these packets can be buffered in user space and paging can be initiated. Question - Is there any plan to support above in near-future in osmocom kernel GTP-U module or larger question would be to plan to enable usage of kernel GTP-U module in SGSN and SGW towards RAN ? Thanks, Anoop

8 years, 5 months

RFC: unit tests for kernel GTP module

by Harald Welte

Dear GTP-interested folks, I would love to somehow get towards some degree of unit testing (or even "continuous integration") for teh kernel GTP code. We currently have the original code in the kernel, we had some recent small fixes and now are getting more patches into place. With relatively few active users out there (and probably none of them in production yet), it's particularly easy to introduce regressions while working on the code. Also, having tested new code even against a test set with limited covrage could help to get more confidence in new patches and thus get them merged sooner. Using tools like sgsnemu of OpenGGSN and the command line tools included in libgtpnl, it should be possibel to cook up some scripts for testing. Even the most basic set of tests would be an improvement over what we have now. One could also think about pcap replay to test with hand-crafted or real-world packets from other GTP implementations. As much as I'd like to put something like this into place myself, I don't think I will be able to work much on this in the near future. The GTP module at this point is a pure hobby and contrary to some years ago while I started it, I don't have any contract work in the GTP area at this point, so other projects currently unfortunately get more attention. So in case somebody among the GTP-interested parties (Travelping, OAI, ...) would want to do something in terms of testing, I'd be more than happy if somebody would step ahead. Otherwise it's all just vapourware going to end up on my ever-growing TODO list :/ Also, if netdev folks have some ideas/pointers about possible frameworks/tools for this kind of testing [it must exist for at least some other kernel networking code?]: Please let me know. I'd be interested to have a look if there's something that can be used as a basis (starting network namespaces, sending/transmitting packets, test case startup/teardown, ...) My "old school" approach would have been to start one or multiple user-mode-linux kernels (those that are to be tested), and then have scripts that set up a gtp socket and gtp tunnels via the libgtp command line tools, and throw packets at that. But I'm sure there must be quite powerful frameworks for that kind of testing in the 21st century? How do other tunneling implementations handle this? Regards, Harald -- - 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)

8 years, 5 months

Re: [PATCH 1/1] gtp: support SGSN-side tunnels

by Harald Welte

Hi Andreas, Pablo, Jonas, I think that the SGSN/GGSN role flag (or whatever it may end up being called) logically belongs in the gtp-device at this point, and will in the future belong to the UDP/GTP-socket (with Andreas' proposed changes). Having it per-pdp-context indeed seems odd and just provide a way to create broken configurations (and increase the memory use per pdp context, of which you have many more than netdevs or gtp-sockets). -- - 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)

8 years, 5 months

tbf test segfault

by Max

Hi. The current OsmoPCU master has segfault in tbf test - at least on my machine: Destroying MS object, TLLI = 0x00000000 === start test_tbf_dl_llc_loss === Assert failed !check_element_exists(cnode, cmd->string) command.c:626 backtrace() returned 9 addresses /usr/lib/x86_64-linux-gnu/libosmovty.so.3(install_element+0xce) [0x7ffff77a5f9e] /usr/lib/x86_64-linux-gnu/libosmovty.so.3(install_element_ve+0x11) [0x7ffff77a6411] /usr/lib/x86_64-linux-gnu/libosmogb.so.4(gprs_ns_vty_init+0x17) [0x7ffff79c1da7] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x22640) [0x555555576640] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x1a73a) [0x55555556e73a] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x1697f) [0x55555556a97f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ffff67e53f1] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x16eda) [0x55555556aeda] Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007ffff67fc3ea in __GI_abort () at abort.c:89 #2 0x00007ffff77a5fa3 in cmd_make_descvec (descstr=<optimized out>, string=<optimized out>) at command.c:327 #3 install_element (ntype=ntype@entry=1, cmd=cmd@entry=0x7ffff7bcf680 <show_ns_cmd>) at command.c:630 #4 0x00007ffff77a6411 in install_element_ve (cmd=cmd@entry=0x7ffff7bcf680 <show_ns_cmd>) at command.c:637 #5 0x00007ffff79c1da7 in gprs_ns_vty_init (nsi=<optimized out>) at gprs_ns_vty.c:578 #6 0x0000555555576640 in gprs_bssgp_create_and_connect (bts=<optimized out>, local_port=<optimized out>, sgsn_ip=<optimized out>, sgsn_port=<optimized out>, nsei=<optimized out>, nsvci=<optimized out>, bvci=1234, mcc=1, mnc=1, lac=0, rac=0, cell_id=0) at gprs_bssgp_pcu.cpp:847 #7 0x000055555556e73a in test_tbf_dl_llc_loss () at tbf/TbfTest.cpp:499 #8 0x000055555556a97f in main (argc=<optimized out>, argv=<optimized out>) at tbf/TbfTest.cpp:2883 Which also seems to be reproducible in jenkins: http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/477/label=linux_amd6… That's odd cause it should have been caught by jenkins way before. Anyone else seeing this? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

8 years, 6 months

Contribute to Osmocom and receive a free 3.5G femtocell

by Harald Welte

Dear all, not everyone might have seen the news item that was posted in late December on our website at http://osmocom.org/news/62 I'm looking forward to receiving your proposal on how you would contribute to the Osmocom project if you were to receive one of those free 3.5G femtocells. Quote of the news item below: ------ So please excuse me to cross-post this over several Osmocom project mailing lists. I know that a number of people have either hacked on femtocells in the past, or at least expressed interest in doing so... Osmocom's support for 2G/GSM is mature and widespread. Since 2016, we're taking on the next level: 3G/3.5G. The key to running your own 3G network is to obtain actual 3G cell hardware -- here is an exciting opportunity to get started: No less than 50 femtocells will be given away for free by sysmocom, one of the main drivers of the Osmocom project. To receive a free 3G femtocell, tell us how you will help the Osmocom project drive 3.5G forward if you had one, before the end of January 2017. This marks the launch of the 3.5G Acceleration Project, backed by the Osmocom community. Join us! Find further details on the 3.5G Acceleration Project and receiving your own 3G femtocell for free at https://sysmocom.de/downloads/accelerate_3g5_cfp.pdf. ------ Best regards and happy hacking, Harald Welte -- - 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)

8 years, 6 months

[osmo-pcu 0.2.875-b3df5] testsuite: 3 4 failed

by Martin Hauke

-------------------------------------------------------------------- 3: tbf FAILED (testsuite.at:23) 4: bitcomp FAILED (testsuite.at:30) -------------------------------------------------------------------- os: openSUSE Tumbleweed arch: aarch64 compiler: c++ (SUSE Linux) 6.2.1 20161209 [gcc-6-branch revision 243481] configure options: --disable-static --enable-shared libosmocore: 0.9.6.48-3419 I have attached testsuite.log best regards, Martin

8 years, 6 months

osmo-pcu: Re: New Defects reported by Coverity Scan for Osmocom

by Neels Hofmeyr

On Thu, Dec 22, 2016 at 10:15:36AM -0800, scan-admin(a)coverity.com wrote: > *** CID 158969: Null pointer dereferences (FORWARD_NULL) > /source-Osmocom/osmo-pcu/src/gprs_rlcmac_sched.cpp: 131 in sched_select_ctrl_msg(unsigned char, unsigned char, unsigned int, unsigned char, gprs_rlcmac_pdch *, gprs_rlcmac_tbf *, gprs_rlcmac_tbf *, gprs_rlcmac_ul_tbf *)() > 125 struct msgb *msg = NULL; > 126 struct gprs_rlcmac_tbf *tbf = NULL; > 127 struct gprs_rlcmac_tbf *next_list[3] = { ul_ass_tbf, dl_ass_tbf, ul_ack_tbf }; > 128 > 129 for (size_t i = 0; i < ARRAY_SIZE(next_list); ++i) { > 130 tbf = next_list[(pdch->next_ctrl_prio + i) % 3]; > >>> CID 158969: Null pointer dereferences (FORWARD_NULL) > >>> Comparing "tbf" to null implies that "tbf" might be null. > 131 if (!tbf) > 132 continue; > 133 > 134 /* > 135 * Assignments for the same direction have lower precedence, > 136 * because they may kill the TBF when the CONTROL ACK is Even though coverity triggered on the recent addition of tbf->ms()->update_dl_ctrl_msg(); in osmo-pcu da7250ad2c1cd5ddc7d3c6e10435a00b357ef8f7, this problem has existed before. This function is handling the tbf pointer improperly. Let's take a look: static struct msgb *sched_select_ctrl_msg( uint8_t trx, uint8_t ts, uint32_t fn, uint8_t block_nr, struct gprs_rlcmac_pdch *pdch, struct gprs_rlcmac_tbf *ul_ass_tbf, struct gprs_rlcmac_tbf *dl_ass_tbf, struct gprs_rlcmac_ul_tbf *ul_ack_tbf) { struct msgb *msg = NULL; struct gprs_rlcmac_tbf *tbf = NULL; This NULL init would only make sense if ARRAY_SIZE(next_list) were zero. Will not happen. struct gprs_rlcmac_tbf *next_list[3] = { ul_ass_tbf, dl_ass_tbf, ul_ack_tbf }; for (size_t i = 0; i < ARRAY_SIZE(next_list); ++i) { tbf = next_list[(pdch->next_ctrl_prio + i) % 3]; if (!tbf) continue; /* * Assignments for the same direction have lower precedence, * because they may kill the TBF when the CONTROL ACK is * received, thus preventing the others from being processed. */ if (tbf == ul_ass_tbf && tbf->direction == GPRS_RLCMAC_DL_TBF) if (tbf->ul_ass_state == GPRS_RLCMAC_UL_ASS_SEND_ASS_REJ) msg = ul_ass_tbf->create_packet_access_reject(); else msg = ul_ass_tbf->create_ul_ass(fn, ts); else if (tbf == dl_ass_tbf && tbf->direction == GPRS_RLCMAC_UL_TBF) msg = dl_ass_tbf->create_dl_ass(fn, ts); else if (tbf == ul_ack_tbf) msg = ul_ack_tbf->create_ul_ack(fn, ts); if (!msg) { tbf = NULL; If this is not the last for() iteration, setting tbf = NULL makes no sense, it will be set to next_list[..] at the start of the next iteration. If this *is* the last iteration, tbf = NULL makes no sense either, because msg is NULL and tbf will be set to dl_ass_tbf or ul_ass_tbf in the if (!msg) {} case below. continue; } pdch->next_ctrl_prio += 1; pdch->next_ctrl_prio %= 3; break; } if (!msg) { /* * If one of these is left, the response (CONTROL ACK) from the * MS will kill the current TBF, only one of them can be * non-NULL */ if (dl_ass_tbf) { tbf = dl_ass_tbf; msg = dl_ass_tbf->create_dl_ass(fn, ts); } else if (ul_ass_tbf) { tbf = ul_ass_tbf; msg = ul_ass_tbf->create_ul_ass(fn, ts); } } At this point, tbf may be NULL, either from 'if (!tbf) continue;' in the last iteration, or because dl_ass_tbf or ul_ass_tbf were NULL. Below code assumes that tbf is non-NULL and will segfault. Add 'if (!tbf) return NULL' here? /* any message */ if (msg) { tbf->rotate_in_list(); LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling control " "message at RTS for %s (TRX=%d, TS=%d)\n", tbf_name(tbf), trx, ts); /* Updates the dl ctrl msg counter for ms */ tbf->ms()->update_dl_ctrl_msg(); return msg; } /* schedule PACKET PAGING REQUEST */ msg = pdch->packet_paging_request(); if (msg) { LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling paging request " "message at RTS for (TRX=%d, TS=%d)\n", trx, ts); /* Updates the dl ctrl msg counter for ms */ tbf->ms()->update_dl_ctrl_msg(); return msg; } return NULL; } @osmo-pcu tbf folks, please fix this potential segmentation fault ASAP. Thanks! ~N -- - 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

8 years, 7 months

enum egprs_puncturing_values

by Neels Hofmeyr

Today I looked at enum egprs_puncturing_values by coincidence: /* * Valid puncturing scheme values * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1 */ enum egprs_puncturing_values { EGPRS_PS_1, EGPRS_PS_2, EGPRS_PS_3, EGPRS_PS_INVALID, }; I notice that TS 44.060 10.4.8a.3.1 defines further items besides PS_1, 2 and 3, and that our EGPRS_PS_INVALID occupies the value the spec defines as "MCS-3/P1". I believe that this is rather unfortunate. [[[ Table 10.4.8a.3.1: Coding and Puncturing Scheme indicator field for Header type 3 bits 4321 First block CPS ---------------------------- 0000 MCS-4/P1 0001 MCS-4/P2 0010 MCS-4/P3 0011 MCS-3/P1 0100 MCS-3/P2 0101 MCS-3/P3 0110 MCS-3/P1 with padding (MCS-8 retransmission) 0111 MCS-3/P2 with padding (MCS-8 retransmission) 1000 MCS-3/P3 with padding (MCS-8 retransmission) 1001 MCS-2/P1 1010 MCS-2/P2 1011 MCS-1/P1 1100 MCS-1/P2 NOTE: All the other values are reserved for future use The bit numbering is relative to the field position. ]]] I would prefer EGPRS_PS_INVALID=-1 (i.e. outside the spec's value range) and the other enum values named appropriately, like EGPRS_MSC4_P1, so that our enum actually reflects the spec as advertised. Is there something I'm missing? These enum values were added in: commit 7a05b039c835868eff34308d861edfeb28d1763b Author: Aravind Sirsikar <arvind.sirsikar(a)radisys.com> Date: Wed Mar 23 18:29:45 2016 +0530 Thanks, ~N -- - 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

8 years, 7 months

← Newer
1
...
25
26
27
28
29
30
31
...
49
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs