| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
gsm48_decode_bcd_number() is unable to provide proper bounds validation of
input and output data, hence osmo-msc's vlr.c introduced a static
decode_bcd_number_safe() a long time ago. Move to libosmocore.
I need to use the same function to decode an MSISDN during inter-MSC Handover,
instead of making it public in osmo-msc, rather deprecate the unsafe function
and provide a safer version for all callers. Mark the old one deprecated.
Change-Id: Idb6ae6e2f3bea11ad420dae14d021ac36d99e921
|
|
|
|
| |
Change-Id: I9dac375331f6bea744769e973725d58e35f87226
|
|
|
|
|
|
|
|
| |
The actual value-string array 'gsm_chan_t_names' describes
the enum values of 'gsm_chan_t', not 'gsm48_chan_mode'.
Change-Id: Ifc2121b23fb8d07589cc5b7aa8fbf4e27eb6b72b
Fixes: CID#188831, CID#188825
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change two instances of Speech Version values to enum gsm0808_permitted_speech.
It is often not trivial to find the right values for a uint8_t member, giving
the enum name makes it a lot easier/safer to use.
In gsm0808_create_handover_required(), use msgb_tv_put() so that the enum's
storage size doesn't matter. (Already used for handover_performed)
Fix typo in doc of gsm0808_create_handover_required().
Change-Id: I6387836bab76e1fa42daa0f42ab94fc14b70b112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on a draft created by Neels, which is the result of reading a MAP
trace of two MSCs negotiating inter-MSC handovers, and of reading the
TS 29.002, TS 29.010 and related specs:
https://lists.osmocom.org/pipermail/openbsc/2019-January/012653.html
I figured out that the "Handover Number" mentioned in the specifications
is the same as the MSISDN IE that we already have, so we can use that
instead of creating a new IE (example usage in tests/gsup/gsup_test.c).
Create a new OSMO_GSUP_MSGT_E_ROUTING_ERROR message type, which the GSUP
server uses to tell a client that its message could not be forwarded to
the destination (see [1]). MAP has no related message.
[1]: Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5 (osmo-hlr.git)
Related: OS#3774
Change-Id: Ic00b0601eacff6d72927cea51767801142ee75db
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
osmo-msc and osmo-hlr have distinct subsystems handling incoming GSUP messages.
So far we decide entirely by message type which code path should handle a GSUP
message. Thus no GSUP message type may be re-used across subsystems.
If we add a GSUP message to indicate a routing error, it would have to be a
distinct message type for subscriber management, another one for SMS, another
one for USSD...
To allow introducing common message types, introduce a GSUP Message Class IE.
In the presence of this IE, GSUP handlers can trivially direct a received
message to the right code path. If it is missing, handlers can fall back to the
previous switch(message_type) method.
Change-Id: Ic397a9f2c4a7224e47cab944c72e75ca5592efef
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various places in our code base figure out how many chars they need to safely
store an IMSI. An IMSI can have a checksum digit, which is not reflected by
GSM23003_IMSI_MAX_DIGITS. And we usually need a terminating \0.
Instead of having a magic +2 repeated every so often, rather define
OSMO_IMSI_BUF_SIZE to contain both checksum digit and nul char, and have the
explanatory comment with it here in libosmocore.
Change-Id: Id11ada4c96b79f7f0ad58185ab7dbf24622fb770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We often compose FSM instance IDs from context information, for example placing
an MSISDN string or IP:port information in the FSM instance id, using
osmo_fsm_inst_update_id_f(). This fails if any characters are contained that
don't pass osmo_identifier_valid(). Hence it is the task of the caller to make
sure only characters allowed in an FSM id are applied.
Provide API to trivially allow this by replacing illegal chars:
- osmo_identifier_sanitize_buf(), with access to the same set of illegal
characters defined in utils.c,
- osmo_fsm_inst_update_id_f_sanitize() implicitly replaces non-identifier
chars.
This makes it easy to add strings like '192.168.0.1:2342' or '+4987654321' to
an FSM instance id, without adding string mangling to each place that sets an
id; e.g. replacing with '-' to yield '192-168-0-1:2342' or '-4987654321'.
Change-Id: Ia40a6f3b2243c95fe428a080b938e11d8ab771a7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To be able to append an escaped or quoted string using
OSMO_STRBUF_APPEND_NOLEN(), the function signature must have the buf and len as
first args, like most other *_buf() functions.
Add osmo_escape_str_buf2() and osmo_quote_str_buf2() to match this signature.
A recent patch [1] has changed the return value of osmo_escape_str_buf() to
char*, removing the const. However, the functions may return const strings,
hence re-add the const. The new signatures always return the non-const buffer.
To avoid code duplication, implement osmo_quote_str_buf() and
osmo_escape_str_buf() by calling the new functions.
I decided to allow slight changes to the behavior for current osmo_escape_str()
and osmo_escape_str_buf(), because impact on callers is minimal:
(1) The new implementation uses OSMO_STRBUF_*, and in consequence
osmo_quote_str() no longer prints an ending double quote after truncated
strings; Before, a truncated output was, sic:
"this string is trunca"
and now this becomes, sic:
"this string is truncat
I decided to not keep the old behavior because it is questionable to begin
with. It looks like the string actually ended at the truncation boundary
instead of the reason being not enough space in the output buffer.
(2) The new osmo_escape_str_buf2() function obviously cannot pass-thru an
unchanged char* if no escaping was needed. Sacrifice this tiny optimization
feature to avoid code duplication:
- it is an unnoticeable optimization,
- the caller anyway always passes a string buffer,
- the feature caused handling strings and buffers differently depending on
their content (i.e. code that usually writes out strings in full length
"suddenly" truncates because a non-printable character is contained, etc.)
I considered adding a skip_if_unescaped flag to the osmo_quote_str_buf2()
function signature, but in the end decided that the API clutter is not worth
having for all the above reasons.
Adjust tests to accomodate above changes.
[1] 4a62eda225ab7f3c9556990c81a6fc5e19b5eec8
Ibf85f79e93244f53b2684ff6f1095c5b41203e05
Change-Id: Id748b906b0083b1f1887f2be7a53cae705a8a9ae
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In OSMO_STRBUF_APPEND, use local variable names that are less likely to shadow
other local variables: prefix with _sb_.
In OSMO_STRBUF_APPEND, add a check to add to .pos only if it is not NULL.
Add OSMO_STRBUF_APPEND_NOLEN(), which works for function signatures that don't
return a length. This is useful for any osmo_*_buf() string writing functions,
so that these write directly to the strbuf.
Change-Id: I108cadf72deb3a3bcab9a07e50572d9da1ab0359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move from a static implementation in tdef_vty.c to utils.c, I also want to use
this in osmo-msc.
The point is that the telnet VTY allows unambiguous partly matches of keyword
args. For example, if I have a command definition of:
compare (apples|oranges)
then it is perfectly legal as for the vty parser to write only
compare app
One could expect the VTY to then pass the unambiguous match of "apples" to the
parsing function, but that is not the case.
Hence a VTY function implementation is faced with parsing a keyword of "app"
instead of the expected "apples".
This is actually a very widespread bug in our VTY implementations, which assume
that exactly one full keyword will always be found. I am now writing new
commands in a way that are able to manage only the starts of keywords.
Arguably, strstr(a, b) == a does the same thing, but it searches the entire
string unnecessarily.
Change-Id: Ib2ffb0e9a870dd52e081c7e66d8818057d159513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add global flag osmo_fsm_term_safely() -- if set to true, enable the following
behavior:
Detect osmo_fsm_inst_term() occuring within osmo_fsm_inst_term():
- collect deallocations until the outermost osmo_fsm_inst_term() is done.
- call osmo_fsm_inst_free() *after* dispatching the parent event.
If a struct osmo_fsm_inst enters osmo_fsm_inst_term() while another is already
within osmo_fsm_inst_term(), do not directly deallocate it, but talloc-reparent
it to a separate talloc context, to be deallocated with the outermost FSM inst.
The effect is that all osmo_fsm_inst freed within an osmo_fsm_inst_term()
cascade will stay allocated until all osmo_fsm_inst_term() are complete and all
of them will be deallocated at the same time.
Mark the deferred deallocation state as __thread in an attempt to make cascaded
deallocation handling threadsafe. Keep the enable/disable flag separate, so
that it is global and not per-thread.
The feature is showcased by fsm_dealloc_test.c: with this feature, all of those
wild deallocation scenarios succeed.
Make fsm_dealloc_test a normal regression test in testsuite.at.
Rationale:
It is difficult to gracefully handle deallocations of groups of FSM instances
that reference each other. As soon as one child dispatching a cleanup event
causes its parent to deallocate before fsm.c was ready for it, deallocation
will hit a use-after-free. Before this patch, by using parent_term events and
distinct "terminating" FSM states, parent/child FSMs can be taught to wait for
all children to deallocate before deallocating the parent. But as soon as a
non-child / non-parent FSM instance is involved, or actually any other
cleanup() action that triggers parent FSMs or parent talloc contexts to become
unused, it is near impossible to think of all possible deallocation events
ricocheting, and to avoid running into freeing FSM instances that were still in
the middle of osmo_fsm_inst_term(), or FSM instances to enter
osmo_fsm_inst_term() more than once. This patch makes deallocation of "all
possible" setups of complex cross referencing FSM instances easy to handle
correctly, without running into use-after-free or double free situations, and,
notably, without changing calling code.
Change-Id: I8eda67540a1cd444491beb7856b9fcd0a3143b18
|
|
|
|
|
|
|
|
|
|
|
| |
To prevent re-entering osmo_fsm_inst_term() twice for the same osmo_fsm_inst,
add flag osmo_fsm_inst.proc.terminating. osmo_fsm_inst_term() sets this to
true, or exits if it already is true.
Update fsm_dealloc_test.err for illustration. It is not relevant for unit
testing yet, just showing the difference.
Change-Id: I0c02d76a86f90c49e0eae2f85db64704c96a7674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a habit of returning static buffers from some functions,
particularly when generating some kind of string values. This is
convenient in terms of memory management, but it comes at the expense
of not being thread-safe, and not allowing for two calls of the
related function within one printf() statement.
Let's introduce _c suffix versions of those functions where the
caller passes in a talloc context from which the output buffer shall
be allocated.
Change-Id: I8481c19b68ff67cfa22abb93c405ebcfcb0ab19b
|
|
|
|
|
|
|
| |
As per 3GPP TS 03.40, section 9.2.3.16 "TP-User-Data-Length (TP-UDL)"
field may contain up to 140 octets (or 140 * 8 / 7 = 160 septets).
Change-Id: I54f88d2908ac47228813fb8c049f4264e5145241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide a common implementation of use counting that supports naming each user
as well as counting more than just one use per user, depending on the rules the
caller implies.
In osmo-msc, we were originally using a simple int counter to see whether a
connection is still in use or should be discarded. For clarity, we later added
names to each user in the form of a bitmask of flags, to figure out exactly
which users are still active: for logging and to debug double get / double put
bugs. This however is still not adequate, since there may be more than one CM
Service Request pending. Also, it is a specialized implementation that is not
re-usable.
With this generalized implementation, we can:
- fix the problem of inadequate counting of multiple concurrent CM Service
Requests (more than one use count per user category),
- directly use arbitrary names for uses like __func__ or "foo" (no need to
define enums and value_string[]s),
- re-use the same code for e.g. vlr_subscr and get fairly detailed VLR
susbscriber usage logging for free.
Change-Id: Ife31e6798b4e728a23913179e346552a7dd338c0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For handling RTP IP addresses and ports, osmo-mgw, osmo-bsc and osmo-msc
so far have their own separate shims and code duplication around
inet_ntoa(), htons(), sockaddr conversions etc. Unify and standardize
with this common API.
In the MGW endpoint FSM that was introduced in osmo-bsc and which I
would like to re-use for osmo-msc (upcoming patch moving that to
osmo-mgw), it has turned out that using char* IP address and uint16_t
port number types are a convenient common denominator for logging,
MGCP message composition and GSM48. Ongoing osmo-msc work also uses this
for MNCC.
This is of course potentially useful for any other IP+port combinations
besides RTP stream handling.
Needless to say that most current implementations will probably stay
with their current own conversion code for a long time; for current
osmo-{bsc,msc,mgw} work (MGW endpoint FSM) though, I would like to move
to this API here.
Change-Id: Id617265337f09dfb6ddfe111ef5e578cd3dc9f63
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a number of static buffers in use in libosmo*. This means
the related functions are not usable in a thread-safe way. While
we so far don't have many multi-threaded programs in the osmocom
universe, the static buffers also prevent us from calling the same
e.g. string-ify function twice within a single printf() call.
Let's make sure there's an alternative function in all those cases,
where the user can pass in a caller-allocated buffer + size, and make
the 'classic' function with the static buffer a wrapper around that
_buf() variant.
Change-Id: Ibf85f79e93244f53b2684ff6f1095c5b41203e05
|
|
|
|
|
|
|
|
|
|
|
| |
osmo_escape_str_buf() used to have the somewhat odd semantics that
if no escaping was needed, it would return the original pointer without
making any copy to the output buffer. While this seems like an elegant
optimization, it is a very strange behavior and it works differently
than all of our other *_buf() functions. Let's unify the API and
turn osmo_escape_str_buf() into a strlcpy() if no escaping is needed.
Change-Id: I3a02bdb27008a73101c2db41ac04248960ed4064
|
|
|
|
|
|
|
|
|
|
| |
Doxygen was confused by duplicated documentation for both
definition and declaration of rate_ctr_for_each_counter().
Moreover, both variants contained some mistakes.
Let's avoid this duplication and keep the only (corrected) one.
Change-Id: Icca2d4a95bd5f96ae85a86909ec90fb8677cacf3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
core/msgb.h:414: warning: argument 'msgb' of command @param is not
found in the argument list of
msgb_pull_to_l2(struct msgb *msg)
core/msgb.h:399: warning: argument 'msgb' of command @param is not
found in the argument list of
msgb_pull_to_l3(struct msgb *msg)
core/msgb.h:351: warning: argument 'msgb' of command @param is not
found in the argument list of
msgb_push_u16(struct msgb *msg, uint16_t word)
core/msgb.h:361: warning: argument 'msgb' of command @param is not
found in the argument list of
msgb_push_u32(struct msgb *msg, uint32_t word)
core/msgb.h:341: warning: argument 'msgb' of command @param is not
found in the argument list of
msgb_push_u8(struct msgb *msg, uint8_t word)
Change-Id: I5d660933ecfa89c631319eccf9e3d5c1986ec8ff
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to the following Doxygen warning:
msgb.h:XXX: warning: The following parameters of
msgb_eq_l2(msg1, msgb2, len) are not documented:
parameter 'msgb2'
parameter 'len'
it was discovered that parameter 'len' is not required at all.
It basically doesn't make any sense to pass any length value,
because it can be calculated using msgb_length().
Let's drop this parameter. Given that this part of the API was
broken so far (see I1079d629abdb8770eef6be7341e586a933cd9cca),
it should be more or less safe to do this.
Change-Id: Icd9b72eb6bfa9628ff1ed2f948b57058551a4328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Neither Doxygen documentation of the msgb data comparison helpers,
nor their actual definitions does refer msgb2. Instead, 'msg2' is
referenced in both cases. This was discovered while investigating
the following Doxygen warnings:
msgb.h:XXX: warning: argument 'msg2' of command @param is not
found in the argument list of
msgb_eq(msg1, msgb2, len)
msgb.h:XXX: warning: The following parameters of
msgb_eq_l2(msg1, msgb2, len) are not documented:
parameter 'msgb2'
parameter 'len'
Due to this bug it was impossible to use the affected macros,
because 'msg2' was not listed in their parameters. Having the
unit test coverage would spot this bug at the beginning!
Change-Id: I1079d629abdb8770eef6be7341e586a933cd9cca
|
|
|
|
|
|
|
|
| |
- fix trailing white-space;
- properly align parameters of functions;
- use tabs instead of 8 spaces where possible.
Change-Id: Iaf616592a6bd72a1e7e94d8c55475710868beef0
|
|
|
|
|
|
|
|
|
|
|
| |
- drop incorrect \ref and \a references;
- add missing documentation to LLIST_HEAD_INIT;
- document parameter 'member' of llist_entry();
- turn @argument naming into a valid \param format;
- fix 'type *' vs llist_head loop counter confusion;
- capitalize and dot-terminate all sentences.
Change-Id: Iac67bdb9d5fbf7c222d04858967337f2428d6a94
|
|
|
|
| |
Change-Id: Ied4cb2bd06147785540a53ef118e9268406da702
|
|
|
|
|
|
|
|
|
|
|
|
| |
The naming of these constants dates back to when the code was private
within OpenBSC. Everything else was renamed (bsc_fd -> osmo_fd) at
the time, but somehow the BSC_FD_* defines have been missed at the
time.
Keep compatibility #defines around, but allow us to migrate the
applications to a less confusing naming meanwhile.
Change-Id: Ifae33ed61a7cf0ae54ad487399e7dd2489986436
|
|
|
|
| |
Change-Id: Ie6877277cddb0a9e049449c260afe3314ba65050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function gsm0808_sc_cfg_from_gsm48_mr_cfg() takes an S15 to S0
bitmask and converts that bitmask into an AMR multirate configuration
struct.
Unfortunately the current implementation implements 3GPP TS 28.062,
Table 7.11.3.1.3-2 wrongly in some aspects. Lets fix this.
- Fix wrong interpretation of the bitpatterns
- 5,15K is invalid and must never be selected
- Make sure that no more than 4 rates are selected in the active set
- Extend unit-test
Change-Id: I6fd7f4073b84093742c322752f2fd878d1071e15
Related: SYS#4470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CGI to Cell ID: for example, for Paging, osmo-msc has a CGI for a subscriber
and needs to send out a Cell Identifier IE. Makes sense to add this conversion
here.
Cell ID to CGI: for a Layer 3 Complete, a subscriber sends the current cell in
the form of a Cell Identifier, which we store as a CGI, if necessary enriched
with the local PLMN.
Add enum with bitmask values to identify parts of a CGI, for the return value
of gsm0808_cell_id_to_cgi(). Can't use enum CELL_IDENT for that, because it
doesn't have a value for just a PLMN (and is not a bitmask).
Change-Id: Ib9af67b100c4583342a2103669732dab2e577b04
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During FSM design for osmo-msc, I noticed that the current behavior that
keep_timer=true doesn't guarantee a running timer can make FSM design a bit
complex, especially when using osmo_tdef for timeout definitions.
A desirable keep_timer=true behavior is one that keeps the previous timer
running, but starts a timer if no timer is running yet.
The simplest example is: a given state repeatedly transitions back to itself,
but wants to set a timeout only on first entering, avoiding to restart the
timeout on re-entering.
Another example is a repeated transition between two or more states, where the
first time we enter this group a timeout should start, but it should not
restart from scratch on every transition.
When using osmo_tdef timeout definitions for this, so far separate meaningless
states have to be introduced that merely set a fixed timeout.
To simplify, add osmo_fsm_inst_state_chg_keep_or_start_timer(), and use this in
osmo_tdef_fsm_inst_state_chg() when both keep_timer == true *and* T != 0.
In tdef_test.ok, the changes show that on first entering state L, the previous
T=1 is now kept with a large remaining timeout. When entering state L from O,
where no timer was running, this time L's T123 is started.
Change-Id: Id647511a4b18e0c4de0e66fb1f35dc9adb9177db
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fi->T values are int, i.e. can be negative. Do not log them as unsigned, but
define a distinct timer class "Xnnnn" for negative T values: i.e. for T == -1,
print "Timeout of X1" instead of "Timeout of T4294967295".
The negative T timer number space is useful to distinguish freely invented
timers from proper 3GPP defined T numbers. So far I was using numbers like
T993210 or T9999 for invented T, but X1, X2 etc. is a better solution. This way
we can make sure to not accidentally define an invented timer number that
actually collides with a proper 3GPP specified timer number that the author was
not aware of at the time of writing.
Add OSMO_T_FMT and OSMO_T_FMT_ARGS() macros as standardized timer number print
format. Use that in fsm.c, tdef_vty.c, and adjust vty tests accordingly.
Mention the two timer classes in various API docs and VTY online-docs.
Change-Id: I3a59457623da9309fbbda235fe18fadd1636bff6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a flag that adds timeout info to osmo_fsm_inst state change logging.
To not affect unit testing, make this an opt-in feature that is disabled by
default -- mostly because osmo_fsm_inst_state_chg_keep_timer() will produce
non-deterministic logging depending on timing (logs remaining time).
Unit tests that don't verify log output and those that use fake time may also
enable this feature. Do so in fsm_test.c.
The idea is that in due course we will add osmo_fsm_log_timeouts(true) calls to
all of our production applications' main() initialization.
Change-Id: I089b81021a1a4ada1205261470da032b82d57872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NS implementation part of the Gb implementation libosmogb
so far implemented a rather classic dialect of Gb, with lots of
heritage to FR (Frame Relay) transports. At least since Release 6
of the NS specification, there's an IP Sub-Network Service (SNS),
which
* permits for dynamic configuration of IP endpoints and their NS-VCs
* abandons the concept of a NSVCI on IP transport
* forbids the use of RESET/BLOCK/UNBLOCK procedures on IP transport
This commit introduces BSS-side IP-SNS support to libosmogb in a
minimally invasive way. It adds a corresponding SNS FSM to each NS
instance, and implements the new SIZE/CONFIG/ADD/DELETE/CHANGE_WEIGHT
procedures very closely aligned with the spec.
In order to use the SNS flavor (rather than the classic one),
a BSS implementation should use gprs_ns_nsip_connect_sns() instead
of the existing gprs_ns_nsip_connect().
This implementation comes with a set of TTCN-3 tests in
PCU_Tests_RAW_SNS.ttcn, see Change-ID
I0fe3d4579960bab0494c294ec7ab8032feed4fb2 of osmo-ttcn3-hacks.git
Closes: OS#3372
Closes: OS#3617
Change-Id: I84786c3b43a8ae34ef3b3ba84b33c90042d234ea
|
|
|
|
|
|
|
|
|
|
|
| |
Modern NS specifications contain a SNS (Sub Network Service) for
negotiating IP/port/weight parameters of NS-over-IP links dynamically.
This patch adds message encoding routines for SNS-CONFIG, SNS-SIZE
and their respective acknowledgements.
Related: OS#3372
Change-Id: I5c47e1c3c10deb89a7470ee2c03adfc174accc93
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It should be large enough to prepend a struct osmo_scu_prim to pass down an
SCCP stack (see libosmo-sccp). 264 should suffice, but pick the next larger
power-of-two instead.
In osmo-msc, I would like to prepend an osmo_prim to the msgb created by
gsm0808 API, but turns out the headroom is too small:
msgb(0x61700001b660): Not enough headroom msgb_push (126 < 264)
Instead of always copying a msgb that has just that instant been created, it
makes more sense to allocate sufficient headroom in the first place.
Change-Id: I95729991eb49555f8bba60c5dc916131b03b6cf2
|