osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

1 participants
483 discussions

Osmocom Year 2017 Review
by Harald Welte 01 Jan '18

01 Jan '18

Dear all, I've written up a "short" review of what I perceive as the most important events in the Osmocom Cellular Infrastructure projects in 2017. See http://osmocom.org/news/84 for all details, or below for a raw copy+paste: h1. Osmocom Review 2017 This is a review of the most significant changes and events in the Osmocom Cellular Infrastructure projects in 2017 h2. January 2017 * announce of first ever public [[OsmoCon:]] conference in April * osmo-bts ** Add Abis OML failure event reporting ** fix memory leaks in osmo-bts-{sysmo,lc15} at every channel activation * openbsc/osmo-bsc ** support multiple UARFCNs in SI2quater * osmo-hlr ** add test suite for 2G and 3G authentication ** fix UMTS AKA re-sync h2. February 2017 * weekly manual testing with related weekly test reports to mailing list * "heads-up about the (lack of a )future of osmo-nitb":http://lists.osmocom.org/pipermail/openbsc/2017-February/010300.html * "heads-up about libosmo-sccp SIGTRAN work":http://lists.osmocom.org/pipermail/openbsc/2017-February/010274.html * "sysmo-usim-tool":http://lists.osmocom.org/pipermail/openbsc/2017-February/010317.html * libosmo-abis ** unix domain socket support (for Ericsson L2TP) * osmo-bts ** fix AMR HR DTX FSM logic ** fix SACCH sending fo system information with enum value > 7 ** osmo-bts-trx: fix RXGAIN and POWER parameters on second TRX ** fix TCH/H interleaving table bit position ** sysmoBTS 1020/1100: slow power ramp-up on TRX enable * osmo-sgsn ** fix PDP context activation memory allocation bug ** integrate support for UMTS AKA * openggsn ** fix kernel-gtp tunnel creation/removal for GTPv1 ** release 0.93 h3. March 2017 * "cgit improvements":http://lists.osmocom.org/pipermail/openbsc/2017-March/010448.html (about page, change-ID hyperlinks, issue hyperlinks) * Add README.md files to all our repositories * libosmocore ** migrate gsm 05.03 coding from OsmoBTS to libosmocore ** fix SQN / SEQ handling in UMTS AKA ** 3GPP AoIP message encoding/decoding * libosmo-abis ** fix ever-increasing jitter buffer * libosmo-netif ** handle SCTP in in stream server ** doxygen documentation on stream an datagram modules * osmo-bts ** octphy: CBCH support ** include MS timing offset in RSL measurements * osmo-sgsn ** handle IMSIs with leading zeroes * osmo-bsc ** fix T3186 encoding in SI13 ** Improved Ericsson OM2000/RBS2000 support ** new ctrl2soap proxy in python * osmo-hlr ** add CTRL interface ** fix SQN/SEQ handling in UMTS AKA h3. April 2017 * "update of coding style for longer line lengths":http://lists.osmocom.org/pipermail/openbsc/2017-April/010502.html * [[osmo-dev-con:OsmoCon2017]] and [[osmo-dev-con:OsmoDevCon2017]] * libosmocore ** "control interface for osmo_fsm":http://lists.osmocom.org/pipermail/openbsc/2017-April/010542.html * libosmo-netif ** fix file descriptor leak in error paths ** work around linux kenrel SCTP bug with sender_dry_events ** RTP marker bit support * libosmo-sccp ** Add new [[libosmo-sigtran:]] library with SS7 AS/ASP Link/Linkset handling, M3UA support, new FSM based SCCP implementation ** Add [[osmo-stp:]] program * osmo-bts ** inform BSC of PCU disconnect ** fix measurement reporting period ** exclude idle channels from uplink measurement processing ** octphy: measurement reports h3. May 2017 * libosmocore ** fix embedded builds ** import and generalise 'sercomm' from osmocom-bb into libosmocore ** SSE optimized convolutional coder ** fix wrong GSM FR codec SID frame generation ** doxygen docs for libosmocoding * osmo-bsc ** TS 04.14 mobile station side loop control * osmo-bts ** consistently check all RSL and OML TLVs for minimum length value ** fix bit-order in every HR codec parameter (spec compliance) ** OML get/set attribute handling ** SI2quater support ** bypass radio link timeout for lab testing * osmo-bsc ** PCU socket support for BSC-colocated PCU for Ericsson RBS2000 ** reelase 1.0.1 * "M3UA and SUA testing as part of jenkins":http://lists.osmocom.org/pipermail/openbsc/2017-May/010698.html * "osmo-gsm-tester produces successful runs with NITB as well as new AoIP":http://lists.osmocom.org/pipermail/openbsc/2017-May/010760.html h3. June 2017 * libosmocore ** doxygen autobrief ** doxygen documentation for libosmogb * osmo-bts ** use CLOCK_MONOTONIC timer for GSM frame timer ** PDTCH loopback support h3. July 2017 * "Plan for openbsc.git split and code review":http://lists.osmocom.org/pipermail/openbsc/2017-July/010914.html * libosmocore ** PDP charging characteristics in GSUP ** PRBS sequence generators ** multicast IP related helper functions ** 'make release' target * libosmo-sccp ** SCCP address book * osmo-bts ** new virtual BTS @osmo-bts-virtual@ for testing without radio hardware ** don't send dummy UI frames on unused BCCH slots on TC=5 ** GSMTAP: don't log/send fill frames consisting of only padding * osmo-hlr ** change to default GSUP port 4222 h3. August 2017 * "Support for SMPP Delivery Receipt / GSM03.40 Status Report":http://lists.osmocom.org/pipermail/openbsc/2017-August/011023.html * "Jenkins now executing M3UA, SUA and GGSN testsuite":http://lists.osmocom.org/pipermail/openbsc/2017-August/011043.html * libosmocore ** fix crash in lapd_est_req() * libosmo-abis ** release 0.4.0 * osmo-bts ** osmo-bts-trx: fix MS power control loop ** release 0.6.0 ** support sending/removing SI13 to/from PCU * osmo-bsc ** indicate R99+ MSC in SI3 to enable UMTS AKA over GERAN * osmo-sgsn ** properly report GERAN/UTRAN mode in PDP CTX ACT REQ to GGSN * osmo-msc ** implement IuCS support ** split openbsc.git into osmo-bsc.git, osmo-msc.git and osmo-sgsn.git * openggsn ** Add IPv6 address pool and IPV6 user (inner) plane support ** release 0.94 h3. September 2017 * libosmocore.git ** "'show talloc-context' VTY introspection":http://lists.osmocom.org/pipermail/openbsc/2017-June/010771.html ** CTRL parsing unit tests ** unification of vty exit/end commands * osmo-hlr ** CTRL interface tests -- - 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

