Fix for building on opensuse 15.4 with GCC 7.5.0+r278197:
osmo_pfcp_tool_main.c:219:15: error: initializer element is not constant
.copyright = osmo_pfcp_tool_copyright,
The variable is only used once, so move its contents directly into the
struct vty_app_info, like it is done in osmo_upf_main.c.
Fixes: OS#5655
Change-Id: Iff273283a082bb6d07c4c98d421b17b54457abe1
This should hopefully fix the many daily build error mails about
failed package builds on a dozen of distributions/architectures:
[ 148s] No package 'libosmo-gtlv' found
[ 148s] configure:12570: error: Package requirements (libosmo-gtlv >= 0.1.0) were not met:
Change-Id: Iac551616a9831dfd9e3203d1f40e312c4dd286b6
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
Upon ^C, do not barf a huge amount of full talloc report for the entire
VTY config tree. Show a brief report on VTY instead.
Related: SYS#5599
Change-Id: I038951c6d62679e3cfcda51512768d1fbacaa0d1
There is no cmdline option --mockup-nft, that was an earlier stage of
the nftables mockup patch.
Related: SYS#5599
Change-Id: I2f77cfe727649bbdcebb4a656ebf97b186134ee8
Accept data on the GTPv1-U socket and respond to GTPv1-U ECHO REQUEST
messages.
We should keep a deterministic recovery counter that increases with
every restart. As a quick and dirty way just use the current time at
startup for now, until osmo-upf reaches production maturity.
Related: OS#5599
Change-Id: I135370a7723e2c667ec681f50c21107cde63ea5b
A tool for quick testing of PFCP interaction with a UPF, based on VTY
scripts / interaction.
The main motivation to create this tool was to test both the CPF and UPF
sides of the new PFCP protocol encoding and decoding, and then to test
interaction of osmo-upf with the kernel modules. It may also come in
handy as a fast way to verify basic operation in a production
environment.
Related: SYS#5599
Change-Id: I34a80d43a14c7b68952c7d337d8042d6f28ceae7
Implement support for PFCP rulesets that ask for mapping a GTP tunnel:
forwarding GTP payload between two GTP tunnels.
For a GTP tunnel mapping, dispatch netfilter rules that detect GTP
packets with a given source address and TEID, and replace the TEID and
destination address according to the PFCP ruleset.
The netfilter implementation is chosen to effect the packet rewriting
and forwarding to take place directly in the kernel, for high throughput
of GTP packets.
Related: SYS#5599
Change-Id: Ic0d319eb4f98cd51a5999c804c4203ab0bdda650
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
So far we had only osmo_pfcp_enc_to_str_node_id(), used for PFCP message
to string conversion. It behaves like a common _to_str_buf() function,
but has an inconvenient void* arg (for use with libosmo-tlv).
Implement the string conversion as common _to_str_buf() and _to_str_c()
functions, and call that from osmo_pfcp_enc_to_str_node_id(). That's
useful for log messages coming up in a subsequent patch.
Related: SYS#5599
Change-Id: I5c580bc510afce58a03dea0861db9630b063b2ae
The spec indicates three bytes of CP Function Features, but both
wireshark and ttcn3 expect only one byte. This makes sense because only
eight CP F.F. flags are defined.
Drop those two always-zero bytes, hence pass the wireshark dissector and
ttcn3 parsing without warnings.
Related: SYS#5599
Change-Id: Icda891a2f3401e58f142f229465403d5dc8befe5
These help to build enums and value_strings using regexes. They are a
verbatim copy from 3GPP TS 29.244 version 16.6.0 Release 16, paired with
C-compatible and possibly abbreviated name strings.
Related: SYS#5599
Change-Id: I7f37efd3cfc4c7b0ae49740ac15e461c52fae6e8
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
I wrote a simple tool that puts the same license headers in all .[hc]
files. These tweaks are the result of running that tool on already
merged files.
Related: SYS#5599
Change-Id: I1f542534903fce9d68fce11f16822e9fbead89ec
Oliver Smith
Neels Hofmeyr
Harald Welte
Vadim Yanitskiy