- osmocom-net-gprs - lists.osmocom.org

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)

7 years, 2 months

3
3
0 0

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)

7 years, 2 months

1
0
0 0

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

7 years, 3 months

2
3
0 0

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)

7 years, 3 months

1
0
0 0

[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

7 years, 3 months

1
0
0 0

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

7 years, 4 months

1
1
0 0

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

7 years, 4 months

2
3
0 0

comments on enum egprs_puncturing_values and gprs_rlc_mcs_cps()

by Neels Hofmeyr

Hi, in the wake of https://gerrit.osmocom.org/1411 I have some more comments on the code that seem to large for the gerrit edit field. I said in that patch comment that gprs_rlc_mcs_cps() must check that it isn't using INVALID enum values in its bitfield calculations. Furthermore: The bit fields are obtained by modulo calculation on enum values. This seems unnecessarily complex and error prone, it is hard to figure out for a reader. The relation is quite direct though, e.g. for EGPRS_MAX_PS_NUM_2 it means that PS_1 and PS_3 mean + 0, PS_2 means + 1. I wish that were easier to see. It would be good to prepare that above the switch() and use it below instead of duplicating the same calculation numerous times. Thirdly, for enum egprs_puncturing_values, the comment refers to TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1. When reading the first time, I saw table 10.4.8a.3.1 reflecting the names found in the table: PS1, PS2 and PS3. And it appeared that there are values missing. Typically, when we place a spec reference on an enum in Osmocom code, it means that this enum *exactly* represents the given table. This enum, however, is "merely" an internal indicator, later translated into the table's bit values. The enum definitions should have a comment sort of like "Puncturing scheme values. See gprs_rlc_mcs_cps()" without TS table references, and TS refs should be with that function. It's also not helpful to place references to two more tables in the comment: the reader is left guessing what the exact relation is. If more than one TS table is involved, the comment should explain the relation. Cosmetic: the switch() statement in that function has line breaking that doesn't match Osmocom coding style, making it even harder to read. These are things we missed when accepting these changes. It would be nice to get them fixed at some point. 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

7 years, 4 months

1
0
0 0

RFC: OsmoDevCon 2017 planning

by Harald Welte

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] >From 2012 to 2016 we were running a series of small, invitation-only Osmocom Developer Conferences. Access was intentionally restricted to those community members who have demonstrated an existing track record of contribution to any of the projects under the Osmocom umbrella. This format of a small, tightly knit group of about 20 people has been successful over the years, and I have received a lot of positive feedback from past participants. On the other hand, the Osmocom project has grown in scope and diversity, and some of those projects don't have all that much relationship to each other - except being started by people from within the same group. There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at some point LTE) protocols which is attracting a lot of professional users. And then there's pure community projects like rtl-sdr, OsmocomBB, OsmocomGMR and many other efforts. Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU, OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow "standing out" of the othe projects in the context of having a wider user bsae, and in that user base also primarily commercial users. So I'd like to start a discussion on how to possibly change the event format to accomodate the various interests and parties. I definitely don't want to loose the "annual meeting of old friends" atmosphere, while at the same time also opening up to other interested parties. One idea would be to keep OsmoDevCon as-is and have a separate event where non-contributing/developing users / sysadmins / system integrators could also be attending. Another idea would be to split into a 'user day' and 'developer days' format. This is something the netfilter developer workshops have been using for many years, and from my limited insight quite successfully so. The "user day" is more like a traditional tech conference, with a large auditorium and talks oriented towards users / sysadmins / integrators of the software. The "developer days" are the invitation-only part, for known contributing developers only, similar to what we have at OsmoDevCon. Having both events (or both parts of an event) back-to-back has the advantage that a large number of potential speakers for the 'user day' are already present, and they don't have to travel yet another time. One could even structure it further and say we have one user day, one public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon classic', maybe reduced from 4 days to 3 or even 2 days only? What is the general opinion about this? Are there people lurking on this list who would be interested in attending a public 'user day' or even 'developer day' about the Osmocom cellular projects, with presentations and workshops around topics such as running Osmocom based cellular networks? In terms of when/where, I would suggest to keep the tradition of April in Berlin/Germany. But I'm of course very happy if somebody wants to host it some place else... Regards, and looking forward to meeting you [again] in 2017, 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)

7 years, 4 months

1
0
0 0

P*CH activation

by Max

