aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2022-12-01add osmo_pfcp_ie_outer_header_creation_to_str_*()Neels Janosch Hofmeyr1-0/+4
Make osmo_pfcp_enc_to_str_outer_header_creation() as osmo_pfcp_ie_outer_header_creation_to_str_*() functions. Used by I0d4d9edcfc94b61bdc74cfd4ff837f151d1c28ae (osmo-upf) Change-Id: I4ad1570485c8081b82284e4e6b4de4d7eed414b0
2022-11-26add osmo_pfcp_ip_addrs_to_str_*()Neels Janosch Hofmeyr1-0/+2
Move static function ip_addrs_to_str_buf() to public API as osmo_pfcp_ip_addrs_to_str_buf() and osmo_pfcp_ip_addrs_to_str_c(). So far the static function was only used in places where it follows other strings, so that it made sense to always start with a comma. Move this comma out of the function to the callers. Sensibly handle a NULL pointer and an empty address set. Rationale: osmo-upf would like to print an osmo_pfcp_ip_addrs struct in logging. Change-Id: I5f67db8d347690cbb1ce273a2d072636859f1bf6
2022-11-11api doc: explain heartbeat handling in rx_msg_cbNeels Janosch Hofmeyr1-1/+4
Related: SYS#5599 Change-Id: I3849060d703494ea43773c0208203f1fc206067f
2022-08-24gtlv: check memory bounds 3/3: encoding to strNeels Hofmeyr1-4/+6
See Id8d997c9d5e655ff1842ec69eab6c073875c6330 Related: CID#275417 Related: SYS#5599 Change-Id: I63d52a4f5dba32d3a3887dd9c5e42e1695fb2aa3
2022-08-24gtlv: check memory bounds 2/3: decoding TLVNeels Hofmeyr1-3/+4
See Id8d997c9d5e655ff1842ec69eab6c073875c6330 Related: CID#275417 Related: SYS#5599 Change-Id: I841da89112ccf70fcd0f60eb902445fb1712eb48
2022-08-24gtlv: check memory bounds 1/3: encoding TLVNeels Hofmeyr1-3/+3
Introduce a maximum bound of memory access to the osmo_gtlv API. Properly pass const-ness within the gtlv implementation. This patch adds membof_const(). The following patch will add the non-const membof() equivalent, which is not needed in this patch, yet. Coverity CID#275417 drew my attention to the fact that the gtlv decoding and encoding does not actually guard against access past the end of the decoded struct. We have not yet officially released libosmo-gtlv; also, osmo-upf and osmo-hnbgw so far only use the libosmo-pfcp API, which "hides" the gtlv API. Hence just change the API without a backwards compat shim. Related: CID#275417 Related: SYS#5599 Change-Id: Id8d997c9d5e655ff1842ec69eab6c073875c6330
2022-07-28apply code review: refactor pfcp_endpoint APINeels Hofmeyr1-45/+45
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 Hofmeyr2-6/+9
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-06-17add generic PFCP CP peer implementation0.1.0Neels Hofmeyr2-0/+64
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/+1
Related: SYS#5599 Change-Id: Iacaeebfad0fe77788da40c3ed7da2ffa3b27043c
2022-06-16add pfcp_endpointNeels Hofmeyr3-0/+111
Related: SYS#5599 Change-Id: Ic8d42e201b63064a71b40ca45a5a40e29941e8ac
2022-06-16libosmo-pfcp: implement PFCP header and msg handlingNeels Hofmeyr2-0/+198
Related: SYS#5599 Change-Id: I3f85ea052a6b7c064244a8093777e53a47c8c61e
2022-06-16api: add osmo_pfcp_ie_node_id_to_str_c()Neels Hofmeyr1-0/+3
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-16pfcp ie: tweak CP Function FeaturesNeels Hofmeyr1-1/+1
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
2022-06-16pfcp/Makefile.am: add missing pfcp_ies_auto.h entryNeels Hofmeyr1-0/+1
Even though it is a generated header, it must still be listed in pfcp_HEADERS. Related: SYS#5599 Change-Id: I6fbfe1fcd084f2d16334bb3e44d9891d9485d59f
2022-06-16libosmo-pfcp: implement/generate TLV and IE value codingNeels Hofmeyr2-0/+179
Related: SYS#5599 Change-Id: I3069045b2d42dac88d955c636230adc64a7a4aa7
2022-06-16libosmo-pfcp: add pfcp_proto.h pfcp_strs.hNeels Hofmeyr3-0/+628
Related: SYS#5599 Change-Id: I568b821e89007ed52eeefcdbcb6edd8052a8b5be
2022-06-16libosmo-gtlv: add TLIV capabilityNeels Hofmeyr3-7/+37
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/+167
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/+202
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/+143
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 Hofmeyr3-0/+6
Related: SYS#5599 Depends: I0a46b147ec6a76d909df28136cfd2b764b2c75ea (libosmocore) Change-Id: I4352dd8738a1a9de6ba2fc250ee8eef69c65ff1e
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-01 09:55:42 +0000