osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

2 participants
516 discussions

libgtp: Users of gtpie_encaps() and gtpie_encaps2() ?
by Harald Welte 14 Oct '17

14 Oct '17

Dear all, during manual review, I found some pretty obvious bugs and inconsistencies in the gtpie_encaps() and gtpie_encaps2() functions of libgtp. Interestingly, it seems those functions have been around since the very fist commit in 2002. However, no code in openggsn, osmo-ggsn, osmo-sgsn or even gtphub seems to be using them. Does anyone know of any users of those functions? Rather than keeping them updated manually without any test cases and users, I would say there's a strong argument to remove them from the code base. 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)

1 0

Planning for OsmoCon + OsmoDevCon
by Harald Welte 14 Oct '17

14 Oct '17

[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org] Dear all, time is flying, and I would like to start early with discussions and planning about OsmoCon and OsmoDevCon in 2018. It helps to start early. Side note: We have some pending issues about the events from last year at http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them in the text below. == OsmoDevCon == For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as every year, which means: * same venue, same catering options * same concept of 'anyone contributing to Osmocom can apply for registration until all seats are taken' * same idea of inviting some few speaker[s] doing other FOSS mobile communications work to join us The parts that we need to change, IMHO: * don't reduce from 4 to 3 days like last year. Have full 4 days again * sort topics per day / half-day, i.e. have "GSM/UMTS Cellular Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co, but then have other days for other projects. This would enable people not interested in the [continued evolvement] of the cellular projects be able to skip those days, or to simply meet in an adjacent room for parallel hacking sessions/discussions * try to be a bit more structured with the schedule in general. The existing approach works for people who attend all the event all day long, but not so well for people with other plans / limited time Any further change requests or topics to discuss? Please note that Pablo Neira has offered to kindly host an OsmoDevCon in Seville (Spain). I've attended a number of netfilter workshops he organized there, and he's doing a great job! However, given the large number of attendees from Berlin (and Germany in general), I think this would make things more complicated, and more expensive for most attendees. If you disagree with that assessment: I'm open for having the discussion, I just thought it's more practical/economic to do it in Berlin. === 10 year Anniversary Party === Given that 2018 marks the 10 year anniversary of Dieter and me hacking with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves some special celebration of some form. I have no concrete idea yet, but for sure we should so something, and it should be at/around OsmoDevCon. And for sure we should have a BS-11 around :) == OsmoCon == The public OsmoCon was welcomed and was a success. However, let's start this discussion with a review of last years event. === Registration === * Registrations came in way too late. Two weeks ahead of the event, we were considering to cancel it. And then within the last few days, we had to turn people down due to limited seating capacity * To make planning more reliable, we see on other option but to significantly raise the registration fee combined with an equally significant discount for early booking === Duration === * Many people requested multiple days rather than just one, in order to make more out of (long distance) travels. This is obvious, but as we had no idea how many people would attend at all (or if we have to cancel due to lack of attendance), planning multiple days in the first incarnation would have been high risk and a multitude of work * I would suggest to expand to two or even three days this week, possibly one days with tutorials and the other day with tech talks * Slightly less crammed schedule due to multiple days === Venue === We recognize this yearso venue was not the best option, due to * Bad ventilation in the basemenet * Difficult to find * No space next to the conference room where people can meet / hang out in parallel to talks (not everyone attends every talk) I still like the "understatement" of the venue. I'd prefer any hostel / non-profit / hackerspace / university over luxurious hotels any time. Going to an expensive venue means more or less automatically more expensive ticket fees, which again is more likely to exclude pure community members without a commercial activity related to Osmocom. So any future venue would ideally: * be able to hold slightly more people than this year * have a second room or large lobby in which people can meet for extended coffee breaks in parallel to some talks, as needed * be slightly easier to find (and we have to put up some signs outside and in the lobby) * have better WiFi and/or wired connectivity === Programme / Format === * less crammed over multiple days * some more "interactive" formats were requested, for users to provide feedback to developers * there was some discussion about topics / speakers in redmine last year, but not too much participation [until it was too late]. * I'd suggest a more formal CfP process with a submission deadline that allows us to publish a preliminary schedule long ahead of the event === Video Recordings === I think they were a big success, and it was a very big surprise that the CCC Video Operations Center was volunteering to help such a small and niche-interest event like OsmoCon. We should make sure that we can repeat this for 2018. == Dates / Frequency == Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at a full week for those of you who would like to attend both events. But then, I think the number of people attending both events is actually not all that big. Without checking the details, I think not more than half of the OsmoDevCon attendees were attending OsmoCon. I would expect that tendency to remain or even increase. I still think it's good to keep them back-to-back. In terms of frequency, I would actually suggest we move to a 6-month cycle rather than a 12-month cycle. There's a lot of development going on at all time. I understand that not everyone is able to attend two events just on Osmocom, especially if it's a spare time / hobby type activity. That's ok, I think there's no problem with attending either of the two only, and catching up by video recordings and/or mail on the other. The qeustion is: Should that second event be developer-oriented or user-oriented? Or again both? Any comments here? Ok, that was a somewhat lengthy e-mail. Please make sure to provide any feedback you may have as early as possible, to increase the chances of your feedback being reflected in the planning. Happy hacking, 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)