HI. Pardon the cross-posting, I'm not sure where this question really belongs. I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what got to be activated both in DL and UL directions. Right now it's PDTCH (UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are commented out. Yet I see code dealing with PACCH in osmo-pcu and corresponding log messages. So the question is - how does this works? The PACCH seems to be used so it's somehow activated but apparently not the same way as PDTCH. -- 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

7 years, 6 months

2
1
0 0

Load balancing issue on Multi-TRX configuration

by Aravind Sirsikar

Hello All, We are testing GPRS/EGPRS functionality in Multi-TRX(2 TRX) configuration for 2MS and we observed that both the MS are always assigned resources in TRX0. It seems like there is no load balancing done Across the TRXs. Similar issue "Bug #1775 LC15: No PDCH allocation across two TRX" is raised on Multi-TRX and its status is "In Progress". Please let us know if any updates on this issue. Thanks and Regards, Aravind Sirsikar

7 years, 6 months

3
2
0 0

Profiling data of decoding EPDAN compressed bitmap

by Prasad Kaup

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

7 years, 6 months

4
17
0 0

GTP-U support for upstream Linux

by Ashish Kurian

Dear Developers, I have a question for you. As you might be knowing. there is a patch now available for OVS for GTP-U support. When the developers of the patch submitted it to add to the main branch of OVS, the OVS developers told the following. It doesn't look like upstream Linux has a GTP implementation. Because our usual workflow is to get code upstream first, you should start by submitting the kernel patches against net-next when that tree is open (I don't follow netdev, so I have no idea when that is). Then, once the GTP code is upstream, we can get it into OVS here. So, is the upstream Linux having support for GTP now? I am asking this because I am not certain about what upstream Linux means. If you say that upstream Linux has support for GTP-U, then I can ask the patch developers to port it for the latest version of OVS and add it to the main branch. Best Regards, Ashish Kurian

7 years, 6 months

2
1
0 0

Load balancing issue on Multi-TRX configuration

by Mrinal Mishra

Hello All, We are testing GPRS/EGPRS functionality in Multi-TRX(2 TRX) configuration for 2MS and we observed that both the MS are always assigned resources in TRX0. It seems like there is no load balancing done Across the TRXs. Similar issue "Bug #1775 LC15: No PDCH allocation across two TRX" is raised on Multi-TRX and its status is "In Progress". Please let us know if any updates on this issue. Thanks and Regards, Mrinal

7 years, 6 months

1
0
0 0

OpenGGSN IPv6 support

by groos＠xiplink.com

Hi All I have added IPv6 support to OpenGGSN and if anybody is interested I will gladly make my patch available. It definitely needs more testing and perhaps a bit of cleanup, but currently it can do 4-in-4, 6-in-4, 4-in-6 and 6-in-6. Gerrie

7 years, 6 months

3
2
0 0

[libgtpnl]add README.md file for build guide

by junpei yoshino

Hello I write build guide. README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..c6718d2 --- /dev/null +++ b/README.md @@ -0,0 +1,11 @@ +# How to build + +``` +$ git clone git://git.osmocom.org/libgtpnl +$ cd libgtpnl +$ autoreconf -fi +$ cd tools +$ make gtp-tunnel +$ make gtp-link +``` + Best Regards, Junpei Yoshino -- junpei.yoshino(a)gmail.com

7 years, 7 months

3
8
0 0

OpenGGSN on live networks

by Bjørn Remseth

Hi I’m Bjørn, I work for Telenor Digital. We’re running a live experimental network (called “loltel” :-) that is technically operating as a full stack MVNO (mobile virtual network operator), renting network access from Telenor Norway. It’s mostly but not exclusively based on open source components. When we started up about two years ago we considered using OpenGGSN, but couldn’t figure out how to get it into an operational state and we couldn’t find anyone to help us, so we chose a commercial vendor instead. But today we’re again thinking of using OpenGGSN for an experiment, possibly in our live network. Are there anyone on this list with experiences either with running it in a live network, or with thoughts about how to do it / what would be necessary to get the job done? We’d love to have a discussion with you. Hope to hear from you soon. Best wishes Bjørn -- Bjørn Remseth --- Senior Software Engineer (+47) 47900184 | rmz(a)comoyo.com <mailto:ane@comoyo.com> | www.comoyo.com <http://www.comoyo.com/>

7 years, 7 months

3
6
0 0

openggsn patches now via gerrit

by Neels Hofmeyr

Hi all, OpenGGSN has moved to gerrit today. Patch submissions shall go there now, no longer to this mailing list. ~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

7 years, 7 months

1
0
0 0

Installation error

by Ashish Kurian

