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

GPRS trafic in PCU - type BVC-UNBLOCK unknown // Protocol error - unspecified

by Osmocom Mailing List

Hi, I'm trying to run GPRS in my network. So far I get flooded with the bellow trafic in the PCU and the GGNS doesn't appear to receive any traffic. <000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=2) Tx BVC-RESET CAUSE=O&M intervention <000c> gprs_bssgp.c:551 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:348 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-UNBLOCK unknown <000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:298 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <000c> gprs_bssgp_pcu.cpp:835 Sending unblock on BVCI 2 <000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=2) Tx BVC-BLOCK <000c> gprs_bssgp.c:289 Cell 1-1-1-0 CI 0 on BVCI 2 Thanks, Filipe Laíns <https://github.com/FFY00> Sent via Migadu.com, world's easiest email hosting

6 years, 3 months

2
1
0 0

Fwd: icmp encapsulation

by fırat sönmez

---------- Forwarded message ---------- From: fırat sönmez <firatssonmez(a)gmail.com> Date: 2018-02-01 15:51 GMT+03:00 Subject: Re: icmp encapsulation To: Pau Espin Pedrol <pespin(a)sysmocom.de> Hi Pau, Thank you for your response. You are right, I should have told the configuration in more detail. However, you came to the point already. I am talking about the second case where there is NAT. There is a slight difference though. After the NAT two IP (IP1 and IP2) will be IPnat, but the NAT maps the IP1 and IP2 to the port range. Since, there is no port in ICMP, both IP1 and IP2 will be go to uplink as IPg and but on the return there must be problem for NAT machine to traverse the two different paths from IPnat to IP1 and IPnat to IP2. I looked into the ICMP header and observed the packets have different identifiers. So, NAT machine must be using the identifies to reverse the packets. Anyways, in my case the *IP1=IP2* (In my experimental architecture, the GGSN will not be assigning distinct IP for each host. Instead, GGSN will assign 1 IP address for 32 hosts (seems like NAT). My configuration is probably out of standard architectures, but I need to understand how would gtp handle matching these two pdp contexts. I have tried this configuration, pinging from two different host with same IP and it was successful! Two packets coming from the server to the GGSN will be *[src:IPs | dst:IP1]* and *[src:IPs | dst:IP2]* IP1=IP2, but two packets have different icmp identifier. And pdp contexts are still resolved successfully. so a big HOW in my mind? Fırat 2018-02-01 13:46 GMT+03:00 Pau Espin Pedrol <pespin(a)sysmocom.de>: > Hi firat, > > I didn't understand fully the configuration you are describing. Something > like this? > > Host1 --SGSN1--\GGSN--Server > Host2 --SGSN2--/ > > Where Host1 has been assigned IP1 and Host2 has been assigned IP2, both > assigned by GGSN where IP1 != IP2. Let's assume the server IP is IPs and > the GGSN public uplink (non-GTP) IP is IPg. > > As far as I understand, it works as follow: > > - Case without NAT between GGSN and Server: > Host1 sends ICMP packet with saddr=IP1 daddr=IPs, which gets encapsulated > through GTP and GGSN decapsulates it. Same for Host2 but in this case the > packet will have saddr=IP2. As there's no NAT (eg. host clients are > assigned a public IP), the server receives 2 ICMP packets with different > saddr, and when answering back using the original saddr now as daddr. As > GGSN keeps track of the saddr assigned to each pdp context, when it > receives a packet from the uplink (non-GTP side), it matches the daddr of > the packet against the saddr of the active pdp ctx to find to which pdp ctx > should forward the packet. > > - Case with NAT between GGSN and Server: > Almost the same but with extra steps done by the NAT. When the GGSN sends > the packet saddr=IP1 daddr=IPs to the server, the NAT changes > saddr=IP1->IPg. It does the same for saddr=IP2, but the NAT keeps track of > the binding. When the response is received from the server, the NAT > converts back IPg->IP1 and GGSN can again track the pdp ctx as described in > the previous case. > > -- > - Pau Espin Pedrol <pespin(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 >

6 years, 3 months

2
1
0 0

icmp encapsulation

by fırat sönmez

Hi, I would like to ask&know how the GGSN holds and finds pdp contexts for icmp packets that have same source and destination address on the downlink? For example, if there are two hosts having same IP address behind two different network pinging same destination address and they are encapsulated at SGSN and then one GGSN receives both and saves the packet, decapsulates and sends to the destination. On the downlink destination responds to the two ping packets (they are different because they have different identifier in icmp packet), but then how does GGSN finds the pdp contexts again to encapsulate these packets and send back to the two SGSNs? The pdp context doesnt include thse icmp identifiers. There is no sockets either since icmp doesnt have sockets. On the downlink, when there are two icmp packets recieved by GGSN, there is only icmp identfier that distinguish each other, but this identifier is not in the pdp context. Would someone help me figure out this? Thank you all

6 years, 3 months

2
1
0 0

sgsnemu ignoring Request accepted

by Viktor Tsymbalyuk

Hello, I continue to play with sgsnemu, and found that it stopped for some reason after "Request accepted". Does sgsnemu working? At my mind problem inside `create_pdp_conf` function . After small changes, I start to see icmp inside gtp tunnel in trace. Please check attachments with console output, patch and pcap. May be I has wrong understanding. -- Viktor

6 years, 3 months

2
4
0 0

sgsnemu: why --listen and --remote in one network?

by Viktor Tsymbalyuk

Hello, I'm querying why sgsnemu shoul work in a same network with ggsn? What the reason for such limitation? -- Viktor

6 years, 3 months

2
3
0 0

Osmocom Year 2017 Review

by Harald Welte

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)

6 years, 4 months

1
0
0 0

OsmoDevCon 2018 schedule 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.] 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)

6 years, 5 months

1
1
0 0

Packets are not arrived at tunnel setup by libgtpnl

by congnt

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.

6 years, 5 months

2
2
0 0

libgtpnl migrated to gerrit

by Harald Welte

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)

6 years, 5 months

1
0
0 0

Re: GPRS EXperiments

by Neels Hofmeyr

(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

6 years, 6 months

1
0
0 0

Want to do paid work on Osmocom? sysmocom is hiring

by Harald Welte

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

6 years, 6 months

1
0
0 0

New "osmocom:latest" package feed

by Harald Welte

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

6 years, 6 months

1
0
0 0

libgtp: Users of gtpie_encaps() and gtpie_encaps2() ?

by Harald Welte

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)

6 years, 6 months

1
0
0 0

Planning for OsmoCon + OsmoDevCon

by Harald Welte

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

6 years, 6 months

1
0
0 0

Current osmo-pcu patch set

by Holger Freyther

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

6 years, 7 months

4
5
0 0

HEADS UP: stricter VTY, possible config fallout

by Neels Hofmeyr

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

6 years, 7 months

3
3
0 0

Kernel patchset for IPv6 support on netdev mailinglist

by Harald Welte

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)

6 years, 7 months

1
0
0 0

回复：Re: Unable to access git repository

by lokira

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

6 years, 7 months

1
0
0 0

Unable to access git repository

by lokira

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

6 years, 7 months

2
1
0 0

Update and Question

by fırat sönmez

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

6 years, 7 months

1
0
0 0

Unable to start osmo-ggsn with -g or --gtp-linux options

by Ravi Tandon

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>

6 years, 7 months

2
1
0 0

OsmoGGSN succeeds OpenGGSN!

by Harald Welte

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)

6 years, 8 months

2
2
0 0

GTP-C v2 in open grps

by Tom Herbert

Hello, I am a newbie in this area so please pardon me if these are dumb or covered questions! I am looking for a GTP stack that implements GTP-C version 2. Is this supported in open grps or is there a plan for that? If not, what stack (preferably open source) is recommended? Thanks, Tom

6 years, 8 months

3
6
0 0

RFC: OpenGGSN split/rename

by Max

Hi. With the ongoing split of OpenBSC into per-project repository, I wonder if we could do the same to OpenGGSN and split libgtp into separate repository? Rationale: * would simplify docs for newcomers (it's not obvious that openggsn have to be built ahead of OsmoSGSN because of libgtp) * simplify release process (we can release libgtp independently of OpenGGSN, makes it easier to automate too) While at it and considering recent IPv6 support (and related config changes) it might be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the breaking point. What do you think? -- 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

6 years, 8 months

3
5
0 0

redmine e-mails broken from 08/26 through 08/31

by Harald Welte

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - 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)

6 years, 8 months

1
0
0 0

OpenGGSN IPv6 PDP context support

by Harald Welte