OsmoDevCon 2018 schedule planning
by Harald Welte 06 Dec '17

06 Dec '17

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.] Like every year in early December, it is time to discuss as schedule for OsmoDevCon in the upcoming year. Note: Ths is about OsmoDevCon, the more private meeting of developers, *NOT* about OsmoCon, the public conference. == When, Who, Where == I propose the following date for OsmoDevCon 2018: April 20 - April 23rd, 2018 * Who: Active developers/contributors of Osmocom projects (as usual) * Where: IN-Berlin, Berlin (as usual) Please let me know ASAP if that proposed date works for everyone who'd want to attend. We can still change it now, but I would want to nail down the date pretty soon. == Format == After the experiment of reducing from 4 to 3 days last year (due to OsmoCon), we will again go for *four days* in 2018. However, we should clearly divide the days in a way that e.g. "GSM/3G" topics are on two days, while SDR+Other topics are on the other days, so people not interested in some topics can skip one or two days, as needed. We could even divide it further like: * 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...) * 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.) * 2 days misc Regards, and looking forward to meeting you [again] in 2018, 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 1

Packets are not arrived at tunnel setup by libgtpnl
by congnt 24 Nov '17

24 Nov '17

Hi guys, I'm using libgtpnl tools (gtp-link, gtp-tunnel) to setup a tunnel in my local machines. I was able to setup gtp link to 2152 port as well as gtp tunnel. I have pre-recorded GTP packets with correct teid and IP address as well as chksum and port to send to 2152. However I can not see any packets in gtp link device when using tcpdump. By add some messages in gtp module, I notice that the function gtp1u_udp_encap_recv in gtp.c kernel file was never been called if I send packet with GTP headers. However, that function is called if I send normal UDP packet without GTP header. Note that I'm using Ubuntu 14.04 with kernel 4.8.0 lowlatency, the tunnel is on a VM created by Virtualbox using virtio network driver. Any suggestions on how to debug/solve this problem? Many thanks in advances. Best regards Cong.