Hi All, I downloaded the tar ball release libgtpnl-1.0.1.tar.gz and un tared it. Then I tried to build and install the package. But the command sudo ./configure is giving me the following error. configure: error: cannot find install-sh, install.sh, or shtool in build-aux "."/build-aux Do you know what could be the reason for this error? Best Regards, Ashish Kurian

7 years, 7 months

2
1
0 0

Re: Dropping packet from invalid source address

by Holger Freyther

> On 06 Oct 2016, at 09:01, Peter Lithner <plithner(a)yahoo.com> wrote: > > Hello Holger, > > I can see packets now, after creating a PDP and running tcpdump on tun0. However, the ICMP requests I send are not GTP encapsulated as I would have expected, and I can only see the "downlink" data (the ping requests, and not the replies). The ping is successful though, so the replies are sent some way. Let's say tun1 is the SGSN emu device and you have a ICMP Request in it. The kernel will tell the sgsnemu process that new data is present and the sgsnemu will then wrap the data with GTP-u and send it to the GGSN. So you should be able to see the wrapped data on the loopback device. > And like I mentioned before, I can not force delays in packet delivery by temporarily pausing the GGSN with ctrl-z. > > What I did was, exactly what you proposed. I used your config, and you command lines (with the only exception that I created to virtual interfaces instead of using 127.0.0.1 and 127.0.0.2. I tried that as well though, and behaviour was the same. > > One thing that looks a bit odd, is that when I run tcpdump on tun0 (ggsn tun interface) and run ping, I can only see the "downlink" packets. That is to say, I only see the Ping requests and not the responses. The attachment shows this. > The setup once again: > Ubuntu 16.04.01 > ggsn installed with apt-get > ggsn.cfg: > root@ip-10-7-0-240:/home/ubuntu# cat ggsn.conf > listen 192.168.1.2 > logfile /tmp/foo > loglevel DEBUG > net 10.10.10.1/24 > pcodns1 8.8.8.8 > > ggsn command line: > ggsn -c ggsn.conf -f > > sgsnemu command line: > sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --apn internet --createif > > capture: > tcpdump -i tun0 -w tun0.pcap > ping: > ping -I tun1 10.10.10.1 > So if you trace on eth0 as well you should see ICMP Echo req and GTP+U ICMP echo req. As you trace on tun0 the GGSN has received GTP-u and wrote it into tun0. Now the kernel decides not to respond. E.g. maybe your cloud image has some kind of firewall, you could try to disable the rp_filter on tun0, etc.

7 years, 7 months

2
2
0 0

Re: Dropping packet from invalid source address

by Holger Freyther

> On 05 Oct 2016, at 18:01, Peter Lithner <plithner(a)yahoo.com> wrote: > >> Dear Peter, > Peter: Did you mean ggsn on 127.0.0.2 and client on 127.0.0.1? yes. > >> While sgsnemu is running a new interface will be created (e.g. tun1 due the --createif route). Can you check >which netmask is being set there? E.g. tun_addroute is called by the sgsnemu and it might capture more than >you wanted? And in that case filter on tcpdump -i tun1 as well. > > Peter: The thing is, that I do not see any tun1 interface (only the ton0 which is created when i start ggsn). This was what I meant in my original post. > > Anyway, I used your config, and in the log file I see this: > <0002> ggsn.c:283 Set file log level to DEBUG > <0002> ggsn.c:492 gtpclient: Initialising GTP tunnel > <000c> gtp.c:700 GTP: gtp_newgsn() started > <000c> gtp.c:661 State information file (/var/lib/ggsn/gsn_restart) not found. Creating new file. > <000c> gtp.c:682 fopen(path=/var/lib/ggsn/gsn_restart, mode=w) failed: Error = No such file or directory > <0002> ggsn.c:510 Creating tun interface > <0002> ggsn.c:516 Setting tun IP address > > I'm probably just missing some stupid/obvious thing in my setup... with tcpdumo you should really see this packet and what kind of message it is. I just tried the following in Debian 8.0 VM with the config I had posted: GGSN: sudo ./ggsn/ggsn -c ./../../ggsn.conf -f SGSN: sudo ./sgsnemu/sgsnemu -l 127.0.0.1 -r 127.0.0.2 -a "foo" --createif Using default DNS server Local IP address is: 127.0.0.1 (127.0.0.1) Remote IP address is: 127.0.0.2 (127.0.0.2) IMSI is: 240010123456789 (0xf987654321010042) Using NSAPI: 0 Using GTP version: 1 Using APN: foo Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library <000c> gtp.c:701 GTP: gtp_newgsn() started Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 10.23.42.2 After network config: tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.23.42.1 P-t-P:10.23.42.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:252 (252.0 B) TX bytes:0 (0.0 B) tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.23.42.2 P-t-P:10.23.42.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:252 (252.0 B) So tun0 has been allocated by the GGSN and tun1 by the SGSN ping -I tun1 10.23.42.1 PING 10.23.42.1 (10.23.42.1) from 10.23.42.2 tun1: 56(84) bytes of data. 64 bytes from 10.23.42.1: icmp_seq=1 ttl=64 time=0.223 ms 64 bytes from 10.23.42.1: icmp_seq=2 ttl=64 time=0.132 ms 64 bytes from 10.23.42.1: icmp_seq=3 ttl=64 time=0.134 ms 64 bytes from 10.23.42.1: icmp_seq=4 ttl=64 time=0.123 ms 64 bytes from 10.23.42.1: icmp_seq=5 ttl=64 time=8914 ms (I used CTRL+Z on the ggsn to see that there are actually delays). Can you try to repeat that? holger

