The TUAK algorithm is specified in 3GPP TS 35.231, 232 and 233 and
intended as an alternative to MILENAGE. It's based around the
cryptographic function of KeccakP1600, which is part of SHA-3.
This patch adds support for TUAK to the libosmogsm authentication
core API via 'struct osmo_auth_impl'.
Unit tests covering the test cases from the 3GPP specification are added
(and are all passing).
Change-Id: Ib905b8d8bdf248e8299bf50666ee1bca8298433d
So far, we were executing the cryptographic functions to generate
MILENAGE authentication tuples *twice* for every call to
milenage_gen_vec: Once for UMTS, and another time for GSM.
Let's do this properly: Execute once for UMTS, an then call the
computationally much simpler C2 and C3 functions to compute the
SRES and Kc values from RES, and CK+IK, respectively.
Change-Id: I20ecf6d32974c1ba196bf56deba5b2cd971eaffb
3GPP specifies the C2 derivation function (generating GSM SRES from UMTS XRES)
independent of the MILENAGE algorithm. So instead of open-coding it in
milenage.c:gsm_milenage(), let's create a separate public function
osmo_auth_c2() similar to the already-existing osmo_auth_c3() function.
gsm_milenage() can then simply use that function.
Change-Id: I0e7cd55f5578f891cb6cc1b0442920ba5beddae4
There are 3G algorithms which support different lengths of RES values
(4, 8, 16 byte). For MILENAGE, we never really had to bother, as
the 4-byte RES is simply the first 4 bytes of the 8-byte RES.
However, for TUAK, the expected RES length is an input parameter to
the Keccak crypto functions, so the result of all parameters (including
CK, IK, ...) will be completely different for RES length 4 than RES
length 8.
So let's permit the caller of the osmocom auth API to specify the
requested RES length via the osmo_auth_vector.res_len parameter.
For backwards compatibility of callers of the old osmo_auth_gen_vec/
osmo_auth_gen_vec_auts API: Always force the res_len to 8 in this case,
which was the hard-coded length before this patch.
Change-Id: Ic662843fbe8b5c58e4af39ea630ad5ac13fd6bef
Since Change-Id Ie775fedba4a3fa12314c0f7c8a369662ef6a40df we are
supporting K-lengths != 128 bit. However, our existing MILENAGE
and XOR-3G algorithms only support that key length, so let's add
some explicit checks for that.
Change-Id: Iae8b93cf059abda087101cdd01bbcf92d355753b
Let's make sure that nobody ever ends up calling the algo_impl
call-backs with data of a non-matching algorithm. This should
never happen at all, as all normal users should go through
the auth_core.c:osmo_auth_gen_vec* API, which dispatches based
on algorithm.
Change-Id: I22b504b6cffb4999b2f14772fffcb2f6f02c198c
3GPP TS 33.102 Section 6.3.7 states that K can be 128 or 256 bits,
while our 'struct osmo_sub_auth_data' had a fixed-size 128bit field.
This means we cannot use our auth_core for algorithms with larger
key sizes, such as TUAK. Let's introduce osmo_sub_auth_data2 for
larger (and variable) sized K and OP[c].
K and OP[c] can even have different sizes in TUAK, where OP[c] is
always 256bit, but K can be 128 or 256 bits. So we need separate
length fields for K and OP[c].
I'm adding backwards-compatibility API wrappers, so old applications
just continue to work as they always did.
However, I'm not adding compatibility wrappers for the plug-in API
that can be used to register additional authentication implementations
at runtime. We don't know of any user of that API outside of
libosmocore, so the function signatures of the 'struct osmo_auth_impl'
are modified in an incompatible way.
Change-Id: Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
These functions encode/decode the NCH position field within the SI1
rest octets. This is used within ASCI (VBS/VGCS).
Change-Id: I24a0095ac6eee0197f9d9ef9895c7795df6cdc49
Related: OS#5781
We have osmo_mobile_identity_decode_from_l3(), which takes a msgb as
argument, and decodes msg->l3h. Not all callers have their data in this
form. Offer a more flexible API for the same decoding.
For example, before the new function, osmo-hnbgw, which extracts a NAS
PDU from asn.1 packed data for CN pooling, would allocate a new msgb and
copy the NAS data just to pass a data pointer as argument.
Related: SYS#6412
Change-Id: I9bd99ccd01f0eedc091fe51687ff92ae1fdff60b
A commit was merged recently attempting to fix decoding of
TLV_TYPE_SINGLE_TV. It did mostly a good job, but missed updating the
o_tag pointer used to fill in the structures.
This commit fixes that specific part missing.
Fixes: 559a6ee683
Change-Id: Id619459c17976b77cd2c7e4179123bb06807285c
The decoding path of TLV_TYPE_SINGLE_TV is wrong, since it is not
shifting right the tag before using it. On the other hand, the encoding
path (tlv_encode_one) is doing that, so it is clear there's a bug.
It seems that in order to workaround the bug some IEs in gsm_04_08.h (TS
24.008 and TS 44.018) were defined incorrectly (eg 0x80) while the spec
clearly assigns eg. "8" to it, and makes sure no full byte IEI collides.
Some other IEIs like GSM48_IE_GMM_CIPH_CKSN which are also of the same
type were already correctly defined as 0x08.
Change-Id: I799e35dc8d4d153fa63bf50563a5482cdf4de2d7
3GPP TS 44.021 specifies the format for modified V.110 frames as used
on the GSM air (radio) interface. Implement encoders and decoders for
this modified V.110 format.
Related: OS#1572
Change-Id: I60a2f2690459359437df20cf4da9043fa7c3ad11
As per gnu extension doc ->
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Thread-Local.html :
".. When used with extern or static, __thread must appear immediately
after the other storage class specifier."
Change-Id: Ied1d3cf3ad2ff424bd0a2682aff29a8939b419b8
Provide the definitions from 3GPP TS 28.062, Table 7.11.3.1.3-2 as
generally usable API.
Likely users:
- upcoming patch to improve conversion between S0-S15 and MultiRate
config, I900fda192742fa8f6dd54e9131ef1704b14cc41a
- osmo-msc to figure out conversion between SDP AMR mode-set and 3GPP TS
48.008 Permitted Speech S0-S15.
- osmo-bsc to choose AMR modes for channel activation from cfg /
permitted speech from MSC.
Related: SYS#5066
Change-Id: Icef7dd626d3d4641c66b8dd87e2047fc0ab547d1
According to 3GPP TS 48.008 3.2.2.11, it is inverted.
0: Transparent service
1: Non-transparent service
Change-Id: I2e5786ad053ee871079b4a8d95caccd6b03b59b6
This patch is a preparation for the upcoming change making use of
the built-in static_assert(), which is available since C11.
When using built-in static_assert(), gcc v12.2.1 fails:
iuup.c: In function 'osmo_iuup_msgb_alloc_c':
iuup.c:194:33: error: expression in static assertion is not constant
194 | osmo_static_assert(size > IUUP_MSGB_HEADROOM_MIN_REQUIRED, iuup_msgb_alloc_headroom_bigger);
../../include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
This one is not really a *static* assert(), because it operates on the
user supplied argument 'size', which is not guaranteed to be an integer
literal. Neither it triggers a compilation failure as expected, nor
does it abort at run-time. It simply does nothing.
Change-Id: I53db679728250e0c60ed277efb18142073ffe9c4
This patch adds the convolutional code definitions for CSD (circuit
switched data) on TCH/F channels with user bit rates of 2400, 4800, 9600
and 14400 bps.
Related: OS#4396, OS#1572
Change-Id: I412131d7ee2e676402bf8d88394af17c4447b664
In the unit tests we're using memcmp() to compare decoding results
against the expected results. This is a reasonable approach, but
there is a pitfall: not only the struct fields are compared, but
also the padding bytes preceding/following them.
When using gcc's extension zero-initializer {} or even the standard
approved { 0 } zero-initializer, padding bytes are not guaranteed
to be zeroed. Even worse, according to [1], the init behavior is
inconsistent between gcc and clang and optimization levels.
All decoding functions in {bsslap,bssmap_le}.c currently use gcc's
extension zero-initializer {}. This is not a problem when building
with CC=gcc, but with CC=clang the bssmap_le_test fails due to
mismatch of padding bytes in struct lcs_cause_ie:
[4] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[5] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[6] PERFORM LOCATION ABORT: ERROR: decoded PDU != encoded PDU
Out of the known struct initialization methods, only the memset()
has consistent behavior and sets all bytes to zero, including the
padding ones. Using it fixes the bssmap_le_test for CC=clang.
[1] https://interrupt.memfault.com/blog/c-struct-padding-initialization
Change-Id: Ib16964b16eb04315efc416164ed46c15b5dc7254
Fixes: OS#5923
It already happened several times [1][2] that new features were added
to enum osmo_bts_features, but the osmo_bts_features_{descs,names}[]
were left unchanged. Let's add static_assert()s to prevent this.
Change-Id: I8e3b7d3996e9f3e16c6d4e0d1d406fa538d5e9be
Related: [1] f4f5d54ea2
Related: [2] 18c6a8183f
Let's disambiguate. Our existing OSMO_AUTH_ALG_XOR was always only
the XOR-3G algorithm. Now that we recently introduced XOR-2G,
let's rename (with backwards compatibility #define).
Change-Id: I446e54d0ddf4a18c46ee022b1249af73552e3ce1
We've so far only been supporting XOR-3G algorithm as specified
in TS 34.108 (in both 3G and 2G-derivation mode).
However, XOR-3G used for 2G auth is different from the XOR-2G algorithm
as defined in Annex A of TS 51.010-1. Let's add support for that one,
too.
Change-Id: I0ee0565382c1e4515d44ff9b1752685c0a66ae39
According to 3GPP TS 48.008 V16.0.0 § 3.2.2.11, the "Channel and rate
type" fills the whole octet 4, so don't cut it off.
This fixes decoding of e.g. GSM0808_SIGN_FULL_PREF_NO_CHANGE, which I
noticed while writing a test.
Related: OS#5911
Change-Id: Ib5fba18eb82736c4f52f315ae1197159b7090e69
Currently there's a big mess where include dir osmocom/gprs/ is used by
both libosmogsm and libosmogb.
Most of the header files under osmocom/gprs/ are actually all the
headers of libosmogb (there's no osmocom/gb/ dir). But a couple files
are actually RLC/MAC (TS 44.060) related are are also stored in there.
Those files have no relation/use in Gb, and are actually interused with
GSM (eg System Information 13 Rest Octets).
Hence, it makes sense to have the RLC/MAC related parts inside
osmocom/gsm/ as they should be in libosmogsm (and they actually are,
see gprs_rlc.h function implemented in src/gsm/gsm48_rest_octets.c).
The fact that some libosmogsm headers were placed in osmocom/gprs
instead of osmocom/gsm already created some issues, like
libosmocore.spec.in putting "%_includedir/%name/osmocom/gprs/" under
libosmogb, which is wrong.
As a first step to fix the mess, we move the 2 RLC/MAC headers currently
under osmocom/gprs/{gprs_rlc,protocol/gsm_04_60}.h under a single header
gsm/protocol/gsm_44_060.h
The two old headers are left existing for backward compatibility and now
simply include the new libosmogsm header, plus a warning asking users to
switch to the new header so we can eventually get rid of them.
This means libosmogb depends on libosmogsm, which is fine and was
already the case beforehand (libosmogb using functions like
gsm48_encode_ra() and linking against it in src/gb/Makefile.am).
Change-Id: I70cc21bf25a7081070738abacb409ed19094c3b2
Stop iterating if the extension bit (0x80) is set but elem is too short
to read another byte.
Related: OS#4393
Change-Id: Id37109dba0f5d40f4b83f0cef9b1dbd9d6bb2c68
Previous SI10 patch added function without exposing it via public header.
Let's fix this.
Fixes: 600d4eeab7
Change-Id: Ia7530e9c8a21f6f99f3aac7baea5cbb38763c4f3
There are some parts of libosmogsm which are not really GSM specific,
but rather ISDN bits that were inherited by GSM. This includes the
I.460 multiplex as well as the core LAPD protocol.
Let's move those bits to its own libosmoisdn library, before we add
more ISDN specific bits to the wrong place.
Backwards-compatibility is created by making libosmogsm depend on
libosmoisdn, and by providing wrapper include files for source
compatibility.
Change-Id: Ib1a6c762322fd5047be3188b1df22408ef06aa50
config.h is created in $(top_buildir)/config.h.
Let's make sure all CPPFLAGS add correct -Ipath includes,
and that all code includes the correct file.
Change-Id: Ie9ea38bb009bc715b01cde4d66d181f7bec2e7bd
This way we have all libosmocore.so in an own subdir instead of having
lots of files in the parent dir, which also contains subdirs to other
libraries.
This also matches the schema under include/osmocom/.
Change-Id: I6c76fafebdd5e961aed88bbecd2c16bc69d580e2
The function gsm_gsmtime2fn() uses a hack to account for the truncated
modulo implementation of C/C++. libosmocore offers proven modulo
functions, so lets use OSMO_MOD_FLR() instead. Also arrange the formula
so that it looks more like the one in the spec.
Also add better spec references and a final modulo GSM_MAX_FN to
prevent frame number results that exceed the valid range.
Change-Id: Ibf94bca8223f1f7858a6dd67bf27de0ab6feab20
The motivation behind adding and using the new API is explained in
the preceeding change [1]. Whenever any of the encoding functions
fails to encode either a Speech Codec or a Codec List IE, free()
the msgb and return NULL.
Change-Id: I28219b61b9347f0652f9fd0c717f6cdf3c63e8f9
Related: [1] I199ffa0ba4a64813238519178155dfc767aa3975
Related: SYS#6229
The problem with most of the existing gsm0808_* functions in this file
is that they assert() too much, assuming that their callers always pass
perfectly valid input parameters. But this is impossible on practice,
as there can be bugs in complex projects using them, liks osmo-bsc.
It was reported by a customer that a heavily loaded osmo-bsc crashed a
few times, dropping more than 100 sites without network coverage for
a few minutes. As was revealed during the investigaion, it crashed
due to a failing assert at the end of enc_speech_codec():
OSMO_ASSERT(sc->cfg == 0);
The problem is that somehow osmo-bsc is passing an unexpected sc->cfg
value to gsm0808_create_ass_compl2(), in particular 0x02, while the
given sc->type value (GSM0808_SCT_HR1) implies that there cannot be
any configuration bits on the wire.
The reason why and under which circumstances this can be happening
is not clear yet, but what we agreed on so far is that the library
API should be enforcing correctness of the input parameters in a
less agressive way, rather than aborting the process without
letting it any chance to recover.
Modify the original gsm0808_enc_speech_codec[_list]() functions, so
that a negative value is returned in case of an error. Rename them
and add backwards compatibility wrappers, because it's public API.
A separate patch making use of the new API follows next.
Change-Id: I199ffa0ba4a64813238519178155dfc767aa3975
Related: SYS#6229
I believe the gsm0808_* API is mature enough to avoid assert()ing
pointers accepted via function parameters. We can assume the caller
never passes NULL, as we do in almost all public API.
Change-Id: If9b4c92ace68191f5ddcc0a8a340fccbfe0f3dc0
This assert can be dropped because the switch statement above does
not leave any sc->type >= 0x0f for type_extended == false.
Change-Id: Iafb45ed66378f2c9c2480f81371e92c6d1da71a7
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: I84fd99442d0cc400fa562fa33623c142649230e2
The weird formatting not only makes it hard to read but caused linter to fail in the follow-up patch.
Change-Id: Ie4e56b4796c1b8f270a692453faccf102c963db5
gsm0808_create_lcls_conn_ctrl() was adding the LCLS-Configuration IE twice.
Correct is LCLS-Configuration followed by LCLS-Connection-Status-Control
(TS 48.008 3.2.1.91)
Change-Id: I455ac7695ad33ef9073bea7d1711508717732607
This is similar to what we already do between BSC<->MSC to pass Osmux
CID (GSM0808_IE_OSMO_OSMUX_CID).
We now want to support Osmux between BSC and Osmocom BTS, hence add an
extension IE which will be used in ipaccess CRCX messages to tell the
BTS to use Osmux.
Change-Id: I580fe99c01bc0a844d877994ec6cd954310e265d
This feature is used by the BTS to signal to the BSC that it supports
using Osmux instead of RTP on the BTS<->BSC(MGW) data plane.
Related: SYS#5987
Change-Id: Ie79bfb6d0a7a8fe2842d2596b3244e7b74a0d5b6
The decoding pointer was not increased correctly, ending up in reading
by 1 byte offset for each item in the list.
Change-Id: I16ed9bd65109a7ce32ff43c5789b4544479838e7
The testcase in gsm0408_test is still failing because the encoder
produces a different result (with octet 3a present). There is no
way to tell the encoder to use the implicit coding, and in general
this is not that critical, so we can live with that.
Change-Id: I722c168f01bffa915cb155eac234a796549d3762
That code path should not happen since this function is only called for
data frames coming with IUUP_FSM_EVT_IUUP_DATA_IND.
Control frames should come with specific events like
IUUP_FSM_EVT_IUUP_CONFIG_REQ.
Hence, let's add an assert to make sure we early exit if that ever
happens (it shouldn't), instead of carrying on reading uninitialized var
"dt".
Fixes: Coverity CID#272996
Change-Id: Iaeba59bc9ebfe817dbb7528572dc669c010ef14d
Once the IuUP FSM moved away from Init state, it stopped handling
Initialization messages received from peers and simply ignored them
starting from that point. As a result, if the first IuUP Init ACK it
sent to the peer was lost, the peer would keep retrying with more IuUP
Init and getting no answer.
In any case, it seems possible and desirable that a peer may send an
IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415.
sec 6.5.2.1:
"""
Upon reception of a frame indicating that an Initialisation procedure is
active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole
protocol information contained in the INITIALISATION control frame to the
upper layers. It also stores the RAB sub-Flow Combination set (and thus
replaces a possible previous set) in order to control during the transfer of
user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches
the expected Iu UP frame payload total length). The peer Iu UP entity
receiving the INITIALISATION control frame shall choose a version that it
supports among the proposed versions indicated by the sender for which it
has enough initialisation information.
"""
sec B.2.2 "Initialisation State":
"""
After sending a positive acknowledgement of the last INITIALISATION control
frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that
CN does not know if the initialisation ACK was correctly received by the RNC
(and Initialisation procedure successfully completed) until it receives RAB
assignment response, or use data from the RNC. The CN must therefore be able
to continue receiving INITIALISATION control frames by re-entering the
Initialisation state (from Support Mode Data Transfer Ready State), if the CN
has started to send user data before receiving the indication that
Initialisation was successfully completed
"""
sec B.2.3 "Support Mode Data Transfer Ready State":
"""
In case of handover or relocation, Initialisation procedures may have to be
performed and Iu UP instance may have to enter the initialisation state.
"""
Related: SYS#5995
Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
Those events are not realy used there and they are not even present in
the FSM definition. Let's drop them.
Change-Id: I4beec96ac4bdf047ebf144a8b009b297b47cacdc
The event is expected since the user of the IuUP stack can send a
CONFIGURE.req to transition to state null. The handling was already
there in the function, but the bit was missing in the FSM definition.
Change-Id: I830835a5b8b98f8b91b866f5280f508098c9ae7e
The initially merged IuUP API and implementation assumed that RFCI with
ID was always in the position of its ID inside the list of RFCIs. This
was the case for messages sent by ip.access nano3g as well as our own
osmocom implementation. However it was noticed that other nodes from
other vendors actually use other order, as allowed by the IuUP message
format.
Hence, we need to break the assumption and provide explicit ID
information in the list.
NOTICE: This commit breaks API and ABI compatibility with older versions
of libosmogsm, but not with any previous release of libosmocore since
the API is only available in master so far (it was added in
9fe1f9fb0b).
Similary, it's only user (osmo-mgw) only uses the API in master, so
there's no API breakage with older releases.
Related: SYS#5969
Change-Id: Ib21cee2e30bf83dff4e167f79541796007af9845
It was recently found that several IEs which were added in the header
file were not actually added to the tlv_definition, and hence the tlv
parser failed to decode them. Let's make sure we don't foget to add new
IEs in the future.
Related: SYS#5915
Change-Id: Id8a679ca43eb0fcc4882780e9a95ec21c7f51972
Those are available in 3GPP TS 48.008 version 16.0.0 Release 16, section
3.2.2.17 Cell Identifier. It can be seen that we have a collision
between the osmocom non-standard format and the SAI standard one.
This is because CGI-PS is not really a TS 48.008 Cell Identifier, but only
specified in TS 48.018 and has no ID number assigned. The CGI-PS was
added there because the whole osmo-bsc neighbour configuration works
with CellIds to manage neighbours, so it felt natural to extend the APIs
to also provide means to use CGI-PS format (TS 48.018 even refers 48.008
existance and mentions there's no explicit ID).
At the time this Cell Identifier was added, the firstly available number
(11) was taken, which was of course a really bad idea since newer
versions of the spec can at some point use it, which is the case if one
checks for instance TS 48.008 Release 16 SAI Cell Id.
There no perfect way to fix this bad decision at the time, but the
CGI-PS is only used in osmo-bsc and only for RIM related purposes, so by
changing the ID of CELL_IDENT_WHOLE_GLOBAL_PS, we only break RIM under
some specific CIs being used, and when an osmo-bsc is built against
older libosmocore and then used at runtime against a newer libosmocore
(which should be rare).
Hence, the downside is acceptable, and by moving the new ID number to be
ouside of the spec proto TS 48.008 range (4 bits), we make sure we don't
have the same problem again in the future.
Related: SYS#5838
Fixes: ca33a71ca8
Change-Id: Id25e563febdb7640174540136225f399515a0089
In general, it's safe not to use talloc API here because those are
internal allocations, and there are no 'return' statements between
calloc() and free(). However, we don't really need to initialize
the heap memory with 0, so let's use the 'normal' malloc().
Change-Id: I6956cbd83b2999dbcf8e2d210134b0a166c33efb
The event names contain '.', and there are spaces ' ' in the state
names. This is a problem since states and events can also be monitored
via the CTRL interface. Unfortunately the CTRL interface does not allow
certain reserved characters. So lets rename the states and event names
to make them compatible with the CTRL interface.
Change-Id: Id19973b56f9d7b1e3d0b0d7c7d0be7beba5428fc
Related OS#4149
Change-Id: I5ebc9ab5b1456fee29aa4e254fae862dc053f0aa
The parameters described in the docstrings for osmo_plmn_from_bcd() do not match the actual parameter list.
Change-Id: Ic0999dbe096a98418db7482bd110e20497d8e4a5
This allows init-passive users to get the configured sizes for the RFCIs
and other similar information once engotiated with the peer.
Realted: OS#1937
Change-Id: I63ee780b4aa162ea097410b234e73984000c0965
The use of an unsinged integer as for loop counter variable doesn't
work when counting down and comparing with >= 0. The existing code
would be an infinite loop if it wasn't for the (data dependent) break
condition:
>>> CID 243259: Control flow issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "i >= 0U".
572 for (i = 15; i >= 0; i--) {
573 if (match_mask & (1<<i)) {
574 iui->mode_version = i;
575 break;
576 }
Change-Id: I019d0f0d8f2b167575a2883a13cca692c96961cf
Closes: CID#243259
Only support for SMpSDU mode is introduced in this commit.
Not supported explicit list:
- Transparent mode
- ATM/AAL2 based Transport layer
- GTP-U based Transport Layer
- Iu Rate Control procedure
- Time Alignment procedure
APIs are provided to allocate the primitives properly inside the related
msgb. This way primitives can be placed in the headroom, leaving the
data part of the msgb for the IuUP payload, hence allowing re-use of the
msgb and 0 copy of IuUP payload when forwarding data over RNL<->TNL.
Since RNL and TNL primitives relu struct osmo_prim_header, which is not
packed, they cannot be set to packed, and hence proper memory alignment
in the msgb must be done to avoid misaligned accesses (Asan errors about
it otherwise).
Related: SYS#5516
Change-Id: Ibe356fa7b1abaca0091e368db8478e79c09c6cb0
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I5050285e75cf120407a1d883e99b3c4bcae8ffd7
Eric Wild
Harald Welte
Andreas Eversberg
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
Oliver Smith
Philipp Maier
Keith Whyte