aboutsummaryrefslogtreecommitdiffstats
path: root/src/libosmo-gtlv
AgeCommit message (Collapse)AuthorFilesLines
2023-03-14build: libosmo-gtlv: move LIBS to libosmo_gtlv_la_LIBADDNeels Janosch Hofmeyr1-4/+4
Change-Id: I6fd777bed9366c35f5b1453cde1e6f5c1617e338
2023-03-14build: drop $(all_includes)Neels Janosch Hofmeyr1-1/+0
Drop this mysterious empty variable. No idea where it came from, there is nothing here that would set it. Change-Id: I7f2736366b34e7a15f73fa81ef1d4659ed6e2361
2023-03-14build: drop COVERAGENeels Janosch Hofmeyr1-2/+0
There isn't even an --enable-coverage in the configure.ac, so drop the always empty COVERAGE_CFLAGS and COVERAGE_LDFLAGS. Change-Id: Ib256ce7d979aec5c368b19ac2c145f75a9dab0fc
2023-02-07Bump version: 0.1.2.25-9c96-dirty → 0.2.00.2.0Pau Espin Pedrol1-1/+1
Change-Id: I44bb6b839a6aefaf269e124c990ff0f0b837588d
2023-01-02silence compiler warning in gtlv_dec_enc.cNeels Janosch Hofmeyr1-1/+1
This was reported with gcc version 12.2.0: /git/libosmo-pfcp/src/libosmo-gtlv/gtlv_dec_enc.c: In function 'osmo_gtlvs_decode_unordered': /git/libosmo-pfcp/src/libosmo-gtlv/gtlv_dec_enc.c:237:42: warning: 'presence_flag_p' may be used uninitialized [-Wmaybe-uninitialized] 237 | *presence_flag_p = true; | ^ /git/libosmo-pfcp/src/libosmo-gtlv/gtlv_dec_enc.c:113:23: note: 'presence_flag_p' was declared here 113 | bool *presence_flag_p; | ^~~~~~~~~~~~~~~ There is no actual code path that will use presence_flag_p uninitialized, but it doesn't hurt to init with NULL. Change-Id: I8f4c420f2182c607abb1ee5d1c8175eaeda904af
2022-12-08gtlv: decoding error: log size limited hexdump of IENeels Janosch Hofmeyr1-2/+6
When a decoding error is encountered, log the value part of the root cause as hexdump, but at most 16 bytes (16*3 chars as hexdump). Contrived example of the change: before this patch: <-tx- PFCP seq-4 ASSOC_SETUP_RESP: 0: Invalid FQDN (-22: Invalid argument) <-tx- PFCP seq-4 ASSOC_SETUP_RESP: 0: tag 0x3c = Node ID: Error while decoding this IE (-22: Invalid argument) after this patch: <-tx- PFCP seq-4 ASSOC_SETUP_RESP: 0: Invalid FQDN (-22: Invalid argument) <-tx- PFCP seq-4 ASSOC_SETUP_RESP: 0: tag 0x3c = Node ID: Error while decoding this IE. L=20 V=[ 02 07 65 78 61 6d 70 6c 65 03 63 6f 6d 01 02 03 ...] (-22: Invalid argument) Change-Id: Ie814a117db3dfea32cf3f01cf124a2e472cb869f
2022-11-03Support building with -Werror=strict-prototypes / -Werror=old-style-definitionHarald Welte1-5/+5
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that uses constructs of earlier C standards, which were abandoned in C99. See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for some related discussion. Change-Id: I79c51b78d1b055361f9ef5434361847353791d0d
2022-08-24gtlv: fix repeated IEIs to several struct membersNeels Hofmeyr1-20/+70
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
2022-08-24gtlv: check memory bounds 3/3: encoding to strNeels Hofmeyr2-14/+19
See Id8d997c9d5e655ff1842ec69eab6c073875c6330 Related: CID#275417 Related: SYS#5599 Change-Id: I63d52a4f5dba32d3a3887dd9c5e42e1695fb2aa3
2022-08-24gtlv: check memory bounds 2/3: decoding TLVNeels Hofmeyr2-26/+44
See Id8d997c9d5e655ff1842ec69eab6c073875c6330 Related: CID#275417 Related: SYS#5599 Change-Id: I841da89112ccf70fcd0f60eb902445fb1712eb48
2022-08-24gtlv: check memory bounds 1/3: encoding TLVNeels Hofmeyr2-10/+28
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-08-12fix warnings: 'uninitialized'Neels Hofmeyr1-1/+1
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
2022-08-09set LIBVERSION=0:0:0Neels Hofmeyr1-1/+1
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
2022-06-17install libosmo-gtlvNeels Hofmeyr1-3/+10
Related: SYS#5895 Change-Id: I9f4651b6bee457583aba99052dc82bbf675515e6
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 Hofmeyr2-0/+305
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