7 years, 7 months

1
0
0 0

Dropping packet from invalid source address

by Peter Lithner

Hi I'm trying out openGGSN, currently running it on an Ubuntu 16.04 VM in Amazon. The reason I'm doing this is part of an evaluation I'm helping out with for a customer in the Telco-industry. I have been able to install, and run ggsn and sgsnemu to the point of sending the ECHO and creating the PDP-C (see attachment). However, I can't see that a network interface is created after the PDP-C has been accepted. According to the README on https://github.com/osmobuntu/openggsn that should happen: "After this it will attempt to establish a pdp context. If successful it will create a local interface and set up routing." Anyway, I have probably missed something in the setup. If you have any suggestions, that would be highly appreciated! What I did so far is: Install sudo apt-get update sudo apt-get install openggsn Create "virtual" interfaces (since I'm running everything on the same machine. Not sure if this is the right way to do it though) ifconfig eth0:0 192.168.1.2 netmask 255.255.255.0 up ifconfig eth0:1 192.168.1.3 netmask 255.255.255.0 up I also did the following steps, but I'm not sure exactly what they do... pardon my ignorance! 1. Add the following line to /etc/modules.conf: alias char-major-10-200 tun 2. depmod -a Start GGSN ggsn -c ggsn.conf --fg -l 192.168.1.2 --net 192.168.0.0/24 --dynip 192.168.0.0/24 After this I can see the new tun0 tun0: flags=81<UP,POINTOPOINT,RUNNING> mtu 1500 inet 192.168.0.1 netmask 255.255.255.0 destination 192.168.0.1 inet6 fe80::9ea3:6876:c4ce:fc96 prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7 bytes 448 (448.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 send ECHO (successfully) sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --dns 10.20.38.51 --timelimit 10 --contexts 0 Send ECHO + Create PDP-C sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --dns 10.20.38.51 --timelimit 10 --contexts 1 --apn internet --imsi 240011234567890 --msisdn 46702123456 --createif --defaultroute Which outputs the following: Using DNS server: 10.20.38.51 (10.20.38.51) Local IP address is: 192.168.1.3 (192.168.1.3) Remote IP address is: 192.168.1.2 (192.168.1.2) IMSI is: 240011234567890 (0xf098765432110042) Using NSAPI: 0 Using GTP version: 1 Using APN: internet Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library <000c> gtp.c:700 GTP: gtp_newgsn() started After printing this line, sgsnemu stays very silent for 30-ish seconds, after which it prints (all in one go): Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 192.168.0.2 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Disconnecting PDP context #0 Received delete PDP context response. Cause value: 128 Where 10.7.0.240 is the ip address of eth0 Once again, if you have any suggestions, I'm all ears! Thanks in advance! /peter

7 years, 7 months

2
1
0 0

[PATCH 0/2] OpenGGSN fixes for gsn_restart file path composition

by Neels Hofmeyr

Neels Hofmeyr (2): fix gsn_restart file buffer overflow and missing path sep gsn_restart file: set umask back to original after write failure gtp/gtp.c | 20 +++++++++----------- gtp/gtp.h | 1 - 2 files changed, 9 insertions(+), 12 deletions(-) -- 2.1.4

7 years, 7 months

3
6
0 0

sgsn segfault wegen sndcp / v42.bis commits?

by Neels Hofmeyr

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

7 years, 7 months

2
2
0 0

RE: GTP-u Kernel module

by Ferrer Guasch Vicent

> 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

7 years, 7 months

1
0
0 0

GTP-u Kernel module

by Ferrer Guasch 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

7 years, 7 months

4
4
0 0