1 0

Current osmo-pcu patch set
by Holger Freyther 05 Oct '17

05 Oct '17

Hi, I am a bit lost with the review of the current osmo-pcu patchset. Going through the patches I have difficulties to see the red thread and what is better after we integrate the changes. I guess the goal is to add the allocation of multiple uplink timeslots but from my point of view this is buried in a lot of subjective sideway development. My wish would be: For multiple slot UL allocation: Make the most direct patchset to implement this feature. I understand that to avoid code duplication some methods can be re-used but instead of having 10 patches that change int->bool, change signatures of functions, maybe make it minimal to see how it works first? After it works send a cover mail that explains what and why you took the approach, what the _speed_ improvement for browsing is or when it is being used. What you see the danger in terms of common ts and allocation. For the clean-ups: I don't say we shouldn't do them but we should do them in a way they don't take much time to review and still provide a net gain to the contributor. A "cosmetic" patch that breaks the build is very suspicious and forces a reviewer to look extra carefully into these "clean-ups". int->bool: I think int->bool and 1->true adds little value for an application but if it is important then please do it by semantic patching so they can be easily reviewed. bts->trx: I think there is little value to change a function signature from getting a BTS to a TRX when the implementation starts to do: - bts->list + trx->bts->list "API" documentation: Comments can be helpful and it is good to explain on a high level what a function will do and what the side-effects will be. But in an application I think writing: \param[in,out] bts Pointer to BTS struct adds not enough value. First it is wrong as the type is not "BTS" but it is the "C" gprs_rlcmac_bts. And second doxygen will perfectly tell you the type of of the parameter anyway. Documenting that -1 of a parameter has a specific semantic can have some advantage but the risk of code/doc not agreeing is there as well. libosmocore: We do have a desire for reuse but everytime you make osmo-pcu depend on a unreleased version of libosmocore rebuilding osmo-pcu get's more difficult and the compile error is not obvious. It is not clear where the macro is coming from. So please keep this in mind and try to find a balance. thank you for your consideration holger

4 5

HEADS UP: stricter VTY, possible config fallout
by Neels Hofmeyr 21 Sep '17

21 Sep '17