Dear all, I've been busy all day (and night) implementing IPv6 PDP context support in OpenGGSN. The related code is currently in gerrit for review, you can also use the 'laforge/ipv6' branch of openggsn.git In terms of configuration, all you need to do is to specify IPv6 address + prefix as the 'net'. If you don't specify a 'dynip' config option, it will automatically use the network/prefix specified in 'net'. My minimalistic example config file for testing looks like this: debug fg listen 127.0.0.6 net 2001:780:44:2000:0:0:0:0/120 Which means it is listening for GTP on IPv4 (no IPv6 on the GTP side supported), and will create a tun device with the stated IPv6 address and a /120 netmask. Your GGSN is 2001:780:44:2000::1, and UEs will get addresses allocated from 2001:780:44:2000::2 onwards. It's important to configure your UE to actually request and IPv6 PDP context. If no v4/v6 is specified in the request, it will default to IPv4. If IPv4 is requested while having a v6 pool configured, OpenGGSN will reject the PDP Context Creation due to not being able to serve a v4 PDP context. I don't have immediate plans for supporting IPv6 on the outer (transport) layer for now. I also have no plans to support v4 and v6 from a single OpenGGSN at this time. It's quite easy to run two different OpenGGSN instances in parallel, on two different IPv4 addresses for the GTP side, and then use OsmoSGSN's PDP context routing to those different GGSNs. This way it is possible to have a v4 APN and a v6 APN without having to do any additional development right now. Architecturally, having multiple IP pools (and some for v4 and some for v6) is definitely possible, and should actually be easy. We just need to switch to a configuration mechanism that supports something like this, such as libosmovty. Once we have a VTY based configuration, it should be simple to operate multiple IP pools or multiple virtual APNs on one OpenGGSN. WARNING: The Linux Kernel GTP code does *not* support IPv6 user payload at this point. So if you want IPv6, you will need to use regular, old-fashioned userspace GTP-U in OpenGGSN for now. Controbutions are always welcome, of course! 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)

6 years, 9 months

1
0
0 0

[PATCH net-next v1 0/3] Flow Based GTP Tunneling

by Jiannan Ouyang

This patch series augmented the existing GTP module to support flow based GTP tunneling and modified the openvswitch datapath to support the GTP vport type. A flow based GTP net device enables that, 1) on the RX path, the outer (IP/UDP/GTP) header information could to be stored in the metadata_dst struct, and embedded into the skb. 2) on the TX path, packets are encapsulated following instructions in the metadata_dst field of the skb. A flow based GTP net device can be integrated with Open vSwitch, which allows SDN controllers to program GTP tunnels via Open vSwitch. Open vSwitch changes are based on patch set [PATCH] Add GTP vport based on upstream datapath Example usage with OVS: ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ ofport_request=2 type=gtp option:remote_ip=flow options:key=flow ovs-ofctl add-flow br0 "in_port=2,tun_src=192.168.60.141,tun_id=123, \ actions=set_field:02:00:00:00:00:00->eth_src, \ set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL" ovs-ofctl add-flow br0 \ "in_port=LOCAL,actions=set_tunnel:888, \ set_field:192.168.60.141->tun_dst,2" arp -s 10.1.1.122 02:00:00:00:00:00 Jiannan Ouyang (3): gtp: refactor to support flow-based gtp encap and decap gtp: Support creating flow-based gtp net_device openvswitch: Add GPRS Tunnel Protocol (GTP) vport support drivers/net/gtp.c | 375 ++++++++++++++++++++++++++++++++------- include/net/gtp.h | 8 + include/uapi/linux/openvswitch.h | 1 + net/openvswitch/Kconfig | 10 ++ net/openvswitch/Makefile | 1 + net/openvswitch/vport-gtp.c | 144 +++++++++++++++ 6 files changed, 475 insertions(+), 64 deletions(-) create mode 100644 net/openvswitch/vport-gtp.c -- 2.9.3

6 years, 9 months

6
16
0 0

[PATCH net 5/7] gtp: Initialize 64-bit per-cpu stats correctly

by Florian Fainelli

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that by using netdev_alloc_pcpu_stats() instead of an open coded allocation. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 1542e837fdfa..f38e32a7ec9c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -364,7 +364,7 @@ static int gtp_dev_init(struct net_device *dev) gtp->dev = dev; - dev->tstats = alloc_percpu(struct pcpu_sw_netstats); + dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats); if (!dev->tstats) return -ENOMEM; -- 2.9.3

6 years, 9 months

2
1
0 0

GTP in previous kernels

by fırat sönmez

Hi, I am currently working on building a GTP tunnel between two hosts. I used two virtual machines to implement GTP tunnel. The machines have the kernel 4.8 since GTP is in mainline. (I just did 'modprobe gtp') I setup the tunnel with libgtpnl tools. What I would like to do is that I want to have GTP module in a kernel 3.18. I did some google search and then I added the headers, libraries and the source code to the source code of 3.18 to compile all the kernel, but it didnt work. I am not experienced in kernel module programming or about the consequences compiling GTP in previous kernels which have different structural mechanisms than the 4.* versions. Is there any way to achieve this? If so, how could it be possible to get help from this community? Thanks all, Fırat

6 years, 10 months

2
1
0 0

[PATCH net-next] net: add netlink_ext_ack support to rtnl_link_ops

by Matthias Schiffer