OVS GTP-U patch

by Ashish Kurian

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

7 years, 7 months

2
1
0 0

High level summary of the performance activity done by Radisys using NuRAN 1.0 platform

by Aravind Sirsikar

Hi All, Below is the high level summary of the performance activity carried on NuRAN 1.0 board with Commercial UE and Dongle under lab conditions. * Single MS test 1. UL Test a. Performance test for long duration (24 hours) for EGPRS Uplink (MCS9) with stable data rate of 45.2kbps 2. DL Test b. Performance test for long duration (24 hours) for EGPRS downlink(MCS9) with stable throughput of 223kbps with all slots configured for single UE c. Performance test for all EGPRS MCS(MCS1-MCS9) with stable expected throughput d. Stress test for short duration with more than theoretical max data rate (MCS9) without any breakage in the system. e. Stress test for short duration with signaling load (MCS8) without any breakage in the system. f. Speed test through speedtest.net downlink - 210kbps uplink - 40kbps * Multi MS test 3. DL Test a. Performance test for long duration (24 hours) for EGPRS downlink (4 UEs - MCS9) with a combined cell throughput of 223kbps. Following are the links to the issues raised in Redmine and related patch information which is merged in master 1. https://osmocom.org/issues/1811 a. https://git.osmocom.org/osmo-pcu/commit/?id=22a901905c9749b03fceccda4d550f3… b. https://git.osmocom.org/osmo-pcu/commit/?id=3463bd4adc1598462560ed84da837d0… 2. https://osmocom.org/issues/1808 a. https://git.osmocom.org/osmo-pcu/commit/?id=e26ee01d56b4c4c2da6abc6b649cb76… b. https://git.osmocom.org/osmo-pcu/commit/?id=8e70bb5bb4751e3a7f33b95b2994bff… c. https://git.osmocom.org/osmo-pcu/commit/?id=0ee31cfa381282d0d724fb36c48bae2… 3. https://osmocom.org/issues/1806 a. https://git.osmocom.org/osmo-pcu/commit/?id=a35c911a91ea7b6d8b017fd103c0d86… b. https://git.osmocom.org/osmo-pcu/commit/?id=7c7a86c080edd9c92778c941bbe484f… 4. https://osmocom.org/issues/1805 a. https://git.osmocom.org/osmo-pcu/commit/?id=9f5f008aedc910ff0ce18bf3f92b9b7… b. https://git.osmocom.org/osmo-pcu/commit/?id=024152683646f1b68c85de74f783b81… 5. https://osmocom.org/issues/1792 a. https://git.osmocom.org/osmo-pcu/commit/?id=e26ee01d56b4c4c2da6abc6b649cb76… Below issue in Redmine is still pending to be submitted to master. 1. https://osmocom.org/issues/1789 Relevant PCU configuration used is present at https://git.osmocom.org/radisys/osmo-pcu/commit/?h=radisys/egprs_integratio… Thanks, Aravind Sirsikar

7 years, 7 months

1
0
0 0

[PATCH 1/3] Fix possible buffer overflow for gsn_restart file path

by Neels Hofmeyr

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

7 years, 7 months

2
5
0 0

[PATCH] gtp: Added 'Bearer control mode' information element from Release 7

by BJovke .

--- 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

7 years, 7 months

2
2
0 0

sgsnemu failing to create PDP context with Cisco GGSN

by BJovke .

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) */ --

7 years, 7 months

2
3
0 0

[osmo-pcu] Unit test execution is reporting as failed

by Aravind Sirsikar

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

7 years, 7 months

1
1
0 0

Regarding the status of gerrit Id 416

by Pravin Kumaravel Manoharan

Hi All, I have addressed all the comments raised. please let me know the status of https://gerrit.osmocom.org/#/c/416/22 Regards, Pravin Kumaravel M

7 years, 7 months

1
0
0 0

osmo-pcu build error in master

by Holger Freyther

Hi, it looks like after the rebase done by gerrit something didn't compile anymore. Could someone please have a look at https://gerrit.osmocom.org/#/c/429/ and fix the fall-out in master? thank you holger

7 years, 8 months

1
0
0 0

[PATCH][libgtpnl] I can't look tei by tools/gtp-tunnel.c in GTPv1

by junpei yoshino

