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
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
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
Implement handling of the Network Instance IEs from PFCP for tunend,
like already done for tunmap.
In 'tunend' cfg, allow indicating a local GTP address for both 'dev
create' and 'dev use'. Select a GTP device by the local address the
Network Instance IE in PFCP PDR indicates.
Related: SYS#6192
Change-Id: I376c09bfc1844df1e61d2efac17561fac614858b
This 'accept' is not an optional addition, it should always be present.
(Just saying because previous patch added a VTY command to configure
additions to the rules, and this patch is orthogonal to that.)
Related: OS#5810
Change-Id: I129133cc5d7180ce3761d5604d602d23a5ef9825
It can be useful to add 'meta nftrace set 1' to nftables rules to help
analysis / site debugging. Add the possibility to do this by cfg.
Instead of adding the fixed string of 'meta nftrace set 1', allow
appending arbitrary strings to the nftables rules, to accomodate any
other future tweaks that may be useful.
Related: SYS#6192
Change-Id: Ia1fac67108902a48b43d8d1dc184ccf541fd9ba8
Add VTY command to print out an nftables ruleset that osmo-upf produces,
with arbitrary IP addrs / TEIDs inserted. This allows tracking in *.vty
tests how the nftables rulesets are changed by patches.
future:
- Adding the 'tunmap' keyword to allow adding show commands for
different uses of nftables.
- Adding the 'example' keyword to allow adding show commands for
actual tunmap IDs / PFCP session IDs / ...
- Matches upcoming vty commands
'nft-rule tunmap append .NFT_RULE'
'no nft-rule tunmap append'
'show nft-rule tunmap append'
Add new separate nft-rule.vty -- more to come here in upcoming patch.
Change-Id: I9b57aa492c051e480c9bd819ae58f8f59a13af40
Add 'netinst' config section to osmo-upf.cfg, to define Network Instance
name to local IP address mappings.
For the tunmap use case (forwarding GTP tunnels), heed the Network
Instance IEs in PFCP session creation and return IP addresses in F-TEIDs
accordingly.
Related: SYS#6192
Related: I37bebc7d6ef75c3e6ae05e81b83a1b5895839a64 (osmo-ttcn3-hacks)
Change-Id: I15ee046a1c37b83b8a83527a67a6215a30106d81
So far the config nodes were named after the implementation:
"GTP kernel module" = "gtp" and
"netfilter" = "nft"
We found that this is confusing, since both are related to handling GTP.
Rename "nft" to "tunmap"; a previous patch already renamed "gtp" to
"tunend".
Keep a hidden "nft" VTY cmd as backwards compat alias.
Related: SYS#6192
Change-Id: Ia3c5224dd3b5f5c9437bbdec997d02176818cc97
So far the config nodes were named after the implementation:
"GTP kernel module" = "gtp" and
"netfilter" = "nft"
We found that this is confusing, since both are related to handling GTP.
Rename "gtp" to "tunend"; a subsequent patch will rename "nft" to
"tunmap".
Keep a hidden "gtp" VTY cmd as backwards compat alias.
In log output, also print "tunend" instead of "endecaps"
(up_gtp_action_to_str_buf()).
Related: SYS#6192
Change-Id: I49ac7b1f8b5b74f586edfed1dfb29f9af55a521b
Clarify "Add" and "Delete" of GTP devices.
Clarify GTP device in config vs. real GTP device.
Clarify s/kernel/Linux kernel
Related: SYS#5599
Change-Id: I918e0a9a332e4dd4b71965614c19481eb41004d6
To avoid actions that require cap_net_admin permissions on build
servers, add this option to "dry run" all kernel GTP actions. Same will
be added for netfilter rules.
On startup, osmo-upf opens sockets to GTP kernel module / NFT ctx.
However, on build servers, this would require giving cap_net_admin
permissions just to run the VTY tests.
Related: SYS#5599
Change-Id: I3b9c796186307fd8562abcff3f0ccfab0e88b6c8
During code review, it was indicated that some TLV protocols that we
will likely deal with in the near future also employ an I, and instance
value of a tag. Add TLIV support.
A usage example for a manually implemented TLIV structure is found in
tests/libosmo-gtlv/gtlv_test.c.
A usage example for a generated TLIV protocol is found in
tests/libosmo-gtlv/test_tliv/.
Related: SYS#5599
Change-Id: I0a076e54dfba6038cc779cb7c8f3967d212226aa
Defining a protocol of message types with lists of IEs bears a lot of
repetitive, copy-paste-error-prone writing out of data structures.
Add a third layer to libosmo-gtlv, which allows helpful code generation.
By non-repetitive data structures that briefly describe the protocol's
messages and IEs, generate possibly repetitive IE list arrays and
decoded-struct definitions automatically, avoiding grunt work errors.
I tried C macros for this at first, but it became too convoluted.
Generating C code that can be read and grepped makes things easier.
A usage example is found in tests/libosmo-gtlv/test_gtlv_gen/.
Related: SYS#5599
Change-Id: Ifb3ea54d2797ce060b95834aa117725ec2d6c4cf
Add osmo_gtlv_coding: describe the value part of a TLV (decode and
encode), describe a struct with its members, and get/put readily decoded
structs from/to a raw PDU, directly.
With osmo_gtlv_coding defined for a protocol's tags, we only deal with
encoded PDUs or fully decoded C structs, no TLV related
re-implementations clutter up the message handling code.
A usage example is given in gtlv_dec_enc_test. The first real use will be
the PFCP protocol in osmo-upf.git.
With osmo_gtlv_coding, there still is a lot of monkey work involved in
describing the decoded structs. A subsequent patch adds a generator for
osmo_gtlv_coding and message structs from tag value lists.
Related: SYS#5599
Change-Id: I65de793105882a452124ee58adb0e58469e6e796
An all new TLV parser supporting:
- Any size of T and L (determined by callback function),
- "Grouped IEs", so that an IE payload is a nested IE structure,
- optional/mandatory/multi-occurence IEs,
- decoding unordered tags (or enforcing strict order).
Will be used for PFCP message decoding and encoding, a T16L16V protocol
which requires above features.
Upcoming patches add
- translating PDUs to plain C structs and vice versa
- TLV generator to reduce repetition a in protocol definition
- TLIV capability
Previously, the way we deal with TLVs causes a lot of code
re-implementation: the TL decoding is taken care of by the API, but for
encoding, we essentially re-implement each protocol and each encoded
message in the individual programs. This API is an improvement in that
we only once implement the TL coding (or just use osmo_t8l8v_cfg /
osmo_t16l16v_cfg), get symmetric de- and encoding of the TL, and only
need to deal with the value part of each IE.
The common pattern of
- store TL preliminarily,
- write V data and
- update L after V is complete
is conveniently done by osmo_gtlv_put_update_tl().
Related: SYS#5599
Change-Id: Ib0fd00d9f288ffe13b7e67701f3e47073587404a
Neels Hofmeyr