The following functions are extended with a netlink_ext_ack argument to allow extended error reporting: * validate * newlink * changelink * slave_validate * slave_changelink Signed-off-by: Matthias Schiffer <mschiffer(a)universe-factory.net> --- Checkpatch is unhappy about the long lines in include/net/rtnetlink.h, but I guess it's as readable as it gets... Most work was done by the following Coccinelle snippet, the original version of which was provided by Johannes Berg: @ops1@ identifier newfn, ops; @@ struct rtnl_link_ops ops = { .newlink = newfn, ... }; @@ identifier ops1.newfn; identifier src_net, dev, tb, data; @@ -int newfn(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +int newfn(struct net *src_net, struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops2@ identifier chfn, ops; @@ struct rtnl_link_ops ops = { .changelink = chfn, ... }; @@ identifier ops2.chfn; identifier dev, tb, data; @@ -int chfn(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +int chfn(struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops3@ identifier valfn, ops; @@ struct rtnl_link_ops ops = { .validate = valfn, ... }; @@ identifier ops3.valfn; identifier tb, data; @@ -int valfn(struct nlattr *tb[], struct nlattr *data[]) +int valfn(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops4@ identifier chfn, ops; @@ struct rtnl_link_ops ops = { .slave_changelink = chfn, ... }; @@ identifier ops4.chfn; identifier dev, slave_dev, tb, data; @@ -int chfn(struct net_device *dev, struct net_device *slave_dev, - struct nlattr *tb[], struct nlattr *data[]) +int chfn(struct net_device *dev, struct net_device *slave_dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops5@ identifier valfn, ops; @@ struct rtnl_link_ops ops = { .slave_validate = valfn, ... }; @@ identifier ops5.valfn; identifier tb, data; @@ -int valfn(struct nlattr *tb[], struct nlattr *data[]) +int valfn(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 10 ++++++---- drivers/net/bonding/bond_netlink.c | 16 ++++++++++------ drivers/net/caif/caif_hsi.c | 6 ++++-- drivers/net/can/dev.c | 11 +++++++---- drivers/net/can/vxcan.c | 3 ++- drivers/net/dummy.c | 3 ++- drivers/net/geneve.c | 6 ++++-- drivers/net/gtp.c | 6 ++++-- drivers/net/ifb.c | 3 ++- drivers/net/ipvlan/ipvlan.h | 3 ++- drivers/net/ipvlan/ipvlan_main.c | 9 ++++++--- drivers/net/ipvlan/ipvtap.c | 9 ++++----- drivers/net/macsec.c | 9 ++++++--- drivers/net/macvlan.c | 9 ++++++--- drivers/net/macvtap.c | 7 +++---- drivers/net/nlmon.c | 3 ++- drivers/net/ppp/ppp_generic.c | 6 ++++-- drivers/net/team/team.c | 6 ++++-- drivers/net/tun.c | 3 ++- drivers/net/veth.c | 8 +++++--- drivers/net/vrf.c | 6 ++++-- drivers/net/vxlan.c | 9 ++++++--- include/net/rtnetlink.h | 15 ++++++++++----- net/8021q/vlan_netlink.c | 13 ++++++++----- net/bridge/br_netlink.c | 15 ++++++++++----- net/caif/chnl_net.c | 6 ++++-- net/core/rtnetlink.c | 13 ++++++++----- net/hsr/hsr_netlink.c | 3 ++- net/ieee802154/6lowpan/core.c | 6 ++++-- net/ipv4/ip_gre.c | 16 ++++++++++------ net/ipv4/ip_vti.c | 9 ++++++--- net/ipv4/ipip.c | 9 ++++++--- net/ipv6/ip6_gre.c | 14 +++++++++----- net/ipv6/ip6_tunnel.c | 9 ++++++--- net/ipv6/ip6_vti.c | 9 ++++++--- net/ipv6/sit.c | 9 ++++++--- 36 files changed, 190 insertions(+), 107 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c index 28884781311b..3e44087935ae 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c @@ -64,8 +64,9 @@ static int ipoib_fill_info(struct sk_buff *skb, const struct net_device *dev) return -EMSGSIZE; } -static int ipoib_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +static int ipoib_changelink(struct net_device *dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { u16 mode, umcast; int ret = 0; @@ -93,7 +94,8 @@ static int ipoib_changelink(struct net_device *dev, } static int ipoib_new_child_link(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_device *pdev; struct ipoib_dev_priv *ppriv; @@ -133,7 +135,7 @@ static int ipoib_new_child_link(struct net *src_net, struct net_device *dev, child_pkey, IPOIB_RTNL_CHILD); if (!err && data) - err = ipoib_changelink(dev, tb, data); + err = ipoib_changelink(dev, tb, data, extack); return err; } diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c index 47a8103610bc..a1b33aa6054a 100644 --- a/drivers/net/bonding/bond_netlink.c +++ b/drivers/net/bonding/bond_netlink.c @@ -118,7 +118,8 @@ static const struct nla_policy bond_slave_policy[IFLA_BOND_SLAVE_MAX + 1] = { [IFLA_BOND_SLAVE_QUEUE_ID] = { .type = NLA_U16 }, }; -static int bond_validate(struct nlattr *tb[], struct nlattr *data[]) +static int bond_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -131,7 +132,8 @@ static int bond_validate(struct nlattr *tb[], struct nlattr *data[]) static int bond_slave_changelink(struct net_device *bond_dev, struct net_device *slave_dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct bonding *bond = netdev_priv(bond_dev); struct bond_opt_value newval; @@ -156,8 +158,9 @@ static int bond_slave_changelink(struct net_device *bond_dev, return 0; } -static int bond_changelink(struct net_device *bond_dev, - struct nlattr *tb[], struct nlattr *data[]) +static int bond_changelink(struct net_device *bond_dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct bonding *bond = netdev_priv(bond_dev); struct bond_opt_value newval; @@ -438,11 +441,12 @@ static int bond_changelink(struct net_device *bond_dev, } static int bond_newlink(struct net *src_net, struct net_device *bond_dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { int err; - err = bond_changelink(bond_dev, tb, data); + err = bond_changelink(bond_dev, tb, data, extack); if (err < 0) return err; diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c index 11ba6e3eea22..438966bf51c2 100644 --- a/drivers/net/caif/caif_hsi.c +++ b/drivers/net/caif/caif_hsi.c @@ -1352,7 +1352,8 @@ static void cfhsi_netlink_parms(struct nlattr *data[], struct cfhsi *cfhsi) } static int caif_hsi_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { cfhsi_netlink_parms(data, netdev_priv(dev)); netdev_state_change(dev); @@ -1399,7 +1400,8 @@ static int caif_hsi_fill_info(struct sk_buff *skb, const struct net_device *dev) } static int caif_hsi_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct cfhsi *cfhsi = NULL; struct cfhsi_ops *(*get_ops)(void); diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index a3011c001080..365a8cc62405 100644 --- a/drivers/net/can/dev.c +++ b/drivers/net/can/dev.c @@ -848,7 +848,8 @@ static const struct nla_policy can_policy[IFLA_CAN_MAX + 1] = { = { .len = sizeof(struct can_bittiming_const) }, }; -static int can_validate(struct nlattr *tb[], struct nlattr *data[]) +static int can_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { bool is_can_fd = false; @@ -880,8 +881,9 @@ static int can_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int can_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +static int can_changelink(struct net_device *dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct can_priv *priv = netdev_priv(dev); int err; @@ -1146,7 +1148,8 @@ static int can_fill_xstats(struct sk_buff *skb, const struct net_device *dev) } static int can_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return -EOPNOTSUPP; } diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c index cfe889e8f172..8404e8852a0f 100644 --- a/drivers/net/can/vxcan.c +++ b/drivers/net/can/vxcan.c @@ -163,7 +163,8 @@ static void vxcan_setup(struct net_device *dev) static struct rtnl_link_ops vxcan_link_ops; static int vxcan_newlink(struct net *net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vxcan_priv *priv; struct net_device *peer; diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c index 9905b52fe293..d0c165d2086e 100644 --- a/drivers/net/dummy.c +++ b/drivers/net/dummy.c @@ -356,7 +356,8 @@ static void dummy_setup(struct net_device *dev) dev->max_mtu = ETH_MAX_MTU; } -static int dummy_validate(struct nlattr *tb[], struct nlattr *data[]) +static int dummy_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c index d586ad93aaff..eb77201cb718 100644 --- a/drivers/net/geneve.c +++ b/drivers/net/geneve.c @@ -1058,7 +1058,8 @@ static const struct nla_policy geneve_policy[IFLA_GENEVE_MAX + 1] = { [IFLA_GENEVE_UDP_ZERO_CSUM6_RX] = { .type = NLA_U8 }, }; -static int geneve_validate(struct nlattr *tb[], struct nlattr *data[]) +static int geneve_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -1181,7 +1182,8 @@ static void init_tnl_info(struct ip_tunnel_info *info, __u16 dst_port) } static int geneve_newlink(struct net *net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { bool use_udp6_rx_checksums = false; struct ip_tunnel_info info; diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 8e333a8a2295..1542e837fdfa 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -636,7 +636,8 @@ static void gtp_hashtable_free(struct gtp_dev *gtp); static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]); static int gtp_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct gtp_dev *gtp; struct gtp_net *gn; @@ -697,7 +698,8 @@ static const struct nla_policy gtp_policy[IFLA_GTP_MAX + 1] = { [IFLA_GTP_ROLE] = { .type = NLA_U32 }, }; -static int gtp_validate(struct nlattr *tb[], struct nlattr *data[]) +static int gtp_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (!data) return -EINVAL; diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c index 144ea5ae8ab4..8870bd2a2e8a 100644 --- a/drivers/net/ifb.c +++ b/drivers/net/ifb.c @@ -273,7 +273,8 @@ static int ifb_open(struct net_device *dev) return 0; } -static int ifb_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ifb_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) diff --git a/drivers/net/ipvlan/ipvlan.h b/drivers/net/ipvlan/ipvlan.h index 7919369c0a72..ba8173a0b62e 100644 --- a/drivers/net/ipvlan/ipvlan.h +++ b/drivers/net/ipvlan/ipvlan.h @@ -140,7 +140,8 @@ unsigned int ipvlan_nf_input(void *priv, struct sk_buff *skb, void ipvlan_count_rx(const struct ipvl_dev *ipvlan, unsigned int len, bool success, bool mcast); int ipvlan_link_new(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]); + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack); void ipvlan_link_delete(struct net_device *dev, struct list_head *head); void ipvlan_link_setup(struct net_device *dev); int ipvlan_link_register(struct rtnl_link_ops *ops); diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c index dc888dd344eb..f37e3c1fd4e7 100644 --- a/drivers/net/ipvlan/ipvlan_main.c +++ b/drivers/net/ipvlan/ipvlan_main.c @@ -455,7 +455,8 @@ static const struct ethtool_ops ipvlan_ethtool_ops = { }; static int ipvlan_nl_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ipvl_dev *ipvlan = netdev_priv(dev); struct ipvl_port *port = ipvlan_port_get_rtnl(ipvlan->phy_dev); @@ -476,7 +477,8 @@ static size_t ipvlan_nl_getsize(const struct net_device *dev) ); } -static int ipvlan_nl_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipvlan_nl_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (data && data[IFLA_IPVLAN_MODE]) { u16 mode = nla_get_u16(data[IFLA_IPVLAN_MODE]); @@ -508,7 +510,8 @@ static int ipvlan_nl_fillinfo(struct sk_buff *skb, } int ipvlan_link_new(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ipvl_dev *ipvlan = netdev_priv(dev); struct ipvl_port *port; diff --git a/drivers/net/ipvlan/ipvtap.c b/drivers/net/ipvlan/ipvtap.c index 2b713b63b62c..22f133ea8d7b 100644 --- a/drivers/net/ipvlan/ipvtap.c +++ b/drivers/net/ipvlan/ipvtap.c @@ -73,10 +73,9 @@ static void ipvtap_update_features(struct tap_dev *tap, netdev_update_features(vlan->dev); } -static int ipvtap_newlink(struct net *src_net, - struct net_device *dev, - struct nlattr *tb[], - struct nlattr *data[]) +static int ipvtap_newlink(struct net *src_net, struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ipvtap_dev *vlantap = netdev_priv(dev); int err; @@ -98,7 +97,7 @@ static int ipvtap_newlink(struct net *src_net, /* Don't put anything that may fail after macvlan_common_newlink * because we can't undo what it does. */ - err = ipvlan_link_new(src_net, dev, tb, data); + err = ipvlan_link_new(src_net, dev, tb, data, extack); if (err) { netdev_rx_handler_unregister(dev); return err; diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index e370d7c894cb..5e1ab1160856 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -3056,7 +3056,8 @@ static void macsec_changelink_common(struct net_device *dev, } static int macsec_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { if (!data) return 0; @@ -3203,7 +3204,8 @@ static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len) } static int macsec_newlink(struct net *net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct macsec_dev *macsec = macsec_priv(dev); struct net_device *real_dev; @@ -3285,7 +3287,8 @@ static int macsec_newlink(struct net *net, struct net_device *dev, return err; } -static int macsec_validate_attr(struct nlattr *tb[], struct nlattr *data[]) +static int macsec_validate_attr(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u64 csid = MACSEC_DEFAULT_CIPHER_ID; u8 icv_len = DEFAULT_ICV_LEN; diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c index 8ca274c6df3d..9ffff0362a11 100644 --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -1162,7 +1162,8 @@ static void macvlan_port_destroy(struct net_device *dev) kfree(port); } -static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -1390,7 +1391,8 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev, EXPORT_SYMBOL_GPL(macvlan_common_newlink); static int macvlan_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return macvlan_common_newlink(src_net, dev, tb, data); } @@ -1408,7 +1410,8 @@ void macvlan_dellink(struct net_device *dev, struct list_head *head) EXPORT_SYMBOL_GPL(macvlan_dellink); static int macvlan_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct macvlan_dev *vlan = netdev_priv(dev); enum macvlan_mode mode; diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index da85057680d6..91e7b19bbf86 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -77,10 +77,9 @@ static void macvtap_update_features(struct tap_dev *tap, netdev_update_features(vlan->dev); } -static int macvtap_newlink(struct net *src_net, - struct net_device *dev, - struct nlattr *tb[], - struct nlattr *data[]) +static int macvtap_newlink(struct net *src_net, struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct macvtap_dev *vlantap = netdev_priv(dev); int err; diff --git a/drivers/net/nlmon.c b/drivers/net/nlmon.c index c4b3362da4a2..4b22955de191 100644 --- a/drivers/net/nlmon.c +++ b/drivers/net/nlmon.c @@ -127,7 +127,8 @@ static void nlmon_setup(struct net_device *dev) dev->min_mtu = sizeof(struct nlmsghdr); } -static int nlmon_validate(struct nlattr *tb[], struct nlattr *data[]) +static int nlmon_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) return -EINVAL; diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index d42091f11eb8..13028833bee3 100644 --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -1061,7 +1061,8 @@ static const struct nla_policy ppp_nl_policy[IFLA_PPP_MAX + 1] = { [IFLA_PPP_DEV_FD] = { .type = NLA_S32 }, }; -static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (!data) return -EINVAL; @@ -1075,7 +1076,8 @@ static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[]) } static int ppp_nl_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ppp_config conf = { .unit = -1, diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c index 629a412dc690..464570409796 100644 --- a/drivers/net/team/team.c +++ b/drivers/net/team/team.c @@ -2101,7 +2101,8 @@ static void team_setup(struct net_device *dev) } static int team_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS] == NULL) eth_hw_addr_random(dev); @@ -2109,7 +2110,8 @@ static int team_newlink(struct net *src_net, struct net_device *dev, return register_netdevice(dev); } -static int team_validate(struct nlattr *tb[], struct nlattr *data[]) +static int team_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index ae49f4b99b67..3d4c24572ecd 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1580,7 +1580,8 @@ static void tun_setup(struct net_device *dev) /* Trivial set of netlink ops to allow deleting tun or tap * device with netlink. */ -static int tun_validate(struct nlattr *tb[], struct nlattr *data[]) +static int tun_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return -EINVAL; } diff --git a/drivers/net/veth.c b/drivers/net/veth.c index 0156fe8cac17..b33553b1e19c 100644 --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -329,7 +329,8 @@ static void veth_setup(struct net_device *dev) * netlink interface */ -static int veth_validate(struct nlattr *tb[], struct nlattr *data[]) +static int veth_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -347,7 +348,8 @@ static int veth_validate(struct nlattr *tb[], struct nlattr *data[]) static struct rtnl_link_ops veth_link_ops; static int veth_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { int err; struct net_device *peer; @@ -373,7 +375,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev, if (err < 0) return err; - err = veth_validate(peer_tb, NULL); + err = veth_validate(peer_tb, NULL, extack); if (err < 0) return err; diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 997ef25189fd..f4d0054981c6 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -1372,7 +1372,8 @@ static void vrf_setup(struct net_device *dev) dev->priv_flags |= IFF_NO_QUEUE; } -static int vrf_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vrf_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -1389,7 +1390,8 @@ static void vrf_dellink(struct net_device *dev, struct list_head *head) } static int vrf_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_vrf *vrf = netdev_priv(dev); bool *add_fib_rules; diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index 653b2bb32be1..0dafd8e6c665 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -2711,7 +2711,8 @@ static const struct nla_policy vxlan_policy[IFLA_VXLAN_MAX + 1] = { [IFLA_VXLAN_REMCSUM_NOPARTIAL] = { .type = NLA_FLAG }, }; -static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) { @@ -3333,7 +3334,8 @@ static int vxlan_nl2conf(struct nlattr *tb[], struct nlattr *data[], } static int vxlan_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vxlan_config conf; int err; @@ -3346,7 +3348,8 @@ static int vxlan_newlink(struct net *src_net, struct net_device *dev, } static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vxlan_dev *vxlan = netdev_priv(dev); struct vxlan_rdst *dst = &vxlan->default_dst; diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h index 78fa5fe32947..abe6b733d473 100644 --- a/include/net/rtnetlink.h +++ b/include/net/rtnetlink.h @@ -63,15 +63,18 @@ struct rtnl_link_ops { int maxtype; const struct nla_policy *policy; int (*validate)(struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); int (*newlink)(struct net *src_net, struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); int (*changelink)(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); void (*dellink)(struct net_device *dev, struct list_head *head); @@ -88,11 +91,13 @@ struct rtnl_link_ops { int slave_maxtype; const struct nla_policy *slave_policy; int (*slave_validate)(struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); int (*slave_changelink)(struct net_device *dev, struct net_device *slave_dev, struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); size_t (*get_slave_size)(const struct net_device *dev, const struct net_device *slave_dev); int (*fill_slave_info)(struct sk_buff *skb, diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c index 9c94aad153b3..5e831de3103e 100644 --- a/net/8021q/vlan_netlink.c +++ b/net/8021q/vlan_netlink.c @@ -39,7 +39,8 @@ static inline int vlan_validate_qos_map(struct nlattr *attr) NULL); } -static int vlan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vlan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ifla_vlan_flags *flags; u16 id; @@ -87,8 +88,9 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int vlan_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +static int vlan_changelink(struct net_device *dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ifla_vlan_flags *flags; struct ifla_vlan_qos_mapping *m; @@ -115,7 +117,8 @@ static int vlan_changelink(struct net_device *dev, } static int vlan_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vlan_dev_priv *vlan = vlan_dev_priv(dev); struct net_device *real_dev; @@ -153,7 +156,7 @@ static int vlan_newlink(struct net *src_net, struct net_device *dev, else if (dev->mtu > max_mtu) return -EINVAL; - err = vlan_changelink(dev, tb, data); + err = vlan_changelink(dev, tb, data, extack); if (err < 0) return err; diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index 63dca347b73b..3bc890716c89 100644 --- a/net/bridge/br_netlink.c +++ b/net/bridge/br_netlink.c @@ -858,7 +858,9 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh, u16 flags) return err; } -static int br_validate(struct nlattr *tb[], struct nlattr *data[]) + +static int br_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -895,7 +897,8 @@ static int br_validate(struct nlattr *tb[], struct nlattr *data[]) static int br_port_slave_changelink(struct net_device *brdev, struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_bridge *br = netdev_priv(brdev); int ret; @@ -960,7 +963,8 @@ static const struct nla_policy br_policy[IFLA_BR_MAX + 1] = { }; static int br_changelink(struct net_device *brdev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_bridge *br = netdev_priv(brdev); int err; @@ -1213,7 +1217,8 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[], } static int br_dev_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_bridge *br = netdev_priv(dev); int err; @@ -1228,7 +1233,7 @@ static int br_dev_newlink(struct net *src_net, struct net_device *dev, if (err) return err; - err = br_changelink(dev, tb, data); + err = br_changelink(dev, tb, data, extack); if (err) unregister_netdevice(dev); return err; diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c index fe3c53efb949..922ac1d605b3 100644 --- a/net/caif/chnl_net.c +++ b/net/caif/chnl_net.c @@ -461,7 +461,8 @@ static void caif_netlink_parms(struct nlattr *data[], } static int ipcaif_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { int ret; struct chnl_net *caifdev; @@ -484,7 +485,8 @@ static int ipcaif_newlink(struct net *src_net, struct net_device *dev, } static int ipcaif_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct chnl_net *caifdev; ASSERT_RTNL(); diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 9a1bd510c812..ed51de525a88 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -2582,7 +2582,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, data = attr; } if (ops->validate) { - err = ops->validate(tb, data); + err = ops->validate(tb, data, extack); if (err < 0) return err; } @@ -2601,7 +2601,8 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, slave_data = slave_attr; } if (m_ops->slave_validate) { - err = m_ops->slave_validate(tb, slave_data); + err = m_ops->slave_validate(tb, slave_data, + extack); if (err < 0) return err; } @@ -2620,7 +2621,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, !ops->changelink) return -EOPNOTSUPP; - err = ops->changelink(dev, tb, data); + err = ops->changelink(dev, tb, data, extack); if (err < 0) return err; status |= DO_SETLINK_NOTIFY; @@ -2631,7 +2632,8 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, return -EOPNOTSUPP; err = m_ops->slave_changelink(master_dev, dev, - tb, slave_data); + tb, slave_data, + extack); if (err < 0) return err; status |= DO_SETLINK_NOTIFY; @@ -2705,7 +2707,8 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, dev->ifindex = ifm->ifi_index; if (ops->newlink) { - err = ops->newlink(link_net ? : net, dev, tb, data); + err = ops->newlink(link_net ? : net, dev, tb, data, + extack); /* Drivers should call free_netdev() in ->destructor * and unregister it on failure after registration * so that device could be finally freed in rtnl_unlock. diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c index 81dac16933fc..b9cce0fd5696 100644 --- a/net/hsr/hsr_netlink.c +++ b/net/hsr/hsr_netlink.c @@ -33,7 +33,8 @@ static const struct nla_policy hsr_policy[IFLA_HSR_MAX + 1] = { * hsr_dev_setup routine has been executed. Nice! */ static int hsr_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_device *link[2]; unsigned char multicast_spec, hsr_version; diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c index 0a866f332290..de2661cd0328 100644 --- a/net/ieee802154/6lowpan/core.c +++ b/net/ieee802154/6lowpan/core.c @@ -111,7 +111,8 @@ static void lowpan_setup(struct net_device *ldev) ldev->features |= NETIF_F_NETNS_LOCAL; } -static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != IEEE802154_ADDR_LEN) @@ -121,7 +122,8 @@ static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[]) } static int lowpan_newlink(struct net *src_net, struct net_device *ldev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_device *wdev; int ret; diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c index 41394a4b9af9..7a7829e839c2 100644 --- a/net/ipv4/ip_gre.c +++ b/net/ipv4/ip_gre.c @@ -779,7 +779,8 @@ static struct pernet_operations ipgre_net_ops = { .size = sizeof(struct ip_tunnel_net), }; -static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { __be16 flags; @@ -802,7 +803,8 @@ static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { __be32 daddr; @@ -823,7 +825,7 @@ static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) } out: - return ipgre_tunnel_validate(tb, data); + return ipgre_tunnel_validate(tb, data, extack); } static int ipgre_netlink_parms(struct net_device *dev, @@ -957,7 +959,8 @@ static void ipgre_tap_setup(struct net_device *dev) } static int ipgre_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel_parm p; struct ip_tunnel_encap ipencap; @@ -979,7 +982,8 @@ static int ipgre_newlink(struct net *src_net, struct net_device *dev, } static int ipgre_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; @@ -1155,7 +1159,7 @@ struct net_device *gretap_fb_dev_create(struct net *net, const char *name, t = netdev_priv(dev); t->collect_md = true; - err = ipgre_newlink(net, dev, tb, NULL); + err = ipgre_newlink(net, dev, tb, NULL, NULL); if (err < 0) { free_netdev(dev); return ERR_PTR(err); diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c index 4ec9affb2252..0192c255e508 100644 --- a/net/ipv4/ip_vti.c +++ b/net/ipv4/ip_vti.c @@ -465,7 +465,8 @@ static struct pernet_operations vti_net_ops = { .size = sizeof(struct ip_tunnel_net), }; -static int vti_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vti_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return 0; } @@ -503,7 +504,8 @@ static void vti_netlink_parms(struct nlattr *data[], } static int vti_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel_parm parms; __u32 fwmark = 0; @@ -513,7 +515,8 @@ static int vti_newlink(struct net *src_net, struct net_device *dev, } static int vti_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); __u32 fwmark = t->fwmark; diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c index 1e441c6f2160..fb1ad22b5e29 100644 --- a/net/ipv4/ipip.c +++ b/net/ipv4/ipip.c @@ -375,7 +375,8 @@ static int ipip_tunnel_init(struct net_device *dev) return ip_tunnel_init(dev); } -static int ipip_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipip_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u8 proto; @@ -469,7 +470,8 @@ static bool ipip_netlink_encap_parms(struct nlattr *data[], } static int ipip_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; @@ -488,7 +490,8 @@ static int ipip_newlink(struct net *src_net, struct net_device *dev, } static int ipip_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c index e0e726c338a7..67ff2aaf5dcb 100644 --- a/net/ipv6/ip6_gre.c +++ b/net/ipv6/ip6_gre.c @@ -1170,7 +1170,8 @@ static struct pernet_operations ip6gre_net_ops = { .size = sizeof(struct ip6gre_net), }; -static int ip6gre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ip6gre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { __be16 flags; @@ -1188,7 +1189,8 @@ static int ip6gre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int ip6gre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ip6gre_tap_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct in6_addr daddr; @@ -1209,7 +1211,7 @@ static int ip6gre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) } out: - return ip6gre_tunnel_validate(tb, data); + return ip6gre_tunnel_validate(tb, data, extack); } @@ -1342,7 +1344,8 @@ static bool ip6gre_netlink_encap_parms(struct nlattr *data[], } static int ip6gre_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *nt; struct net *net = dev_net(dev); @@ -1403,7 +1406,8 @@ static int ip6gre_newlink(struct net *src_net, struct net_device *dev, } static int ip6gre_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *t, *nt = netdev_priv(dev); struct net *net = nt->net; diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c index 8c6c3c8e7eef..3a0ba2ae4b0f 100644 --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1885,7 +1885,8 @@ static int __net_init ip6_fb_tnl_dev_init(struct net_device *dev) return 0; } -static int ip6_tnl_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ip6_tnl_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u8 proto; @@ -1974,7 +1975,8 @@ static bool ip6_tnl_netlink_encap_parms(struct nlattr *data[], } static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net *net = dev_net(dev); struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id); @@ -2005,7 +2007,8 @@ static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, } static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *t = netdev_priv(dev); struct __ip6_tnl_parm p; diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c index 837ea1eefe7f..486c2305f53c 100644 --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -907,7 +907,8 @@ static int __net_init vti6_fb_tnl_dev_init(struct net_device *dev) return 0; } -static int vti6_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vti6_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return 0; } @@ -940,7 +941,8 @@ static void vti6_netlink_parms(struct nlattr *data[], } static int vti6_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net *net = dev_net(dev); struct ip6_tnl *nt; @@ -966,7 +968,8 @@ static void vti6_dellink(struct net_device *dev, struct list_head *head) } static int vti6_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *t; struct __ip6_tnl_parm p; diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c index 2378503577b0..e9958b1398cb 100644 --- a/net/ipv6/sit.c +++ b/net/ipv6/sit.c @@ -1406,7 +1406,8 @@ static void __net_init ipip6_fb_tunnel_init(struct net_device *dev) rcu_assign_pointer(sitn->tunnels_wc[0], tunnel); } -static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u8 proto; @@ -1537,7 +1538,8 @@ static bool ipip6_netlink_6rd_parms(struct nlattr *data[], #endif static int ipip6_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net *net = dev_net(dev); struct ip_tunnel *nt; @@ -1573,7 +1575,8 @@ static int ipip6_newlink(struct net *src_net, struct net_device *dev, } static int ipip6_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; -- 2.13.1