Hello I can't look tei by gtp-tunnel in GTPv1. I write patch for libgtpnl. head version $./tools/gtp-tunnel add hoge v1 65535 65535 10.0.3.2 192.168.0.2 $./tools/gtp-tunnel list version 1 tei 0/0 ms_addr 10.0.3.2 sgsn_addr 192.168.0.2 fixed version $./tools/gtp-tunnel add hoge v1 65535 65535 10.0.3.2 192.168.0.2 $./tools/gtp-tunnel list version 1 tei 65535/65535 ms_addr 10.0.3.2 sgsn_addr 192.168.0.2 diff --git src/gtp-genl.c src/gtp-genl.c index 1e77e06..24a640d 100644 --- src/gtp-genl.c +++ src/gtp-genl.c @@ -119,7 +119,7 @@ static int genl_gtp_validate_cb(const struct nlattr *attr, void *data) const struct nlattr **tb = data; int type = mnl_attr_get_type(attr); - if (mnl_attr_type_valid(attr, CTRL_ATTR_MAX) < 0) + if (mnl_attr_type_valid(attr, GTPA_MAX) < 0) return MNL_CB_OK; switch(type) { -- junpei.yoshino(a)gmail.com

7 years, 8 months

2
1
0 0

Re: [EGPRS] Performance results for EGPRS test in Radisys lab

by Saurabh Sharan

Hello Max, > What about MCS UL? Do you have some statistics which one has been used The uplink tests have been completed for all EGPRS coding scheme (MCS1 - 9) using the ping or TCP download. We have not conducted specific test for throughput estimation in uplink direction till now. Regards Saurabh

7 years, 8 months

2
1
0 0

[PATCH 1/2] Remove unused function

by msuraev＠sysmocom.de

From: Max <msuraev(a)sysmocom.de> --- ggsn/ggsn.c | 1 - gtp/pdp.c | 11 ----------- gtp/pdp.h | 1 - 3 files changed, 13 deletions(-) diff --git a/ggsn/ggsn.c b/ggsn/ggsn.c index 7725016..6866901 100644 --- a/ggsn/ggsn.c +++ b/ggsn/ggsn.c @@ -154,7 +154,6 @@ int create_context_ind(struct pdp_t *pdp) pdp->eua.l = 0; /* TODO: Indicates dynamic IP */ - /* ulcpy(&pdp->qos_neg, &pdp->qos_req, sizeof(pdp->qos_req.v)); */ memcpy(pdp->qos_neg0, pdp->qos_req0, sizeof(pdp->qos_req0)); memcpy(&pdp->pco_neg, &pco, sizeof(pdp->pco_neg)); diff --git a/gtp/pdp.c b/gtp/pdp.c index f0d6adf..f297af9 100644 --- a/gtp/pdp.c +++ b/gtp/pdp.c @@ -370,14 +370,3 @@ void pdp_set_imsi_nsapi(struct pdp_t *pdp, uint64_t teid) pdp->imsi = teid & 0x0fffffffffffffffull; pdp->nsapi = (teid & 0xf000000000000000ull) >> 60; } - -int ulcpy(void *dst, void *src, size_t size) -{ - if (((struct ul255_t *)src)->l <= size) { - ((struct ul255_t *)dst)->l = ((struct ul255_t *)src)->l; - memcpy(((struct ul255_t *)dst)->v, ((struct ul255_t *)src)->v, - ((struct ul255_t *)dst)->l); - return 0; - } else - return EOF; -} diff --git a/gtp/pdp.h b/gtp/pdp.h index 57af8b3..217b1d6 100644 --- a/gtp/pdp.h +++ b/gtp/pdp.h @@ -252,6 +252,5 @@ int pdp_ipget(struct pdp_t **pdp, void* ipif, struct ul66_t *eua); int pdp_ntoeua(struct in_addr *src, struct ul66_t *eua); int pdp_euaton(struct ul66_t *eua, struct in_addr *dst); uint64_t pdp_gettid(uint64_t imsi, uint8_t nsapi); -int ulcpy(void *dst, void *src, size_t size); #endif /* !_PDP_H */ -- 2.9.2

7 years, 9 months

1
1
0 0

gerrit openggsn

by Max

Hi. I've noticed that OpenGGSN is not part of https://gerrit.osmocom.org/#/admin/projects/ Is there plan to move it to gerrit as well or shall I send patches to this list instead? -- 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

7 years, 9 months

2
1
0 0

[EGPRS] Performance results for EGPRS test in Radisys lab

by Saurabh Sharan