Hi all, we have recently merged a profound change to the inner workings of the VTY configuration. We've hit some fallout due to that, hence I would like to let you know that you might hit the same. The VTY parsing of config files is now strict about indenting. A child node *must* be indented below the parent node, and indenting must be consistent. For more details on the reason why and a definition of 'consistent', see the commit log of https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a04… So, if you are in the near future faced with config files being rejected that worked perfectly before, it is most probably because your indenting was wrong all the time, and only now did we start checking it. If the cause is hard to figure out, a good aid is the telnet VTY, where you may either 'show running-config' or traverse the nodes manually to query which command exists on which level. If your current config is broken, you may be able to start the program with an empty or stripped down config file to make its telnet available. The above is about reading config files, but we have also dropped the implicit 'exit' to parent level on the telnet VTY console. This caused fallout where nodes by plain omission lack the 'exit' command: one is unable to leave such a node once it is entered. That is a fault in the program's VTY setup that was not found before, because the VTY would often just find the parent node's exit command instead. I have a patch to avoid all of these everywhere, by installing the exit and end commands automatically for every VTY node that gets created; it is not merged yet: https://gerrit.osmocom.org/3998 ------ Config Fallout Example ------ For example, we hit a breakage with this osmo-bts-trx.cfg: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance 0'. The first fix looked like this: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 But alas, this time it said the command 'osmotrx ip local' does not exist. I suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a direct child of the 'phy 0' level. Before, the VTY would implicitly step out of a child level if it found a matching command one parent above. That is confusing in other situations (see above commit log), hence we now require indenting to clarify the structure. This is the correct one: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 Or rephrased: phy 0 osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml To query the structure via telnet, I did: $ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg $ telnet localhost 4241 OsmoBTS> enable OsmoBTS# configure terminal OsmoBTS(config)# phy 0 OsmoBTS(phy)# list [...] osmotrx ip HOST osmotrx ip (local|remote) A.B.C.D [...] OsmoBTS(phy)# inst OsmoBTS(phy)# instance 0 OsmoBTS(phy-inst)# list [...] osmotrx rx-gain <0-50> osmotrx tx-attenuation <0-50> osmotrx tx-attenuation oml [...] ------ No Exit Example ------ The same osmo-trx VTY nodes also show the exit failure: $ telnet localhost 4241 OsmoBTS> enable OsmoBTS# configure terminal OsmoBTS(config)# phy 0 OsmoBTS(phy)# exit % Unknown command. OsmoBTS(phy)# instance 0 OsmoBTS(phy-inst)# exit % Unknown command. On the phy level, we would previously find the parent's 'exit' command, but in the 'instance' level, 'exit' has never been available. Above patch should fix all of these. ~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

3 3

Kernel patchset for IPv6 support on netdev mailinglist
by Harald Welte 19 Sep '17

19 Sep '17

Hi all! Just in case anyone here is intrerested, I'd like to point out that a recent patch series for IPv6 (and other feature) support of the Linux kernel GTP-U code has been posted to the linux-netdev list and is under review/discussion there: https://www.spinics.net/lists/netdev/msg455286.html Please follow-up with any review comments there. Thanks! -- - 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)

1 0

回复：Re: Unable to access git repository
by lokira 19 Sep '17

19 Sep '17

Hi Holger, It's working now!Thanks for the quick fix! Regards, WangSS

1 0

Unable to access git repository
by lokira 19 Sep '17

19 Sep '17

Hello, I was trying to clone git repository from http://git.osmocom.org/libgtpnl/but got an error : remote: An error occurred while reading CGI reply (no response received)fatal: unable to access 'http://git.osmocom.org/libgtpnl/': The requested URL returned error: 502 I can't open http://git.osmocom.org/libgtpnl/ in browser either. It said 'An error occurred while reading CGI reply (no response received)'. Is my url to git repository wrong ? Thanks, WangSS

2 1

Update and Question
by fırat sönmez 18 Sep '17

18 Sep '17

Hi, I want to ask two questions. I dont know if you remember, but I have been trying to backport GTP to 3.18 kernel. I fixed all the errors, it works. However there is one issue that I'm not sure how to implement it correctly. --->There is one private flag called IFF_NO_QUEUE and it has no implemetation in 3.18 kernel, I just set it to an unused bit in the private flag field. I would like to get your opinion on this. *include/linux/netdevice.h ->(*@IFF_NO_QUEUE: device can run without qdisc attached*) The other thing I would like to ask is that I cannot reach the git repository for libgtpnl. Could you please check it? Thanks, Fırat

1 0

Unable to start osmo-ggsn with -g or --gtp-linux options
by Ravi Tandon 14 Sep '17

14 Sep '17

