aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2022-07-28pfcp_endpoint: fix final PFCP retrans resp_cbNeels Hofmeyr1-7/+8
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
2022-07-28apply code review: refactor pfcp_endpoint APINeels Hofmeyr2-13/+74
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
2022-07-23clarify osmo_pfcp_msg alloc APINeels Hofmeyr3-21/+39
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
2022-07-23fix wrong constants used in osmo_pfcp_tdefs (typo)Neels Hofmeyr1-2/+2
s/MSGT/TIMER Related: SYS#5599 Change-Id: Iaecce86064b65aa003e9903d09f60d760e0689c3
2022-07-20separate pfcp_queue_timer_cb() in req and respNeels Hofmeyr1-17/+30
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
2022-07-19fix incorrect timeout values: milliseconds vs microsecondsVadim Yanitskiy1-2/+2
osmo_timer_schedule() takes (*timer, seconds, microseconds), so the last argument must be in microseconds, not milliseconds. Change-Id: I1e0b319033415e42ca7f4da9bae348c5cb1da38c
2022-06-17add generic PFCP CP peer implementation0.1.0Neels Hofmeyr2-0/+405
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
2022-06-17add osmo_pfcp_ie_f_seid_cmpNeels Hofmeyr1-0/+25
Related: SYS#5599 Change-Id: Iacaeebfad0fe77788da40c3ed7da2ffa3b27043c
2022-06-17install libosmo-pfcpNeels Hofmeyr1-3/+10
The first user of this is osmo-hnbgw, to implement GTP mapping via a UPF. Related: SYS#5895 Change-Id: If4465095000a898296d69d5b725507f909c87aa3
2022-06-17install libosmo-gtlvNeels Hofmeyr2-4/+11
Related: SYS#5895 Change-Id: I9f4651b6bee457583aba99052dc82bbf675515e6
2022-06-16add pfcp_endpointNeels Hofmeyr2-0/+474
Related: SYS#5599 Change-Id: Ic8d42e201b63064a71b40ca45a5a40e29941e8ac
2022-06-16libosmo-pfcp: implement PFCP header and msg handlingNeels Hofmeyr3-1/+543
Related: SYS#5599 Change-Id: I3f85ea052a6b7c064244a8093777e53a47c8c61e
2022-06-16api: add osmo_pfcp_ie_node_id_to_str_c()Neels Hofmeyr1-2/+11
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
2022-06-16libosmo-pfcp: implement/generate TLV and IE value codingNeels Hofmeyr3-0/+1386
Related: SYS#5599 Change-Id: I3069045b2d42dac88d955c636230adc64a7a4aa7
2022-06-16libosmo-pfcp: add pfcp_proto.h pfcp_strs.hNeels Hofmeyr2-0/+520
Related: SYS#5599 Change-Id: I568b821e89007ed52eeefcdbcb6edd8052a8b5be
2022-06-16libosmo-gtlv: add TLIV capabilityNeels Hofmeyr3-49/+127
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
2022-06-16libosmo-gtlv: add C code generator for IE structs and arraysNeels Hofmeyr2-0/+418
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
2022-06-16libosmo-gtlv: add auto dec/enc to/from structsNeels Hofmeyr2-0/+518
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
2022-06-16libosmo-gtlv: add generic TLV de- and encoderNeels Hofmeyr3-0/+306
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
2022-06-16initial osmocom boilerplate source treeNeels Hofmeyr2-0/+3
Related: SYS#5599 Depends: I0a46b147ec6a76d909df28136cfd2b764b2c75ea (libosmocore) Change-Id: I4352dd8738a1a9de6ba2fc250ee8eef69c65ff1e