Hello, We have completed first phase of performance test on EGPRS using iperf tool for short duration runs (1 to 3 hours). Steady throughput of 215 to 223 kbps in Downlink has been achieved under lab conditions over the air test using one Huawei E398 dongle as UE. PCU was configured for 4 PDTCH allocation. Osmo-pcu is based on master branch plus Radisys code changes which are currently under Gerrit review. The execution of test was done on NuRAN 1.0 hardware. Below is a summary of test results Test type MCS DL Duration Throughput(kbps) Achieved Theoretical TCP MCS9 1hour 217 236.8 UDP MCS9 3hour 223 236.8 Regards Saurabh

7 years, 9 months

2
1
0 0

PDTCH and PTCCH activation

by Max

Hi all. I've noticed in osmo-bts logs several messages from L1: 238:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 243:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 246:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 251:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 254:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 260:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 263:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 274:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) Similarly, there are messages related to PTCCH: 257:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 266:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 277:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 288:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) Notice that while PDTCH is activated for both UL and DL, the PTCCH is only activated for DL. As far as I've understood continuous TA procedure I've got to have PTCCH activated in both directions. The problem is that I have troubles locating the code which triggers the activation above. There is l1if_connect_pdch() in osmo-pcu src/sysmo_l1_if.c but it uses GsmL1_PrimId_MphConnectReq while if I understood correctly GsmL1_PrimId_MphActivateReq is necessary for channel activation. There is mph_send_activate_req() in osmo-bts oml.c which uses it. It's called from lchan_act_compl_cb() via sapi_queue_send() which is also in mph_send_activate_req() - I have hard time understanding how this works at all. Do we have this documented somewhere? -- 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

7 years, 9 months

3
5
0 0

signal quality in osmo-pcu

by Max

Hi. While looking at http://projects.osmocom.org/issues/1616 I've noticed that there seems to be no particular function which get signal quality info from dsp. At least looking at code around ENABLE_DIRECT_PHY have not enlightened me so far. The question is - how exactly signal quality is obtained from dsp (on hw with direct dsp access) to osmo-pcu. There is clear difference between l1if_pdch_req() and pcu_tx_data_req() on TX path but what's the equivalent for RX? -- 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

7 years, 9 months

2
1
0 0

access bts from pcu's L1 code

by Max

Hi. While working on https://osmocom.org/issues/1531 I've found that I have to update BTS's configuration (see src/bts.cpp) from osmo-pcu L1 code (see src/osmo-bts-sysmo/sysmo_l1_hw.c). The problem is that the only thing I got in L1 is struct femtol1_hdl which have trx_no but that's about it. Is there a way to get pointer to BTS so I can call bts->set_ta() using trx_no? Or I shall somehow change interface for l1if_fd_cb() - that's where my function with new data is called from? -- 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

7 years, 9 months

1
0
0 0

Testcase + commit on EDGE patches

by Holger Freyther

Good Morning all, my real life distraction is mostly gone and I can be more active in developing and reviewing again. From my point of view Sysmocom and me have responded to all Gerrit reviews and we are waiting for the next iteration of the patchset. Before giving a high-level point of view of orders and dependencies I would like to say some words about testing. (Automatic Unit-)testing is crucial. Sometimes it is the easiest way to test a behavior, it allows to hit/test error paths but are hit less frequently. Combined with regular execution of the tests and forbidding to merge code that breaks tests, features that worked once and have a good test will continue to work. It is the key for being able to move forward quickly. For many patches I reviewed test + feature or test + bugfix were in separate commits and then the order is problematic. From my point of view there are only a few "right" combinations. Let me try to explain: Assume some code is doing "if (res) " instead of "if (!res)" and after long debugging we have found that single line (and our code is full of printf now) and it is a path that has not been systematically tested yet. To move forward and create a patchset we should: * Add a test case that triggers the broken behavior. With a xUnit framework we would add an expected failure, with our approach we either capture the broken output, comment the OSMO_ASSERT or revert the OSMO_ASSERT condition. (See libosmocore * Let's say that if is already in code like: if (a) if (b) if (c) if (d) and we would like to re-factor it to be more readable. Then please do the refactoring _before_ applying the bugfix. The test output/result should not change as it is a refactoring. * Finally apply the fix. For bugfixes try to make them as small and clear as possible. Let's say even if you don't like the algorithm used, fix it. As part of the fix the test assertions can be enabled and the output change. The smaller the fix, the better. See libosmocore 6ac70a41ee4cc9f3f286fb6b8f397215590fc2ac for such an example. * If the algorithm is indeed bad now is the time to change it. It should just change the (refactored) method, test output and result should be stable and maybe add more tests as the new code is easier to test. In general my preferred way: New feature => one commit to add feature + test Bugfix => First test, then bugfix+test output/result update thank you holger

7 years, 9 months

2
1
0 0

Status of EDGE work and plans

by Holger Freyther

Hi guys, maybe a short summary helps to see where we are and where we need to go. Let me start with myself. Besides reviewing code I have two GPRS related topics I want to look at. The first one is the missing state transition for single phase access to avoid having to revert, the second one is to use perf to look at the performance difference of the two compressed bitmap routines. The bigger picture is that we have some features that work in parallel and the right order might be important to unlock them. My review/merging priority right now is: * 11bit RACH decoding: ** Get the libosmocore change in. As 0x0 is used as a value it needs to be inside the enum ** PCU protocol change to transport this access burst type and update to uint16_t ** OpenBSC change to allow 11bit burst access ** PCU change * T4 compression/decompression: I am not sold on the look-up tree yet but I understand that for good compression the API in libosmocore needs to change. a.) We remove T4 support from libosmocore as it is not used outside of the PCU and this gives us a way to mature the API without having to synchronize two projects b.) We know which out variables we need to add and can define the API The implementation (unrolled loop vs. tree) can be decided at a later point as we can hide it from the interface. * Changing coding schemes on re-transmission/etc. These are features and fixes that only relate to the PCU. I can merge whatever patchset is ready first. kind regards and looking forward to rebased patchsets holger