6 years, 10 months

3
2
0 0

[PATCH] net: fix potential null pointer dereference

by Gustavo A. R. Silva

Add null check to avoid a potential null pointer dereference. Addresses-Coverity-ID: 1408831 Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 4fea1b3..7b652bb 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -873,7 +873,7 @@ static struct gtp_dev *gtp_find_dev(struct net *src_net, struct nlattr *nla[]) /* Check if there's an existing gtpX device to configure */ dev = dev_get_by_index_rcu(net, nla_get_u32(nla[GTPA_LINK])); - if (dev->netdev_ops == &gtp_netdev_ops) + if (dev && dev->netdev_ops == &gtp_netdev_ops) gtp = netdev_priv(dev); put_net(net); -- 2.5.0

6 years, 11 months

3
2
0 0

Removing FCS from SNDCP packages

by Holger Freyther

Hi, I see that while adding decompression support dexter has fixed a bug in the sndcp code. Before the GTP-U frame would include the LLC FCS and now we do this: npdu_len = (msg->data + msg->len) - npdu - 3; What I wonder (and the commit message didn't say is) was the fragment part handled as well. The calculation is: /* make sure to subtract length of SNDCP header from 'len' */ rc = defrag_enqueue(sne, suh->seg_nr, data, len - (data - hdr)); and len is passed in from the TLV struct in gprs_llc_rcvmsg. I think the fragmented case is working okay. Shall we try to unify the length calculation to rely on the local "len" variable instead of checking msg->data+msg->len? cheers holger

6 years, 11 months

3
3
0 0

kernel-to-kernel gtp implementation

by fırat sönmez

Hi, I am currently working in a project where I was asked to implement a GTP tunnel from client to company servers. I have read through osmocom pages and tried to implement the simple network structure. I have seen from Basic testing of openGGSN page: " test GTP-U interoperability of the kernel with at least one other implementation, not just kernel-to-kernel (which currently is not supported in the kernel, as it only implements the GGSN/P-GW role) " I would not like to implement openGGSN but just linux-kernel-gtp-u implementation between two kernels. To achieve kernel-to-kernel implementation, I found sgsn patch on the internet: https://patchwork.ozlabs.org/patch/739408/ and there is already a kernel-gtp-U in osmocom. So, my basic network structure is below. [image: Satır içi resim 2] I would like make a tunnel between sgsn and ggsn. I have used libgtpnl tools to create link and then tunnel. I have added a default gateway GTP interface to route table on sgsn side, but the packets cannot reach ggsn side. Is there any detailed explanation for a simple bidirectional tunnel setup. If so, it would be so nice to know about. Thank you for all your efforts, Fırat

7 years

2
1
0 0

Video Recordings of OsmoCon 2017

by Harald Welte

Hi all, the Osmocom Conference 2017 last week was an overwhelming success. We received lots of positive feedback from all sides. Thanks to all the speakers, to the attendees as well as to the anonymous sponsor of the travel grant funds. It is my great pleasure that due to the great support by C3VOC (The CCC Video Operation Center), we have full recordings of all talks given at OsmoCon 2017. You can find the videos on the C3VOC site at https://media.ccc.de/search/?q=osmocon They are also linked individually from the OsmoCon 2017 homepage at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017 I hope the video recordings will be of help for everyone who could not make it to the event in person. We will also be collecting the slides and put them up on the wiki during the next few days. Please don't hesitate to raise any feedback and/or questions. Technical feedback/questions regarding Osmocom software / projects should be addressed to the appropriate mailing lists, such as openbsc(a)lists.osmocom.org. Feedback to the organizers should be sent to osmocon2017(a)sysmocom.de. Looking forward to the next OsmoCon, which we'll expect to be spanning ore than just a single day. 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

1
0
0 0

kernel GTP-U support dev roadmap

by Jiannan Ouyang

Hi Harald and Andreas, I’m writing to inquiry about the development roadmap of the kernel gtp module. For example, is there any plan to support the following features soon - lightweight tunnel - ipv6 The openair-cn project I’m working on is a user of the kernel gtp module. I’m happy to help improve the kernel gtp support, so it’s good to first ask about the roadmap. Regards, -Jiannan

7 years

3
4
0 0

GTP echo response

by Alandre de Carvalho

Hi everyone, We're using kernel GTP developed by Osmocom on openair-cn. Turns out that we are not able to connect an UE for longer than 20 seconds using an ZTE eNB apparently because the GTP-U is not answering to the echo requests. As far I know this response is supposed to be implemented but it is not answering. Do you guys have any tips on this issue? Thanks in advance, Alandre

7 years, 1 month

3
2
0 0

allow gtp tunnel updating in libgtpnl: gtp_add_tunnel()

by Jiannan Ouyang

Hi All, In current OAI implementation, we found that there are cases SPGW is out-of-sync with MME, because of the delete_session_request is not received by the SPGW because of some errors, however MME has cleared the state of that session. Then when the UE re-attaches, a new create_session_request is sent to SPGW; and because we try to allocate the same IP for the same IMSI (local change), the SPGW will result out in trying to update an existing GTP tunnel. According to http://lxr.free-electrons.com/source/drivers/net/gtp.c#L937 and https://github.com/RoadRunnr/osmo-ggsn/blob/master/libgtnl/src/gtp-genl.c#L…, the NLM_F_EXCL flag is used to prevent updating an existing tunnel. I’m is wondering what is the reason of preventing updating? While we are actively investigating sending delete_session_request properly, as temporary workaround, I’m thinking to recovery from the out-of-sync problem, we can allow the new GTP tunnel to overwrite the old one in libgtpnl. Your suggestions are welcomed. Thanks. Regards, -Jiannan

7 years, 1 month

3
4
0 0

Updates on Osmocom Conference 2017

by Harald Welte

OsmoCon 2017 updates There are some updates related to OsmoCon2017, the first Osmocom Conference, held on April 21st, 2017 in Berlin, Germany. See http://osmocom.org/news/68 for the web version of this announcement. == Summary == Summary (for those too busy to read the full post): * Schedule of talks has been released http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule * Travel Grants available for participants who are otherwise unable to travel to Berlin: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants * Social Event details available, including menu: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent * April 21st is approaching fast, make sure you get your Ticket in time. Limited number of seats available http://shop.sysmocom.de/products/ticket-for-osmocon-2017 == Details == === Schedule has been released === The list of talks with their abstracts has been on the website for quite some time, but now we actually have put together a schedule based on those talks. Please see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule for the schedule. As you can see, the day is fully packed with talks about Osmocom cellular infrastructure projects. We had to cut some talk slots short (30min instead of 45min), but I'm confident that it is good to cover a wider range of topics, while at the same time avoiding fragmenting the audience with multiple tracks. === Travel Grants === We are happy to announce that we have received donations to permit for providing travel grants! This means that any attendee who is otherwise not able to cover their travel to OsmoCon 2017 (e.g. because their interest in Osmocom is not related to their work, or because their employer doesn't pay the travel expenses) can now apply for such a travel grant. For more details see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants and/or constact osmocon2017(a)sysmocom.de. === Social Event === Tech Talks are nice and fine, but what many people enjoy even more at conferences is the informal networking combined with good food. For this, we have the social event at night, which is open to all attendees. See more details about it at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent -- - 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, 1 month

1
0
0 0

[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed

by Arnaud ZANETTI

Hi, building osmo-pcu on a raspberry Pi 3, I noticed a failure in make check: ## --------------------------------- ## ## osmo-pcu 0.2.896-0a8f test suite. ## ## --------------------------------- ## Regression tests 1: rlcmac ok 2: ts_alloc ok 3: tbf ok 4: bitcomp FAILED (testsuite.at:30) 5: edge ok 6: types ok 7: ms ok 8: llc ok 9: llist ok 10: codel ok 11: fn ok ## ------------- ## ## Test results. ## ## ------------- ## ERROR: All 11 tests were run, 1 failed unexpectedly. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ## The exact same test also fails on a raspberry Pi 2, with the same osmo-pcu and gcc versions but succeeds on an old Pentium4 Feel free to contact me if you need further informations. ----- Arnaud ZANETTI

7 years, 1 month

2
1
0 0

[PATCH 0/2] libgtpnl patches

by Jonas Bonn

Here are two small patches for libgtpnl. They both apply to the laforge/sgsn-role branch (although patch 2/2 could be taken separately into the main branch, too). Patch 1/2 is a small fixup for a netlink parameter rename in a kernel patch. Patch 2/2 is a trivial include file addition to prevent some warnings. Jonas Bonn (2): Rename netlink attribute Provide declaration for struct in_addr include/libgtpnl/gtp.h | 1 + include/linux/gtp.h | 2 +- src/gtp-genl.c | 8 ++++---- 3 files changed, 6 insertions(+), 5 deletions(-) -- 2.9.3

7 years, 1 month

2
3
0 0

git.osmocom.org cgit improvements

by Harald Welte

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. 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, 1 month

3
3
0 0

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

by Harald Welte

Hi Pablo, On Wed, Mar 15, 2017 at 06:23:48PM +0100, Pablo Neira Ayuso wrote: > On Wed, Mar 15, 2017 at 05:39:16PM +0100, Harald Welte wrote: > > > > I would definitely like to see this move forward, particularly in order > > to test the GGSN-side code. > > Agreed. I've modified the patch slightly, see below (compile-tested, but not otherwise tested yet). Basically rename the flags attribute to 'role', expand the commit log and removed unrelated cosmetic changes. I've also prepared a corresponding change to libgtpnl into the laforge/sgsn-rol branch, see http://git.osmocom.org/libgtpnl/commit/?h=laforge/sgsn-role This is not yet tested in any way, but I'm planning to add some associated support to the command line tools and then give it some testing (both against the kernel GTP in GGSN mode, as well as an independent userspace GTP implementation). > It would be good if we provide a way to configure GTP via iproute2 for > testing purposes. I don't really care about which tool is used, as long as it is easily available [and FOSS, of course]. > We would need to create some dummy socket from > kernel too though so we don't need any userspace daemon for this > testing mode. I don't really like that latter idea. It sounds too much like a hack to me. But then, I don't have enough phantasy right now ti imagine how an actual implementation would look like. To me, it is perfectly fine to run a simple, small utility in userspace even for testing. Regards, Harald >From 63920950f9498069993def78e178bde85c174e0c Mon Sep 17 00:00:00 2001 From: Jonas Bonn <jonas(a)southpole.se> Date: Wed, 15 Mar 2017 17:52:28 +0100 Subject: [PATCH] gtp: support SGSN-side tunnels The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP contexts based on the incoming packets _destination_ address. For real-world use cases, this is sufficient, as the other side of a GTP tunnel is not in fact implemented by GTP, but by the protocol stacking of a mobile station / user equipment on the radio interface (like PDCP, SNDCP). However, if we want to simulate the mobile station, radio access network and SGSN (for example to test the GGSN side implementation), then we want to be identifying PDP contexts based on _source_ address. This patch adds a "role" attribute at GTP-link creation time to specify whether we behave like the GGSN or SGSN role of the tunnel; this attribute is then used to determine which part of the IP packet to use in determining the PDP context. Signed-off-by: Jonas Bonn <jonas(a)southpole.se> Signed-off-by: Harald Welte <laforge(a)gnumonks.org> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 99d3df788ce8..9aef4217f6e1 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -71,6 +71,7 @@ struct gtp_dev { struct net_device *dev; + enum ifla_gtp_role role; unsigned int hash_size; struct hlist_head *tid_hash; struct hlist_head *addr_hash; @@ -149,8 +150,8 @@ static struct pdp_ctx *ipv4_pdp_find(struct gtp_dev *gtp, __be32 ms_addr) return NULL; } -static bool gtp_check_src_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, - unsigned int hdrlen) +static bool gtp_check_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, + unsigned int hdrlen, enum ifla_gtp_role role) { struct iphdr *iph; @@ -159,18 +160,21 @@ static bool gtp_check_src_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, iph = (struct iphdr *)(skb->data + hdrlen); - return iph->saddr == pctx->ms_addr_ip4.s_addr; + if (role == GTP_ROLE_SGSN) + return iph->daddr == pctx->ms_addr_ip4.s_addr; + else + return iph->saddr == pctx->ms_addr_ip4.s_addr; } /* Check if the inner IP source address in this packet is assigned to any * existing mobile subscriber. */ -static bool gtp_check_src_ms(struct sk_buff *skb, struct pdp_ctx *pctx, - unsigned int hdrlen) +static bool gtp_check_ms(struct sk_buff *skb, struct pdp_ctx *pctx, + unsigned int hdrlen, enum ifla_gtp_role role) { switch (ntohs(skb->protocol)) { case ETH_P_IP: - return gtp_check_src_ms_ipv4(skb, pctx, hdrlen); + return gtp_check_ms_ipv4(skb, pctx, hdrlen, role); } return false; } @@ -204,7 +208,7 @@ static int gtp0_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, goto out_rcu; } - if (!gtp_check_src_ms(skb, pctx, hdrlen)) { + if (!gtp_check_ms(skb, pctx, hdrlen, gtp->role)) { netdev_dbg(gtp->dev, "No PDP ctx for this MS\n"); ret = -1; goto out_rcu; @@ -261,7 +265,7 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, goto out_rcu; } - if (!gtp_check_src_ms(skb, pctx, hdrlen)) { + if (!gtp_check_ms(skb, pctx, hdrlen, gtp->role)) { netdev_dbg(gtp->dev, "No PDP ctx for this MS\n"); ret = -1; goto out_rcu; @@ -490,7 +494,11 @@ static int gtp_build_skb_ip4(struct sk_buff *skb, struct net_device *dev, * Prepend PDP header with TEI/TID from PDP ctx. */ iph = ip_hdr(skb); - pctx = ipv4_pdp_find(gtp, iph->daddr); + if (gtp->role == GTP_ROLE_SGSN) + pctx = ipv4_pdp_find(gtp, iph->saddr); + else + pctx = ipv4_pdp_find(gtp, iph->daddr); + if (!pctx) { netdev_dbg(dev, "no PDP ctx found for %pI4, skip\n", &iph->daddr); @@ -665,12 +673,26 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, int hashsize, err, fd0, fd1; struct gtp_dev *gtp; struct gtp_net *gn; + unsigned int role; + + /* The default role is GGSN, and for backwards compatibility + * reasons, the lack of a IFLA_GTP_ROLE IE means that we're + * operating in GGSN role. */ + if (data[IFLA_GTP_ROLE]) { + role = nla_get_u32(data[IFLA_GTP_ROLE]); + if (role != GTP_ROLE_GGSN && + role != GTP_ROLE_SGSN) + return -EINVAL; + } else + role = GTP_ROLE_GGSN; if (!data[IFLA_GTP_FD0] || !data[IFLA_GTP_FD1]) return -EINVAL; gtp = netdev_priv(dev); + gtp->role = role; + fd0 = nla_get_u32(data[IFLA_GTP_FD0]); fd1 = nla_get_u32(data[IFLA_GTP_FD1]); @@ -722,6 +744,7 @@ static const struct nla_policy gtp_policy[IFLA_GTP_MAX + 1] = { [IFLA_GTP_FD0] = { .type = NLA_U32 }, [IFLA_GTP_FD1] = { .type = NLA_U32 }, [IFLA_GTP_PDP_HASHSIZE] = { .type = NLA_U32 }, + [IFLA_GTP_ROLE] = { .type = NLA_U32 }, }; static int gtp_validate(struct nlattr *tb[], struct nlattr *data[]) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index 72a04a0e8cce..79037cca6b51 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -19,7 +19,7 @@ enum gtp_attrs { GTPA_LINK, GTPA_VERSION, GTPA_TID, /* for GTPv0 only */ - GTPA_SGSN_ADDRESS, + GTPA_SGSN_ADDRESS, /* Remote GSN, either SGSN or GGSN */ GTPA_MS_ADDRESS, GTPA_FLOW, GTPA_NET_NS_FD, diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h index 6b13e591abc9..de7bea223749 100644 --- a/include/uapi/linux/if_link.h +++ b/include/uapi/linux/if_link.h @@ -536,11 +536,18 @@ enum { #define IFLA_PPP_MAX (__IFLA_PPP_MAX - 1) /* GTP section */ + +enum ifla_gtp_role { + GTP_ROLE_GGSN = 0, + GTP_ROLE_SGSN, +}; + enum { IFLA_GTP_UNSPEC, IFLA_GTP_FD0, IFLA_GTP_FD1, IFLA_GTP_PDP_HASHSIZE, + IFLA_GTP_ROLE, __IFLA_GTP_MAX, }; #define IFLA_GTP_MAX (__IFLA_GTP_MAX - 1) -- 2.11.0 -- - Harald Welte <laforge(a)netfilter.org> http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie

7 years, 1 month

2
2
0 0

[PATCH net-next 0/4] gtp: support multiple APN's per GTP endpoint

by Andreas Schultz

Support multiple APN's per GTP endpoint and as an additional benefit support multiple GTP sockets per GTP entity. Use case multiple APN's: ------------------------ In 3GPP a APN is control path construct. When mappend into the data path, it mean that UE IP's can be source from independended IP networks with overlaping IP ranges. 3GPP, TS 29.061 version 13.6.0 Release 13, Section 11.3 describes this as: > 2. each private network manages its own addressing. In general this will > result in different private networks having overlapping address ranges. > A logically separate connection (e.g. an IP in IP tunnel or layer 2 > virtual circuit) is used between the GGSN/P-GW and each private network. > In this case the IP address alone is not necessarily unique. The pair > of values, Access Point Name (APN) and IPv4 address and/or IPv6 prefixes, > is unique. To support such a setup, each APN is mapped to a Linux network device. VRF-Lite, network namespaces or other mechanismns can the be used to realize the full separation of the per APN IP networks. Use case multiple GTP sockets per GTP entity: --------------------------------------------- A GTP entity like a PGW can use multiple GTP sockets for: * separate IPv4 and IPv6 transport endpoints * support multiple reference points in separated IP networks, e.g. have Gn/Gp/S5/S8 in a GRX attaches network and S2a/S2b in another private network Especially the S2a/S2b separation is an important scenario. The networks use for roaming and non roaming attachment (Gn/Gp/S5/S8 reference points) are usually different from the connection for trusted and untrusted WiFi access (S2a/S2b). Will the GTP transport networks are separated, it is still desirable to terminated the tunnels in the same GTP entity to ensure uninterrupted IP connectivity during 3G/LTE to/from WiFi handover. Implementation: --------------- APN's are a control path construct, the identification of the associated network device need therefore to be bound to be tunnel endpoint identifier. This series moves the hash for the incoming tunnel endpoint identifiers into the socket to support multiple network devices per GTP socket. It the adds a method of enabling the GTP encapsulation on a socket without having to bound the socket to a network device and finally allows to specify a GTP socket per PDP context. API impact: ----------- This is probably the most problematic part of this series... The removeal of the TEID form the netdevice also means that the gtp genl API for retriving tunnel information and removing tunnels needs to be adjusted. Before this change it was possible to change a GTP tunnel using the gtp netdevice id and the teid. The teid is no longer unique per gtp netdevice. After this change it has to be either the netdevice and MS IP or the GTP socket and teid. Fortunatly, libgtpnl has always populated the Link Id, TEID, GSN Peer IP and MS IP. The library interface has ensured that all information that is mandatory after this change is guaranteed to be present. The only project that doesn't use libgtpnl (OpenAir-CN) is also populating all of those values. The API change will therefore not break any existing userspace applications. -- Andreas Schultz (4): gtp: move TEID hash to per socket structure gtp: add genl cmd to enable GTP encapsulation on UDP socket gtp: add support to select a GTP socket during PDP context creation Extend Kernel GTP-U tunneling documentation Documentation/networking/gtp.txt | 103 ++++++++++++++- drivers/net/gtp.c | 263 ++++++++++++++++++++++++++++----------- include/uapi/linux/gtp.h | 4 + 3 files changed, 292 insertions(+), 78 deletions(-) -- 2.10.2

7 years, 1 month

4
14
0 0

[PATCH net-next v5 0/7] gtp: misc improvements

by Andreas Schultz

Hi Pablo, This is a resent of last series that missed the merge window. There are no changes compared to v4. v4: Compared to v3 it contains mostly smallish naming and spelling fixes. It also drops the documentation patch, Harald did a better job with the documentation and the some things I described do not yet match the implementation. I'll readd the relevant parts with a follow up series. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlapping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support, coming a follow up series). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. v4->v5: * resent for new merge window v3->v4: * drop the documentation patch * spelling fixes * pass nlattr instead of genl_info into gtp_find_dev, makes the code slightly more compact and readable v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (7): gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context drivers/net/gtp.c | 543 +++++++++++++++++++++++++++--------------------------- 1 file changed, 269 insertions(+), 274 deletions(-) -- 2.10.2

7 years, 1 month

4
12
0 0

SMS over GPRS

by Christian Wilkinson

Hi! According to the OsmoSGSN wiki, SMS delivery over GPRS is currently a TODO item. I was wondering about the current state of this feature, and if there is any work in progress that could be built upon. Is there an estimate of the amount of dev work required to contribute this feature to the project? Thanks, Christian

7 years, 1 month

2
2
0 0

Basic test setup for testing of Kernel GTP-U

by Harald Welte

Hi all, [intentionally breaking the thread here] On Thu, Feb 23, 2017 at 05:46:57PM +0100, Harald Welte wrote: > I'll try to cook up some instructions extending > https://osmocom.org/projects/openggsn/wiki/OpenGGSN to cover also > sgsnemu for a basic use case of establishing one single tunnel. That's > of course like a manual "HOWTO" and not yet anything that can be tested > automatically. I've documented the instructions at https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing Please let me know any updates/corrections/questions if you try to reproduce this. The above instructions were working for me yesterday. Please find an ASCII export of this below (much less readable than the wiki). Regards, Harald h1. Basic Testing This page documents some basic testing setup for the Kenrel GTP-U code. It follows the below rationale: * focus on testing the kernel GTP-U module without too much external dependencies * test GTP-U interoperability of the kernel with at least one other implementation, not just kernel-to-kernel (which currently is not supported in the kernel, as it only implements the GGSN/P-GW role) * limit testing to SGSN/S-GW and GGSN/P-GW, without a real cellular network (which is possible e.g. using [[OsmoSGSN:]] and [[OsmoPCU:]]) h2. Building / Installing dependencies In order to follow below test instructions, you will need * A Linux kernel including the GTP-U driver (@drivers/net/gtp.c@) either compiled-in or as kernel module * [[libgtpnl]] - the userspace library providing an API around the kernel GTP-U netlink interface * [[OpenGGSN:]] - a minimal C-language implementation of a 3GPP GGSN, also contains a SGSN-side emulator called [[OpenGGSN:sgsnemu]] ** make sure you use Version 0.93 or later ** make sure you compile it with @--enable-gtp-linux@ enable during the @./configure@ step You can find some instructions on how to build [[OpenGGSN:]] with support for [[libgtpnl]] and kernel GTP-U at this wiki page: [[OpenGGSN:Kernel_GTP]] h2. Test setup description We will run the GGSN natively on the host, and put the emulated SGSN inside a separate network namespace. The two namespaces are interconnected by a virtual ethernet device using the transfer network 172.31.1.0/24 The GGSN is configured to provide a pool of IP addresses from the 192.168.71.0/24 range. Each PDP context will be allocated one dynamic address from that pool h2. Test instructions h3. create the network namespace for the SGSN ip netns add sgsn h3. add veth to be used between SGSN and GGSN ip link add veth0 type veth peer name veth1 h3. remote (SGSN) side of veth device <pre> ip link set veth1 netns sgsn ip netns exec sgsn ip addr add 172.31.1.2/24 dev veth1 ip netns exec sgsn ip link set veth1 up </pre> h3. local (GGSN) side of veth device <pre> ip addr add 172.31.1.1/24 dev veth0 ip link set veth0 up </pre> h3. execute the GGSN on the host ggsn -g -c ./ggsn.conf.test (use the file attached to this wiki page) The @-g@ option is responsible for activating kernel-GTP support. If you cannot get the example described in this document to work, try the pure GTP-U userspace implementation by removing @-g@ from the above command line. If it works then, there's something related to Kernel GTP-U that breaks the setup. h3. execute the emulated SGSN inside the sgsn namespace ip netns exec sgsn sgsnemu -d -r 172.31.1.1 -l 172.31.1.2 --defaultroute --createif h3. verify the existnace of the GTP tunnel <pre> ggsn:~# gtp-tunnel list version 1 tei 1/1 ms_addr 192.168.71.2 sgsn_addr 172.31.1.2 </pre> h3. further testing in the @sgsn@ namespace, there's now a default-route that points into the GTP tunnel. You can use this to ping any network address that's reachable to the GGSN host. If that host is connected to the internet, you can e.g. run a ping command from within the namespace using ip netns exec sgsn ping -c 10 8.8.8.8 which will send some IP packets to 8.8.8.8 via the tun0 device (created by [[OpenGGSN:sgsnemu]]). It will be encapsulated by the userspace GTP-U implementation of sgsnemu, sent via the veth device to the host, where it ends up inthe GTP-U kernel module, decapsulating the package and passing in on to the gtp0 device there. Anything beyond that point depends on your local routing configuration. == Building OpenGGSN == h1. OpenGGSN and Linux Kernel accelerated GTP-U OpenGGSN has support to use the Linux kernel GTP-U code to accelerate the data/user plane while still implementing the control plane (GTP-C) in userspace in OpenGGSN. For more information about the Linux kernel GTP-U code, please see [[linux-kernel-gtp-u:]] h2. Building OpenGGSN with kernel which has GTP-U support At the time of writing (2017-01-09) of this wiki, below listed distributions have support of GTP kernels : * Debian 4.9.1-1~exp1 - Debian's latest experimental build * Ubuntu 16.10 kernel 4.8 * OpenSUSE Tumbleweed (stable) 4.8 (.12) * Fedora 25 kernel 4.8 Following two Debian kernels do not activate GTP kernel module during build: 4.8.0 and 4.9.0. *It is expected that complete openbsc project and related dependencies are pre-installed.* Check if package @libc-ares-dev@ is installed and if not please add it. Ubuntu 16.10, kernel 4.8.0-30-generic is used. * Installing dependencies and build library @libgtpnl@ You can install those packages with: <pre> sudo apt install libtalloc-dev libpcsclite libmnl-dev </pre> Please follow instructions provided at [[cellular-infrastructure:Build from source]] in order to install following library and projects : Information about dependencies between Osmocom projects is given at the above link: * libgtpnl <pre> sudo make install sudo ldconfig </pre> * libosmocore * openggsn <pre> ./configure --enable-gtp-linux make sudo make install sudo ldconfig </pre> Following message is shown at end of the command: @ ./configure --enable-gtp-linux@ <pre> openggsn Configuration: GTP Linux kernel support: yes </pre> This means that appropriate header files are available. -- - 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

[PATCH net-next v4 0/7] gtp: misc improvements

by Andreas Schultz

Hi Pablo, This is v4 of the GTP improvements. Compared to v3 it contains mostly smallish naming and spelling fixes. It also drops the documentation patch, Harald did a better job with the documentation and the some things I described do not yet match the implementation. I'll readd the relevant parts with a follow up series. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlaping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support, comming a follow up series). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. v3->v4: * drop the documentation patch * spelling fixes * pass nlattr instead of genl_info into gtp_find_dev, makes the code slightly more compact and readable v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (7): gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context drivers/net/gtp.c | 543 +++++++++++++++++++++++++++--------------------------- 1 file changed, 269 insertions(+), 274 deletions(-) -- 2.10.2

7 years, 2 months

4
16
0 0

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

by Andreas Schultz

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

7 years, 2 months

4
17
0 0

Roaming allowed for using local sims

by Saba Arshad

Hello, I want to use the local sims having different MNC/MCC for implementing GPRS using osmocoms with OpenBTS same as I have used them for GSM calls and sms using only openBTS. But your site http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently not possible". As it is long when posted on this site so I want to ask is it possible *now* to use the local sims? Hope you have understood my question. Waiting for your reply. Thanks. Regards, Saba Arshad

7 years, 2 months

2
1
0 0

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

by Anoop Singh Tomar

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

7 years, 2 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs