osmocom-net-gprs September 2020

osmocom-net-gprs@lists.osmocom.org

7 participants
5 discussions

RFC: unit tests for kernel GTP module
by Harald Welte 01 Jan '26

01 Jan '26

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)

4 5

ns2 thoughts
by Harald Welte 22 Sep '20

22 Sep '20

Hi List and Lynxis, I've been reading through the ns2 code more thoroughly and had some thoughts for improvement. As we have no users yet, and the code is unreleased, we can still make changes now. == unused argument in ns2_recv_vc int ns2_recv_vc(struct gprs_ns2_inst *nsi, struct gprs_ns2_vc *nsvc, struct msgb *msg) The 'nsi' is not used and should be redundant, as the nsvc has a back-pointer anyway, right? == consider using an osmo_ prefix to all symbols / types The fact that the old code doesn't have that is a tribute to its age, and not something we need to keep. The current code has quite a bit of 'gprs_ns2' prefixing for types, but not for the symbols/functions. At least that inconsistency should be resolved, so all have the same prefix, even if it is without osmo. == const-ify input arguments If arguments pointing to data are used read-only, let's express that by the const qualifier. The easy ones are the likes of "gprs_ns2_is_frgre_bind(struct gprs_ns2_vc_bind *bind)", but there are definitely many more. == use of msgb->dst In several other osmocom implementations we use msgb->dst to point to the underlying element receiving or transmitting a message. So I could imagine ns2_recv_vc() not only without the 'nsi' argument, but also without the 'nsvc' argument, if we introduce the convention that msgb->dst would always point to the ns-vc. Not sure here, it has pros and cons. Just brainstorming. == output arguments vs. return value There are functions like gprs_ns2_find_vc_by_sockaddr() where the result is not returned, but rather a **pointer output argument is used. What is the rationale here? I don't understand what benefit the extra 0/1 return value gives. The only other return value is -EINVAL if the **ptr was NULL - an error situation that wouldn't exist if we simply returned the pointer from the function. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 2

GSM, GPRS
by Сергей Егоров 20 Sep '20

20 Sep '20

Hi! I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE. While communication MS and Osmocom base station (BS) we've got the LLC-message: LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434 with the following parameters: Cipher Algorithm: GEA3 Kc_GPRS: A8FC3A996A80D000 SAPI: 1 NU: 3 IOV_UI: 0 OC: 0 After applying algorithm GEA3 we've got deciphered LLC-message: LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal. While communication MS and the real BS we've got the following LLC-message: LLC MESSAGE (ciphered) 41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35 with the following parameters: Cipher Algorithm: GEA3 KC_GPRS: 8f94a69c3d9bdf48 SAPI: 1 NU: 2 IOV_UI: 0x10000000 (got from XID) OC: from 0 to 8388608 So we tried to apply the OC parameter from 0 to 8388608 to decipher the message (other parameters were not been changed). In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success. Finally the question: Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how?? With regards, students of the telecommunication department. Thank you for your attention! Best regards, Sergei ----------------------------------------------------------------------

2 1

GSM, GPRS
by Сергей Егоров 18 Sep '20

18 Sep '20

Good afternoon! I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE. While communication MS and Osmocom base station (BS) we've got the LLC-message: LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434 with the following parameters: Cipher Algorithm: GEA3 Kc_GPRS: A8FC3A996A80D000 SAPI: 1 NU: 3 IOV_UI: 0 OC: 0 After applying algorithm GEA3 we've got deciphered LLC-message: LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal. While communication MS and the real BS we've got the following LLC-message: LLC MESSAGE (ciphered) 41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35 with the following parameters: Cipher Algorithm: GEA3 KC_GPRS: 8f94a69c3d9bdf48 SAPI: 1 NU: 2 IOV_UI: 0x10000000 (got from XID) OC: from 0 to 8388608 So we tried to apply the OC parameter from 0 to 8388608 to decipher the message (other parameters were not been changed). In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success. Finally the question: Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how?? With regards, students of the telecommunication department. Thank you for your attention! Best regards, Sergei ----------------------------------------------------------------------

1 0

OsmoDevCon / COVID-19
by Harald Welte 05 Sep '20

05 Sep '20

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs September 2020