7 years, 9 months

1
0
0 0

GTP, GGSN and PGW testing

by Vasu Devan

Hi, Currently i am working in LTE and would like to test SGW and PDN-GW along with GTP protocol for my research aspect. I have already worked and used OpenairInterface EPC. But, i wanted to explore other kernel or user-space options of GTP. Please let me know the procedure to access the code of , (i) Latest mainline linux kernel version with your GTP code and user space GTP module. (ii) Also, could you please kindly provide me access to the SGW/GGSN and PGW codes. Please kindly provide me access to the latest code, such that i could test it and will even post the test results to the community. Thanks & Regards Vasu.

7 years, 9 months

3
3
0 0

RE: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL

by Aravind Sirsikar

Hi Harald/Holger, Please let me know any further updates on the pending review for ARQ2?. Since it is pending for long time we would like to know how to proceed over this. Thanks, Aravind Sirsikar

7 years, 10 months

2
1
0 0

RE: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL

by Aravind Sirsikar

Hi Holger, >Line 130: GprsCodingScheme cs_current_trans; >I would prefer to cs and cs_current_trans being private here. The cs_current_trans is made public to align with existing variables like block[RLC_MAX_LEN], len and others to have consistency. will it make sense to have cs and cs_current_trans as private?. We can rename cs to cs_last_tx as suggested in review of other patch. But it will have modification in other source files to address compilation errors. Thanks, Aravind Sirsikar

7 years, 10 months

2
2
0 0

conversations in gerrit "lost" here

by Neels Hofmeyr

I am a bit ambiguous on our use of comments in gerrit. We do discuss at least some fairly interesting things in the comments on patches waiting for approval in gerrit. When these discussions are attempted on openbsc@ or osmocom-net-gprs@, you tend to block off and redirect the discussion back to the gerrit comments infrastructure. However, we have moved the gerrit mails to a separate and very noisy mailing list, and these potentially interesting discussions are moved essentially out of the public focus. Also, if we in future would like to investigate discussion on some topic, we need to search both the main ML and the gerrit ML. IMHO it would make sense to copy the human originated comments to our "human" mailing lists, so that the automatic jenkins and gerrit notifications remain on the noisy ML while we see all discussions here. Is that easy to achieve (filter on originator of comment), and would you guys agree? ~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

7 years, 10 months

1
0
0 0

gerrit and branches

by Neels Hofmeyr

Today I've taken another close look at branches and gerrit, and have written down my conclusions here: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Submitting-… In summary: * Branch re-submission needs the workaround of tweaking the first commit. It would be nice to fix gerrit to not need this, but for the time being the effort of cosmetically changing the first commit log is acceptable. * It *is* possible to have private branches in the gerrit repos and still be able to submit them to master, with the proper project config. I have thus switched all our gerrit projects' configs to rebase-if-necessary with the flags as described on the wiki page. (Except for osmo-pcap, where we still disallow content merges.) I will now go back to pushing my "private" developments to the public repository (gerrit) under the neels/ or sysmocom/ namespaces. ~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

7 years, 10 months

2
4
0 0

testing gerrit, might be down shortly

by Neels Hofmeyr

I'm testing things related to our gerrit bug report, if it's not working for you right now it may be because I'm restarting gerrit to test with/out our fix. I'll repost when I'm done. ~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

7 years, 10 months

1
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs