Support receiving of Echo Responses, so far showed an error log for
unsupported message type. Just log the message.
Prep for upcoming patch to allow sending Echo Requests from VTY.
Change-Id: Idad417746a1ea797e8fbfe04ca9c84923a6118fa
Like e.g. in osmo-msc.git, osmo-bsc.git, use wildcard $(srcdir)/*.vty to
make sure we never forget to distribute committed VTY test scripts.
Change-Id: If4dca81ce287ce1b1af32057634af912a8b89665
Do not attempt to change permissions/ownership if the package gets
upgraded from a version higher than the next release.
Do not fail if the user deleted the config file.
Be verbose when changing permissions.
Related: OS#4107
Change-Id: I8994759df644d6edd8f937051b95690537b749be
We see GTP-U originating from ports other than 2152 in the field. When
osmo-upf forwards these, we want to forward from our GTP-U port 2152,
since that is the only port osmo-upf has bound for GTP-U (for echo).
According to 3GPP TS 29.060, the *destination* port for GTP-U shall be
2152 -- but the source port is apparently allowed to be different.
Before this patch, we would forward GTP-U like this:
3.3.3.3:33333 -> (3.3.3.4:2152 UPF 2.2.2.2:33333) -> 1.1.1.1:2152
^^^^^
Instead we want to always send from UDP source port 2152:
3.3.3.3:33333 -> (3.3.3.4:2152 UPF 2.2.2.2:2152) -> 1.1.1.1:2152
^^^^
This hasn't shown up before because so far all GTP-U peers we saw
consistently used source port 2152.
Related: SYS#6773
Change-Id: Idaf43f1c2b915846b50a8b97305f0229e34ad539
Set CAP_NET_ADMIN so osmo-upf can set up GTP tunends and tunmaps even if
running as user.
Fix for:
Operation not permitted (you must be root)
netlink: Error: cache initialization failed: Operation not permitted
20240430095022378 DNFT ERROR error running nft ruleset: rc=-1 ruleset="add table inet osmo-upf { flags owner; };\n" (upf_nft.c:79)
20240430095022378 DNFT ERROR Failed to create nft table "osmo-upf" (upf_nft.c:111)
Fixes: OS#6444
Change-Id: I17b21ad92837ad360d667248f3f002d44251891c
* Explicitly chown /var/lib/osmocom to osmocom:osmocom, instead of
relying on systemd to do it when the service starts up. This does not
work with the systemd versions in debian 10 and almalinux 8.
* deb: Use "useradd" instead of the interactive "adduser" perl script
from Debian. This makes it consistent with how we do it in rpm, and
avoids the dependency on "adduser".
* deb: Consistently use tabs through the file, instead of mixing tabs
and spaces.
* deb: Remove support for the "dpkg-statoverride --list" logic. This
seems to be a rather obscure feature to override permissions for
certain files or directories, for which it does not seem to be a good
idea to make the postinst script less maintainable. Something similar
can be achieved by using your own Osmocom config file in a different
path with different permissions.
Related: OS#4107
Change-Id: Ib129217f6aff713d1d0e7aa831b4b54823e9bade
Create osmocom user & group during package installation.
Fix the configuration dir/files permission to match.
Related: OS#4107
Tweaked-By: Oliver Smith <osmith@sysmocom.de>
Change-Id: I6caa561eff63d6ee58b5c7b0f8c69bfd2d134eb3
I'd like to add more sub-levels in an upcoming commit, and the levels
are becoming too many. So let's get rid of one depth level in the
'Running osmo-upf' chapter.
Change-Id: I0bd43300aa4b45315ea58ab35c77da005d1a4fa4
From time to time we see sporadic master build failures on Jenkins
because git fails to clone one of the repositories:
```
Cloning into 'nftables'...
error: garbage at end of loose object '0ca03ecd6ab3cfdc94f8f9ef6e3a7c40d1aa7195'
fatal: loose object 0ca03ecd6ab3cfdc94f8f9ef6e3a7c40d1aa7195
(stored in /build/libnftnl/nftables/.git/objects/0c/a03ecd6ab3cfdc94f8f9ef6e3a7c40d1aa7195) is corrupt
Cloning into 'libnftnl'...
fatal: unable to access 'https://git.netfilter.org/libnftnl/':
Failed to connect to git.netfilter.org port 443: Connection timed out
```
Running git with GIT_CURL_VERBOSE=true reveals that the server is using
an old "dumb" git protocol, so the client is sending hundreds of HTTP
requests to the server. I also noticed that cloning via http[s]://
takes significantly more time than cloning via git://, because of the
old protocol being used.
```
$ time git clone https://git.netfilter.org/nftables
...
real 1m16.848s
user 0m4.867s
sys 0m1.883s
$ time git clone git://git.netfilter.org/nftables
...
real 0m2.453s
user 0m1.180s
sys 0m0.158s
```
According to [1], there is a more modern "smart" protocol, which is
relatively more stable and fast. However it's not supported by the
remote server, so let's use git:// as a workaround.
[1] https://www.git-scm.com/docs/http-protocol
Change-Id: I8e943c74052cc74eae8dc1d80ab243f792a90156
Coverity complains about a supposedly missing NULL check for the pointer 'pdr', that check
however happens before the function in question is called.
It makes sense to be consistent inside the function, so remove the NULL check before calling
'pdr_del', because we don't NULL check anywhere else in the function either.
Fixes: Coverity scan CID#307494
Change-Id: Ia33e4211b4a24abc87c3c2ceffe807ca3322f29d
When handing out a chain_id, make sure it is not in use yet.
So far picking a chain_id was of PoC grade quality. As osmo-upf is
approaching production grade, make this waterproof.
So far with inefficient iteration of all sessions; faster lookup follows
in I36a75ec4698cd83558185c1f202400eb53ae8ff6.
Related: OS#5900
Change-Id: I139b46de0bd15185a7a06109d55f7c759755ec81
Verify that skipping used IDs works for:
- PFCP UP-SEID
- GTP local TEID
- chain_id for nft rulesets -- so far expected to fail,
fix follows in I139b46de0bd15185a7a06109d55f7c759755ec81.
Related: OS#5900
Change-Id: I36acff15f22d23ade4d281c2af3eb117dfc10359
Like we do in osmo-bsc.git, gather the osmo-upf objects into a
not-installed libupf.la, so that we can trivially and flexibly link
these to regression test programs.
Will be used by upcoming patch I36acff15f22d23ade4d281c2af3eb117dfc10359
(unique_ids_test).
Change-Id: Id179a47b5d40821d86c7214add14449600198e07
We don't use the python bindings of nftables with osmo-upf, so don't
build them. Without this, it tries to build them with python2 for some
reason and since a recent nftables commit it fails with:
running install
Checking .pth file support in /build/deps/install/stow/nftables/lib/python2.7/site-packages/
/usr/bin/python -E -c pass
TEST FAILED: /build/deps/install/stow/nftables/lib/python2.7/site-packages/ does NOT support .pth files
error: bad install directory or PYTHONPATH
Change-Id: Ie172dca3e6953c353239173bca07b1f62fbf4c34
After libosmo-gtlv was dropped from configure.ac in
22006ba039, these $(LIBOSMO_GTLV_*) are
empty anyway.
Since we depend on libosmo-pfcp, there is no need to list libosmo-gtlv,
which should be implicitly included.
Change-Id: I3acd3d674e226b004101d65d47beacbbdeed0466
up_endpoint is about the PFCP endpoint, handing out local TEID is about
local GTP endpoints. Move the TEID allocation to g_upf / upf.c.
An upcoming patch will use a hash table in g_upf to speed up lookup
whether a local TEID is already in use; cosmetically prepare for that.
Change-Id: I8eae5b53c563400ddfded264678d9cfb28b6f737
Upcoming patch I8eae5b53c563400ddfded264678d9cfb28b6f737 will introduce
a g_upf->gtp sub struct for more generally GTP related things (local
TEID assignment).
Change-Id: I74df838af50f38604e2ff06cac0af11ccfdab386
Use a common struct upf_tun_ep and struct upf_tun for both tunend and
tunmap definitions, with a nicer local / remote sub-structuring.
Change-Id: I07866e2acbeb74914e1fd6f66839a5a8ae247b1e
The "desc" has no meaning, every struct is a description of its data.
The "nft" and "gtp" hint at the specific "nftables" and "GTP kernel
module" implementations. I'd rather keep it more abstract and shorter.
That serves removing dup of shared bits in an upcoming patch.
Change-Id: I15e4552a20067265abb8d2dd716861cd50270028
Some things in osmo-upf and libosmo-pfcp have changed without accounting
for that in osmo-pfcp-tool. (This tool is not that important, forgive me
for submitting various changes in one patch.)
Properly represent all of {access,core} x {local,remote} GTP F-TEIDs in
the internal osmo-pfcp-tool state.
Adjust and clarify osmo-pfcp-tool script commands.
Adjust the osmo-pfcp-tool scripts in contrib so that they work again.
Change-Id: I22cfaa4aedd465c81de85e673b9960eaf99c426b
Make the nft table owned by the osmo-upf process, so that any kind of
graceful or ungraceful exit will drop all tunmap rules implicitly.
Related: SYS#6327 SYS#6264
Change-Id: Ia26bb295849905ccfeaec801d7b187bf85f21366
Take care of two problems:
- limitation of <= 1024 base chains in nftables, so far meaning we can
establish at most 1024 GTP tunnel mappings.
- mangling of source IP in prerouting so far meaning that the system
needs to be configured to permit 'martian' packets
The new ruleset separates in pre- and post-routing, so that we set a new
destination IP address in pre-routing, and set a new source IP address
in post-routing. Hence no problem with martian packet rejection.
The new ruleset uses verdict maps, which are more efficient, and do not
hit a limit of 1024 as base chains do.
Before, the nft rule used one chain id. In the new ruleset, each tunmap
now needs two distinct chain ids. Refactor.
Related: SYS#6327 SYS#6264
Change-Id: Iccb975a1c0f8a2087f7b7dc4942a6b41f5675a13
Instead of logging a full nft chain/rule name like 'tunmap123', log only
the id '123'.
Rationale: with the new nft rulesets, there will be four distinct
identifiers:
tunmap-pre-123a
tunmap-pre-123b
tunmap-post-123a
tunmap-post-123b
so let's simplify.
Related: SYS#6327 SYS#6264
Change-Id: Ic46ae5bd824a211668d4ac9a77b3597eaca17146
Subsequent patch will refactor the tunmap nft ruleset. Instead of
adapting the 'tunmap append' feature to the new ruleset, rather drop
this feature entirely.
The 'nft rule tunmap append' was intended for enabling 'trace' in the
nft ruleset. However, the same can be achieved via the nft cmdline tool.
For example:
sudo nft 'add chain filter trace_chain { type filter hook prerouting priority -301; }'
sudo nft 'add rule filter trace_chain meta nftrace set 1'
Related: SYS#6327 SYS#6264
Change-Id: I1ae36f2f520217254c81fd765d27333ff0f457b2
upf_gtp.h is for the GTP kernel module interaction. The GTP port numbers
are also relevant for the netfilter part, upf_nft.h. An upcoming patch
will use PORT_GTP1_U in the nft ruleset.
Related: SYS#6327 SYS#6264
Change-Id: I37d13cfee225c7ee2cc45525b76d9579d65e847c