Hello, I compiled osmo-ggsn and was trying to run it as per the instructions present on https://osmocom.org/projects/openggsn/wiki/Kernel_GTP But when I try to start osmo-ggsn *using -g or --gtp-linux*, it says invalid option. Please let me know how to start it using gtp kernel. I have modprobed gtp.ko successfully. [root@localhost osmo-ggsn]# lsmod |grep gtp gtp 28672 0 ip6_udp_tunnel 16384 1 gtp udp_tunnel 16384 1 gtp [root@localhost examples]# osmo-ggsn --gtp-linux -c osmo-ggsn.cfg -d *osmo-ggsn: unrecognized option '--gtp-linux'* <0002> ggsn.c:159 APN(internet): Starting <0002> ggsn.c:162 APN(internet): Opening TUN device tun4 <0002> ggsn.c:167 APN(internet): Opened TUN device tun4 <0002> ggsn.c:178 APN(internet): Setting tun IP address 176.16.222.0/24 <0002> ggsn.c:224 APN(internet): Creating IPv4 pool 176.16.222.0/24 <0002> ggsn.c:245 APN(internet): Successfully started <0002> ggsn.c:159 APN(inet6): Starting <0002> ggsn.c:162 APN(inet6): Opening TUN device tun6 <0002> ggsn.c:167 APN(inet6): Opened TUN device tun6 <0002> ggsn.c:190 APN(inet6): Setting tun IPv6 address 2001:780:44:2000::/56 <0002> ggsn.c:236 APN(inet6): Creating IPv6 pool 2001:780:44:2000::/56 <0002> ggsn.c:245 APN(inet6): Successfully started <0002> ggsn.c:159 APN(inet46): Starting <0002> ggsn.c:162 APN(inet46): Opening TUN device tun46 <0002> ggsn.c:167 APN(inet46): Opened TUN device tun46 <0002> ggsn.c:178 APN(inet46): Setting tun IP address 176.16.46.0/24 <0002> ggsn.c:190 APN(inet46): Setting tun IPv6 address 2001:780:44:2100::/56 <0002> ggsn.c:224 APN(inet46): Creating IPv4 pool 176.16.46.0/24 <0002> ggsn.c:236 APN(inet46): Creating IPv6 pool 2001:780:44:2100::/56 <0002> ggsn.c:245 APN(inet46): Successfully started <0002> ggsn.c:687 GGSN(ggsn0): Starting GGSN <000d> gtp.c:705 GTP: gtp_newgsn() started at 192.168.11.128 <0002> ggsn.c:724 GGSN(ggsn0): Successfully started <0005> telnet_interface.c:102 telnet at 127.0.0.1 4260 <000c> control_if.c:788 CTRL at 127.0.0.1 4257 Also, I tried executing gtp-tunnel list but it gives empty output. [root@localhost tools]# ./gtp-tunnel list [root@localhost tools]# Please help. Thanks, Ravi <https://osmocom.org/projects/openggsn/wiki/Kernel_GTP>

2 1

OsmoGGSN succeeds OpenGGSN!
by Harald Welte 06 Sep '17

06 Sep '17

Hi all, 12 years after OpenGGSN was seemingly abandoned by its original creators, and 7 years after Osmocom adopted it, it is time for a significant change: OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN. We had already taken some baby-steps in the past by introduction of a CTRL interface as well as the use of libosmocore logging. However, my recent patches introducing a VTY interface and changing the configuration file format from the 'gengetopt' style to libosmovty based change the look+feel of the program significantly that it is a good point to rename. After all, if command-line arguments and config file syntax are changing, documentation will also need to change and it becomes confusing to users to understand that depending on the version the documentation is correct or incorrect. So from today on, * osmo-ggsn is available from http://git.osmocom.org/osmo-ggsn/ * osmocom:nightly packages will build both openggsn + osmo-ggsn * osmocom:nitb-split:nightly packages will only build osmo-ggsn * redmine still at http://osmocom.org/projects/openggsn due to permanent redmine project naming... The introduction of the VTY interface comes with many new possibilities, such as * multiple GGSN instances bound to different GTP IP addresses * multiple APNs within each GGSN, each with different Address Pools and tun-devices * sophisticated logging configuration (syslog, file, stdout, telnet) What's still missing: * re-integrate kernel GTP-U support * create OsmoGGSN user manual in osmo-gsm-manuals.git * migrate TTCN-3 test execution on jenkins to osmo-ggsn * perl/python script to convert old config file to new config file format (any volunteers?) Roadmap: * IPv6 transport plane support (outer IP layer surrounding GTP/UDP) * improved logging (ensure context is always included) * libgtp: migration of kernel GTP-U support into libgtp (not just ggsn) * libgtp: make PDP context hash table part of the 'gsn' structure * once all expected ABI/API changes are done, rename libgtp to libosmo-gtp In terms of maintenance, I don't want to continue to maintain OpenGGSN for much longer. We'll keep it around for some time and merge important security and/or bug fixes, but I won't accept new feature patches into OpenGGSN. 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)

2 2

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs