Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
Related: SYS#5599
Change-Id: I3849060d703494ea43773c0208203f1fc206067f
|
|
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
|
|
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
|
|
Related: SYS#5599
Change-Id: Ic8d42e201b63064a71b40ca45a5a40e29941e8ac
|
|
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
|
|
Related: SYS#5599
Depends: I0a46b147ec6a76d909df28136cfd2b764b2c75ea (libosmocore)
Change-Id: I4352dd8738a1a9de6ba2fc250ee8eef69c65ff1e
|