Coverity Scan has brought my attention to a problem with decoding
repeated IEIs, where there are multiple struct members in the decoded
struct that these are decoded to.
Before this patch, gtlv aborts with an error as soon as the first struct
member for a given tag is full, not parsing following IEIs into
subsequent struct members.
After this patch, gtlv continues to look whether subsequent entries in
the message coding also decode the same tag, but to a different struct
member.
First commit without changing the gtlv regression test, to show that all
current tests still succeed. The test for this particular issue follow
in I994d0fb1f1435d2c27a8630a43fe106652ac6e41
Related: CID#275415
Related: SYS#5599
Change-Id: Ie37585178ff27306d425b75d8e407b71f92f1cdc
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
Tag a new release with all the packaging fixes, so building libosmo-pfcp
for latest isn't failing anymore on obs.osmocom.org.
Related: OS#5654
Change-Id: I9a7be8342754fdbc21b83281c8ebcbf38112c61b
Require the same libosmocore version in configure.ac and rpm spec as
already set in debian/control.
Change-Id: I701f1aacca22a697f35aba0041a71945c5aea107
Follow what we are doing in other Osmocom rpm packaging by not building
and packaging static libraries.
Fix for rpmlint errors when building for OpenSUSE:
libosmo-gtlv-devel.x86_64: E: static-library-without-debuginfo /usr/lib64/libosmo-gtlv.a
libosmo-pfcp-devel.x86_64: E: static-library-without-debuginfo /usr/lib64/libosmo-pfcp.a
libosmo-gtlv-devel.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib64/libosmo-gtlv.a
libosmo-pfcp-devel.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib64/libosmo-pfcp.a
(If we wanted to build with static libraries, we would need to use
-ffat-lto-objects to get rid of the second error.)
Related: https://github.com/rpm-software-management/rpmlint/issues/458
Change-Id: I49dd454afd8bd3473bcadbc8cd8724574011f886
Fixes the following rpmlint error:
[ 17s] libosmo-pfcp.src: E: summary-too-long (Badness: 200) libosmo-pfcp: PFCP protocol encoding and decoding, and generic PFCP endpoint implementation
[ 17s] The 'Summary:' must not exceed 79 characters.
also, coincidentally it fixes:
[ 17s] libosmo-pfcp.src: E: summary-not-capitalized (Badness: 20) libosmo-pfcp: PFCP protocol encoding and decoding, and generic PFCP endpoint implementation
[ 17s] Summary doesn't begin with a capital letter.
and the non-critical warning:
[ 17s] libosmo-pfcp.src: W: name-repeated-in-summary libosmo-pfcp
[ 17s] The name of the package is repeated in its summary. Make the summary brief and
[ 17s] to the point without including redundant information in it.
Related: OS#5653
Change-Id: I293f77849d50e68753b82d7b5476c19217ecc2de
Though these can never be used uninitialized, initialize to NULL to
avoid compiler warnings like:
pfcp_msg.c:188:66: warning: 'h_no_seid' may be used uninitialized
Change-Id: Icb338b200fe3186ccd7fd3f502c1723f60947190
Fix debian packaging, so far a copy-paste from osmo-upf.git crept in
here by accident.
Related: SYS#5895
Change-Id: Id7169fc67b4f8f77dfbeff9f199e6557ced67a53
I wrote '1:0:0', but we should start with '0:0:0', according to
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Since the packaging for this repository is not functional yet, i.e. it
was never packaged by anyone anywhere, i assume it is safe to go back
from '1:0:0' to '0:0:0'.
Related: SYS#5895
Change-Id: I5b80de2f486fdae62f0da1b74cb70dc9de7bb9cc
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
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
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
Neels Hofmeyr
Neels Hofmeyr
Oliver Smith
Harald Welte
Vadim Yanitskiy