Age | Commit message (Collapse) | Author | Files | Lines |
|
Related: SYS#5599
Change-Id: Id822c9c7a71461d17f062c2a3d10cb2f616c7f63
|
|
Fix debian packaging, so far a copy-paste from osmo-upf.git crept in
here by accident.
Related: SYS#5895
Change-Id: Id7169fc67b4f8f77dfbeff9f199e6557ced67a53
|
|
Related: SYS#5599
Change-Id: Ia2818106fe257a237d1875034b77c1d4cb136fa1
|
|
AFAICT, everything compiles just fine with -flto=auto.
Change-Id: I632cfd8deaaaa50f0ffba04aca4d422b7b51034e
|
|
There is no need to do so, this project has nothing to do with systemd.
Change-Id: I57d6c46a6b9aab161f7ccfa663c26ea2e7f05e7b
|
|
Change-Id: I72b2b62cfa232accb4f8ae114be40058ccd512c7
|
|
Change-Id: I71fc8dc78b8b10628ef0533c69e42c0298fb27df
|
|
Create m4/.gitkeep to eliminate the following warning:
aclocal: warning: couldn't open directory 'm4': No such file or directory
Add 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac to as suggested:
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac
Change-Id: Id9d605490c4b403b99ed54745838cc9f242030c3
|
|
After the final retransmission of a sent request, still keep the message
in the queue for its expiry period, so that a later response is matched
to the request.
The osmo_pfcp_msg.resp_cb() depends on the sent message to remain in the
queue until it times out. That was not the case in an earlier stage of
libosmo-pfcp development.
I noticed this during ttcn3 testing, where osmo-hnbgw continuously
resends PFCP Association Setup Requests, and fails to associate if ttcn3
happens to respond to the final retransmission of a request.
Related: SYS#5599
Change-Id: Iaca396891921f7057015ce6e1e4528b955757809
|
|
Code review requested that the API should use functions instead of
direct access to a struct.
I have moved all user provided config to a separate struct
osmo_pfcp_endpoint_cfg, to be passed to osmo_pfcp_endpoint_create().
Halfway through those changes, I am not so certain whether that is what
reviewers had in mind. It makes sense from the point of view to keep nr
of arguments passed to osmo_pfcp_endpoint_create() small, and to allow
changing the user provided config without requiring a new
osmo_pfcp_endpoint_create2() API function. Though that again has ABI
compat problems, and makes no sense from the point of view that all
access should be done via API functions.
Personally I don't really agree with this change, which is probably the
reason why this patch ended up this way.
Related: SYS#5599
Change-Id: If80c35c6a942bf9593781b5a6bc28ba37323ce5e
|
|
Looking at the osmo_pfcp_msg_alloc API with a bit of distance now, I
found that:
- it is confusing to have a single function for req and resp. A resp
may pass remote_addr as NULL, and a req may pass in_reply_to as NULL.
Make this much more obvious with separate req/resp functions.
- the osmo_pfcp_endpoint_tx() implicitly puts the local Node ID into
sent PFCP messages, so the local_node_id arg for msg alloc is
redundant. Drop that.
Refactor without backwards compat, because we have not yet officially
released this API. This requires a fixup patch to osmo-upf.git (and
affects unmerged patches to osmo-hnbgw.git).
Related: SYS#5599
Related: I73e6da3b80f05e9408c81f41ac05d6578b8e31cf (osmo-upf)
Change-Id: I0d71134e42932cc72992eba73a15e82bc7cd11bd
|
|
s/MSGT/TIMER
Related: SYS#5599
Change-Id: Iaecce86064b65aa003e9903d09f60d760e0689c3
|
|
Having separate callbacks for request and response messages makes for
an easier read. No functional change.
This applies code review from
https://gerrit.osmocom.org/c/osmo-upf/+/28244
Ic8d42e201b63064a71b40ca45a5a40e29941e8ac (osmo-upf.git)
Related: SYS#5599
Change-Id: Ic8ab71f5efd4cf669689a0b075f9a52ce66bdd5d
|
|
osmo_timer_schedule() takes (*timer, seconds, microseconds), so
the last argument must be in microseconds, not milliseconds.
Change-Id: I1e0b319033415e42ca7f4da9bae348c5cb1da38c
|
|
Will be used by osmo-hnbgw, our first PFCP Control Plane entity. The
implementation is generic enough that it can be re-used by other CP
entities.
Related: SYS#5895
Change-Id: If8c5f69f596ea6ba8bd1723f4dc57b91d3799795
|
|
Related: SYS#5599
Change-Id: Iacaeebfad0fe77788da40c3ed7da2ffa3b27043c
|
|
The first user of this is osmo-hnbgw, to implement GTP mapping via a
UPF.
Related: SYS#5895
Change-Id: If4465095000a898296d69d5b725507f909c87aa3
|
|
Related: SYS#5895
Change-Id: I9f4651b6bee457583aba99052dc82bbf675515e6
|
|
Related: SYS#5599
Change-Id: Ic8d42e201b63064a71b40ca45a5a40e29941e8ac
|
|
Related: SYS#5599
Change-Id: I55474daa6bb204a0fe7da0a3bf888bb7d1c46677
|
|
Related: SYS#5599
Change-Id: I30bdfc66a8f96c0639513ef406e9b66525dced6d
|
|
Related: SYS#5599
Change-Id: I3f85ea052a6b7c064244a8093777e53a47c8c61e
|
|
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
|
|
Even though it is a generated header, it must still be listed in
pfcp_HEADERS.
Related: SYS#5599
Change-Id: I6fbfe1fcd084f2d16334bb3e44d9891d9485d59f
|
|
Related: SYS#5599
Change-Id: I3069045b2d42dac88d955c636230adc64a7a4aa7
|
|
Related: SYS#5599
Change-Id: I568b821e89007ed52eeefcdbcb6edd8052a8b5be
|
|
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
|
|
Related: SYS#5599
Depends: I0a46b147ec6a76d909df28136cfd2b764b2c75ea (libosmocore)
Change-Id: I4352dd8738a1a9de6ba2fc250ee8eef69c65ff1e
|
|
|