2 2

libgtpnl migrated to gerrit
by Harald Welte 12 Nov '17

12 Nov '17

Hi all, FYI: I migrated libgtpnl (the kernel-GTP netlink interface helper library used by OpenGGSN and OsmoGGSN) to gerrit earlier today. This means direct pushes to git.osmocom.org no longer work and you will have to submit modifications via gerrit, as we do for all our other major repositories. I've also set up a gerrit build verification job via jenkins-job-builder and added a corresponding contrib/jenkins.sh script to it. The buildhosts now need libmnl-dev as build dependency installed. I added this to our current debian8 + debian9 build slaves and the wiki documentation about them. In other news: libgtpnl is already part of the network:osmocom:nightly and network:osmocom:latest feeds for some weeks. I intend to test kernel GTP support in osmo-ggsn soon and then change the package builds to include kernel-gtp support via libgtpnl by default. 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

Re: GPRS EXperiments
by Neels Hofmeyr 03 Nov '17

03 Nov '17

(BTW, for GPRS we use osmocom-net-gprs(a)lists.osmocom.org but admittedly, almost all osmocom communication is taking place on openbsc@) On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote: > I've installed up to date versions of osmo-bts and osmo-pcu > on sysmobts 2050 hardware and it's working great! > Dynamic channels are really nice, with half rate TCH and AMR > working perfectly. Thanks for all that work! Good to hear that! > I configured pcodns1 in the ggsn to point to this DNS > server, AND I setup a port 53 redirect to catch quite a lot > of traffic from android that likes to just talk directly to > 8.8.8.8 anyway. Interesting, this sounds like it would make for a good wiki page on osmocom.org. > games. Such is the sad state of affairs on today's internet. > Fortunately, we have iptables and ip sets and we have AS > blocks assigned to certain bandwidth hungry corporations :-) So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;) > I have observed that if I initiate any data transfer from > the network side then the uplink is established. By the same > token, If I transfer a file from the network (http download > or some such), the same applies. The link stays active and > the IM chat session is very responsive alongside the file > transfer. Shortly after the file transfer completes, the > uplink is quiet again and the latency in the IM session > becomes a problem. It might be related to a basic problem we still have with data services: we don't cache anything. If a PDP context is still being established, we drop data transfers to the floor, instead of storing them and sending them through when the context is established. I'm personally not familiar with the details there, but that's my current understanding. So a first ping would get lost, a second one within a timeframe that still has the PDP context open will go through. I think the idea there is that generally, higher level data communication should attempt to resend, but in practice that often doesn't seem to work that well. Not sure how to configure the PDP context timeout, or whether we even can. Theoretically, if you had on your phone a regular ping running in the background ... it's ugly, but yea. Caching those first packets is quite complex, especially for SGSNs sitting on a small device like a sysmoBTS with limited memory. I guess something could be tried there, by limiting resources used for caching in intelligent ways... Someone would need to fund that, or go ahead and try. ~N

1 0

Want to do paid work on Osmocom? sysmocom is hiring
by Harald Welte 31 Oct '17

31 Oct '17

Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to jobs(a)sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwelte(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

1 0

New "osmocom:latest" package feed
by Harald Welte 29 Oct '17

29 Oct '17

Dear Osmocom community, since the NITB-split has completed, and we have integrated 3G fully into master, and also merged nitb-split and nitb packages in one feed, the next step on the agenda was to create packages/feeds that are more stable than "nightly". After a long day of "release engineering" work and related fixes, starting from today, Osmocom not only has the "osmocom:nightly" feed tracking the "master of the day" of all repositories. We now also have a "osmocom:latest" feed for various Debian and Ubuntu GNU/Linux distributions which contains packages for the last tagged version of each source code repository. The setup is fairly similar to that of the "osmocom:nightly" packages and is described at https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds I've also removed all known references to Nightly_Builds on the wiki and replaced it with a reference to the new Binary_Packages page explaining the differences between Nightly_Builds and Latest_Builds: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages As you can see at https://build.opensuse.org/project/monitor/network:osmocom:latest almost all the packages are building already. I intend to fix the remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly. -- - Harald Welte <hwelte(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

1 0

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

← Newer
1
...
21
22
23
24
25
26
27
...
49
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs