The function is improved to support AF_INET:v4->v4, AF_INET6:v6->v6 and
AF_UNSPEC:v4+v6->v4+v6.
Unit tests for the function are added to make sure function behaves
correctly in several scenarios.
Change-Id: I36d8ab85d92bba4d6adb83bc1875eb61094ed2ef
Address resolution is done first and once we have the information, it
proceeds to create the socket. This separation in steps will help when
adding support for IPv6+IPv4 sets, where AF_UNSPEC is passed and created
socket needs to be AF_INET6 in order to handle addr of both versions.
Change-Id: I03147e3033a0c1fd04c9ac61d2ffbd78a1bb784a
Durin dev cycle, node was initially called "sched" instead of
"cpu-sched", and when it was renamed, this specific part was missed.
Change-Id: I0709fee12cc8ddc4d57efb4ea40b0b79b7ea4151
It's more convenient to use i in the outer loop, and j, k, etc.
in the inner loops. Otherwise it looks a bit confusing.
Change-Id: I61ef48fcf977d6a872e288571a4ff2c3dfe3184b
Shared code might be used by applications that have no vty, so sched
can't be initialized, do not assert and break everything in this case, a
warning should suffice.
Change-Id: Ic40075df8d4cf9fe8f1d711f899dae9a4b5b0928
Process willing to support this kind of configuration through VTY simply
need to call "osmo_sched_vty_init(tall_ctx);" during startup to register
the commands.
For multithreaded processes, new threads willing to get their
cpu-affinity mask according to VTY config should call
osmo_sched_vty_apply_localthread() (potentially after
setting the thread name through pthread_setname_np()).
Related: SYS#4986
Change-Id: If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
configure flag required to enable this: --enable-neon
Although autodetection according to __ARM_NEON would work because this
is only defined if the fpu is neon neon-fp16 neon-vfpv3 neon-vfpv4
neon-fp-armv8 crypto-neon-fp-armv8 doing that would lead to a unknown
performance impact, so it needs to be enabled manually.
Speedup is about ~1.3-1.5 on a unspecified single core Cortex A9. This
requires handling a special case for RACH with len 14 which is far too
short for neon and would actually incur a performance penalty of 25%.
Related: OS#4585
Change-Id: I58ff2cb4ce3514f43390ff0a2121f81e6a4983b5
osmo_sock_init2 abstract two calls of getaddrinfo into one.
While there aren't problems with AF_INET or AF_INET6. When using
AF_UNSPEC there are corner cases when this fails. E.g. calling
local_host with "" and remote_host with an IPv6 only address results in
setting up a local socket with AF_INET while trying to connect from there towards
AF_INET6 will most likely fail.
To prevent such cases with AF_UNSPEC, search prio calling any syscalls if local and remote site
supports AF_INET or AF_INET6. In case both supported, prefer AF_INET6
Change-Id: I397c633931fd00d4f083955a3c49a40fb002d766
The sysmobts uses the same OML attributes as IP.access. Because the IP.access
attribute only supports IPv4 as NSVC configuration, add an own attribute.
Change-Id: Ic261bc43a07fa741b97a9c6ec5a9ed6f5ecae588
Add bssgp_ns_send callback() to set the transmission path into the
NS library. This allows to use the Gb implementation with
the old NS and the new upcoming NS implementation.
Users of the old NS implementation don't have to set the callback as
the default is the old NS implementation.
Only users of the new NS implementation need to set the callback and
the callback data.
Change-Id: I3a498e6a0d68b87fed80c64199b22395796761b4
When I wrote the new I.460 mux + demux code, I failed to realize that
* bit numbers in relevant ITU specs start with 1 as MSB ... 8 as LSB
* sub-slot 0 is bits 1+2, i.e. the two MSBs of a byte
* bit-ordering within each sub-slot is also MSB first
As a result, the code and test data was broken.
Change-Id: I6df7dbf411efbdeaf516e72ac552432bf5a569d0
When calling a user-provided call-back function for the i460 mux
or demux, always pass a pointer to the osmo_i460_subchan the callback
relates to. This way, the user can walk the i460 data structures
to obtain information about which mux/demux instances is calling.
Change-Id: Id842c72ce371a67fe5df6694e195c281aaf607ab
There is no way for the API user to know if the TX queue of the
multiplexer runs empty. However, this is criticil since an empty TX
queue will cause dropout of a TRAU frame, which can have quite severe
effects to the receiving end. Lets add a callback that allows the APU
user to insert appropiate idle frames or silent frames into the queue
before it runs empty.
Change-Id: I88a87724235fe50d55ce6215bb385c044072226e
Related: OS#2547
The define constants for the cause codes "BTS not equipped",
"remote transcoder failure" and "notification overflow" are missing.
Lets add them including value strings.
Change-Id: Ic3e936da00bd256bae03867887851f1a4e30e218
Without this patch, for instance having a range 0-ULONG_MAX would match
if someones types value -3, which would be converted to unsigned but
that's clearly what is expected here from user point of view.
Change-Id: Ia95f6314a2dd3f94d21fc219cf69bb8d39b8e7f0
This fixes commands not being matched due to providing a range with more
than 10 digits.
The last case (passing -4000 matching 0-ULONG_MAX) shows a different bug
which will be fixed in next commit.
Change-Id: I0afa0caabffe36083c36b92ba90696ded00bb7be
At least on Debian unstable, newlib is [currently?] buggy in that
we need to include sys/types.h before including inttypes.h, otherwise
PRIu64 is not defined.
Change-Id: Ic1c9cdf66cfd5b82bd7e20eaaf05b10e6bdb675e
Closes: OS#4686
When a subchannel is deleted or created the initalization mainly
consists of a memset over the wohle subchannel struct a message buffer
initailization.
However, when we delete a subchannel we also must take of the resetting
of the related struct. Currently this is done with a memest.
Unfortunately this creates not only a memory leak (there might be still
items in the multiplexer tx queue) but also it makes the application
crash when the message buffer is used the next time since the llist_head
of the tx queue looses its initialization.
Lets fix the memory leak problem and the message buffer problem and put
the reset functionality in a single place.
Change-Id: I937a9d4db95f44a860cd2c5dbb660dc1970b9a49
Previous both the IPA nanobts and the sysmobts has been using the IPv4 only OML
attribute NM_ATT_IPACC_NS_LINK_CFG.
A bts with BTS_FEAT_IPV6_NSVC supports IPv6 for NSVC (PCU<Gb>SGSN) using
the new OML attribute NM_ATT_OSMO_NS_LINK_CFG.
Change-Id: I9ef7949f66764b3c639e45eb440122e318da44a0
* Allow to set the reporting interval to 0 for manual reporting
* stats reset command to reset all statistics
* stats report command to manually trigger statistics reporting
Change-Id: I9febcb65650abfd538caedfbca77a787e66d517a
Related: SYS#4877
The talloc_asprintf() series includes an unconditional call to
talloc_set_name_const(), turning the entire long constructed string
into the name of the talloc object. That simply doesn't work when
creating kilobytes-sized VTY reference strings including linefeeds.
Let's add an explicit talloc_set_name_const() to prevent this.
Change-Id: Ibd77684b88cc3572047daa98c9a6b9119fba041b
Closes: OS#4668
Follows patch I353adc1aa72377f7d4b3336d2ff47791fb73d62c that was merged too
soon. Applying my code review in form of this fixup patch.
Change-Id: I979bca0c6aaa8fe4feddda922bd2e6c1cb49585b
Reverting due to being completely normal for some applications to submit
usning this channel type when decoding/parsing failed and hence not
being able to determine channel type.
This reverts Change-Id Ib4147a33a75c3cf425c30da8b0678c7fba8a371d
(commit 12f93be6073ed89055862baafbfe0e08e50ed17a.)
Change-Id: I6ebaa89cc3422df1d7fd2365a6176cb2902d1c67
While processing an I-frame we may deliver its payload to L3. After
returning from L3 procesing, we run some additional code, assuming
the LAPD/DL state has not changed meanwhile.
However, if the application destroys the LAPD/DL meanwhile, our state
might be NULL again, and in this state we should not perform any further
action.
This is one of the cases where synchronous in-line dispatch across
various layers is hitting us. L3 should have an input queue, and only
start processing after all L2 work has completed and we're about to go
back to sleep in select().
Change-Id: I026b64503511002c13c0f4117648c366c48ecc62
Related: OS#1761
Closes: OS#4646
At some points, e.g. when allocating message buffers from the Tx
history, we used to allocate them exactly as large as the defined
headroom plus the user data. This means that the underlying PH layer
(E1 mostly) had no tailroom to add anything to the end of the message.
Especially for DAHDI this is a problem, as we need to make space for
two more bytes of frame check sequence (FCS).
So let's simply make sure we always have some extra space at the end
of such buffers.
Change-Id: Id362ce131157c7513d744b0248c7f78fb75c590c
Related: OS#4644
We cannot just set sockaddr_in.sin_addr + sin_port, we also must
initializa sin_family. The reason this has worked so far is
because we probably always first received a NS packet from the
peer, rather than being the first one to send.
Change-Id: I6cefc2cd5516c7a4c01a2cc040afca454e59dd57
Related: OS#4629
If a BVC-RESET is sent from SGSN, there must not be a cell ID IE
included. See "Note 1" of TS 48.018 Section 10.4.12.
Change-Id: I11d4e70d510265b9c09dffccdab10b3f0816715a
The previous example showed a type == IMSI while setting a TMSI value.
Rather show how to encode IMSI digits.
Change-Id: I41af6bf0d61443465172123297b1228584d791d6
This feature indicates if the given BTS supports paging coordination,
that is the transmission of CS paging (received on Abis) to be sent
via PACCH/PCU in PS domain fro MS with active TBF.
Change-Id: Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38
Related: OS#2406
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for current osmo CNI programs, replacing the Mobile
Identity coding with this new API. Deprecate the old MI API.
osmo-bsc: I71c3b4c65dbfdfa51409e09d4868aea83225338a
osmo-msc: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
osmo-sgsn: I4cacb10bac419633ca0c14f244f9903f7f517b49
Note that some GPRS and SGs related coding is done here in libosmocore and
hence currently remains using the old implementation (see previous version of
this patch: Ic3f969e739654c1e8c387aedeeba5cce07fe2307).
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
As a result, applications using osmo_mobile_identity will be stricter in
rejecting coding mistakes (some of which we currently have in our test suites,
and which we'll need to fix).
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
This patch was first merged as Ic3f969e739654c1e8c387aedeeba5cce07fe2307 and
caused test fallout, because it re-implemented old API with the new stricter
decoding. In this patch version, old API remains 1:1 unchanged to avoid such
fallout. Applications will soon switch to the new osmo_mobile_identity API and
become stricter on MI coding when that happens, not implicitly by a new
libosmocore version.
Change-Id: If4f7be606e54cfa1c59084cf169785b1cbda5cf5
This reverts commit d1ceca9d48, as it
introduces regressions in both osmo-msc and osmo-nitb which have been
causing failing builds for several days now.
Change-Id: I4bd958d0cd2ab4b0c4725e6d114f4404d725fcf7
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for all osmo programs, completely replacing the Mobile
Identity coding with this new API. Hence deprecate the old MI API.
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
Change-Id: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
If start_nibble were passed negative, we'd end up accessing invalid memory.
Safeguard against that.
Change-Id: Ied3c1e02c3a01d868e08195cbd8dfa52d2c19ac3
These utilities will be used by osmo-bsc to determine the Network Resource
Indicator seen in the TMSI, and (potentially) by osmo-msc to compose a TMSI
with a specific NRI, for osmo-bsc's load balancing between several MSCs.
Add utility functions to:
- extract an NRI value from a TMSI.
- overwrite the NRI value in a TMSI.
- limit an NRI in a (random) TMSI to a given list of ranges.
- add NRI value ranges to a list.
- remove them from a list.
- match NRI value (range) to a list.
- parse NRI values from string, for VTY.
- common VTY functionality of adding/removing NRI values from argv.
Add C tests for the above.
Why we need public API for NRI ranges: In osmo-bsc alone, we need the same NRI
API twice, 1: to manage/list NRI value ranges per-MSC, and 2: to manage/list
NULL-NRI values. If we also consider (potentially) adding NRI support to
osmo-msc, we need the same API twice again there. Hence it is useful to define
re-used API up here in libosmocore.
Related: OS#3682
Change-Id: Icb57a2dd9323c7ea11b34003eccc7e68a0247bf5
The call identifier in the ASSIGNMENT COMMAND is encoded in the wrong
endieness. 3GPP TS 48.008, section 3.2.2.105 specifies that the least
significant byte should be transmitted first, which means that the
endieness here is little endian. Lets make sure that the endieness is
correctly transmitted, regardless of the host byte order.
Change-Id: I6468e502f552f99ab54aec9d4b1c169fdc0adfb8
Related: OS#4582
At the moment we print the pointer address to identify the log lines
belonging to a specific connection. Since pointer addresses are
difficult to work with, a human readable ID should be printed instead.
e.g. "This is LAPD instance for SAPI3 on bts0/trx1/ts5/lchan3"
Change-Id: Ie6742843fff809edffcac24c4dce4edf66bc71be
Closes: OS#1938
Pau Espin
Vadim Yanitskiy
Eric Wild
Harald Welte
Alexander Couzens
Philipp Maier
Daniel Willmann