This callback was drepecated and is not ever called since
libosmocore.git 70ce871532ab21955e0955d7e230eae65438f047 (release 1.3.0).
See also libosmocore.git d31de237582f6fe3315d61bb9a488d4cda92654e.
Change-Id: Ifdecb35f329c243222bc5d77f0a6d394c9413684
The only truly correct way to pass FR/HR/EFR traffic from an
incoming RTP stream to TRAU-DL frames is to apply the transform
of TS 28.062 section C.3.2.1.1, originally specified for TFO
but also necessary in the non-3GPP-specified case of GSM TrFO
as it happens here. Unlike the situation with EFR, a FOSS
implementation of TFO transform for FRv1 does exist in Themyscira
libgsmfr2 - however, making these Themyscira codec libraries
usable from mainline Osmocom programs by way of a proposed
libosmocore DSO plugin mechanism, followed by a major redesign
of OsmoMGW-E1 to pass all DL traffic through this TFO transform,
would be a major project, difficult to justify prior to development
of a proper TFO transform for EFR to complement the one for FRv1.
Hence no change is being made currently to the arguably flawed
general architecture of OsmoMGW-E1, which consists of passing
through unaltered all valid codec frames that are received in RTP,
and inserting fixed dummy TRAU-DL frames when no RTP-derived ones
are available.
The original dummy TRAU-DL frame for FRv1 exhibited the following
defects:
* The payload frame transmitted to the MS consisted of all zero
bits. Standard type-approved GSM MS would interpret this bit
pattern as a SID frame, even though the BTS is told via C16 bit
"this frame is not a SID". Passing a SID is not inherently bad
in itself in this context, but a SID with all LARc parameters
set to 0 is a strange/poor choice.
* The setting of C-bits (defined in TS 48.060 section 5.5.1.1.1)
was a mish-mash between TRAU-UL and TRAU-DL frame formats,
thereby not matching the standard TRAU-DL C-bits fill produced
by osmo_rtp2trau().
The replacement fill frame introduced here differs as follows:
* The payload bit content is the silence frame of GSM 46.011
Table 1: certainly better than a SID with all LARc parameters
set to 0, and arguably better than any SID at all.
* The full TRAU-DL frame (C-bits pattern, peculiar ordering of
D-bits) was generated by passing said silence frame through
osmo_rtp2trau(), using this ad hoc tool:
https://gitea.osmocom.org/themwi/dummy-dl-frames
Change-Id: I995824586058e4e4ed77e900d4b57e5113f9eff6
The only truly correct way to pass FR/HR/EFR traffic from an
incoming RTP stream to TRAU-DL frames is to apply the transform
of TS 28.062 section C.3.2.1.1, originally specified for TFO
but also necessary in the non-3GPP-specified case of GSM TrFO
as it happens here. However, no FOSS or even published-source
implementation of TFO transform for EFR exists at the present time
(no implementations at all are known outside of TRAU DSP firmware),
hence the general architectural approach of OsmoMGW-E1, flawed
as it is, has to remain for now. This flawed architecture consists
of passing through unaltered all valid codec frames that are
received in RTP, and inserting fixed dummy TRAU-DL frames when no
RTP-derived ones are available.
The original dummy TRAU-DL frame for EFR exhibited the following
defects:
* D1 bit was set to 0, even though TS 48.060 section 5.5.1.1.2
states it shall be 1;
* All 5 EFR frame CRCs were invalid: each 3-bit CRC was 000, even
though the correct TS 48.060 section 5.5.1.1.2 CRC from an
all-zeros payload would be 111;
* Even if the 5 CRCs were fixed, transmitting an EFR frame of all
zero bits to the MS won't produce good results - it is a bad
choice of dummy filler;
* The setting of C-bits (defined in TS 48.060 section 5.5.1.1.1)
was a mish-mash between TRAU-UL and TRAU-DL frame formats,
thereby not matching the standard TRAU-DL C-bits fill produced
by osmo_rtp2trau().
The replacement fill frame introduced here differs as follows:
* The payload bit content is the decoder homing frame (DHF) of
TS 46.060 section 8.2 Table 7 - the best we can do in the absence
of a proper TFO transform for EFR;
* The full TRAU-DL frame (C-bits, CRC etc) was generated by passing
said EFR DHF through osmo_rtp2trau(), using this ad hoc tool:
https://gitea.osmocom.org/themwi/dummy-dl-frames
Change-Id: I5a33a1c9ddf1372f91870d61b5eafac4729ee458
By changing the white space structure of these hard-coded frames
to only have one leading tab on each line of 8 frame bits, we make
it easier to replace these hard-coded frames with different versions
that are programmatically generated, as will be done in the following
patches.
Change-Id: I3d0c931d4dc3d916ba4c5eb081bea22d9c7144de
The TODO was written because the author had in mind the ptr where the
codec was stored was a MGCP endpoint object, but it is actually an
rtp_end which is an object under conn_rtp, so that's fine already with
current code.
Change-Id: I99d2211e81443883c45cc3fdda10e39a8c152063
Do most of the initial parsing and verification in a prior step, filling
in a "parsed" struct which simplifies logic coming after for different
message types.
Change-Id: I557a3a257ddefedc479a4aff974a74c4e4e2c85d
Do most of the initial parsing and verification in a prior step, filling
in a "parsed" struct which simplifies logic coming after for different
message types.
This commit only modifies stuff enough to work for MDCX.
Further work (commits) will follow for DLCX.
Change-Id: I6ecb41fc2cc737c3a161b6bc98bd08ae01909655
Do most of the initial parsing and verification in a prior step, filling
in a "parsed" struct which simplifies logic coming after for different
message types.
This commit only modifies stuff enough to work for CRCX.
Further work (commits) will follow for MDCX and DLCX.
Change-Id: I3ee5158c254213203830fe9c38de11c15b4b19c1
Clean up pointers passed. Rename function since it's clearly operating
on trunk related fields through mutexes.
Change-Id: Ib894afcb61609c247883d5ccdd7b8fbf29b2cbf8
Clean up pointers, join 2 functions only making stuff more confusing.
Rename function to make it clear it operates on a conn_rtp object.
Change-Id: I50a251b66e85ceeeccb30dcd1813863d7c754961
The previous logic to configure SSRC patching was over complex and
confusing, with even some broken logic like "patch only once", which is
not really needed. Hence, simplify the internal logic to either patch
SSRC always or don't do it, based on VTY configuration.
The "force SSRC" feature was added in
db2d431697 and further changed in
e2292f3aa1, due to the need for nanoBTS to
always keep the same SSRC on received packets. However, it makes no
sense that is actually needed only once: if remote end changed several
times, then we should keep patching in that case.
This change allows getting rid of confusing applying of settings at a
later time through mgcp_rtp_end_config(), which is no longer needed and
can be dropped, simplifying steps during CRCX/MDCX/DLCX.
Change-Id: Ib7216a775f4ad126e62b9e99aff381fd45015819
Apply the forced value automatically during init, and then only
override it based on received input from MGCP when it has not been
forced by VTY config.
Change-Id: I02a92a090887caa8e05917a44c8b2351fa7b9b50
We do tons of operations on 3 fields (array of codecs, len of array,
selected code) which can be isolated.
Right now, we are using APIs which somehow require structs 2-3 levels of
encapsulation above the ones really required, which makes all code
totally entangled, difficult to understand and prone to errors when
changing stuff in deeply nested structs.
A prove of this is how this patch affects a lot of lines in lots of
places.
Change-Id: Id7db7ab01d56b7fa2415123b604375e48c82ab25
Preparation path to add an init function and start untangling related
code.
While at it, move definition of struct mgcp_rtp_codec to the mgcp_codec.h where it belongs.
Change-Id: Id1b6cab57e44ad4859bde8212d0ac9f7146d7198
While at it, moving the only clearly existing API for the same object to
the same place to have them together
(mgcp_rtp_end_remote_addr_available()).
Change-Id: Ifabd1cf69273a6d22feb65c08de590d083987d09
This has several benefits:
* easily improving/changing the impelemntation later on (eg. by storing
a count instead of iterating the whole list).
* Remove code complexity from mgcp_protocol.c.
Change-Id: I77c298abf0a1488b91f58c9e76507ef8add0168e
There's no need to lookup (iterate over conns) for rtp_conn in endp, we
have it accessible in constant time.
While at it, simplify some accesses to the pointer after it.
Change-Id: I8316e76a1789d4a8eaa1eb89bdaf86e25dc0a1e8
Add a new mgcp_conn_get_conn_rtp() and use it everywhere instead of
accessing deep structure fields.
Change-Id: Iee2c19598e9570ea3b1ceba3cdfd2a5f5be2c954
These functions act on the endp object, hence prefix them with
mgcp_endp_* and move them to mgcp_endp.{c,h}.
Change-Id: Ifff01331db68998e9e23f99d8836d96022d550c2
All the code to free conns in an endpoint is really entanged, which also
makes it inefficient in several places because the list of conns is
iterated twice, or even ~N*2.
* Move code freeing the conn object to its own mgcp_conn_free()
function.
* Rename functions acting on endp to be mgcp_endp_* prefix, and move
them to mgcp_endp.{c,h}.
* Remove old mgcp_conn_free(endp, id) since it's not really needed
anymore.
Change-Id: I9a87a07699dd8aa7856d5036e9b95a4ddf699a15
This was added in e3d16bb775 14 years ago:
"""
[mgcp] Protocol extension to not generate answers.
For the NAT we want to send requests in a send and forget
way and we are not interested in seeing the answers, so tell
the gateway to not answer them.
"""
So this code is most probably related to osmo-bsc_mgcp time, and we
don't really need this feature in osmo-mgw, it really makes no sense.
Drop it.
Change-Id: Ica2d3d54cda41e0c6416913ab056843a0cd80c17
If user (VTY) configured the local IP address to use for MGCP, and that
IP address was not the one selected by kernel routing table lookup, the
IP address filled in the MGCP message would be wrong, not matching the
one sending the MGCP message.
Change-Id: I35624db853dc1f0fee85503105960613f70473c6
struct mgcp_client defined here has a field "struct mgcp_client_conf
actual", which is defined in osmocom/mgcp_client/mgcp_client.h.
Change-Id: I61a67c371dbcfab073fa75ba08a3cac0f46e0ac0
errno is positive, hence we need to change the value of "res" being
passed to strerror().
While at it, use thread-safe variant strerror_r().
Change-Id: Ibc278199bc8f66e5521bff72bad150f44716f3eb
This makes it easier to catch possible failures while running the test,
plus makes gcc on OpenSUSE_Factory happy and not warn.
Related: OS#5044
Change-Id: I01c3c84e58a11055f0e0a6955016dc2489c73379
The comment in struct mgcp_rtp_end says that the RTCP port number has to
be stored in network byte order. Such a port number is 16 bit long, so
let's use an uint16_t instead of an int here.
Related: OS#6527
Change-Id: I392b07b243389a78d4ad1d784cdfdc28ec59b487
The original code did E1 raw TS output by posting directly to
&ts->raw.tx_queue instead of calling e1inp_ts_send_raw();
doing so bypasses the call to driver->want_write performed in
e1inp layer. This approach worked for DAHDI where no
select-for-write is used; however, e1inp interface to osmo-e1d
does use select-for-write, hence applications like osmo-mgw
do need to use e1inp_ts_send_raw() API in order to work
correctly.
Change-Id: I6ce9a1dea6834632faf75059e85ca9a0c25d57c2
Currently, a CRCX in sendrecv mode results in:
DLMGCP ERROR endpoint:rtpbridge/2@mgw CI:7F4C8EDD CRCX: selected connection mode type requires an opposite end! (mgcp_protocol.c:1090)
But it is not actually practical, nor logical to require another conn
for the 'sendrecv' ConnectionMode.
Impractical: If I want to create two conns on an endpoint that both are
in 'sendrecv' mode, I have to send two CRCX, one for each conn. At the
time of the first CRCX, there cannot be any other conn, so I am
currently forced to send a different ConnectionMode in the CRCX,
followed by another MDCX later, just to change the first conn to
sendrecv.
Illogical: In a situation where two conns are currently in sendrecv
mode, if I now DLCX one of them, I can legally reach a state with a
single conn in sendrecv mode, just as currently forbidden for CRCX.
In general, MGCP is not forcing any particular number of connections.
Simply start forwarding RTP as soon as there is a remote conn, and not
require another explicit MDCX.
Related: SYS#6974 SYS#6907
Related: osmo-ttcn3-hacks I00fd854f058f7f53e2f579e8481ca2b9253f08e3
Change-Id: Ic089485543c5c97a35c7ae24fe0f622bf57d1976
Note, there are also ttcn3 tests sending the same to osmo-mgw being
submitted along with these patches, and the ttcn3 tests currently fail:
osmo-mgw rejects the connection mode "sendrecv" in the first CRCX.
Change-Id: Icdb1085b8e44ac4cff6c457163349b81e81bf765
In our GSM world, the packet time is 20 ms, hence 20 is the typical
value that we should test. Maybe we can do one test with 40 at most, but
we'll most probably never see anything else than 20 in practice.
Change-Id: Ia2292198bf6e3b72912afd69607654ca77fd549d
The only valid line endings are '\n' and '\r\n'.
We usually use '\r\n' like we were in MSDOS.
MGCP, RFC3435 3.1:
Headers and session descriptions are encoded as a set of text lines,
separated by a carriage return and line feed character (or,
optionally, a single line-feed character).
SDP, RFC8866 5:
The sequence CRLF (0x0d0a) is used to end a line,
although parsers SHOULD be tolerant and also accept lines terminated
with a single newline character.
There should probably be tests for '\n' line endings, but mixing them in
the same MGCP message is ridiculous.
Change-Id: I6d530535a3a5f1d1a0716ab9e4a8079ba1de242e
HRv1 support in OsmoMGW-E1 was previously broken (couldn't work
on either 16k or 8k subslots) because of inconsistency: the TRAU
frame type was set to OSMO_TRAU16_FT_HR, but the TRAU sync pattern
was set to OSMO_TRAU_SYNCP_8_HR. However, now that libosmotrau
has proper support for HRv1 TRAU frame encoding and RTP conversion
in both 16k and 8k formats, drive it correctly in OsmoMGW-E1.
While at it, change the code structure to avoid else-after-return.
Was the original code written and merged in a time before strict
linter checks?
Change-Id: Ifadbdc68905178c6ffdd673a6fb71c18610c9847
When osmo-hnbgw does not yet know the remote port, it wants to send a
CRCX to set up IuUP at the MGW, with the audio port set to zero.
Make sure osmo-mgw accepts port == 0.
Related: SYS#6907 SYS#6974
Change-Id: I42011c2e7256d372a37b6a2fe86af0153038e2d0
Re-add the m=audio line to SDP emitted from libosmo-mgcp-client, even if
the audio port is not set yet
Patch a5acaa68db introduced a presence
flag for the RTP audio port number. This flag, when unset, also omitted
the 'm=audio...' line completely, dropping the PT number definitions.
Correct:
m=audio 1234 RTP/AVP 96 <--- anounce 96
a=rtpmap:96 VND.3GPP.IUFP/16000 <--- further specify 96
a=fmtp:96 ... <--- further specify 96
When m=audio is missing, we only have orphaned rtpmap and fmtp entries.
They are supposed to further specify the 96 listed in 'RTP/AVP 96',
instead they are without context:
a=rtpmap:96 VND.3GPP.IUFP/16000
a=fmtp:96 ...
When the presence map indicates no port known, we still need to emit the
list of PT numbers; so we're forced to send a port of 0:
m=audio 0 RTP/AVP 96
a=rtpmap:96 VND.3GPP.IUFP/16000
a=fmtp:96 ...
This is an important fix for osmo-hnbgw, which sends the first CRCX with
an IUFP codec, at a time when the remote port is not yet known. osmo-mgw
requires an m=audio line to accept incoming IuUP Initializaition
requests. When m=audio is missing, osmo-mgw does not parse the IUFP
codec, and 3G voice fails completely. This mgcp-client patch will emit
valid codec config also when port == 0, fixing osmo-hnbgw voice, because
osmo-mgw will know about IUFP from the start.
Related: SYS#6907 SYS#6974
Related: osmo-mgw a5acaa68db
Change-Id: Id95b629453aec999100b5af821c6a0b9562bb597
Fix for:
range must end at an odd port number, autocorrecting port (16000) to: 16001
% Deprecated 'sdp audio-payload number <0-255>' config no longer has any effect
% Deprecated 'sdp audio-payload name NAME' config no longer has any effect
% Deprecated 'loop (0|1)' config no longer has any effect
Change-Id: I62a4fd119de48039c3c450d5323d8f9b7de8120f
I have verified that with AmbientCapabilities=CAP_SYS_NICE, setting
scheduling policy as described in the manual still works as expected.
Related: OS#4107
Change-Id: Ibb83c231231b39dc6732c0f375aeb3b21f3938ef
This way holes can be detected. In practice it's not much important
since it would be really strange that UDP fails for a while and then it
starts working out of the blue...
Related: SYS#6907
Change-Id: I8095f3505c859650c0b83abce405067bef745975
Previous commit add osmo_io changed mgcp_udp_send() implementation from
"return sendto()", which is documented as:
"return the number of bytes sent. Otherwise, -1 shall be returned"
to "return mgcp_udp_send_msg()", which in turn calls
"return osmo_iofd_sendto_msgb()", and which is documented as:
"\returns 0 in case of success (takes msgb ownership), -1 on error
(doesn't take msgb ownership)."
So successful return code changed from >0 (bytes sent) to ==0,
but forgot to update mgcp_send_iuup() return code path check (and also
some related function documentation calling mgcp_udp_send()".
This commit fixes all the related aspects of that return code change.
Related: SYS#6907
Fixes: 352b967d1b
Change-Id: I154e1e41cd02fd4d9b88ad98fc7c4d657246c589
Converting from osmo_fd to osmo_io allows us to switch to the new
io_uring backend and benefit from related performance benefits.
In a benchmark running 200 concurrent bi-directional voice calls with
GSM-EFR codec, I am observing:
* the code before this patch uses 40..42% of a single core on a
Ryzen 5950X at 200 calls (=> 200 endpoints with each two connections)
* no increase in CPU utilization before/after this patch, i.e. the
osmo_io overhead for the osmo_fd backend is insignificant compared
to the direct osmo_fd mode before
* an almost exactly 50% reduction of CPU utilization when running the
same osmo-mgw build with LIBOSMO_IO_BACKEND=IO_URING - top shows
19..21% for the same workload instead of 40..42% with the OSMO_FD
default backend.
* An increase of about 4 Megabytes in both RSS and VIRT size when
enabling the OSMO_IO backend. This is likely the memory-mapped rings.
No memory leakage is observed when using either of the backends.
Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a
The old approach was: rtp_data_net() reads a msgb from the incomging
socket, calls through whatever function chain and in the end free's it.
So none of the intermediate functions was permitted to take msgb
ownership.
This was a good choice as all processing would happen synchronously,
up to the point where that msgb was written on the output RTP socket.
Let's change this from passing msgb ownership throug the whole call
chain, through rx_rtp() to the various *_dispatch_rtp() functions.
This is required for upcoming migration to osmo_io, as in that case the
write (sendto) calls are asynchronous and hence msgb ownership needs
to be transferred.
Change-Id: I6a331f3c6b2eb51ea312ac6ef8c357185ddb79cf
the processing call-back is working with a raw buffer + length,
while we actually work with struct msgb. Let's simply pass the msgb
into the call-back, and the call-back can then do what they want with
the contents of that msgb.
Change-Id: I002624f9008726e3d754d48aa2282c38e3b42953
The existing support preparing the mgw for transcoding (which doesn't exist)
has some kind of method where the transcoding function might be called
multiple times in a row. However, as it is not used, it is not entirely
clear how it was intended to work. Let's remove this unused looping
feature which makes it hard to understand how upcoming osmo_io should
deal with it.
Change-Id: Ie1a629fd31c5ab806fc929d1e6b279c4be5b8246
The entire mgw has no transcoding support. So printing that message is
useless to begin with. And printing it for *every RTP packet* is even
more useless. Let's remove it.
Change-Id: If0ee2607404afc3a00665a5cf22a9e0eb62eb476
Before this patch, when an CRCX+MDCX wants to set a codec list that has
no match with the codecs for the other conn of that same endpoint,
osmo-mgw returns an MGCP "FAIL" response.
When a client wants to change the codec, it has to do that one RTP port
at a time. So osmo-mgw *must* allow to configure an MGCP conn with a
codec choice that mismatches the other conn.
This is crucial to allow codec negotiation in osmo-msc: if MO has
already assigned a specific codec, and later wants to re-assign to the
codec that MT has chosen, the codec needs to be changed at osmo-mgw.
This patch is the minimal fix required to get re-assignment to a
different codec to work (via osmo-msc). There is more work to be done
about this bit of code in osmo-mgw, but keep that to a separate patch.
In detail, before this patch, we fail both
- when a side has no codecs,
- or when there is no single match between codecs of the two sides of
the endpoint.
Remove only the second condition; after this patch, still fail when a
side has no codecs -- this allows mgcp_test.c to still pass.
Related: OS#6293
Related: osmo-msc I8760feaa8598047369ef8c3ab2673013bac8ac8a
Change-Id: I3d1163fe622bdd7dc42a485f796072524ab39db9
The new osmo_io framework means that we can [optionally] make use
of the io_uring backend, which greatly reduces the syscall load
compared to the legacy osmo_wqueue + osmo_select_main + read/write.
We only use features already present in the intiial osmo_io support
of libosmocore 1.9.0, so no entry in TODO-RELEASE is needed.
Closes: OS#5754
Related: OS#5755
Change-Id: I766224da4691695c023d4d08d042a4bbeba05e47
We already did a lookup from conn_src[i] and found a matching
codec_conn_dst, no need to do another reverse lookup to end up at the
same conn_src[i] codec.
Change-Id: Iecc7f22c551fd17b23db434fdb177266407d2621
There is considerable code complexity in place for this ancient hack.
It dates back to 5ea1bc77a3
"
mgcp: Allow to freely control the a=fmtp line for experiments
In case of AMR one can specify the available codecs out-of-band. Allow
to configure this line statically in the configuration file.
"
Looking in mgcp_test.c output, the fmtp-extra tests do not even make
sense: they result in fmtp for pt=126 being added, even though there is
no payload type 126 listed in the SDP...
Related: OS#6313
Change-Id: Icee0cd1f5a751fa760d5a9deca29089e78e7eb93
It seems to be a remnant from early openbsc_mgcp. There is only the
default implementation for this callback and it simply returns two
pointers. Simplify that.
Change-Id: I18dfd44c931540caf4ac360c08ed10e5f65b2165
Removing the duality of codecs[] and ptmap[] in structs mgcp_msg,
mgcp_response and mgcp_conn_peer has removed the need to "map" from
codec type enum to payload type number. They are stored together now.
Remove functions that are no longer used.
None of our osmocom users of libosmo-mgcp-client call these functions.
Change-Id: I84e5285831397c992af59deee12dea8458d16cc6
So far we allow only MGCP_MAX_CODECS-1 entries, because the parsing exit
condition hits only after the array size check. Instead, check the array
size a bit later, just before actually adding a valid entry.
This is verified to work as expected in upcoming patch
I842ce65a9a70f313570857b7df53727cc572b9e6 that adds a new
mgcp_client_test.c section for this.
Change-Id: I9a28da85e437f118026ea71a5a708e5758fff623
codecs[] is an array of enum osmo_mgcp_codecs.
ptmap[] is an array of { enum osmo_mgcp_codecs, unsigned int ptmap }.
MGCP lists first a bunch of payload type numbers and then specifies them
again for details, like the numbers 112, 96, 3 in this example:
m=audio <port> RTP/AVP 112 96 3
a=rtpmap:112 AMR/8000
a=rtpmap:96 VND.3GPP.IUFP/16000
a=rtpmap:3 GSM-FR/8000
So far we keep these lists in two separate arrays:
- codecs[], codecs_len stores the 'm=audio' list
- ptmap[], ptmap_len stores the 'a=rtpmap' list (and may omit some
elements present in codecs[])
This applies to both struct mgcp_response and struct mgcp_msg.
These are semantically identical, and the separation leads to checks,
conversions and dear hopes of correct ordering.
So let's keep only one list with both codec and payload type number in
it. The 'm=audio' list establishes the order of the pt numbers, and the
'a=rtpmap' list adds codec information to the established entries.
In the internal API structs mgcp_msg and mgcp_response, just drop the
codecs[] entirely.
In public API struct mgcp_conn_peer, keep the codecs[] array, mark it
deprecated, and provide a backwards compat conversion: if any caller
invokes mgcp_conn_create() or mgcp_conn_modify() with codecs[] still
present in the verb_info arg, then move codecs[] entries over to the
ptmap[] array in a sensible way.
(BTW, even mgcp_conn_create() and mgcp_conn_modify() are never called
from outside of libosmo-mgcp-client in any of our osmo-cni programs;
users call osmo_mgcpc_ep_ci_add() and osmo_mgcpc_ep_ci_request(), which
in turn may pass user-provided codecs[] lists on to mgcp_conn_create() or
mgcp_conn_modify().)
Tests for parsing the MGCP response are mostly missing. They will be
added in upcoming patch I842ce65a9a70f313570857b7df53727cc572b9e6,
because they will be using only the new ptmap API.
Related: OS#6171
Change-Id: I798e02c6663376d3d52f4a74fc4b32411ce95bed
As was pointed out during code review of a previously merged patch,
whenever we write something to the tailroom, we must use msgb_put().
Change-Id: Ibe1605631a94088bfd1f603f7043322ed5585ffe
We need to be able to terminate the received string in case it was
not nul-terminated by the sender (see mgcp_msg_terminate_nul()).
Change-Id: Icc878af7f671213bb516af62cb601914d86ff808
Fixes: CID#272990
The current statement:
msg->l2h + msgb_l2len(msg)
looks as follows, if we expand the msgb_l2len():
msg->l2h + msgb->tail - msg->l2h
so this is basically equal to msgb->tail alone.
Change-Id: I4f4b0f792bbeef94a5449c4a5843628a703a3d54
Related: CID#272990
There is an upcoming modification of structs mgcp_msg and mgcp_response.
When it is public API, it needs to be kept backwards compatible.
But no libosmo-mgcp-client caller (in the osmocom-cni world) has used
these structs in years and years. Everyone should use the higher level
osmo_mgcpc_* API only.
Move this legacy API to a private header, so we no longer need to worry
about compatibility there.
Related: OS#6171
Related: I798e02c6663376d3d52f4a74fc4b32411ce95bed
Change-Id: I6d8bdda5c2ffa236e94a0b6111de4dbfac923187
end.codec may be NULL, depending on whether a single matching codec
could be found or not, i.e. based on external input. So let's not crash
if an RTP packet arrives while end.codec == NULL.
Change-Id: I9bfb55a343b3f2b1459e0aba4ee71a6133b992b3
A client may know the IP address during CRCX but not yet the port, or it
may simply want to hint an initial IP address so that the MGW can better
guess when allocating a local IP address.
Related: SYS#6657
Change-Id: I30165dbac5e484011d0acf46af36f105954a501d
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote port is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any address or port.
An osmo-mgw client (eg. osmo-hnbgw) may wish to initially set a remote
IP address as a hint during CRCX, hence the IP address may already be
set while the port may be unset.
Related: SYS#6657
Change-Id: Idd833997abce46886e9664505b2776fa5dadc8db
We have proper IuUP support and everything about this legacy hack should
be purged.
The purpose of this function is to validate that RTP is coming from the
expected address and port. To allow that legacy IuUP hack, which is no
longer needed, we punched a hole into this validation, by adding this
special case for loopback mode (suddenly we don't care who or what sends
RTP and bounce it back to anyone). So let's get rid of this hole that
was only needed for very early 3G voice hacking.
Instead, we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b
Related: SYS#6657
Change-Id: I158dd046fdfcb10392cde3de8cc88dd095a05b40
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote IP address is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any remote address if the remote IP address is not yet known.
If we refuse the IuUP Initialization, a 3G RNC may fail to set up a RAB.
We will know the remote address only *after* assigning a RAB succeeded.
So the IuUP Initialization must be allowed before knowing all addresses.
At the time of writing, CRCX for IUFP are sent to osmo-mgw in either
LOOPBACK or in RECVONLY mode:
- current osmo-msc: recvonly
- osmo-msc <= v1.10.0: loopback
- osmo-hnbgw: loopback
IuUP Initialization should work regardless of that.
See also next patch I158dd046fdfcb10392cde3de8cc88dd095a05b40
IuUP is one layer below the loopback/send/recv decision for RTP; IuUP is
always terminated at the MGW, while the AMR payload carries through.
Related: alternative patch Idd833997abce46886e9664505b2776fa5dadc8db
Related: SYS#6657
Change-Id: I6c365559a7bd197349f0ea99f7a13b56a4bb580b
A typical OS imposed limit is 1024 open FD, which can bee too low when
there are hundreds of concurrent voice calls.
In systemd service file, set a super high limit of 65536.
In osmo-mgw's user manual, add section 'Configure limits' describing
this in detail.
Related: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I46512517bc3b5bb90cac7643e7ac73afba398d36
A user reports crashes of osmo-bsc upon EV_MDCX. It turns out that there
is a lot of error reporting and a distinct possibility to get a NULL
return value because of external input. Terminate the FSM instead.
FSM termination is the proper way to report a bad error, it signals the
parent_term_evt to the FSM parent, which will then be able to act on the
failed MGCP operation.
Related: SYS#6632
Change-Id: Ia5d8a9aff565399a85a5b116d7029fedcab234e0
Before:
CONN: (1226/rtp, id:0xD94316AD, ip:127.0.0.2, rtp:2344 rtcp:2345)
After:
CONN: (1226/rtp C:D94316AD r=127.0.0.2:2344<->l=127.0.0.1:4002)
While changing that string, also include these changes for consistency
and readability:
- use the same r:...<->l:... format as osmo_sock_get_name().
- Instead of 'id:0x' use the actual MGCP format 'C: 9B686BE3'.
- drop the commas
- drop RTCP port: it is always RTP+1 and always an odd number.
Rationale:
The CONN pairs associated with each endpoint show remote RTP
ports. When osmo-mgw is being used by both BSC and MSC, one
side of the pair is showing the internal loop connection inside
osmo-mgw, while my intuition suggested this connection pair
is showing me the RTP port tuple of a single RTP stream. Adding
the local port to the display makes it more clear, IMHO.
Seeing the local port can also help to correlate the MGW vty
dump with a capture of RTP.
Implementation:
I first tried directly using osmo_sock_get_name_buf() on
conn->u.rtp.end.rtp.fd, but that might hide already known information
when the fd is not actively used yet (before SDP): the local address and
port would then be shown from the fd, not from
conn->u.rtp.end.local_addr/_port == hidden before the fd is set up.
Patch-By: whytek, nhofmeyr
Change-Id: Ib89a6779e1d68c6600f00699d4303f6c0ee07132
The mgcp client may first configure the connection to use RTP-AMR, but
after setting up another call leg may find out that both legs are IuUP
and hence want to forward the IuUP between the 2 connections instead.
In that case, an MDCX with codec VND.3GPP.IUFP would be set.
Until now, osmo-mgw didn't take that scenario into account, and it was
only upgrading the rtp conn to iuup internally during CRCX.
As a result, in the mentioned scenario osmo-mgw would continue to
output RTP instead of IuUP after the MDCX with VND.3GPP.IUFP, which is
wrong.
Related: SYS#6578
Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2
For each RTP packet that is received from a connection, the mode is
checked whether receiving is allowed or not. If not it is discarded.
In case of "confecho" mode, the RTP is also sent by the receiving
connection.
Then a loop is used to send RTP to all sending endpoints except the one
that received the packet.
Because we have a loop that allows to have 1..n connections, we have no
maximum number of allowed connections anymore.
Change-Id: Ic99a55ab5a3a6170e940403fadd52697e99f2f3a
Related: OS#4853
The new mode "confecho" is similar to "sendrecv", except that it also
echoes back RTP towards the sender. This is required for voice group or
broadcast calls. Talker and listeners use the same timeslot, so that
audio must be echoed from the talker to the listeners.
It is different from "loopback", because a loopback only echoes back RTP
towards the sender, but does not forward audio through the endpoint to
the other connections. Also it does not forward RTP from senders of
other connections.
The current implementation of MGW does not support transcoding and
mixing. This means that a sending connection must not send RTP that has
been received by multiple receiving connections. The application that
uses the MGW has to set the connection modes, so that only one
connection receives RTP in case of a conference.
Change-Id: I0639c663e119d85bef1010c7aa45e2f133a9daf0
Related: OS#4853
Instead of calling strlen() for every loop iteration, just use strchr()
to find the position of '/'.
Change-Id: Ifc7302b6c5f9288a622e33c3e8b5fe0e7037dbdc
In the "L: a:" header, read the first codec name only up to the ";"
separator, and ignore the rest.
According to RFC-2705, the "L: a:" header may include multiple codecs
like "GSM-EFR;GSM" in:
L: p:20, a:GSM-EFR;GSM, nt:IN
osmo-mgw can handle only a single codec here. Since recently, osmo-msc
is our first client that may actually send more than one codec. This
uncovered a bug that leads to failing voice calls:
* osmo-mgw parses the entire list "GSM-EFR;GSM" as a single codec name,
* puts that into the ptmap without scrutiny,
* and even sends it back in the OK response, in the *SDP* part, as a
single "GSM-EFR;GSM" codec entry.
We do not care very much about the "a:" codec list, because we always
establish codecs via SDP later. So all we need to fix this is: parse the
first codec done correctly, and ignore the rest.
Related: OS#6081
Change-Id: I0342e85b32ed89f3a1fdb6131c3c8ded8f47a455
Abort with error log when map_str_to_codec is -1, instead of writing it
as unsigned integer into ptmap[i].codec.
Related: OS#6074
Change-Id: I08b91c849d810fe3cdb72c0f6f2a558b7377deab
This way if keepalive becomes disabled for an MGW, it can be selected
again (otherwise it would become non-selectable forever, and we already
have a "blocked" config for that).
Fixes: 563386e8bb
Related: SYS#6481
Change-Id: I263d23885a1a967f844033f9810b96691b8e3b30
In the previous logic, if "keepalive request-interval" was disabled
(value 0, default), then if the client was configured to send a DLCX on
startup it would end up in state UP or DOWN depending on whether the MGW
answered to that request.
As a result, an MGW that wouldn't answer would be left forever in DOWN
state since it would have been selected no more and there would be a
keepalive configured to re-mark it as UP.
Fixes: 563386e8bb
Related: SYS#6481
Change-Id: I290f7436f48418ee25179951359c76208796e279
This way the user ends up picking a working MGW instance instead of one
which is not reachable around the time.
Related: SYS#6481
Change-Id: Ia3f451d3cd97851f65074408812b1ddc68f67056
The `keepalive` feature in libosmo-mgcp-client allows scheduling periodical
queries on the MGCP layer in order to make sure it is reachable and hence
obtain information on the state of the MGCP link.
This patch only uses it to print the status on the VTY, but it will be used
too in a follow-up commit by the MGW Pool when picking an MGW from the pool:
MGWs whose link is considered to be DOWN are skipped.
The feature consists of:
- A `keepalive request-interval` which will trigger a transmission of an MGCP
AuditEndpoint command targeting endpoint with name `keepalive request-endpoint`.
This interval is updated every time any message is transmitted in the MGCP
link, meaning the MGCP AuditEndpoint message is only triggered if no message
has been transmitted since `keepalive request-interval` seconds ago.
- A `keepalive timeout` considering the MGW to be non-reachable (link DOWN) if
no message is received over that amount of time.
The `keepalive` parameters are to be preferrably configured so that
"keepalive request-interval" * 2 < "keepalive timeout".
Example VTY configuration of `keepalive` feature in libosmo-mgcp-client:
----
mgw 0
...
keepalive request-interval 20 <1>
keepalive request-endpoint null <2>
keepalive timeout 50 <3>
----
<1> Transmit an MGCP AuditEndpoint message to the MGW if no message has been
sent to it over last 10 seconds
<2> The MGCP AuditEndpoint targets the `null` endpoint. This is a special
endpoint available at OsmoMGW for those purposes, but any available
endpoint can be configured and used instead.
<3> Consider the MGCP link to be DOWN if no message is received from the
MGW over the last 50 seconds
NOTE: The `keepalive` feature is disabled by default, and must be explicitly
configured in order to enable it.
Related: SYS#6481
Change-Id: I3dc74c78548d017f272da863d5282dc5e0020ca3
This is a special endpoint which can always be audited. This is useful
for clients who wish to submit requests to osmo-mgw periodically to find
out whether the MGW is still reachable. This endpoint will be used by
libomso-mgcp-client as default target endpoint to implement such
feature.
This "null" Endpoint is osmo-mgw specific, not described in MGCP specs.
Related: SYS#6481
Change-Id: Ia409b16e9211e6261e2e0f21288544289d6f3733
This is a preparation commit for follow-up one, where some of these
functions need to be used in other static functions.
Related: SYS#6481
Change-Id: I3a00d8c47ec773390d9626364c4c75ca579f1508
So far, the users of the old non-pooled API were in charge of allocating
the struct mgcp_client_conf by themselves, then init them using
mgcp_client_conf_init(). This causes a major problem, since it makes it
difficult to extend the struct mgcp_client_conf structure to add new
features, which may happen frequently.
The MGW pool API doesn't have this problem, because the struct
mgcp_client_conf is allocated as parts/fields of private structs defined
in internal headers. Only pointers to it are used in public headers.
Since it still has to internally initialize the conf fields, we still
need the API to initialize it internally, and hence why is it marked as
DEPRECTED_OUTSIDE instead of DEPRECATED.
While some programs already moved to the new MGW pool infrastructure,
they still use the old APIs to accomodate for old config files in order
to be back-compatible, hence most users of libosmo-mgcp-client are
affected.
Introduce an API to allocate the conf struct internally, which, while
still breaking the ABI, allows for a more relaxed update path where it's
possible to extend the struct mgcp_client_conf at the end.
Eventually the non pooled API should be gone and the struct
mgcp_client_conf can then be moved to a private header, but for now
let's add this small feature to avoid major ABI breakage.
Change-Id: Iba0853ed099a32cf1dde78c17e1b34343db41cfc
Some payload type numbers are defined in 3GPP TS 48.103, let's put the
spec reference between all of those so that it is immediately clear
where those numbers come from.
Change-Id: Ie9d949ee72286ee4de7590c99acc740011208466
When two codecs are checked for convertibility we insist that
subtype_name and rate are equal since normally when those are different,
we assume a completely different codec that will require a transcoder,
which we do not have yet.
However when IuFP is used, the call agent will always negotiate IuFP as
VND.3GPP.IUFP with a rate of 16000, even though the IuFP payloads
contain regular AMR at a rate of 8000.
This means that if we detect IuFP on one side of the call leg and AMR on
the other side of the call leg, we must not insist on equal subtype_name
and rate.
This fixes the following TTCN3 testcases:
MGCP_Test.TC_two_crcx_mdcx_and_iuup_rtp
MGCP_Test.TC_two_crcx_mdcx_and_iuup_rtp_rfci_unordered
Related: OS#5461
Change-Id: I6bc1e6022efe21cb893ef213f3da35017960357d
When a call leg is set up, then the call agent (e.g. BSC, MSC, etc.)
will also negotiate a codec along with a payload type number. When
sending RTP packets, each RTP packet must also contain the negotiated
payload type number. To prevent the emission of RTP packets with an
incorrect payload type number, ensure that no packet is sent when
mgcp_patch_pt() fails.
Change-Id: I013a24c1e0f853557257368cfab9192d4611aafa
Related: OS#5461
Unfortunately OsmoMGW was never really tested with multiple different
codecs on either side of the connection. While OsmoMSC and OsmoBSC only
assign exactly one codec on each side this has never been a problem,
however it might become a problem when a call agent assigns multiple
codecs on one side. This has been observed in a setup where OsmoMGW had
one leg towards an external call agent. Also due to recent upgrades to
the TTCN3 tests we are now able to simulate different codecs on both
sides to pinpoint issues.
Testing has shown that OsmoMGW has difficulties with multiple codecs.
The reason for this is that the function that makes the codec decision
was not fully finished. So let's finish the codec decision function and
let's also use that decision when patching the payload type of outgoing
RTP packets.
Related: OS#5461
Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
In a follow up patch we intend to fix mgcp_codec_decide, since the
fixed version of mgcp_codec_decide will use some functions below its
current position let's move it down before fixing it to make reviewing
the changes easier.
Related: OS#5461
Change-Id: I2f2538ff912eae4d80d3b74b766e18c4da94d6b6
add_sdp(), add_lco():
- do not msgb_free() within these functions. Just return error, and move
the msgb_free() to the caller.
- when failing to write to the msgb, directly return error.
Change-Id: I904d56f56053952c2ebbbe5dca744fafa32b333e
Check if the private struct mgcp_client_pool has an empty member_list.
Clients that support both the legacy config and the pool config can
use this to properly exit with error if pool members are configured,
but no connection to any of the pool members can be established.
Currently clients can't distinguish a config without pool members and a
config with pool members that is broken and will fall back to using the
defaults of the legacy config in both cases.
Related: OS#5993
Change-Id: I009483ac9dfd6627e414f14d43b89f40ea4644db
in mgcp_codec.c we have a function mgcp_codec_pt_translate that is used
to find the equivalent payload type number on an opposite connection.
This is quite specific and the resulting payload type number may still
belong to a codec that might require some form of conversion.
Lets refactor this so that the function just finds a convertible codec
for a given connection. This also opens up other usecases. The payload
type conversion like we did it before can then be done with a few lines
in mgcp_network.c
Related: OS#5461
Change-Id: I085260a2ca8cfecdb58656b7a046c536189e238d
The function mgcp_codec_pt_translate is very strict when comparing the
codecs to each other to find a matching payload type number to be used
on the egress side.
This poses a problem when one side uses AMR in bandwith-efficient, while
the other side uses AMR in octet-aligned payload type format. To the pt
translate function the difference in the payload format will appear as
if the codec were different and eventually the payload type number
cannot be translated.
since osmo-mgw offers conversion between the payload type format it
would be no problem to ignore the payload type format when making the
translation decision. The only exception here would be if one side would
announce AMR two times, the first time with octet-aligned and the second
time with bandwith-efficient format. Then we would have to use the
payload type number from the exact match. (and skip any formatconversion)
To archive such an optimized decision we will first go through the codec
lists and perform an exact match. If we don't get a match we go through
the codec lists a second time, but this time we ignore the payload
format.
Change-Id: Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d
Related: OS#5461
This reverts commit e0058b7207. The reason
for this revert is that the solution in the reverted patch does not
cover a situation where the other side announces both payload formats at
the same time.
It could be that the end facing to a transit network announces both
formats under two different payload types. In this case no conversion
would be necessary. Depending on the input format the output would be
send to the transit network under the payload type that matches and no
conversion would happen at all.
This revert re-intruduces the problem that was fixed in the patch
before. Therefore it must be merged together with the follow up patch
(Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d) that contains the proper fix.
Change-Id: I0b2854ef2397f38606fab3425be586a3d0ca27d1
Related: OS#5461
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I4bc03bdc1f2de2574558e2ad753e116486993a7f
While adding CSD, this failed for me in add_lco without a descriptive
log message, so add more error messages.
Related: OS#4393
Change-Id: I4873a2db95525aab3e13046b645dd8f90e951466
At the moment we open an E1 timeslot when needed, but we never
close it even when it is not needed anymore. This may block other
entities from using it. Lets add some logic to detect whether the E1
timeslot is still needed and make sure that it is closed when it is no
longer needed.
Depends: libosmo-abis.git I073cfaba0d5073447842f22665e213135ea3f635
Change-Id: Ie6a32abbc5cd984f6d72a384e3b47c1b82ce7058
Related: OS#5198
It is more logical to move the function mgcp_endp_release to the end
since it is used to release the endpoint when it is no longer needed for
any transmission. (Also the follow up patch requires the function to be
moved)
Change-Id: Id3166a6a817ddb9ce36ff1b375ff8ed3598a00c2
Set 120 as payload type, as specified in 3GPP TS 48.103 table 5.4.2.2.1.
Related: OS#4395
Related: https://www.rfc-editor.org/rfc/rfc4040#section-5
Change-Id: I55f9fe241a405935dbedc3947b0a4f4986acd5cb
the comment that explains the AMR frame format check is a bit difficult
to understand, lets rephrase it.
Change-Id: I07f12c03449e1e8eda8bdd3edad6d1007f5ba48d
This is the only user outside libosmo-abis using this define, which
meaning is not clear at all. Let's simply use the related API to clearly
check the FT.
Related: SYS#6161
Change-Id: I40c7ed2e7f6a99a33b467734e33acf3d5befac0d
Before this patch, the free CID with the smallest number was always
selected to be used. This caused more or less the same subset of CIDs to
be used all the time, while the CIDs with bigger numbers were mostly
unused.
Let's distribute the use so that all CIDs are used roughly the same.
This has the advantage, among others, that the same CID will not be
re-used immediatelly after being freed if a new call is established.
It is useful to leave the CIDs unused for some time since the other end
peer may know of the call being tear down with some delay.
Hence if a new call is established immediately after the CID was
released, the same CID would be allocated and passed at the peer, which
would then detect that the old call (in its view still active) would
already make use of that remote CID.
Change-Id: I9dfbcc5e4b4c61ce217020e533d68fbcfa6b9f56
Related: SYS#6161
This sets lowest realtime priority which still takes precedence over any non-realtime service.
Related: OS#5687
Change-Id: Ib1705a164b04b876f129a17c4e8353b9ddcc538e
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: I98a3c0d5cfda2c4b020652efb4f445f8288342b6
For IuUP -> AMR, we log a message like
Convert IuUP -> AMR OA:...
Do the same for the direction AMR -> IuUP.
Related: SYS#5092
Change-Id: I525685a7dedb6d5d1deecbd026844cbe23193fac
The Osmux implementation in libosmo-netif expects to work with RTP AMR
in octet-aligned mode. Therefore, if the peer connection received RTP
AMR in bandwidth-efficient mode, we need to convert it to octet-aligned
before feeding the packets to the osmux layer.
Related: SYS#6161
Change-Id: Ifeec44241079f7a31da12745c92bfdc4fb222f3a
The new prefix now matches other related functions acting on an osmux
connection.
Pass the msgb to it so simplify new msgb copy.
Change-Id: I8c0121485d0c96f70fe8bcbdb150793d428183ff
The previous name is misleading since the function is not really sending
stuff over a socket, but rather handling/dispatching the incoming
message internally (and finally later it may be sent over a socket under
some conditions).
Change-Id: Idaf791997b8438a4aede50f614afa0d55ad41faa
First validate the origin of the message, then later the content
of the message and finally execute whatever triggers are necessary.
This way contents from unknown senders are not even parsed or acted
upon, avoiding useless potential harm.
Change-Id: I011a6d7d705768c32a35cec5cd7169725a21a670
The previous naming was quite confusing, since the function is not
really checking whether a conversion is needed, but rather whether the
codec has the AMR RTP mode defined explicitly and hence forced.
The previous naming didn't harm because the amr_oa_bwe_convert also
supports the conversion path OA<->OA and BE<->BE.
Hence nowadays the amr_oa_bwe_convert() function is called always if the
dst conn has its codec with AMR RTP mode explicitly set, no matter if
the src and dst conn have the same mode.
Related: SYS#6161
Change-Id: I8dce3038ebccf5e1e37e2908070a67d66693a96f
Enhance the existing log message
Convert IuUP -> AMR:...
to
Convert IuUP -> AMR OA:...
(or BE) to show wether emitting Octet-Aligned or Bandwidth-Efficient.
Related: SYS#5092
Change-Id: I3672d01d2879ae8820176a46454f26a4f5f584de
When converting IuUP to AMR/RTP, bridge_iuup_to_rtp_peer() sets the AMR
side's payload type number and then calls mgcp_send(). In mgcp_send(),
do not attempt to patch the payload type number a second time.
In mgcp_send(), skip patching payload type numbers if the source side is
IuUP. This matches exactly the case of converting IuUP to AMR/RTP.
There already is a check for IuUP, but for the wrong side. Drop that one
and explain in a comment why.
Move the comment about transcoding into the failure branch, where it is
relevant and doesn't clutter the new explanation of payload type
patching conditions.
Related: OS#5720
Related: SYS#5092
Change-Id: I7c722cd959f76bd104ae4941d182c77e5c025867
Fix the reversed logic when composing IuUP.FQC:
AMR.Q == 1 means the frame is good.
Without this fix, all frames on IuUP are marked as bad, and no voice is
heard on the IuUP side.
Related: SYS#5092
Change-Id: I29878dd27af9ba0c9e600324c528b22940cdcc30
When translating AMR to IuUP, when AMR data arrives before the IuUP side
has negotiated an IuUP Initialization, do not crash osmo-mgw, but return
failure and drop the AMR packet.
As soon as IuUP Initialization occured and RFCIs are defined, the AMR
starts to pass through to the IuUP side.
Related: SYS#5092
Change-Id: Id9efb7e523d8d9af988e4bf4f5e925839204f934
Recent commit dropped the 'mgw ' prefix in commands under the "mgw" VTY
node because it was redundant.
However, for old apps still not supporting the 'mgw' node, the commands
are still printed in another node and hence the 'mgw ' prefix must still
be appeneded to them, to avoid breaking backward compatibility.
Related: SYS#5987
Fixes: 8c138fe89c
Change-Id: Ifbfb71f8864b425c1b842cdee241ce279d17a8ba
Move the regular writing logic to a subfunction, and raise the flag only
on one of them.
This simplifies the code paths but not marking stuff true and false over
the same code path.
Change-Id: I070798863f2bdc253df004a63262d4bcd529348f
That command was already deprecated when the new commands without the
"mgw" prefix were dropped, so there was no need to create a new command
for it (since it shouldn't be used and it's currently implemented as a
NOOP).
However, the recent patch moved the install line out of the common
function, which meant the command was not available anymore on the old
node, and as a result old config files using it would fail to be parsed.
This commit moves the command back to the common function so that it is
still available for config files using the old node.
Related: SYS#5987
Fixes: 8c138fe89c
Change-Id: I800abcc9869ed097a9d28715269c42552f5aaf29
Previous existing ones are left marked as deprecated, to avoid breakage
with older configs.
Related: SYS#5987
Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
It is not a good idea to use a personal write_config function for the
MGW node, since it's not meant to be a 1st level (top) node.
During write-config the node function will be called at an
implementation specific time (based on the order defined by the app in
the node type enum), so there's no real way to control that the output
of the MGW node will end up under the parent configured in
mgcp_client_pool_vty_init(). As mentioned the order can be tweaked based
on how the node enums are configured, installed, etc. but that's really
a nightmare, so let's better not rely on that.
Therefore, this patch introduces a new API which the users (apps such as
OsmoBSc and OsmoMSC) can use to write the config at the required time
(when writing its own parent node).
A hack is introduced internally to detect older versions of the users
which didn't call this function to still print stuff (up to to the app
if the order is correct).
Related: SYS#5987
Change-Id: I7a620cf47886d8ecab30ce369cf123d98ab842c5
If the user (app) already supports the MGW Pool VTY command set
(mgcp_client_pool_vty_init() was called), then if single MGW mode is in
use it's because the config file was not updated to use the new MGW Pool
node. Let's convert it to the new format to help in transitioning to the
new VTY command set.
Related: SYS#5987
Change-Id: I2f6658cc66f8bcbd4a60ee2b932bb5dd65888233
Deprecate mgcp_client_connect2() and all the related messy system where
configured port is incremented until a free port is found.
Let's simply use local_port=0 by default and let the kernel take care of
doing all that.
The mgcp_client_connect2() is actually not being used anywhere outside
of libosmo-mgcp-client, so it's not a real problem deprecating it. We
could poitentially remove it too.
This helps in fixing a regression in recent refactoring commit
f48cd95bbc, which unified calls to
mgcp_client_connect() and in the process dropped the code path which was
setting the retry_n_ports=99.
As a result, since all libosmo-mgcp-client instances set local_port=2727
and addr=NULL by default, using MGW pooling or having several osmo-bsc
or osmo-msc processes would make creating the socket fail.
Change-Id: I5683bcf3b2c4e8058338433f2cd1b143753f6512
Let's advise all our users to migrate to the new pooled mode, the old
VTY interface should be dropped at some point to avoid making it
overcomplex to configure MGW. There's no need to maintain the same set
of commands under 2 different places.
Change-Id: I95f717a0fcd3c4ca622e3989baa28fac1f7ec1ca
Fix for:
[ 34s] In file included from vty.c:22:
[ 34s] /usr/include/osmocom/mgcp_client/mgcp_client_pool.h:18:1: error: unknown type name 'bool'; did you mean '_Bool'?
[ 34s] bool mgcp_client_pool_member_is_blocked(const struct mgcp_client_pool_member *pool_member);
Related: https://obs.osmocom.org/package/live_build_log/osmocom:master/osmo-bsc-nat/CentOS_8/x86_64
Change-Id: Ic3773f49160cbb8c6f53c4f0e17b897017dec98a
This will be used by osmo-bsc to implement MGW-pinning for specific BTS.
This is useful for instance to keep all BTS connections targeting the
same MGW in order to make use of Osmux trunking optimizations (AMR
payload of different calls filling same underlaying UDP packet).
Related: SYS#5987
Change-Id: I75ce3e04cd3f6d9cc20d7b4fc0f51083780786c8
Let's properly store backpointers so that it is easy to access all
relation chain (pool<->pool_member<->mgcp_client).
Related: SYS#5987
Change-Id: I5ec2465075da2e3c8eabca9df60681620a7db499
Move mgcp_client_pool up in the file as a preparation for next commit,
where pool_member will have a pointer to the pool added.
The related APIs on the object are also moved up in the file.
Change-Id: I9ff9c6e1e722690835c5d59b1fa87fb7d9e3120c
The second parameter of mgcp_client_pool_member_reinit_client() will be
removed in a follow-up patch after further refactoring.
Related: SYS#5987
Change-Id: I0ab59278629c0e7e7c62a68b54b4235df58a5d77
Having a list named pool inside an object already named pool is quite
confusing. Let's rename the field so that it makes sense immediatelly
when looking at it.
Change-Id: I4062af6b619317c48223ad4577eaaad05d4eec9d
* Move all of them to an anonymous "osmux" substruct to have them all
together.
* Rename some fields to clarify its meanings, similar to what
was already done in osmo-bts.
* Move the port VTY config next to the ip address ones.
Change-Id: Icc1c1ce3ab3a8beb941cda7c112485a0db882a90
It's basically the same code path (one function calls the other), but it
makes a lot more sense to have it in the init function itself.
Change-Id: I63d7dfff451870f708f7cb710d66f4ec786c27d7
Parameters passed to several functions are rearrange to make code
simplier to follow, as well as dependencies between the different
functions. As a result, some parameters can be marked as const while
doing the change.
Change-Id: Idebd4a66630c16548f557632a54d6b7e1b3906fd
It's checked in all code paths being called, which makes sense since
it's impossible to send anything if the remote address is not set. Let's
check it once in a unique to simplify the code.
Change-Id: I224dbfeda17c364b85166268e2ac1e019a87edb6
A new osmux bind-ip-v6 VTY command is added, similar to what's already
available for RTP. This way the user can decide whether to support IPv4,
IPv6 or both types of IP versions.
Both IP sockets are by default disabled, and must be explicitly enabled
by setting the bind-ip in the VTY configuration.
Change-Id: I446cd7da217e9f4a74995d7784ae55dcc60a29b7
Since recently the port is guaranteed to be placed at
CRCX/MDCX in the sockaddr, hence we can check it using the API instead
of checking manually only for the address part.
In osmux_send_dummy() we actually fix a bug where an in_addr was being
compared against a struct sockaddr.
Change-Id: I736e7f4c51e577d8eb0b96bc776f984f928b6d27
Let's use the port part of the struct mgcp_rtp_end->addr field instead
of keeping it separate. This makes it easier passing around and
using/checking the RTP remote address + port, and avoids confusion
having to check stuff outside of the address, with its port part
potentially unset.
Change-Id: I294eb5d85fae79bf62d36eb9e818426e187d442c
A commit refactored this code around one year ago, which broke osmux
detection of dummy messages. This commit partially reverts the earlier
commit and rearranges the existing code to make it more robust.
Fixes: b3d14eb552
Change-Id: Iedf085932c45af5d13e04e56a4cd1082de81d869
There's no need to separate between BSS and CN side nowadays, the
different types are used nowehere. This separation dates from
osmo-bsc-nat code days.
Change-Id: I65effeddf033eb1955553e8d659c593b4e67f7bc
Documentation of rtp_bridge_cb was outdated, and caused confusion when
adding initial osmux support. Let's clear all the mess.
Change-Id: I42d1f2e2919eae3b1555ca4929e571855960792e
This way we have no more access to internal osmux structures.
Moreover, we already have similar information in our rate_ctrs, so
there's no need to print those there.
Change-Id: I853e118f843070ea29b19e1b0fe56b52f267437a
Receiving an unknown CID (for which we don't have an active conn) is
totally expected at the end of the call, were some messages from the
peer may be send for a while, specially if latency is high.
If this occurs, we simply drop that batch and keep decoding the osmux
message in order to keep delivering content to other circuits.
Related: SYS#5987
Change-Id: I315949853bdcc07bef15d2e8579029cc72c427cf
This is actually quite common, since our peer may be sending some osmux
packets to us a while after we have closed the conn on our side,
specially if latency is high in the network (eg satellite links).
Related: SYS#5987
Change-Id: Idffd91b68d1f98ac906d78e7fbc0e6eaa1962f9e
Let's not delay allocation of rate counters until the osmux conn is
fully enabled, since we may want to count stuff before that point in
time.
Fixes crash accessing null conn->osmux.ctrg in
MGCP_Test.TC_two_crcx_and_rtp_osmux_bidir.
Change-Id: Ic31d3567f4d24e628f8983d8362e5c7c2f66ec02
During development of the counters, they were first added to the same
RTP counter group and later on split, but some places still used the
RTP related functions to increment the counters.
Let's add a seaprate set of helpers to update the correct osmux counter
group.
Fixes: 582c2bf7b0
Change-Id: Ia2e5601c7d476b79afd95032dbc019517f8209af
So far the implementation only allowed the remote CID being the same as
the one dynamically implemented internally.
Related: SYS#6138
Change-Id: I6b03eabc0305580c9788c529bec7dda9044a008f
This makes all lines operating on rate groups way shorter. The "ctrg"
naming is already used in tons of places in osmocom code.
Change-Id: I745eddbf66e7d811bb73c8ae9bb54ea93073c71b
struct osmux_handle, which is shared by several rtp_conn, is
attached to the trunk object, since the socket also attaches to it.
Related: SYS#5987
Change-Id: If4980424cdb8e3dc26a23e9ee419c0a38912f38f
It makes sense to handle one osmux socket per trunk. Since we only so
far operate one RTP/osmux trunk, let's stick to that only one for
simplicity.
Change-Id: I173266c4058d5db9479d773d7dec1304bc8f1f99
The struct osmux_handle is a shared structure which goes together 1-1
with libosmo-netif's struct osmux_in_handle, which is common to all CIDs
to be muxed together. Hence, it makes no sense to store a specific conn
object to it, since it actually manages several of them. Hence, all the
conn specific stuff must be handled beforehand, not at osmux deliver
time.
Related: SYS#5987
Change-Id: Ie739b556e9eb7d3133e798831a09728c7cc87135
This cleans up all the code, and makes it a lot easier to add IPv6 support
later on (mostly only a matter of adding an IPv6 bind address in VTY).
Similar changes were done to the Osmux code being added to osmo-bts.
Related: SYS#5987
Change-Id: I5a100fc654f88d29b2bcd85889a5a92aef3d576d
The local Osmux IP address (cfg->osmux_addr) was never applied in
generated MGCP messages. Instead, the RTP one was written into the
MGCP message.
Related: SYS#5987
Change-Id: I305f2501221e86d1eb0140446c03f36698f3194a
This way we don't need to worry about implementation details (struct
size) in the future in case they change (they will).
Related: OS#5987
Requires: libosmo-netif.git Change-Id Ie8df581f375c9a183a7af60b431561bda82f6e34
Change-Id: I2d0d8c152b8f1234ddfcd74d6cb04b1818b41510
By default systemd will execute service with root directory (or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I7696cd92953787591e7b4777ee79c2671326b972
Since libosmocore.git Change-Id
I5cb740702805693cc7f0a550e2e093f9bfdd507c, the IuUP stack can send INIT
event more than once, it sends one each time an IuUP Initialization
message is received.
This is done since potentially a peer could send an Initialization
message at any time with a different subflow size configuration. So
ideally we should update all osmo-mgw state regarding codecs, and
forward the Init starting the procedure on the other conn of the
endpoint.
However, this scenario is most probably not going to happen right now
and it would be a lot of work to implement and test,
and subsequent INITs we received will almost surely come from
retransmissions of the initial Initialization message, which means
content will not really change.
Hence, it makes sense to simply drop the receive message (the IuUP stack
already takes care of re-ACKing it) and let the endpoint state continue
with its ongoing procedures.
Related: SYS#4705
Change-Id: Ib97bc6f57d265622e24a776b96f0a82c25d33d39
The initially merged IuUP API and implementation in libosmocore 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 implies an API change when using libosmogsm.
However, the previous API was never available in any libosmogsm release,
and only available in both libosmogsm and osmo-mgw master, so we are
only breaking compatibility between different master versions, which is
acceptable.
Related: SYS#5969
Depends: libosmocore.git Change-Id Ib21cee2e30bf83dff4e167f79541796007af9845
Change-Id: I40ebf36ad37f5196751caf2297a340e538ad28bc
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I938669a78b4afa808ca4f741aee9919944aeb7f6
Make sure that RTCP packets do not enter the code path where AMR OA and BWE
is converted. The conversion will fail and the RTCP packet will be
dropped.
Change-Id: Ic850344d8b5f7710d12e4553a4033b733dced52b
Related: SYS#5902
AMR that has the payload format bandwith-efficient is the same codec as
AMR that has the payload format octet-aligned. Its the same codec, and a
comparison of the codec info with the function codecs_same() should
return true (=equal).
The affected function codecs_same() is used by mgcp_codec_pt_translate().
When the egress payload type number is looked up, the ingress and egress
codec information is compared. When one end is using AMR in
bandwith-efficient format and the other end is using it in
octet-alingned format. Then the codec still must be recognized as the
same codec. Othersiwse the payload type number translation would not
work, even though the codec is the same on both sides.
Change-Id: I64731570c287a75d39c79c10e1bc09a37bdd54d6
Related: SYS#5834
3GPP TS 25.414 5.1.3.3.1.6 specifies that IuUP can use RTP as transport.
The payload type is specified from 96-127, which shall be ignored on the
receiving end anyway.
The payload type number we use shall be 96 by default.
Change-Id: Ifd1210a897743396899f34457c96e6fd2109c6b3
Related: SYS#5152
Using "payload" there is misleading, the proper naming is payload type,
a well known term for RTP.
Change-Id: Ifcad63b0ba5068acd555960c71c3ad1489a2b870
Discovered while debugging wireshark CRC calculation and implementing
new IuUP code in libosmocore.
Change-Id: Ic8350d1f9a9e5dcefeb787462d267bfac08d778f
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: I2a623f67e116d5e56091ae5860ca2a305c57e50a
When configuring osmo-mgw the user may choose an arbitrary trunk number
for the E1 trunk and sets a line number that must match the number of
the physical line that is used with the particular trunk. This is easy
to confuse, so lets add a note to the maual that mekes this clear.
Change-Id: I4b647a60d21cae99663a8258d6636ec8a7609d97
Related OS#5308
Change-Id: Ide27fda6d9ee2627bb544d21aa65161eace35a34
We don't really care about the kernel style after all and the linter
complains about proper formatting, so remove all for-like macros so
we don't accidentally apply kernel style formatting.
Change-Id: Ia1b5848b31470b694a2031ad83e84f3132212f94
Not entirely wait-free: allows waiting on a fd, and in general fd
notifications for poll-loop integration between threads.
Change-Id: I4f17042baf76d086ce6b20eb99402dc64c22c657
This was previously broken and a free endpoint was requirted to dlcx *,
additionaly globally handling this is difficult due to different
response
codes, so just do it in the functions, they know best.
Change-Id: I8cbbe5936067ea1caa7935e8d14908ac5c4010bd
Do not turn some compiler warnings into errors by default. This patch
was added before --enable-werror was available.
We build with --enable-werror during development and in CI. If the code
is built with a different compiler that throws additional warnings, it
should not stop the build.
This reverts commit 34f012639d.
Related: OS#5289
Change-Id: I6042f917a5a891dd13cb96d9477a45a45a7b35fe
There is no obvious reason why we would want to complicate the code by
caching pointers, since pointer traversal is probably not a performance
bottleneck, and if it is we should rather take a look at our dozens of
linked lists first..
Change-Id: I2456ba63598f76200d53e00223abf60bb36a49c0
Usually only one MGCP client per application is present. Then the log
lines from mgcp_client.c will be distinguishable without additional
information. When the application is using a pool of MGWs, then the
various MGCP Client instances become hard to distinguish.
- Add a possibility to set a description (name) for each MGW pool
member. When no description is set, use the domain name.
- Output the pool member name on each log line in mgcp_client.c
and mgcp_client_pool.c
Change-Id: I53ff5445c8e5faffa4ef908ffb1fdb1f47ea2904
Related: SYS#5091
there is no obvious reason why the endpoints that belong to a trunk would
have the (global) config as parent context, you can't really have endpoints
without a trunk anyway.
Change-Id: Id3d5fefc12b7d442c09c507b3a8b0231e46e3068
They are mostly not even as large as the talloc header used to
dynamically allocate them, and they are also not "shared" by anything.
Change-Id: I7b46d531c5d3b53984f2ce44538116973f6a074d
Trunk is safe, since it will not disappear sooner than the endpoints or
connections.
osmux still missing!
Change-Id: I15b01085f31e9a10a1ad381713ca2275356ca20c
No need to complicate audio codes with pointers, our "usual" string is
barely larger than a poointer, five times smaller than a talloc header,
and most importantly not really optional anyway...
Change-Id: Icc41643050a5e1ca3c66f307d60b6911ba1b8032
The test expects wrapping here, but the undefined sanitizer is not happy
with that, so disable it.
Change-Id: I59ec65519ea028d4628ba4b56c939aef70794abf
Clang and gcc have different names for this, but the check fails without
-Werror since clang only warns about unknown args.
The previous check led to a lot of "unknown arg" spam while compiling
with clang.
Change-Id: Iad6c16beed26d5fe8952d7d5a79a93845c391b48
The change I19f67db1c56473f47338b56114f6bbae8981d067 removes the
policy_cb and change_cb callback funtions, but it does not remove
the related ratecounters.
Change-Id: I53aa3c890555055466e86b09a359375a10d3be7b
The docstring in the VTY command that is used to remove MGCP client
instances lacks the NO_STR constant.
Change-Id: I53f3e763a77ed8be78c5a51b1472f4b70bade9d4
Related: SYS#5091
The interactive VTY commands to reconnect, block and unblock MGCP
clients from the pool are not displayed properly because the doctring
lacks the reference number.
Change-Id: I0367c33f5cd02978e3f14b1343dfaafa1ea62370
Related: SYS#5091
When the function mgcp_client_pool_vty_init is called with pool = NULL,
then it segfaults. Lets put an OSMO_ASSERT() on pool to make clear that
a pool must be present before initalizing the VTY on it.
Change-Id: I36893bf5341d4ad21161e92d2d25d284647f7d18
At the moment the MGCP Client only supports one MGW per application.
Depending on the requirements of the application one MGW might not offer
the performance needed. Lets add support for an MGCP Client pool that is
backward compatible to existing applications.
Change-Id: Icaaba0e470e916eefddfee750b83f5f65291a6b0
Related: SYS#5091
The function init_socket has an arbitrary retry count when opening the
socket. After each retry the local port is incremented by one. The
intention behind this is to find a useable local port in case the
configured port is used by another process.
The maximum number of retrys is hardcoded. The upcomming MGW pooling
patch requires to set the maximum retry count.
Change-Id: Ifd65511daa92fbe610f52da1c4c3b6a7c761d890
Related: SYS#5091
When the address is set to ANY, the address string is NULL. The log then
prints "(null)" where the address normaly would be. This looks odd, lets
print "(any)" instead.
Change-Id: I2ea138827ee5b9f40d352bf594364ee930520609
The vty always checks if global_mgcp_client_conf exists. (there is also
an assert This check about global_mgcp_client_ctx).
global_mgcp_client_ctx and global_mgcp_client_conf are populated before
the VTY commands are installed. Unleass the caller uses the API wrong
and calls mgcp_client_vty_init with NULL pointers there cannot be a
problem with unpopulated pointers. Lets remove the checks as they are
not needed.
Change-Id: I892d14c588573f76640453cb9c194594289b59f1
Related: SYS#5091
Depending on the usecase of osmo_mpcg_client it may be helpful to send a
DLCX to certain endpoints. Usually this would be a wildcarded endpoint
that resets the entire trunk to drop lingering RTP flows which may still
present after a restart/crash, but it might be also a group of specific
endpoints. The user may specify an arbitrary amount of endpoints where
the mgcp client will send a DLCX to. It does not matter if the endpoints
are wildcarded or not.
Change-Id: I47e7ff858d5067b46d52329be5f362ff61c0dff8
Related: SYS#5535
The rate counter and stats item groups, which are allocated in
mgcp_ratectr.c are freed using a talloc destructor that is set in the
context of the item we just allocated using the stats / rate counter API
functions. When we do that, we risk overwriting an already existing
talloc destructor. Lets instead implement own free functions and set
those as talloc_destructor from above (trunk and MGCP config)
Change-Id: Ifc5091e9f95cc721e58d1eb2e55b97102c497706
Related: OS#5201
The two callback functions policy_cb and change_cb are essentially dead
code. They also make the code more difficult to read and understand.
Lets remove them.
Change-Id: I19f67db1c56473f47338b56114f6bbae8981d067
We are currently counting events in rate counters, but there is
currently no way to get a sample of the current situation of the trunk
usage. In particular how many endpoints are currently in use.
This is a corrected version of:
Ib7b654168dc3512f55e45cc4755dc1f6f423d023
Change-Id: I6d3a74f6087512130d85002348787bffc672de81
Related: SYS#5201
The MGW domain name is usually checked while resolving the endpoint
after the trunk has been resolved. This was no problem before, but since
we allow wildcarded DLCX requests, which require only a trunk to work,
the check is not done correctly for wildcarded DLCX requests and invalid
domain names may slip through.
Checking the domain name earlier while the trunk is resolved makes sense
and it fixes the problem.
Change-Id: I9944a9103981fb5f4d0d8714ee2847ae020f76df
The logic when an endp pointer is guranteed and when we are able to
process the request without the endp pointer populated is qute complex.
This shows up as a bug to coverity.
Change-Id: I1d4221f2df13c43321d5466534485cf21f0d9010
Fixes: CID#237088
The request handler handle_delete_con currently rejects wildcarded DLCX
requests even though a wildcarded DLCX would be a valuable tool to
remove lingering connections from the trunk in case osmo-bsc has to be
restarted.
Change-Id: I5c2de6b2b61ee64ba9c0618fd20e8fc2fe6a5ed3
Related: SYS#5535
This reverts commit 6bad138c96.
Reason for revert: heap-use-after-free during 'make check'
in mgcp_test.c test_retransmission()
Change-Id: I96792a719c9c7273676ab9ffe0b9e2aae4c23166
Related: OS#5201
The function create_response_with_sdp calls add_params, which is rather short.
The code in there can also be put in create_response_with_sdp. The
decision whether the endpoint name (Z) should be added or not, should be
made by the caller.
Change-Id: I7e29c513f4386832646e96194ed6c2397405ed3b
Related: SYS#5535
There is not always an endp pointer present when mgcp_check_param() is
called but we always have a trunk pointer. Lets add a trunk parameter so
that the function can pick LOGPTRUNK when endp is not available.
Change-Id: I7327c5a105e7f0e20cabf64623ff9f36fd83bbb8
Related: SYS#5535
We are currently counting events in rate counters, but there is
currently no way to get a sample of the current situation of the trunk
usage. In particular how many endpoints are currently in use.
Change-Id: Ib7b654168dc3512f55e45cc4755dc1f6f423d023
Related: SYS#5535
At the moment the MGCP request handling and message parsing is not
clearly separated. The function mgcp_parse_header() in mgcp_msg.c is
also responsible for resolving an endpoint. This leads to unclear layer
separation. We eventually end up in a situation where we can not execute
any request handler without beeing able to resolve an endpoint, however
this is necessary if we want to implement wildcarded DLCX resquests.
In the current situation a wildcarded DLCX is not possible to implement
as we always have to resolve a an to get to the trunk which we need to
iterate. However, we just can't resolve a free endpoint in a situation
where all endpoints on te trunk are in use.
We have to refactor the request handler so that the parsing in mgcp_msg
only extracts us the endpoint name. The resolving is then done in
mgcp_handle_message() in mgcp_protocol.c. Then we are able to decide
what to do if we are unable to resolve an endpoint but still be able to
resolve the trunk.
This patch does not change the behaviour of osmo-mgw yet, but it lays
the foundation for request handler implementations that can still
perform useful actions if no endpoint but a trunk has been resolved. A
wilcarded DLCX is such a case. It does not need an endpoint, just the
trunk.
Change-Id: I9f519d8a0ee8a513fa1e74acf3ee7dbc0991cdde
Related: SYS#5535
the trunk_nr is in struct mgcp_trunk. The trunk number can not be
negative and there is no magic value that makes use of the fact that it
could be negative. Lets use unsigned int to make this less irretating.
Change-Id: I5d0e1d76adb8c92d84331a0aca2496908e41d621
Related: SYS#5535
the various types of MGCP requests are implemented in request handlers
functions. The function pointers to those functions are held in an array
that is used to find the right handler and call it then. The struct used
to model the array is defined somewhat away from the array definition
and there is also a macro in between that does not help to make the code
more understandable. Lets refactor this a bit to have it more distinct.
Change-Id: I2ef167b2ac179d2b0683a27a095f9662fda460bf
Related: SYS#5535
There is verbose debug logging on MGCP messages sent out to the MGW, but
none on received MGCP messages. Add Rx logging.
Related: SYS#5529
Change-Id: Id76230896aa87c1a12bd5ad87a62430c048a2873
To see state transitions and events on LMGCP DEBUG logging, actually set
the log_subsys of the mgcp_client_fsm.
Related: SYS#5529
Change-Id: I6e84d5f7b85752a7a54f17be1d074b01d1467f26
When the mgcp_client_endpoint_fsm terminates, do not directly pull each
conn FSM instance (mgcp_client_fsm) into oblivion as well. Those should
emit a DLCX and wait for the "OK" response before deallocating.
In programs using the mgcp client endpoint FSM (osmo-bsc, osmo-msc),
this gets rid of false LMGCP ERROR logging related to DLCX like this:
Cannot find matching MGCP transaction for trans_id 71998
Related: SYS#5529
Change-Id: I8fbfec5533e9be9cc7ea550df1e6639a0a215973
Upon mgcp_conn_delete(), we unparent the FSM instance. Instead of
setting the talloc ctx to NULL, place the deleting conn under the
struct mgcp_client talloc ctx.
Related: SYS#5529
Change-Id: Ia12749e0d7d520f24a967c2df9a4651267e1019e
osmo-mgw currently does only a very simple detection method for
wildcarded requests, but it makes sense to split this detection
off into a separate function so that it can be used from different code
locations and we still have it at one place only.
Change-Id: I27018c01afb8acabfcf5d435c996cc9806e52d6b
Related: SYS#5535
The function mgcp_rtp_end_config() takes an mgcp_endpoint as
parameter. The header file does not declare the mgcp_endp struct
and it also does not include mgcp_endp.h because that also would
cause problems. Since the endp parameter in mgcp_rtp_end_config()
is only a pointer we can simply forward declare it.
This patch will currently not change anythig, but it will prevent
compiler warnings when we remove the endp pointer from
struct mgcp_parse_data in a follow up patch
Related: SYS#5535
Change-Id: I07a4d6f9d5334b1f4cf4b262482b8a67b1384398
The rate counter group is currently only referenced by an index. In a
system with multiple trunks this makes it difficult to say which rate
counter group belongs to which trunk sinde the index that is used does
not necessarly corespond to a specific trunk.
Since rate counter groups can now get a human readable name assigned, we
should do that.
Also E1 specific rate counters only make sense for E1-trunks, so they
should not be present on the virtual trunk.
Change-Id: I5e7f0e9081a06af48e284afa5c36a095b2847704
The braces as put before this patch would read as {"is known", "is not
yet known"}, which is confusing the actual situation.
Change-Id: Icd1f22a9f4147a2758c2f068ecba46cf7f732604
The loop that resets all endpoints in read_call_agent() starts counting
at endpoint index 1, but it should begin counting at index 0
Change-Id: I82a385e547e54d82eff95213652317ed2fdaadd8
The logic in mgcp_keepalive_timer_cb() only sends dummy packets for
endpoints 1-N, leaving out endpoint 0, this is not correct it should
include all endpoints (0-N).
Change-Id: I99a9b572eac26780bc1286a8dd63c4c5652fda4f
On a deployed osmo-mgw with RTP traffic coming from a thirdparty
RTP source, it was usual to see log messages like following one from
time to time:
"The input timestamp has an alignment error of 159 on SSRC"
Doing a quick traffic analysis showed that the above mentioned RTP
source was generating traffic from time to time containing RTP packets
with the Marker (M) bit.
Those messages were logged because the verification & patching funcions
in osmo-mgw were not Marker-bit aware. Hence, this patch implements
support for Marker bit when handling RTP packets.
The Marker bit is usually used as a start of a talkspurt, and has to be
considered a syncrhonization point, where timestamp and relation to real
time don't need to match with last received RTP packet in the stream.
Related: SYS#5498
Change-Id: I1fb449eda49e82607649122b9b9d983a9e5983fa
use the recently new available API to check both remote address and
port, instead of only the port.
It doesn't make sense to configure a conn as sendrecv if we have no IP
address to send stuff to, similar to what was already being checked with
the port.
Change-Id: I6ce8cf52930d423d3db8c27251be8350a26a4ede
The following sequence of events was seen frequently in a osmo-mgw
instance running on the field with heavy traffic:
"""
endpoint:rtpbridge/1@mgw CRCX: creating new connection ...
mgcp_network.c:236 endpoint:rtpbridge/1@mgw CI:1C8CCFA9 Failed to send dummy RTP packet.
"""
Allegedly, that happens because at CRCX time the remote address may
still not be known, hence we end up trying to send a dummy rtp packet
to, for instance, host 0.0.0.0 port 0, which will of course fail.
Let's avoid sending it if the address is not yet known.
Similary, same issue could be seen during MDCX, since at MDCX we don't
necessarily need to have a valid addr+port (there could be several MDCX
and only last one set it).
Finally, the keepalive timer also needs the check, since it iterates
over all connections, and it could be that some is still not fully
configured.
Related: SYS#5498
Change-Id: I8ceafda691146823b12232b4a804b4ce74acbdc8
Several log messages showing "Failed to send dummy RTP packet." were
seen in a osmo-mgw on the field. Let's re-use the function to check and
provide more information on what's wrong to ease debugging.
Related: SYS#5498
Change-Id: Iee6ac1f4d24c131e3bf40c37e6fdc252e5208ec8
This is a preparation for next commit, where one of the function will
require an static function available before it in the file.
Moving the functions also make sense, in order to have the 3 mgcp send
functions together for more easy understanding.
This commit does small style changes to fix followint linter errors:
"""
src/libosmo-mgcp/mgcp_network.c:1036: ERROR:SPACING: space required after that ',' (ctx:VxV)
src/libosmo-mgcp/mgcp_network.c:1091: WARNING:BRACES: braces {} are not necessary for any arm of this statement
src/libosmo-mgcp/mgcp_network.c:1145: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
src/libosmo-mgcp/mgcp_network.c:1163: ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
src/libosmo-mgcp/mgcp_network.c:1204: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
src/libosmo-mgcp/mgcp_network.c:1226: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
"""
Change-Id: Iff8dab942182a0d909519acddb86be75d9cda7ae
The functions add_lco and add_sdp assert when the codec string can not
be generated. This is the case when an unexpected codec is addressed in
the input parameter mgcp_msg for mgcp_msg_gen(). Even though the API
user is expected only to use the codec identifiers in mgcp_client.h the
check should not be done with an assert. Instead mgcp_msg_gen() should
just return NULL imediately.
Also all generation functions should not use magic numbers as return
codes. Instead constants from errno.h should be used. It is also
problematic that the return codes from msgb_printf are added up.
Depending. It makes more sense to use an OR operator since msgb_printf
only returns 0 or -EINVAL, so the end result will be -EINVAL if one or
more msgb_printf fail and not just a random negative value.
Change-Id: Ibb788343e0bec9c0eaf33e6e4727d4d36c100017
Related: OS#5119
The constant MGCP_DUMMY_LOAD is used ambigously. Sometimes it is used as
initalizer for an array, sometimes it is used as a single byte. Also the
name is not very expressive. Lets refactor this.
Change-Id: I21d96cefeeb647958bfa1e22a0ea030884746fad
Related: OS#4005
Generated with spatch with this and similat snippets:
"""
@@
expression E1, E2;
@@
- &E2->ctr[E1]
+ rate_c
Change-Id: I53b75ea8a88bc1ae4ceb479ed272865054de9665
When mgcp_udp_send() is called, the memory where *buf is pointing to is
never modified. It should be marked as const.
Change-Id: Iac90de5beb19bf52586ac6ffeab9eb5152edf339
So far an mgcp_client user can get the RTP address+port information that
the MGW has returned upon a CRCX. Add this function to return the other
RTP end, i.e. address+port that the MGW was told to send RTP to.
This will be used to fix the MGCP in osmo-bsc, which so far mixes up the
two RTP ends and compares the MSC's RTP address+port with the MGW's one
and hence fails to skip unnecessary MDCX.
Change-Id: Ibb488925827d9dc0ccb1f8d6d84728745d086793
A call agent may send a CRCX to create a connection in LOOPBACK mode but
without specifiying the destination address. In those cases the MGW
should deduct the destination address from the first incoming RTP
packet.
Unfortunately this is currently blocked by an OSMO_ASSERT that checks the
current sa_familiy against the sa_family from the incoming packet. This
makes no sense since the current sa_family is still uninitalized, which
is expected and not an error since the code that follows will initalize
it.
It also makes sense not to access the osmo_sockaddr struct members
individually but rather copy the address as a wohle.
Since the event only happens once and since it is also somewhat special
it makes sense to log the event as well.
Change-Id: I2dbd6f62170a7f62e5287d04a4ee6716b8786c26
Related: OS#5123
Sending a DLCX upon FSM cleanup is not unusual. Move the log about that
DLCX to INFO, and also print the endpoint and conn identifier.
Change-Id: Id723d949f101b66fb75296d01489d9dac350c7c8
If the mgcp_client_fsm gets terminated in ST_DLCX_RESP, it has already
sent a DLCX to the MGW. So do not send a second one.
I noticed the duplicate DLCX for the same endpoint conn identifier while
running TTCN3 tests and watching the network trace of test teardown.
Change-Id: I35e415f67946b73c74408afe265618cfe4f72b0b
With just one E1 line, the 'show mgcp' command outputs
several hundred lines to the vty. Add a 'active' parameter to
only show endpoints that are active.
Change-Id: I23a26b4fdc03d8b2469d293dd6c06ed83ce739e9
This is useful for affecting the 802.1Q PCP value without any separate
external packet filter rules for classification.
Change-Id: I69136c6dd114c24b1dace034e75dba5157bac37e
Depends: libosmocore.git I89abffcd125e6d073338a5c6437b9433220e1823
libosmocore If22988735fe05e51226c6b091a5348dcf1208cdf introduces
an even more convenient mechanism for specifying the DSCP of
an IP socket via OSMO_SOCK_F_DSCP()
Change-Id: If0b11dea08716ed3952a25b546b2a9bd013857bf
We have VTY options that allow to set the DSCP value. However, we
then call a function to set the TOS bits in the kernel. This is
very wrong. The DSCP is only the upper 6 bits of the 8-bit TOS
value, and hence we are mussing that translation.
As libosmocore now has a helper function osmo_sock_set_dscp(),
let's make use of it and don't care about the low-level details.
However, this means we need to finally remove the deprecated
alias for "rtp ip-tos <0-255>".
Closes: OS#5137
Change-Id: I9c18c90273be97aedd2ad212b82f650e35c32851
Depends: libosmocore.git Ia4ba389a5b7e3e9d5f17a742a900d6fd68c08e40
In I64ff22193ab2a95a9a7d66e9957a875d096e23de the soversion was
chhanged, but the spec.in file was not adjusted accordingly.
Change-Id: I45d7321adb2db8e7b9ea41b6bcf0c6cc59984a0e
In change I55605ea083565b6950d0820e3f72c50c9dc19ffa, the default
number of endpoints was increased to 512, however the
configuration examples were not updated.
Change-Id: I449a612065a5208c9f70ae74f594e8d45eb344cf
Related: OS#4711, SYS#5262
The manual does not say much about the endpoint naming, even though
osmo-mgw is oriented at RFC 3435 the endpoint names are specific to
osmo-mgw. In particular the E1/T1 endpoints and their overlapping need
some explaination
Change-Id: I16265eb667221959a69f33701d024bd8d9b22040
The cunfiguration chapter does not say anything about E1 trunk
configurations, lets add a subsection that explains how an E1
trunk is added.
Change-Id: I4059771df0f115242398d1af499c837005a7dabc
The E1 trunk lacks the VTY commands force-realloc and rtp-accept-all.
However, the function that write the E1 trunk config includes those
commands. Also they would be applicable, so lets add those two commands
also for E1 trunks.
Change-Id: Ief2bc7502bb8d1e0f9c784d42edbe1aed5ffb728
When a trunk 0 is created (which is legal) than it is impossible to
write this trunk back to the config. The reason for this that there is
still a filtering in place from the time where trunk 0 was not allowed.
This filter needs to be extended to filter only virtual trunk 0 but not
E1 trunk 0 out.
Change-Id: Iad6b577b5a711c35f98c477351fde567d8c87298
The trunk 0 was reserved for rtpbridge in earlier versions of osmo-mgw,
this was due to internal technical limitations which no longer exist.
Change-Id: Ic322f7dcf28db827187a4537e2634a887bd7b13b
Add a graph similar to "OsmoMGW used with OsmoMSC" that shows the
integration of a legacy E1 BTS into a AoIP network
Change-Id: I71dc2f4a188fbc25e81050be3dd4c83e1797e63d
The graph "OsmoMGW used with OsmoMSC" shows a BSC entity that accepts
AoIP and RTP, however osmo-bsc has no RTP proxy functionality. It makes
probably more sense to remove the BTS from the graph and call "BSC" "2G
BSS"
Change-Id: I6c7d26b6e45d0f953b82bca3ae7b2f26600982b2
The graph "OsmoMGW used with OsmoBSC" shows an RTP and 3GPP AoIP going
to OsmoMSC, this is technically wrong since osmoMSC has no RTP proxy
functionality whatsoever. Since the graph is not so much about OsmoMSC
it makes more sense to label OsmoMSC with "core-network", then it makes
sense and correctly highlights the role of osmo-mgw on the BSS side.
Change-Id: If3550a101e1e3cc2a25e21dcfe5474134015a6a7
The limitations section is outdated. We now have support for osmux and
E1 timeslots with trau frames. However, we did not mention that we still
have no transcoding as well.
Change-Id: Ia0fe8be96bbf880cfcd9d18256f4ac23a6efae79
To make clear which configuration changes (configure terminal)
apply when, add appropriate user attributes to VTY commands.
Change-Id: I2d9487801b3b78f94577264b56d217c926ef76a9
Related: SYS#4937, OS#1601
The initialization of the E1 line in mgcp_e1.c is controlled internally,
there is no need to expose the function mgcp_e1_init(), lets make it
static and remove the prefix mgcp_
Change-Id: I6aba1c55c9b1d729709ee1fba2994c77bd848a9b
The VTY command "bind early" is deprecated but it prints an error
message and the DEFUN is not set to DEFUN_DEPRECATED.
Change-Id: I594a87d2f63826a9d7b4f6a380586b08b3b79518
There exist trunk_loop commands, which sets an trunk->audio_loop
variable, however all it does is to turn on a log message. There is no
actual implementation present. Lets set the VTY commands to
DEFUN_DEPRECATED and remove the variable.
Change-Id: I72b0f8b908e32643e6e3db6ac024371b13c074a1
The error message: "abrupt FSM termination with connections still
present, sending unconditional DLCX..." implies a more serious problem
than in actually is. Even when connections are present on the
mgcp_client_fsm while it terminates, normal operation is still possible.
Lets change the loglevel to NOTICE and remove the "aprupt" from the
phrase.
Change-Id: I9749c024e208835bd4188bace13f723008de54c8
Related: SYS#5082
libosmo-mgcp-client looks up this timer in a caller provided osmo_tdef
definition. So far, all of our libosmo-mgcp-client callers do not configure
such a timer, so that we always use the default timer value.
We have introduced X timers (negative numbers) to indicate Osmocom specific
timers, and reserve T timers for 3GPP specified ones. So now is still a good
chance to move this timer to the Osmocom X realm.
Remove a comment about this timer at an unrelated place. It is still described
at osmo_mgcpc_ep_alloc().
Change-Id: If097f52701fd81f29bcca1d252f4fb4fca8a04f7
It is currently done upon receival of RTP packets in rx_rtp for pure RTP
conns, but nothing similar is done for Osmux conns, which eventually
trigger a connection time out.
Change-Id: Id592d7db7b9399a497176e0d28cc826b3bce48c0
Otherwise some state is kept, like the previous CallId, which may then
provoke issues next time the endpoint is to be used.
Change-Id: I3ac4f4542c1c8c877127c64acce6c82b458f697f
MDCX may provide a new remote address, which means we may need to update
our announced IP addr and re-bind our local end. This can happen for
instance if MGW initially provided an IPv4 during CRCX ACK, and now MDCX
tells us the remote has an IPv6 address.
Change-Id: Iaed424e2c209e1753e1f579752fc684aaad7a512
It doesn't make sense to call the function several times since anyway we
are only binding during
allocate_port()->mgcp_bind_net_rtp_port()->bind_rtp()->mgcp_create_bind()->osmo_sock_init2().
Let's better calculate the local IP addr once and use that stored value.
THis is a previous step towards next commit updating the local IP addr
and re-bindng if encessary.
Change-Id: I803b99c5e5fe0f92a5bf6796d8c25df88d1608e6
This commit allows for fully IPv6 systems to work fine. However, if a
remote endpoint still wants to use IPv4, it will fail since at this
point osmo-mgw still doesn't re-bind the local end of the connection to
an IPv4 after having initially bound it to an IPv6 one. This kind of
scenarios get fixed in next commits.
TODO: really bind the socket if a different IP address is requested.
Change-Id: I8ed94bd3f674f498e6ba315f44a351fff9c1be15
This commit contains the bulky work of moving all address parsing to
support IPv6 together with IPv4.
Some specific patches required for full IPv6+IPv4 support requiring
behavioral changes come after this one.
Full Osmux IPv6 support is left out of the scope of this patch.
Depends: libosmocore.git Ie07a38b05b7888885dba4ae795e9f3d9a561543d (> 1.4.0)
Depends: libosmocore.git I59bf4b4b3ed14766a5a5285923d1ffa9fc8b2294 (> 1.4.0)
Change-Id: I504ca776d88fd852bbaef07060c125980db3fdd7
This is needed in case MGW changes the local IP address (for instance
because it initlaly offered an IPv4 address, and a client submitted a
remote IPv6 address, so MGW needs then to offer a local IPv6 address for
the RTP connection to be possible).
Change-Id: Ie964412b81fe6e10914790baaea724ca5f772adc
The API and related implementation fields are not used internally nor
externally, and only support IPv4. Let's simply deprecate the API and
drop all the uneeded implementation.
Change-Id: I905d4c4efabb6b4a4bc5c02e956808777243cadc
If "0.0.0.0", the default, is passed together with an IPv6 configured
address (ex: "mgw remote-ip ::1") in VTY, socket creation will fail due
to address version mismatch (because getaddrinfo() returns only an IPv4
address in the local result set).
If instead NULL is passed, then 2 entries are returned, one in IPv4 and
one in IPv6, and osmo_sock_init2 is smart enough to take one or another
when passed AF_UNSPEC.
Change-Id: I1be6f3b71486ce1782ba6b8c62f25145b42ec894
Existing mgcp_client_test code required the '.' to trigger the same code
path, since with this commit we do extra checks and without a dot the
address is not accepted as IPv4 by osmo_ip_str_type().
Change-Id: I936bf57d37f5f0607dfe7fc66c37e424c3793f9b
The VTY default for the number of endpoints is 32. This is sufficient
for small setups and lab testing, but for medium sized setupts the limit
might be reached soon. Lets increase the default to 512 virtual endpoints.
Change-Id: I55605ea083565b6950d0820e3f72c50c9dc19ffa
Related: OS#4711
The struct member trunk->e1.line is never set. Also it is always
possible to use e1inp_line_find() to get a pointer to the e1.line.
Lets remove it.
Change-Id: Id4ff52285917ce3885b8dad3a16270999c9da0aa
The E1 timeslot initalization may fail silently in the last steps. There
is an error code returned, but no log lines are printed. This can make
debugging difficult.
Change-Id: I9aab17fc1ba6666c81b14035a8f1f17e5a55adaf
In this example, we are using the first span (0) of the first DAHDI card
and use it as 'trunk 1' in the MGW.
Change-Id: I0a97da5163a94379b327403b1258696855836bad
Since osmo-mgw supports trau frames it requries a newer version.
The spec file already requires those newer version.
Change-Id: If6c7ecdde09c6e09ded7e0959b7765a01a31d702
It contained name from a different program, probably due to main.c being
copied over during project start.
Change-Id: I4bfa40eec0277705f5d3335d779bff35518470a8
Due to the internal handling of the trunks it was not possible to allow
an E1 trunk that has the ID 0. However this limitation is no longer
present, so we now can allow an E1 trunk with ID 0.
Change-Id: I302c2007628f607033686e277c407232351e66ad
Related: OS#2659
When endpoints become unavailable when MDCX/CRCX/DLCX are executed on
them a major problem may be the cause, lets make sure that those events
are logged.
Change-Id: I059b7e29f960e75a53bfb5dfb2b83ab3d79e84f3
The function e1inp_line_update() is called without assigning its return
code to the rc variable.
Change-Id: Ia72ea2dca210b038766151d547f66b7b7139a2c4
Fixes: CID#212160
Confusingly, in Debian the package is called libosmo-abis, but in
the CentOS/RPM it's called libosmoabis. Fixes a bug introduced
in I45717bda3ef7eba1ef59b993cc8a69bf2f92a29f
Change-Id: I97dfec72a99295148e84e60c1e5037381f736c03
In I6b93809b5ac7d01af55888347dd787b0bc997ae1 we introduced E1 support
to osmo-mgw, but failed to add it to the build dependencies of the
Debian packages, making network:osmocmo:nightly builds fail.
Change-Id: I45717bda3ef7eba1ef59b993cc8a69bf2f92a29f
The file mgcp_internal.h still contains mostly definitions and types
that are relevant for mgcp_network.c and mgcp_protocol.c. Lets give
the network and protocol module its own header files, also move stuff
that does not relate to protocol and network to the appropiate places.
Change-Id: I837eaad771ed7252304db4a81c37953b70766fff
Currently only the endpoint handling for E1 exists, but there is no
actual code behind it that handles the E1 traffic.
Change-Id: I6b93809b5ac7d01af55888347dd787b0bc997ae1
Related: OS#2659
The function allocate_port() has pointer a variable end, it even does an
OSMO_ASSERT on it, but it never uses it. Lets remove it.
Change-Id: I369361389c6276e5511c683ebd630093713bdd37
This problem was noticed while running several LCLS test cases from
ttcn3-bsc-test. Every test case makes osmo-bsc leak at least two
chunks named 'struct mgcp_response_pending'.
Here is the related osmo-bsc output with additional debug messages:
DRLL ERROR mgcp_client_fsm.c:525 MGCP_CONN(to-MSC)[0x612000016120]{ST_READY}:
MGW/DLCX: abrupt FSM termination with connections still present,
sending unconditional DLCX...
DLMGCP DEBUG mgcp_client.c:1010 mgcp_client_next_trans_id(id=35): new trans ID
DLMGCP DEBUG mgcp_client.c:918 mgcp_client_pending_add(id=35): allocated and queued
DLMGCP DEBUG mgcp_client.c:962 Queued 53 bytes for MGCP GW
DLMGCP DEBUG mgcp_client.c:725 Tx MGCP: r=127.0.0.1:2427<->l=127.0.0.1:2727:
len=53 'DLCX 35 rtpbridge/1@mgw MGCP 1.0\r\nC: 5\r\nI:'...
DLMGCP ERROR mgcp_client.c:704 Failed to read: r=127.0.0.1:2427<->l=127.0.0.1:2727:
111='Connection refused'
The MGCP client FSM enqueues a DLCX from its fsm_cleanup_cb(), and
terminates. Thus if the remote MGCP peer becomes unavailable (e.g.
due to a network failure), we would never get a response, and since
the FSM is already terminated, nobody would pop and free() the
response handler from the queue (mgcp->responses_pending).
As a simple workaround, let's avoid allocating dummy entries of
'struct mgcp_response_pending' without a response handler. The
only case where an MGCP message is sent without a handler is
exactly during the FSM termination.
Change-Id: I83938ff47fa8570b8d9dc810a184864a0c0b58aa
Related: OS#4619
Instead of numerous arguments (buf, len and context data), use a msgb, like
most other osmo programs do, with a msb->cb pointing at a context data struct.
This opens the future for adding/stripping IuUP header data from the msgb
easily.
(Checked to pass current ttcn3-mgw-tests.)
Change-Id: I3af40b63bc49f8636d4e7ea2f8f83bb67f6619ee
_talloc_zero_array is not supposed to be called by the API user. Lets
use talloc_zero_array instead.
Related: OS#2659
Change-Id: I27549585016a7998e9233c52f6d86429fc75f509
Some of the unit-tests initalize a second trunk (trunk2) but the test
never do anything with this trunk. Lets remove it.
Change-Id: I228aa45160152091baac9d9c2e6486b774278b6a
Related: OS#2659
At the moment the number of possible E1 endpoints (depends on the number
of E1 timeslots that should be used) is hardcoded and the configuration
of the number of virtual endpoints has an off-by-one problem.
For the E1 timeslots one might choose not to occupy all E1 timeslots of
once. A one TRX E1 BTS usually requires 3 E1 timeslots. One as D-Channel
timeslot and two to cover the voice channels. The voice channels
timeslots need to be set up in osmo-mgw, while the D-Channel timeslot
must not be touched. The VTY config needs to be able to reflect that.
Change-Id: I73b31e3c236a61ea0a6f76ef5ff98ce589f52c77
Related: OS#2547
The test assumes that the endpoint "rtpbridge/X@mgw" is at array
position X in many places. This does not necessarly have to match.
Accessing the array elements directly was the prefered way when the MGW
did use integer numbers and not strings to identify endpoints. Since the
endpoint name strings are used to access the endpoints the unit-test
should also reflect this.
Lets replace the integer variable last_endpoint with a string variable
and do related verifications based on strings.
Change-Id: Ic950c427f23be4a792af94972554637c2b0fbdf2
Related: OS#2659
At the moment, the trunk prefix is checked twice. Lets re-arange the
code a bit so that the check only happens once.
Change-Id: I91fb8cf6e3b077ba8f18fdbcd071275c6fd7cacd
Related: OS#2547
There are 15 possible subslots (not all at the same time) in one E1
timeslot. Lets use a define constant for that.
Change-Id: If7cb74e486946aff09e22abf8a8885bf0693f34e
Related: OS#2547
mgcp_client.h offers functions to generate endpoint names for wildcarded
request. This is used in osmo-bsc, lets now also add a function that can
generate e1-endpoint names.
Change-Id: Iec35b5bae8a7b07ddb3559f7114a24dcd10e8f14
Related: OS#2547
Move 'doc' subdir further down to "make sure" the osmo-mgw binary is built
before the docs.
Remove mgw_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-mgw --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: I526af21134087e2b43b9ada59c93f636ae242e24
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: Ia988ea1c3f5169bdb4d21f2f05933665711cfcbf
The function mgcp_trunk_by_num() is used to directly pick a specific
trunk that is known by its id number (sometimes called "index").
Traditionally the virtual trunk will reside under id number 0 and all
consecutively created E1 trunks will be created under number 1 to 64.
This works fine, but puts a limitation on us should we ever introduce an
aditional trunk type (e.g. T1). Since the numbers must be unique
regardless of the trunk type one could not have an E1 trunk number 1 and
e.g. a T1 trunk number 1 at the same time. So we should pick the trunk
not only by its number, but also by its type to allow different trunk
types to carry the same number. The trunks will still be distinguishable
by its type along with the respective endpoint prefix.
Change-Id: I7af1e9ce601babd4a51e88201a98319e03945f83
Related: OS#2659
RFC3435 requires an MGW domain name appeneded to every endpoints. When
defining endpoint names in Appendix E, the domain name is is not
mentioned for digital trunks, however, this does not mean that digital
trunks do not have a domain appended. Osmo-mgw currently violates the
spec because it explicitly checks if the domain name is _NOT_ present
for E1 endpoints.
Change-Id: Ibb800b689e090b97b58d0206959b660890acd967
Related: OS#2547
e1_trunk_nr_from_epname() returns a signed integer:
int e1_trunk_nr_from_epname(const char *epname);
mgcp_trunk_by_num() accepts a signed integer:
struct mgcp_trunk *mgcp_trunk_by_num(const struct mgcp_config *cfg, int index);
Change-Id: Id333a6ddcefd37d82d19f9378ab87d1c02ffd7e3
Closes: CID#211333
E1 endpoint names also represent different rates, this may mean that
some rate / subslot combinations are not possible because they overlap
within nthe timeslot. When the equipment (BSC) is properly configured,
this will be no problem, however invalid configuration may cause the
selection of overlapping endpoints and this needs to be prevented, and
logged. Also rate counters need to be in place.
Change-Id: I18e90b10648a7e504371179ad144645fc82e1c27
Related: OS#2547
The struct mgcp_conn is currently defined in mgcp_internal.h, however it
makes more sense to put the struct in mgcp_conn.h
Change-Id: Ibe9a356300ddb9567432fe48e37c956b7125c79c
Related: OS#2659
Add an endpoint typeset for E1 support, also lets add dummy callbacks
for the cleanup and rtp dispatch functionality.
Related: OS#2547
Change-Id: I68b719a906e8f7251f0ca8c74ceec73bc40376f7
The E1 trunk number is currently not parsed, whenever a trunk prefix is
detected that indicates an E1 trunk, then the entire request is
rejected.
Parse the trunk number and select the trunk accordingly
Related: OS#2547
Change-Id: Ifdaab953544151e73b58cc3e95d21afdb40765f4
The trunk_type variable in struct mgcp_trunk is specified as an int,
however there is an enum mgcp_trunk_type specified. Lets use the enum as
type for trunk_type instead of int.
Related: OS#2659
Change-Id: I8e8b0cf448cfe67ad3b7caab24f301708d2a515f
The enum mgcp_trunk_type, which is currently located in mgcp_internal.h
makes more sense in mgcp_trunk.h, so lets move it.
Related: OS#2659
Change-Id: I077121503c44fc112a33f1c946f368414e28f841
The define constants CONN_ID_BTS and CONN_ID_NET were used in mgcp_osmux
long time ago when osmux support was temporarly broken. Now those
defines are no longer used anywhere, so lets remove them.
Change-Id: I3d0b9d482ef0e2187bccace5779a7f8b9507c4e2
This function calls mgcp_client_pending_add(), that in its turn
allocates a 'mgcp_response_pending' and appends it to the queue.
In case of an error, it calls mgcp_client_handle_response() that
would free the 'mgcp_response_pending', but this structure would
still remain in the linked list (the queue).
Change-Id: Id94bb93a6b0ea7b7241cf7868112e9bec3e60f0b
Currently the endpoint name that is generated for an E1 endpoint is not
correct. Let's add an endpoint name generator function that derives a
full endpoint name for a given E1 index
Change-Id: I70e0c3f96aa3947165f9926666815ee5614c8f57
Related: OS#2547
When the trunk allocates its endpoints by using mgcp_endp_alloc()
ist passes the name for each endpoint as a parameter. In order to
generate the name endpoint specific knowlege is required.
This process can be simplified, since all what
mgcp_trunk_alloc_endpts() does is calling mgcp_endp_alloc() in a loop in
order to generate a consecuitve series of endpoints. The endpoint names
are generated from the index of the for loop.
When we just pass the index instead of the endpoint name to
mgcp_endp_alloc(), then we can greatly simplify the code since all the
knowledge about the name generation can go into mgcp_endp.c. The
endpoint will name itsself by the trunk properties and the index number
we pass with the allocator function.
Change-Id: I8dee07f1c63037d1f73113f69c612d1f2703cee5
Related: OS#2659
The virtual trunk is a pre-configured trunk that always exists. It is
kept separate from the trunk list using a separate pointer. This makes
thinks unecessarly complicated. Lets organize the trunk in the trunk
list like any other trunk, except that we automatically create it on
startup and assign it always the trunk id number 0.
Change-Id: I81934fbd211b225ab7920e78510729c8e22607b3
Related: OS#2659
The rate counter definition (enums) are still in mgcp.h.
Lets move them to mgcp_ratectr.h since it makes more sense
to keep them there.
Change-Id: Id37f66673bc20f9c2cc47a6b44cdfe75f728b936
Related: OS#2659
get rid of deprecated trunk parameters which seem to be leftovers
from the old osmo-bsc_mgcp implementation. This is in particular
audio_name and audio_payload in struct mgcp_trunk_config which
allowed the user to "hardcode" an andio name and payload type
via VTY configuration
The removal of the struct members above also require a change to
mgcp_codec.c. The code that is is never actively used and even
causes wrong behavior when activated (set the no-transcoding
flag in VTY). Since the code is removed also the unit tests
also require to be changed to match the new behavior.
Change-Id: Ia050ec3cd34b410dfe089c41b977ae3d5aed7354
Related: OS#2659
The trunk and endpoint handling in osmo-mgw is still very complex and
implemented in various places (mostly mgcp_protocol.c). Also we use
still integers for endpoint identification, which is not flexible enough
to address timeslots/subslots on an E1 trunk. Some refactoring is needed.
- get rid of integers as endpoint identifiers, use strings instead and
find the endpoint based on its string name on the trunk.
- identify the trunk based on the trunk prefix given in the endpoint
name.
- refactor trunk and endpoint allocation. Aggregate functionality in
in mgcp_endp.c and mgcp_trunk.c. Also remove non-reusable code that
relates to the still exisiting, but unfinished E1 trunk support.
- refactor rate counters, put them into a separate module and do no
longer allocate them per trunk. Allocate them globally instead.
Change-Id: Ia8cf4d6caf05a4e13f1f507dc68cbabb7e6239aa
Related: OS#2659
The config under the node mgcp is written with an indentation that has
one space too much.
Change-Id: I2aefeaf3d7ad4a98b7bfcdc7cbc1ce6ebcbe0537
Related: OS#2659
rename struct mgcp_trunk_config to struct mgcp_trunk and the related
symbol name "tcfg" to "trunk" in order to better match the reality.
Change-Id: I02889dbf8149e139b1bd0326e13ce4c1aec867d1
Related: OS#2659
When a trunk is selected that does not exist, a new one is created. In
this case the VTY would print an error message but the function exits
early. The code that would print the error is unreachable.
Change-Id: Ie8c3b083174eb8209df2c06f65db6d7bbfaa87f7
fixes: CID#210637
There were two code paths that were supposed to do exactly the same,
but then in Change-Id I3994af016fb96427263edbba05f560743f85fdd4 only
one of the two was modified, resulting in OS#4034
Let's
* dynamically allocate the virtual trunk
* rename mgcp_config.trunk to mgcp_config.virt_trunk to clarify
* as a result, abolish copy+pasted code for trunk initialization
Change-Id: I54762af6d417b849a24b6e71b6c5c996a5cb3fa6
Related: OS#4034
The logging defines LOGPCONN and LOGPENDP are currently located in
mgcp_internal.h. However, there are specific header files for conn
(mgcp_conn.h) and endpoint (mgcp_endp.h) related stuff. Lets put LOGPCON
into mgcp_conn.h and LOGPENDP in mgcp_endp.h
Change-Id: I25ff37ee8108c27d169d294fd16ddcdde9b00195
I wanted to use gerrit to merge v1 of
I8d58281e1ff898638293c9e8cb000329462c7a70, but gerrit merged v2
nevertheless :(
Change-Id: I7b16912e66e91f0c30716e4ea1181b39906bacc1
struct mgcp_config contains a function pointer realloc_cb, which is
never popoulated nor used anywhere in the code. Lets remove it
Change-Id: I8d58281e1ff898638293c9e8cb000329462c7a70
Remove OpenSUSE bug report link, set version to @VERSION@, make it build
with CentOS 8 etc.
Related: OS#4550
Change-Id: I1d03ac87a7d0c3c600d187f3e485cb2dab8838bb
Not having a second leg of an MGCP endpoint is a normal situtation
and can't be treated as an ERROR message, especially not as an ERROR
message logged on every RTP packet. This happens routinely at
the beginning of call setup and we get tens of ERROR messages in
the logs for every call.
Change-Id: If741a742208772bda4e59236345d7ae650368d5a
New define is available since libosmocore 1.1.0, and we already require
1.1.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: I9b6463af713f76c06a144bdbf202c0d91eef4d21
Right now a lot of errors with MGCP processing are invisible in rate
counters which makes them difficult to trace or even notice in
a production environment. E.g. reaching a limit of MGCP endpoints
is completely invisible even though it's a critical opertion alarm.
Change-Id: I6db68f044255c927dfd534fed880e405ec3ed4d6
Before this patch rate counters started right after trunk information
with no visual separation which was quite confusing. We're adding
a new line and a header to warn a user of the section change.
Change-Id: I3943def03ab821b05ac597f40bdfa4a3a71ddca3
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I2314ef45e6f588e88d5aab8213cc7b5cdef11325
The example config bind the MGW to a random ip-address, lets use the
loopback address here, this will suit cases where osmo-bts runs on the
same machine as the MGW (nitb). For all other cases were an external BTS
is used the ip-address still needs to be changed.
Change-Id: Iae52c671c48953ea6b52b18c5d77347343cde0df
Enlarge the MGCP client workqueue maximum limit by factor 100.
During Abis load testing, a BSC trying to DLCX 200 conns at the same time hit
the limit of 10 very very quickly, and everything broke down.
Change-Id: I8980cce37bae0757828b28455b25c77bcb6316d0
We used to update only the per-connection rx/tx packet/byte counters
on-the-fly, but not the per-trunk global counters. The latter would
only be updated at the end of a connection. As MGCP connections
can last quite long (think of a long phone call) this is maybe
not the best of ideas.
Note: The all_rtp:err_tstmp_in and all_rt:err_tstmp_out are still
only updated at the end of a connection.
Change-Id: Ib3866cb8149d3257fcf39733846c97c33881c4ee
Related: OS#4437
OsmoMGW has a lot of nice built-in statistics (rate_ctr,...) but it
seems the only way to look at them is via the VTY. While libosmocore
contains automatic exposure of all rate counters via CTRL, the CTRL
interface simply is not used by osmo-mgw so far.
Closes: OS#4441
Change-Id: I7ed6bdb9f4749c24ca11a5905a620546cfe42952
If a config file doesn't have a 'number endpoints' config line,
we would use -1 as unsigned integer and end up with
number endpoints 4294967295
if the config file is re-written
Change-Id: I05a3814117b1d6e0cdc30740da31709ce333df4b
Closes: OS#4034
libosmocore required version increased due to include used from
libosmo-netif including an include from libosmocore which in previous
versions misses including an include from a symbol used.
Change-Id: I1d5f14b1ad36b2ed94343fca71fdc622424403d3
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I48f4c2c520e8285aff5d6d65f95bd041c13466e8
This way we can avoid the runtime overhead of checking whether or not
it is initialized over and over again. It also brings this code more
in line with other users of osmo_fsm_register().
Change-Id: Ia73ba8e46c13d925e88203e08a8966839e573183
API doc: require osmo_fsm_set_dealloc_ctx().
mgcp_client during delete: do not reparent the FSM when it is already
terminating.
I have recently discovered a vulnerability: if an endpoint FSM deallocates
during event handling of a successful MGCP response, this causes a
use-after-free; and once that is fixed, a state change on the already
terminated FSM causes a pointer corruption by using already cleaned data
structures. osmo_fsm_set_dealloc_ctx() fixes the use-after-free, and
osmo_fsm_set_term_stops_actions() fixes the pointer corruption.
Related: Ib7fce7b7d54dfb87af97544796680919e5929a50 (osmo-bsc),
I08c03946605aa12e0a5ce8b3c773704ef5327a7a (osmo-msc)
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Change-Id: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3
SDP is an optional part of MGCP messages. Do not fail when there is no SDP part.
Practically this is useful to compose simpler MGCP responses from TTCN3 tests.
osmo-mgw itself always includes SDP, so there is no real impact on operating
libosmo-mgcp-client with osmo-mgw from osmo-bsc or osmo-msc.
Change-Id: I608001626459ea72415fb142f857550bbb90c683
If an API user only has access to the ci FSM (which is managed via an opaque
struct), provide this function to obtain the backpointer to the parent endpoint
FSM, mostly to be able to call osmo_mgcpc_ep_cancel_notify() on it.
osmo-msc's rtp_stream FSM will use this in
I351bb8e8fbc46eb629bcd599f6453e2c84c15015.
Change-Id: I14f7a46031327fb2b2047b998eae6ad0bb7324ad
There is a use-after-free problem if a 'notify' FSM as passed to
osmo_mgcpc_ep_ci_request() deallocates before the notify event has been
dispatched. To avoid that, add API to allow cancelling a notify.
Change-Id: I41687d7f3a808587ab7f7520f46dcc3c29cff92d
In case the ep gets deallocated during event dispatch, move all ci[] cleanup to
*before* dispatching a DLCX OK event. Afterwards, it might become a
use-after-free.
Change-Id: Ib2032e5566e465c02a9a525ccd38f9dcc84fb669
Upcoming patches introduce copying notify information. Prepare by combining
notify info into a separate sub-struct.
Change-Id: I47c0dd112011b8cb4dc88e8efd010466d4ba6308
If an MGCP operation on one conn of an endpoint fails, no longer carry out
other pending requests for that endpoint. Only allow pending DLCX to be sent.
If the caller schedules two CRCX at the same time, the first CRCX is sent with
a wildcarded endpoint name like "rtpbridge/*@mgw". Only when the OK for that
returns an allocated endpoint, will the second CRCX be sent, using that actual
allocated endpoint name. But, if the first CRCX fails, then we should not send
another wildcard CRCX, but rather assume both as failed.
Since a failed MGCP message means that the endpoint becomes unusable /
undefined and typically deallocates directly, we can actually discard all other
pending requests except for DLCX.
Change-Id: Icb1d485224bb486b84eff6329f0bd95932e63246
During FSM instance cleanup, a DLCX message composition may fail if a preceding
received MGCP message was missing parameters. If that occurs, don't crash, just
log an error and deallocate.
Change-Id: Ic1c3c4deeb4703b60e870af9d5d7be216a87fff8
Currently in handle_create_con(), mgcp_conn_alloc() is called with NULl
ctx. As soon as this ctx is changed to be part of the trunk's endpoint
array (tcfg->endpoints), test will segfault because some fds from
previous tcfg are still registered after the whole tcfg object was freed
with talloc_free() by previous test. That's because
mgcp_endpoint_release() must be called on all endpoints to make sure all
registered components are correctly unplugged.
Related: OS#3950
Change-Id: I813d52b518ed0bb8db4e42dff83e040b0891fee2
If a ptmap appears in the SDP, always store it in the ptmap array. No longer
attempt to drop entries if they match the conventional payload type number.
- One reason is that the past code only matched full explicit "FOO/8000/1"
strings, while the channel number "/1" can be omitted to imply 1; by simply
storing everything received in the SDP, there is no need to add complexity
to match both "FOO/8000" and "FOO/8000/1".
- The other reason is to rather parse exactly what was received, instead of
filtering entries, to take away a degree of implied magic.
Change-Id: I2a69c21e68c602daf804744212d335ab1eafd81b
- move the error logging up to the actual errors. Each appear only once, no
goto labels needed.
- instead of strstr("rtpmap"), use osmo_str_startswith("a=rtpmap:") to more
concisely trigger on the actual syntax of the audio parameters. Same for
"a=ptime:".
Change-Id: I730111e245da8485c1b5e8811f75d140e379cec6
There are allocated bits in conn->end.codecs[], free them.
This is not fixing a memleak, since mgcp_rtp_conn_cleanup() is currently only
called from mgcp_conn_free(), which soon after frees the conn; the conn serves
as talloc parent for the codec strings freed in this patch.
The rationale: it is better style to explicitly free them, to also guard
against future callers of mgcp_rtp_conn_cleanup() which might expect complete
cleanup.
Change-Id: Ic471107ce6e94d9ce582d887429c744ff93e3053
In codec_set(), for each 'goto error', log the specific error cause.
Also add a TODO and a FIXME comment about inventing dynamic payload type
numbers.
Change-Id: I0b44b574c814882b6f8ae7cd738a6f481cd721fd
In codecs_same(), do not compare the complete audio_name. The parts of it are
already checked individually:
- subtype_name ("AMR"),
- rate ("8000"; defaults to 8000 if omitted) and
- channels ("1"; defaults to 1 if omitted)
So by also checking the complete audio_name, we brushed over the match of
implicit "/8000" and "/8000/1", which otherwise works out fine.
As a result, translating payload type numbers in RTP headers now also works if
one conn of an endpoint set an rtpmap with "AMR/8000" and the other conn set
"AMR/8000/1".
It seems to me that most PBX out there generate ptmaps omitting the "/1", so
fixing this should make us more interoperable with third party SDP.
See IETF RFC4566 section 6. SDP Attributes:
For audio streams, <encoding parameters> indicates the number
of audio channels. This parameter is OPTIONAL and may be
omitted if the number of channels is one, provided that no
additional parameters are needed.
Also allowing to omit the "/8000" is a mere side effect of this patch.
Omitting the rate does not seem to be specified in an RFC, but is logical for
audio codecs defined to require exactly 8000 set as rate (most GSM codecs).
Add tests in mgcp_test.c.
Change-Id: Iab00bf9a55b1847f85999077114b37e70fb677c2
Instead of manually entering codec values, use mgcp_codec_add() to populate
test conns with codecs. The idea is to better test what actually happens when
parsing SDP codec strings.
Rewrite current test_mgcp_codec_pt_translate() from procedural to a data model
with human readable stdout logging.
This prepares to enable interpreting codec strings like "FOO/8000/1" as
equivalent with "FOO/8000": the SDP standard defines the final "/1", indicating
the nr of channels, as optional for a single channel, but osmo-mgw currently is
unable to match these two formats as identical. So prepare the
test_mgcp_codec_pt_translate() so that upcoming patches can incorporate strings
with and without the final "/1" by extending the struct arrays.
Change-Id: I888000d77512cfecb0f199b86ef6003e7fc0e6cb
The audio_name and subtype_name are allocated from talloc, so they need to be
freed before resetting the codec array. Use mgcp_codec_free() to ensure this.
Change-Id: I07f207dcb7ce66bbf3445a30af41e696677b384f
Both are used only in the same .c file, so make them static.
Move codec_set() guts into codec_add(): codec_set is only called by codec_add.
If codec_set were left separate, it'd look like the codec_init() is a bug and
lacks a codec_free() first. When looking at the entire context in codec_add(),
it becomes obvious that codec_init() should be called, not codec_free(),
because it is populating a previously unused entry.
Preparation to fix a memleak in a conn's codec list.
Change-Id: I120cab0a352a1e7b31c8f9c720c47b2c291311d7
If mgcp_send() runs a transcoder loop, break the loop if rfc5993_hr_convert()
or amr_oa_bwe_convert() return with error. Possibly fixes an infinite loop
situation for erratic packets? (Didn't check for that in detail.)
Change-Id: Iba115a0b1d74e7cefba5dcdd777e98ddea9eba8c
Remove various OSMO_ASSERT() on size of incoming packets. Doing an assert on
incoming data is a DoS attack vector, absolute no-go. Instead, return -EINVAL
and keep running.
Change some return values to be able to distinguish successful operation from
invalid RTP sizes. In rtp_data_net(), make sure to return negative if the RTP
packet was invalid.
Some of the error return codes implemented here will only be used in upcoming
patch Iba115a0b1d74e7cefba5dcdd777e98ddea9eba8c.
Change-Id: I6bc6ee950ce07bcc2c585c30fad02b81153bdde2
The name 'cmp' implies a return value of -1, 0, 1 to indicate smaller, match or
larger. Since this function returns bool, it should not be named with 'cmp'.
Change-Id: I2d41b1a32300e295551e85d3f9ab82dd2b0e86b8
Current code uses APIs like osmux_xfrm_output_init2() and osmo_amr_*(),
that are only available in libosmo-netif 0.6.0 onwards. Let's update
configure.ac accordingly.
Change-Id: I3bc0196bb6b5c5e5cf96935422fd56c4582ed7f5
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Icf4d18969488c9eacca7a597d4071828e649e772
Related: OS#4138
Return variable specified by strtoul() is "unsigned long int". If
"unsigned int" is used, according to Coverity the return value can never
be ULONG_MAX:
CID 202173: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
"pt == 18446744073709551615UL /* 9223372036854775807L * 2UL + 1UL */" is always false regardless of the values of its operands. This occurs as the logical second operand of "&&".
Furthermore, PT is 7 bit in RTP header [1], so let's avoid accepting
incorrect values.
[1] https://tools.ietf.org/html/rfc3550#section-5
Fixes: c5c1430a1c ("Catch unsigned integer MGCP parsing errors with strtoul")
Fixes: Coverity CID#202172
FIxes: Coverity CID#202173
Change-Id: Ice9eee6a252fab73dbab5ebf3cfc83c1b354fd08
There is unfortunately no way to suppres this witha pragma,
and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed
Related: OS#4123
Change-Id: Ib157bd2e110b271dbe5ac928c98251e016477f56
Mark osmocom/mgcp_client/mgcp_common.h as nodist, so "make dist" will
not try to include it in the source tarball. This caused "make dist" to
fail in a clean osmo-mgw source tree with:
make[2]: *** No rule to make target 'osmocom/mgcp_client/mgcp_common.h', needed by 'distdir'. Stop.
The file gets copied during make from osmocom/mgcp/mgcp_common.h (see
include/osmocom/mgcp_client/Makefile.am). Therefore it is not included
in the source tree and we don't need to distribute it.
Related: OS#4084
Change-Id: Ia1d7b051c0924a785b0f7ec0195192e3a852ed70
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I637cb20f0af4de33ebf6589b1aff260d57d03e7b
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: Ifc1b3bfe6ff6922df478cea89bbbb291b5fa5706
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I7d1e55faddafa3c3093d38513d4a434ecf5ea5bd
Otherwise it would not catch a duplicate if first the param is
introduced in upper case and later in lower case, or the other way
around.
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I254bfa3a2d2562441ca3a576cc8e1e7967d9c495
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I51dc1cdcbe2a5587769335fbecb5039ef22cae5d
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I4da93dfc69b5585a197a7e201a1afb72c2f97030
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I4f7b07b77c2946e9cd6f0eeca00011bd905126dd
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I48252415f9d0cd985ad097f334aa4c1665f52511
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: Ic28a5eacc4c441d68e8a20d2743956ab2e01125d
It can be used together with LCLS, just make sure to also enable
keep-alive packets.
In OS#3429 it was pointed out, that during LCLS the media path remains
active but is not used. Without any traffic flowing, this looks like a
timed out connection and so it will be killed if conn-timeout is set.
However, OsmoBSC and OsmoMSC have an option to enable RTP keep-alive
packets (through libosmo-mgcp, originally intended to keep connections
behind NAT open). If that option is enabled, the keep-alive packets
should also prevent the conn-timeout.
Related: OS#3783
Change-Id: Ib4d19104d558a26a444a80fb36f4b7b33bc5cc59
VTY command to disable conn-timeout again, after it has been enabled.
conn-timeout was introduced in [1].
[1] Change-Id I18886052e090466f73829133c24f011806cc1fe0.
Change-Id: I7dee7dafaaf4bb93fd692ea06b52b9e012beac6d
Move code in RTP specific path to generic dispatch_rtp_cb. This way
loopback logic is applied both for Osmux and RTP connections.
Change-Id: Ia30f5a14f150e4d151eac4d1046ea834f1685a5f
That MGCP_DUMMY_LOAD is an old hack prior to Osmux spec update, and it's
not nice since it cannot be 100% distinguished from a usual AMR ft
frame.
Let's use the correct DUMMY ft type and build it according spec. Allow
handling differently the old format for a while until we are sure no old
implementations (like bsc-nat) exist sending that kind of message.
Change-Id: Ib17d20b87b28aade49ba60519b56a96e694819af
Remove old BTS/NET no longer in use and meaningless. Use new osmo-mgw
APIs to inject payload RTP<->Osmux on the correct socket and conn.
Change-Id: I60b6ba3ffdc74efff945ba13a0b736798bdf5d8c
Previously the local one was used but nobody cared because probably
everybody was using default 1984 on different IP addresses.
Change-Id: I01e590465fa247185d74103578681e9041249099
During MDCX state is already changed to ACTIVATING but we still want to
send the local CID back to announce that we still use same local CID.
Change-Id: If182a48743ebe03f97caf9034e49b9947014bdf9
We also update code to allow setting up RTP related fields to succeed
during CRCX. We also update code to allow setting up RTP related fields to
succeed during CRCX.
Change-Id: Ia6e723d9a28ba38fc3382a4fb35ea6e5bab30c09
This is going to be useful to know if a conn is to use Osmux without
looking at implementation details. Currently we have some duplicated
information (type, osmux.state, etc.) which we may want to refactor
later. This will allow changing implementation details without caring
much about rest of code.
Change-Id: Ib5a239fdbc319bcb16317f5e959d9a724b7a444a
* remove tons of old cruft from openbsc.git that doesn't exist here
* actually add the osmo-mgw binary and .la file that we're building
Change-Id: Ic0e27c05e3ab368c195f9f9961fa70feb077a5e0
Recent commit moved mgw_endpoint_fsm from osmo-bsc.git here as
osmo_mgcpc_ep_fsm. Some API name changes were applied to avoid
collisions, but FSM was kept and it is registered during startup with
__attribute__((constructor)). As a result, with old osmo-bsc (+tests)
try to allocate its copy of mgw_endpoint_fsm, it fails because that name
is already registered.
Fixes: 538d2c53d9
Change-Id: I694ce58baa43f536b7e594b003edc891f029aa4a
osmux_xfrm_input_open_circuit returns 0 on success and -1 on error.
Confusion comes from that function being implemented by calling
osmux_batch_add_circuit which returns NULL on error.
cherry-picked from: openbsc.git ac1b03c8e59408336d07527e2597171cb99ed654.
Change-Id: Iba018aa57901642ea4c486526a973fe6023e10cf
In certain cases the endp can be NULL. LOGPENDP will dereference the
pointer to retreive the endpoint number.
Fixes: 8a893442a1e9 ("mgcp_internal: LOGPENDP: ensure *endp is not NULL")
Change-Id: Ie9b5ecf08f69533ccb2fbd7fbbb529105e0c922f
The first CRCX responds with the actual MGW endpoint name that is assigned (at
least for rtpbridge/*@mgw requests).
If multiple CRCX are scheduled at the same time on a fresh MGW endpoint, both
get fired with a '*' and each creates a separate MGW endpoint.
Make mgcp_client_endpoint_fsm avoid this, and schedule only one CRCX at first,
and the rest once the MGW endpoint name is fixated. It is thus possible to
safely issue two osmo_mgcpc_ep_ci_request() at the same time.
Change-Id: I92a9944acc96398acd6649f9c3c5badec5dd6dcc
Move mgw_endpoint_fsm from osmo-bsc here as osmo_mgcpc_ep_fsm. Apply various
renames for consistency. Use osmo_tdef from libosmocore instead of osmo-bsc's
(so far) local T_defs API.
Change T23042 to T2427001, which is a slightly less arbitrary number and
slightly more extendable in the future (2427 corresponds to the default MGCP
port at osmo-mgw, 001 is the first MGCP timer and so far the only one).
Change-Id: I9a3effd38e72841529df6c135c077116981dea36
* Cleanup naming to make it far more clear
* Drop 2 variables holding CID values (allocated_cid, cid), in favour of
1 value holdinf the value and one bool stating whether the value is
used.
* Change conn_osmux_allocate_cid to allow allocating either next
available CID or a specific one, in preparation for forthcoming patches.
This commit can be merged straight away because anyway osmux cannot be
enabled in current status (blocked by vty config) and
(conn_)osmux_allocate_cid was/is not called anywhere. However, it helps
improving code base for future re-introduction of Osmux as it is
envisioned.
Change-Id: I737a248ac6c74add8e917fe2e2f36779d0f1d685
In previous code, 2 blocks were handling osmux inclusion one after the
other under same osmux.state. However, first block changes osmux.state
so second block can never be true and X-Osmux is never added.
Change-Id: Iceee8b64978651f1fe6bb883923561b081f73d9b
Let's define macro once and use it everywhere instead of passing endp
information in different ways everywhere. Furthermore, use conn whenever
appropiate to have more information.
Change-Id: I1c49b1eb16bc5f1010376da5cf407ca6e31d81f2
This way we prepare it to add more endpoint types in the future (osmux)
and also make it clear that E1 endpoint specifics allocation is still
missing.
Change-Id: I7633b5287a436c11f0bbbdbaef1cf59a051a2471
* Get rid of string define containing printf statements
* Split name from rest of checks to easily add new names later
Change-Id: I46e05a7a3432733976760bbf1c5deb4f7610db11
RFC3267 specifies two framing modes for AMR packets. An octet aligned
mode is specified where all fields of the AMR packets are aligned to
octet boundaries. The second framing mode is the bandwith efficient mode
where the fields are directly packed one after another.
- add paring/generation functions for related SDP fmtp parameters
- add conversion function to convert AMR payload
Depends: libosmo-netif I5b5a0fa644d8dbb1f04f9d7e35312683c7b3d196
Change-Id: I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Related: OS#3807
The callback function mgcp_get_format() is used to request the codec
parameters for a specific connection. This function returns the
parameters as idividual pointers. Since there is a struct that holds all
important codec information among the ones which are currently returned
by mgcp_get_format, lets just use this codec struct as single return
value.
Change-Id: I348f9141eb59ed1a986447b96ab4a24ddf326936
Related: OS#3807
The if construct that takes care for parsing the a= parameters is
unnecessary complex. Lets handle each of the possible parameters
seperately on the same level.
Change-Id: Ifc801a757e9beb6b3974863d5ee99fc7c194559e
Related: OS#3807
The header file mgcp_sdp.h is not included by mgcp_sdp.c. Lets include
it here as well in order to be complete.
Change-Id: I3d9f28d6e7ca027b1be25d775a6a75d0fc491a50
Add conn_mode to struct mgcp_conn_peer, to allow setting an explicit connection
mode instead of implicit MGCP_CONN_RECV_ONLY / MGCP_CONN_RECV_SEND depending on
remote RTP port presence. Default to old behavior if this is left unset.
Rationale:
For IuUP Initialization, osmo-msc currently still uses a hack at osmo-mgw to
echo the IuUP Initialization back to the sender as an ACK. For sanity checking
reasons, this is done iff the CRCX created the CI in loopback mode. So, in
order to be able to switch to the mgcp_client_fsm in osmo-msc instead of
"manual" MGCP message composition and yet still be able to support IuUP and
IuCS, we need to be able to set the conn mode upon CRCX to loopback.
If we merged the IuUP patch (which is already on a branch somewhere) to
osmo-mgw, we wouldn't bother with this patch, but adding this conn mode choice
has these benefits:
- post-IuUP-fix osmo-msc versions can interop with older osmo-mgw IuUP for
IuCS.
- It is conceivable that some MGCP clients prefer explicit conn modes instead
of the implicit MGCP_CONN_RECV_ONLY / MGCP_CONN_RECV_SEND choice. This opens
the possibility to switch between conn modes with MDCX messages.
Change-Id: I26be5c4b06a680f25f19797407ab56a5a4880ddc
currently, when looking at an osmo-mgw log output with a phone call working
completely fine, you see these messages on LOGL_ERROR for each RTP packet:
20190304221420619 DRTP ERROR endpoint:0x0 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420639 DRTP ERROR endpoint:0x1 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420639 DRTP ERROR endpoint:0x0 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420659 DRTP ERROR endpoint:0x1 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420659 DRTP ERROR endpoint:0x0 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
Put these messages on DEBUG level instead. They currently do not convey useful
information.
Possibly our MGCP clients could use some changes in behavior regarding payload
types, but since that topic is quite unresolved, let's not spam the ERROR log
level with this.
Change-Id: I4afc41fd472ec8ba887b9263fbac62de50d7cef9
There are different specifications around on how a GSM-HR frame should
be encapsulated into an RTP packet. RFC5593 specifies a ToC (Table of
Contents) byte to be prepended in front of the payload data.
The two formats can be distinguished easily by their length. Then the
data can be formatted into the corresponding opposite format and vice
versa.
- Add new VTY rtp-patch options
- Add conversion function
Change-Id: Iceef19e5619f8c92dfa7c8cdecb2e9b15f0a11a1
Related: OS#3807
Add a watchdog timer to connections, and close these connections when
the watchdog timer expires. Kick the watchdog whenever RTP messages or
the relevant MGCP messages arrive. Add the currently remaining timeout
to "show mgcp stats" in the VTY.
This feature is disabled by default, as it is incompatible with LCLS
(connections in LCLS state appear to be inactive). Enable it with the
new "conn-timeout" VTY setting. In general, this feature can be used to
work around interoperability problems causing connections to stay open
forever, and slowly exhausting all available ports. This happened for
various reasons already.
MDCX is the only relevant MGCP message:
- CRCX creates the conn and timer
- DLCX deletes the conn and timer
- MDCX is the only remaining supported MGCP message that indicates a CI
- Can't easily generically parse a CI for all MGCP messages, parsing is
done in handle_modify_con().
Related: OS#3429
Change-Id: I18886052e090466f73829133c24f011806cc1fe0
So far, both osmo-msc and osmo-bsc always pass endpoint names of the form
'...@mgw' to osmo-mgw. Allow configuring the 'mgw' part.
Note that the actual way to pass a differing name is to pass a composed
'rtpbridge/*@foo' to mgcp_msg_gen() in the struct mgcp_msg. So this merely adds
a common VTY config for the domain name part, changes to clients are necessary.
- add mgcp_client_rtpbridge_wildcard() (useful for AoIP endpoints)
- add mgcp_client_endpoint_domain() (useful for SCCPlite endpoints)
- add mgcp client vty cfg 'mgw endpoint-domain NAME'
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
Also: our MGCP clients osmo-bsc and osmo-msc use code dup to compose the
initial 'rtpbridge/*@mgw' rtpbridge wildcard. It should be defined by this API
instead.
This will be used by:
* osmo-msc I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
* osmo-bsc I492023e9dca0233ec0a077032455d9f2e3880f78
After these, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint on two separate osmo-mgw instances:
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
osmo-mgw-for-msc.cfg:
mgcp
domain msc
osmo-msc.cfg:
msc
mgw endpoint-domain msc
There can also be '0@bsc' and '1@msc' endpoints on one single osmo-mgw instance with:
osmo-mgw.cfg:
mgcp
domain *
and same osmo-{bsc,msc}.cfg as above.
(By default, everything will still use '@mgw')
Change-Id: Ia662016f29dd8727d9c4626d726729641e21e1f8
Fix typos, use osmo_sock_get_name2() to show the tx source and target IP:port,
shorten some wording.
Depends: I8ad89ac447c9c582742e70d082072bdd40a5a398 (libosmocore)
Change-Id: Iae728192f499330d16836d9435648f6b8ed213b6
Remove public API that makes no sense anymore and is dead code.
I see the dropped API as a dead-end initial misconception of the early mgcp
client, and it doesn't really make sense to drag this stuff along. It has not
been used by osmo-msc,-bsc for a long time now, and just confuses the reader.
It is public API, yes, and older versions of osmo-msc / osmo-bsc will not be
able to compile against this, but even if it did, the resulting MGCP client
would not work with the current osmo-mgw: this API is still based on the
premise that the MGCP client dictates the MGW endpoint numbers, a concept that
cannot be used with the current osmo-mgw. Instead, osmo-mgw expects a
wildcarded endpoint upon CRCX and assigns its own endpoint names.
Also, the bts-base configuration is unused and a legacy of when osmo-bsc_mgcp
had explicit BTS and CN sides.
Change-Id: I98a9f1f17a1c4ab20cea3b08c7d21663592134d6
If the vty client enters multiple local / remote addresses, that leaks talloc
memory of the previously set addresses. Free those first, if any, using
osmo_talloc_replace_string().
Change-Id: I331b3d53b5eb330b87d798f952077a043674d409
Add the expected domain name, and move the error log to where the expected
domain name is compared.
Change-Id: I59f40dc9263f686852f103ca904fc0a6702d7c8e
Half of those are obviously zero, but I'd rather print the raw data instead of
adding string constants, even if the condition must always lead to 0.0.0.0:0.
Rationale: I had osmo-mgw listen on 0.0.0.0 and got the error message
DRTP ERROR endpoint:0x1 destination IP-address is invalid
which didn't convey that 0.0.0.0 is regarded as invalid.
Change-Id: I9e98d464a27038904797c5c10735a98ef5b7b9c3
mgcp_do_write() is the final stage of writing data towards the MGCP server
(MGW). In that function, drop an unconditional iteration and copy of the MGCP
message to a static string buffer for no apparent reason besides debug logging.
Instead, use osmo_escape_str() with a limited length, which can just be an
inline format argument in the LOGP() statement. This way, the string mangling
is simpler and only gets run when DMGCP is actually on debug log level.
Change-Id: Id6877ed7fd7dbe009b2ece8792d5160d040c1aaa
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: I24179b21ce4ff182649243e286c87c824b889454
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: Ie9db1519e89d2a8ca1e403e480f57d72fc25ab75
Jenkins currently runs the build twice, once with
MGCP="--enable-mgcp-transcoding" and once with
MGCP="--disable-mgcp-transcoding". The configure.ac does not have this
parameter, so let's remove the confusing variable.
This is in preparation for describing all environment variables used in
jenkins.sh (follow up commit).
Change-Id: I6223afef0f34d90170a691d7d5b1d9542c34c6b0
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I504f05a49721f2dfe105b6c5fd1995c4e7a0be9c
See also Ia6fe5ead4b601931c1bf41b29fc1b237aac37d2c in osmo-mgw.git, which
changes the initial single-character implementation to match this specification
of string tokens separated by spaces.
Change-Id: If15a88c3b5b40fd1d24ad0f94f3231f678669ab1
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Change-Id: I79804ec0e61cc19a679f079a083a5ea2ea3ee2de
Add a counter group for DLCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of DLCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'
While here, rename MGCP_MDCX_FAIL_DEFERRED_BY_POLICY to
MGCP_MDCX_DEFERRED_BY_POLICY; we have decided that deferred connections
aren't failures, and this keeps names used by DLCX and MDCX in sync.
Also remove some allocation failure checks with OSMO_ASSERT(); such
checks aren't en vogue anymore.
Change-Id: Ie0dde2faf02fd68a69f986973d39b1bea367039b
Depends: I80d36181600901ae2e0f321dc02b5d54ddc94139I
Related: OS#2660
Even though osmo-mgw advertises the -s option, the getopt configuration lacks
-s and that option does not work. Thus the osmo-mgw.service file that uses -s
was unable to start.
Add 's' to the getopt configuration, fix -s and hence also fix the .service
file.
Change-Id: I6f298aef73eb3486d04706910e9fdbaaebaf2481
The function that parses the LCO uses an internal buffer to store the
codec name that has been issued via LCO. This buffer is only 9 byte
long, this means an 8 character string can be stored. If a codec name
exceeds this limit it gets chopped. For example "GSM-HR-08" becomes
"GSM-HR-0", which may mess up the codec negotiation.
- Increase the buffer from 9 to 17 byte.
Change-Id: I17ce7acde1f23ab1394227d74214fe2a55cd2264
Related: OS#3673
Add a counter group for aggregated RTP connection statistics.
This group contains RTP counters which aggregate values of the
ephemeral RTP counters maintained per connection (mgcp_conn).
This provides a global overview of RTP processing for each
trunk throughout the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'.
While here, fix a typo in an item of the mgcp_conn_rate_ctr_desc array:
"rtp:octets_rx" was displayed for outbound packes; now says "_tx".
Change-Id: I80d36181600901ae2e0f321dc02b5d54ddc94139
Related: OS#2660
Add a counter group for MDCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of MDCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'.
Change-Id: I79c27425ba40c3a85edc6cd846cba325d847298c
Depends: Ia2004f8063f3a50b5d7a838ebe8a784a47fcc50d
Related: OS#2660
Add counters for error conditions which I overlooked in
commit 1e174875bf
Change-Id: Ia2004f8063f3a50b5d7a838ebe8a784a47fcc50d
Depends: If4f097c5e441914eaa24c7657813ebb3f9a49916
Related: OS#2660
Use a local variable to shorten the length of rate counter names.
Cosmetic only; no functional change.
Change-Id: If4f097c5e441914eaa24c7657813ebb3f9a49916
Related: OS#2660
Make the 'mgcp show stats' VTY command display TX/RX counters
for an RTP stream. This command was already showing the counter
for dropped packets from the same counter group, so it seems
natural to display other relevant counters in the group as well.
Change-Id: I1313e64d7d8b49964f21fc8d213cba6c9fb6c7cf
Related: OS#2660
Add a counter group for CRCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of CRCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
For example, after running the TTCN3 mgw test suite, the counters show
the following values:
OsmoMGW> show rate-counters
crxc statistics:
crcx:success: 88 (0/s 88/m 0/h 0/d) CRCX command processed successfully.
crcx:bad_action: 0 (0/s 0/m 0/h 0/d) bad action in CRCX command.
crcx:unhandled_param: 1 (0/s 1/m 0/h 0/d) unhandled parameter in CRCX command.
crcx:missing_callid: 1 (0/s 1/m 0/h 0/d) missing CallId in CRCX command.
crcx:invalid_mode: 1 (0/s 1/m 0/h 0/d) connection invalid mode in CRCX command.
crcx:limit_exceeded: 0 (0/s 0/m 0/h 0/d) limit of concurrent connections was reached.
crcx:unkown_callid: 0 (0/s 0/m 0/h 0/d) unknown CallId in CRCX command.
crcx:alloc_conn_fail: 0 (0/s 0/m 0/h 0/d) connection allocation failure.
crcx:no_remote_conn_desc: 1 (0/s 1/m 0/h 0/d) no opposite end specified for connection.
crcx:start_rtp_failure: 0 (0/s 0/m 0/h 0/d) failure to start RTP processing.
crcx:conn_rejected: 0 (0/s 0/m 0/h 0/d) connection rejected by policy.
OsmoMGW>
These same counters are now also shown by 'show mgcp stats'
in the context of the trunk which they belong to.
With input from Philipp Maier.
Change-Id: Ida82fc340d5c66180e5fe9a0d195e9be6dc64c61
Related: OS#2660
in_addr consists only of s_addr, which is an integer type that
can be compared directly. By avoiding memcmp() here we would have
been able to catch Coverity CID#188874 even without Coverity, and
make the code more compact...
Change-Id: Ic6105d39ae2fb4b301f87448b16763fe9f695621
We were comparing 16 bytes (sockaddr_in) in memcmp() rather than using
four bytes (struct in_addr in mgcp conn end).
This is a good example why we should actually simply use the == (equals)
operator rather than using memcmp which treats everything as void.
Change-Id: Ic64256619ef893d625400e8b1b573ea2c629ed9c
Fixes: Coverity CID#188874
* Refactor code to have unified checks on all paths activating Osmux.
* Improve checkings at activation time and add logging.
* Code now enforces endp osmux status to be enabled before processing
the frame through endp->osmux.out. Before, a delayed or bad pkt could
arrive and be processed by an endp with osmux not enabled, using
endp->osmux.out that was not initialized and ended up crashing:
libosmo-netif/src/osmux.c:281:3: runtime error: member access within null pointer of type 'struct msgb'
This could also happen if a BSC started sending or we received (non legacy dummy) osmux
frames before we received the BSC CRCX ACK agreeing on osmux negotiation
and switching to ACTIVATING state.
Related: SYS#4350
Port from openbsc 4a2cc9eb0a0f9424c16b26fcb757483a39d67482.
Includes fixup from openbsc I438349bffaa46a10ad8983090a4b17aed7e00d82.
Change-Id: Iac11e447ec0d76e4e74ec982a6e3f63b35548978
State ACTIVATING is set once negotiation between the 2 parts went
successfuly.
Port from openbsc 96bd7b075a59eb051079152241b127ca944b0781.
Change-Id: Ic56eda1251be41369d869e687a1cf955df2c6d61
Prior to this commit, the check was only done on legacy dummy frames.
Port from openbsc a42d4584fd01c9cd1021fab609bdaaafe859c13a.
Change-Id: I5b6606d72a9f5ae593a8e3ab5fbbe7e1e5a0ae11
Otherwise we end up in a weird state where we have timers set up but
osmux is still flagged as not enabled.
Cherry-picked from openbsc cad739d2386640a68c24e3d470ddacdcaf377561.
Change-Id: I0a334842463d311bc80a980e60fb702a0a9ad610
Since that define is already used to allocate size of osmux_cid_bitmap,
let's use it here too instead of hardcoding its value.
Change-Id: Ib2e4febee8bc6bcc035ad0a65c5c1eb94ef5e6fb
Right now it's not a big issue since OSMUX_CID_MAX is 255, so 255+1 is
256 which fits array boundaries correctly (multiple of 8). However, if
for example OSMUX_CID_MAX was modified to be 12, 12+1/8 = 1, so we'd
have an undesired memory access when accessing last 4 CIDs.
A +1 should be kept on top, because OSMUX_CID_MAX specified the maximum
number used by a CID, that is (0,OSMUX_CID_MAX), and as a result we
require OSMUX_CID_MAX+1 slots.
Change-Id: Iaf9b93712dbd2a862b01e70dd8e11893bfa6b24c
osmo-bsc-mgcp was removed recently from osmo-mgw.git as it belongs to
openbsc.git.
This symlink was a leftover from that time.
Change-Id: Ifdcb266efd821eac9d90aff186400f85751e8f42
When the peer address is still 0.0.0.0, the endpoint is not yet configured.
This commonly happens before bridging a call is complete, so instead of ERROR
logging about an invalid packet, rather INFO-log this as "early media".
Related: OS#3539
Change-Id: I335f6453bd599be76eef08fcf9e5daed071e5b6d
The Connection Identifier is defined as a hex string, so clients may send the
ID back with or without leading zeros. Ignore all leading zeros when comparing.
A specific SCCPlite MSC is observed to DLCX with Connection Identifier with
leading zeros removed, which would mismatch pefore this patch.
Extend test_conn_id_matching() in mgcp_test.c to include leading zero tests.
Now, mgcp_conn_get() would match a valid id with *any* amount of leading zeros,
even if that far surpasses the permitted conn id length. Valid lengths of
incoming conn ids should be and is checked elsewhere.
Related: OS#3509
Change-Id: If55a64a2da47b6eff035711c08e4114d70dbec91
The Connection Identifier is defined as a hex string, so clients may send the
ID back in lower case. Convert to upper case before comparing.
A specific SCCPlite MSC is observed to DLCX with Connection Identifier in lower
case, which would mismatch pefore this patch.
Add test_conn_id_matching() in mgcp_test.c to verify case insensitivity.
Cosmetic: use strcmp(), not strncmp(). In the presence of a terminating nul as
we can assume here, this makes no functional difference, but it clarifies the
code.
Related: OS#3508
Depends: Ib0ee1206b9f31d7ba25c31f8008119ac55440797 (libosmocore)
Change-Id: I8e52278c3abe9e9c8c848c2b1538bce443f68a43
Reduce the number of hex chars generated as Connection Identifier from 32 to 8.
According to RFC3435 2.1.3.2 "Names of Connections", the maximum length is
indeed 32 characters, but there isn't really a benefit of using IDs of that
size. That, and:
A specific SCCPlite MSC is seen to be able to store conn IDs of up to 8 hex
characters of length. If given more than that, it will later send 'ffffffff' as
ID, e.g. in the DLCX message, causing mismatches and rejected DLCX.
Conn IDs need to be unique only within the context of one endpoint, so
producing 32 characters of ID is far beyond overkill, especially if we
currently expect exactly two IDs per endpoint.
Notice that the maximum length of conn ID that can be handled by the message
parsing and composition doesn't change, only the length that an osmo-mgw will
generate upon CRCX does.
Related: OS#3507
Change-Id: Ia290c22a91fca0e5aa44515fca6df00064aff100
MGCP_CONN_ID_MAXLEN actually includes a terminating nul, so we need to compare
strlen() against MGCP_CONN_ID_MAXLEN-1.
Log the length if it is too long.
Add MDCX_TOO_LONG_CI test to mgcp_test.c, testing a conn id of 33 characters.
Before this patch, the test returns error code 515 meaning "not found", while
now it returns 510 meaning "invalid", showing the off-by-one. Same is
illustrated by the error log ("not found" before, "too long" now), but the
error log is not verified by mgcp_test.c.
Change-Id: I8d6cc96be252bb486e94f343a8c7cae641ff9429
Instead of just -1, return RFC3435 error codes that can be used to compose a
FAIL message response. Note that the return value stays compatible in that it
returns 0 on a valid Connection Identifier, nonzero otherwise.
The idea is to be able to distinguish between "Conn ID not found" and "Conn ID
invalid" in mgcp_test.c's expected output, in upcoming change
I8d6cc96be252bb486e94f343a8c7cae641ff9429.
Change-Id: Ifc17f2893cc4b9a865f3ffcb9888bbf1039337a6
So far, MGCP_CONN_ID_LENGTH was often used as exactly the length of the
Connection Identifier. To indicate this length as a maximum, introduce the
MGCP_CONN_ID_MAXLEN and use it everywhere. Keep the old name as an alias.
Change-Id: I1117003c7614e98535d5c201d002e459c01bdc3f
Instead of just silently truncating the conn ID if it is too long, rather
verify its length and return an error where applicable.
Adjust expected test output.
Change-Id: If2a1aab1f13e771a6705c430e3c75bd42477a23b
Add a full length (32 characters according to spec) conn ID in a CRCX response,
as well as a too long one.
The too long one is currently silently truncated, a subsequent patch will
improve on that (If2a1aab1f13e771a6705c430e3c75bd42477a23b).
Change-Id: I5f2d52f086ea2d330fcce88a176488ace972bf79
The separator between MGCP and SDP section is typically "\r\n\r\n". For some
reason the test so far used "\n\n" instead, rather use the standard separator.
Change-Id: I41c73722e5fae00663bcf96de0b57b7155809a06
I want to test arbitrary length Conn IDs ('I:'), and hence don't want to pass
the conn_id as int, but rather just include it in the message string. Prepare
for that by eliminating the extra conn_id arg and just pass a params string.
Change-Id: Ib2e718dda3aa1f6e9979dee823d973dd002e2318
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: I4bf7b6124c747a0cff5562187a099c33525e109e
Related: OS#3449
This function is set on conn ID length of 32 characters. Make it detect a
shorter length also when parsing 'o=-' headers. Before, this failed to
recognize a space as the end of the conn ID, now sees any non-hex char as end.
Related: OS#3507
Change-Id: I762c273bac172acb6d0aae6ea6267603ab654cbf
Flip logic to accurately log whether an 'I:' is included, instead of logging
the opposite.
Note that it isn't possible to log the actual conn ID, because they are random
and differ in every test run, which would collide with the fixed expected
output file mgcp_test.ok.
Change-Id: Idcd731b9daf618b97d8f7e6a776266071cd29e08
The change Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57 has replaced the
functions make_crcx_msg_bind() and make_crcx_msg_bind_connect() with
make_crcx_msg() and add_audio(). When a bidirectional connection is
needed, the user calls add_audio() to add the remaining connection
details. Unfortunately add_audio() leaves the conn_mode struct member
unchanged. Which means the connection is still at MGCP_CONN_RECV_ONLY,
which will instruct the MGW not to forward any of the received packets.
- Make sure that conn_mode is set to MGCP_CONN_RECV_SEND when
add_audio() is called.
Change-Id: Id12de37797de5af5cc447642d2fbb1af7de680df
Closes: OS#3511
Adjust the X-Osmo-IGN parsing to use string tokens instead of parsing single
characters.
Reconsidering the first implementation as a poor choice, rather specify the
format of X-Osmo-IGN as any-length string tokens separated by spaces, which is
more flexible and more future proof.
See also osmo-gsm-manuals If15a88c3b5b40fd1d24ad0f94f3231f678669ab1 which
defines the X-Osmo-IGN format as string tokens, matching this patch.
In mgcp_test, add an unknown X-Osmo-IGN item. Though the output is not checked
by the testsuite.at, running manually shows the error log about the unkown
X-Osmo-IGN item.
Change-Id: Ia6fe5ead4b601931c1bf41b29fc1b237aac37d2c
Add VTY commands "show mgcp endpoint NAME" and
"show mgcp trunk <0-64> endpoint NAME" which
show information about specific endpoints.
Change-Id: I5330e697ec34bf215de91d44209048a8dc226d51
Related: OS#2660
The format is
CRCX ...
C: ...
M: ...
X-Osmo-IGN: C
So far the only ignorable element is C, i.e. the CallID. Any other items may be
added in the future.
(I initially intended to also add '@' to ignore the endpoint name's domain
part, but in the osmo-mgw code base the domain part is verified long before any
additional headers are even parsed, so sparing that refactoring for now.)
The intention is that osmo-bsc will issue "X-Osmo-IGN: C" for all SCCPlite
calls, because we are unable to retrieve the CallID that the MSC sends to
osmo-mgw for the network side of the endpoint.
Testing with a specific SCCPlite MSC, I actually observe that all CallIDs are
1, even for concurrent calls. So, an alternative hacky solution would have been
to always pass CallID == 1 for SCCPlite connections from osmo-bsc.
Related: I257ad574d8060fef19afce9798bd8a5a7f8c99fe (osmo-bsc)
Change-Id: Id7ae275ffde8ea9389270cfe3db087ee8db00b51
Both make_crcx_msg_bind() and make_crcx_msg_bind_connect() were mostly
identical. Rather, compose the CRCX bits in one common function and just add
the audio bits in another.
Prepares cosmetically for adding X-Osmo-IGN header.
Change-Id: Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57
HACK: for IuUP, we want to reply with an IuUP Initialization ACK upon the first RTP
message received. We currently hackishly accomplish that by putting the endpoint in
loopback mode and patching over the looped back RTP message to make it look like an
ack. We don't know the femto cell's IP address and port until the RAB Assignment
Response is received, but the nano3G expects an IuUP Initialization Ack before it even
sends the RAB Assignment Response. Hence, if the remote address is 0.0.0.0 and the
MGCP port is in loopback mode, allow looping back the packet to any source.
None of these are anything near nice, during call setup using a 3G femto cell,
we still lack a proper IuUP handling. See OS#2459, OS#1937. This is merely a
temporary hack to maintain 3G voice usability in a quick and dirty way.
Related: OS#3411
Change-Id: Ib25e6261855eae8ddb8d1c0b8838cc3e30332cf1
Make the 'domain NAME' vty doc more descriptive, and add the hint that '*'
means any domain.
In check_domain_name(), exit early in success if the configured domain name is
'*'.
(Do not implement other wildcard functionality for partial matches or the
like, just the single '*'.)
Related: OS#3490
Change-Id: Ie0220c88d2f5cee15f2a90390b3c4590ac61d5eb
If no endpoint was found, assert that the cause code indicates error, so that
the remaining code path doesn't assume finding an endpoint was successful.
Also fix find_endpoint() to return an error cause (not 0) in case it finds the
domain name to be wrong.
After this, the error described in OS#3488 simply results in a CRCX failure,
not in a program crash.
Related: OS#3488
Change-Id: I87e2d76c22603d6fef89907c3cf8f7965abf35a0
When the user has set a local port for the mgcp client we want the
client to exit if this port is already occupied. If no port is set the
IETF default port is configured automatically. When we find this port
occupied we try up to 100 times the next port to find a useable port.
Since the for loop that controls the attempts always sets the port
config it uses for its checks it will mistakenly assume that the user
has set a port on the second cycle.
- Make sure we only check for the default port in the first cycle
Change-Id: Ic1fd1018d68fcac94961321615bfdd726465532d
The function mgcp_write_response_sdp() is responsible to write the
audio port and the list with the supported payload type numbers to
the sdp response. At the moment it can only write exactly one payload
type number to the response, but in the future we may want to write
several payload type numbers to the response. Lets add a function
for that so that now.
- add add_audio() helper function to add multiple payload type
numbers, but keep the functionality as it is for now
Change-Id: I662c725f697b2ffb1e3ad4671a445f943cd79b63
Related: OS#3442
The function mgcp_write_response_sdp() generates the rtpmap lines in the
sdp response. Since we will likely support multiple codecs we will need
to generate several rtpmap lines. Therefore it makes sense to split up
that part in a separate function without altering the overall
functionality (yet)
- add static function add_rtpmap() to generate the rtpmap.
Change-Id: I520e2d40fe6294c88bae63dfcbc5238ef98101e2
Related: OS#3442
When we receive a packet, we do not really check the contents. However,
we should at least do some basic checks.
- Check for short RTP packets
- Check if the length field of RTCP packets seems plausible
- Check if the packet type of RTCP packets makes sense (IANA)
Change-Id: Id47b9eee2164c542e6b673db24974859dd0a7618
Related: OS#3444
At the moment all packets that are sent with mgcp_send are fed into
mgcp_patch_pt(). This functions corrects the payload type so that it
matches the codec configuration on the egress side. However, this
functions is only to be used with RTP packets and must not be used on
RTCP packets, which we currently do because we do not check if the
packet is RTCP or RTP.
- Check if the packet is RTP before running mgcp_patch_pt()
Change-Id: I55b8aa830e4e23f991373470bd04d4db12241c56
Related: OS#3444
The test function test_multilple_codec() in mgcp_test.c creates a
lot of connections, but it never releases them. Just freeing the
cfg object is not enough since the UDP ports stay open and this
may interfere with other tests that also create connections
(port numbers).
- Make sure all endpoints are released when test_multilple_codec()
is done.
Change-Id: Ic13b4368162149ec36c93f4188fa4c71166e08d5
The IETF has designated port 2727 for call agents (clients). This
works as long as only one call agent is running. As soon as two
call agents (e.g. osmo-bsc and osmo-msc) run on the same machine.
The port numbers will collide.
To avoid such a situation we will first try the IETF port and if
we fail to use it we increment the port number until we found a
usable port. However, we should only do this if the user has not
configured a non standard port. (The rationale behind this is that
if there is a non standard port configured the choice must have
been made conciously by the user and therefor we should fail hard
so that the user gets aware of the problem.)
Change-Id: Iaa5f41fdb43ec6bf4feaefa174fd82622e37d4d0
Related: OS#2874
At the moment the mgcp client uses an arbitrary port as sourceport to
exchange MGCP messages with the MGW. However, IETF has designated a
specific port as sourceport for MGCP clients (Call agents), which is
2727. See also RFC3435, capter 3.5 Transmission over UDP.
- Change MGCP_CLIENT_LOCAL_PORT_DEFAULT from 0 to 2727
Change-Id: I96de84df3a3bf623d98b057ec3f3f621a3330a8a
Closes: OS#2874
Since no transcoding is in place osmo-mgw forwards the incoming rtp
packets as they are (there may be minor modifications of the header) from
an ingress connection to an egress connection.
This works without problems as long as both connections use the same
payload type. For IANA defined fixed payload type numbers this is
usually the case, but for dynemic payload type numbers both ends may set
up the same codecs but with different payload type numbers.
When different payload type numbers are set up, and the packet is passed
through without modification, it will have the wrong payload type when
it is sent. The receiving end may then toss the packet since it expects
packets with the payload type it has configured.
The machanism, which is introduced with this patch looks up actual codec
inside the struct data of the ingress connection and then looks for the
matching codec in the struct data of the egress connection. When it
finds the codec there it looks up the payload type of this codec. The
header of the RTP packet is then patched with the correct payoad type.
- Add function mgcp_codec_pt_translate() to look up the payload type
- Add unit-test for function mgcp_codec_pt_translate()
- Add payload type translation to mgcp_network.c
Change-Id: I3a874e59fa07bcc2a67c376cafa197360036f539
Related: OS#2728
Related: OS#3384
The regular version of the mgcp_client supports the configuration of of
custom payload types. In case some corner cases require a specific
dynamic paylod type number that is not according to 3GPP standards has
to be used the user can override the standard settings. However the fsm
based variant of the mgcp_client does not have that feature but it
should have it as well.
- add struct members for ptmap config.
- pass configuration values down to the underlying magcp client.
Change-Id: If176a3719dd9e888da16196d5fc0bdb53cc2a5f2
Related: OS#2728
Related: OS#3384
Some distributions (archlinux) or versions of libgsm install gsm.h in
/usr/include/gsm/gsm.h
Since libgsm doesn't come with a pkfconfig, let's first check if gsm.h
and take the correct path in the build setup.
Change-Id: I07d3c03903e0d4bb80e843c7ed917a27b791ea53
This check is not in all our repos that use git-version-gen. Indeed it
seems to be a leftover of openbsc where I think it wanted to ensure
being called in the openbsc subfolder or something? libosmocore e.g.
doesn't have it.
In any case .git being a directory is not always true (if using git
worktree) so remove this check.
Change-Id: I83b84099c34d593a8a384f001a8131c2a8085606
We currently still patch over an RTP message to make it look like an IuUP
Initialization Ack specifically for the ip.access nano3G femto cell.
Be more specific about it:
- only patch over RTP in 'loopback' mode. osmo-msc specifically leaves the
endpoint in loopback mode for this hack, so if we're not in 'loopback', then
this hack is out of place.
- only patch over RTP if the header indicates an IuUP Initialization (check for
0xe4 byte).
Change-Id: Ia9ec4debc138b34f6ca6a871a8778eafa6c0ba21
The function setup_rtp_processing() in mgcp_protocol.c executes a
function pointer setup_rtp_processing_cb(). The function pointer
gets two struct mgcp_rtp_end pointers as parameter. To get those
parameters it has to dereference them from struct mgcp_conn_rtp
pointers. The variable conn_src is such a struct pointer and there
are conditions where this pointer may be NULL. The function at the
function pointer should get the conn pointers directly instead of
the dereferenced end (rtp) pointers. This also gives additional
flexibility to the implementation behind the function pointer,
which is not yet defined (the function pointer points always to
a stub function since we donot support transcoding yet.
- give conn pointers directly to setup_rtp_processing_cb() insed
of dereferencing conn_src->end
Change-Id: Id46e9bfba88613387026639eb4957221cce6820a
Closes OS#3406
When creating the mgcp statistics (DLCX) and also when printing
values in the VTY. The printf placeholder %lu is used. However,
this is not portable when the same code is compiled on a machine
with different integer size (e.g. armv7).
- Use PRIu64 when printing ->current value of the rate counters
Change-Id: Ifb8944cec83868845f74ad84551eb090f812daf8
In struct mgcp_rtp_end one finds unsigned int counters. Those should
be replaced with libosmocore rate counters
- replace packets_rx, octets_rx, packets_tx, octets_tx and
dropped_packets with libosmocore rate counters.
Change-Id: I47c5c9006df5044e59ddebb895e62adb849d72d5
Related: OS#2517
The struct member rtp_process_data in struct mgcp_rtp_end is
unused and should be removed
- remove rtp_process_data
Change-Id: I3a66d159ce32359621ff2e772ee3421340b78cd5
There has obviously been a misunderstanding on how the doxygen comments work.
A comment marked '<' is for placing a comment *after* a member, to point back
to the item before it, typically
enum foo {
thing, /*!< this is a thing */
a_bobby,
}
It does not make sense to place these above the item they are describing.
We actually don't use doxygen in the osmo-mgw build, but if we have doxygen
syntax, we might as well have the correct one.
Change-Id: I9e8ea0e3bd5ae5fcc0a6fae8e26e11baa8f35e27
The current implementation does not support any way to influence the
codec that is negotiated via SDP or LCO. The client statically
negotitates AMR on an invalid payload type number. Also we ignore
any codec information in the responses.
- Add struct members to allow setting of user defined codec information.
- Add struct members to retrieve parsed codec info from responses.
- Add code to generate codec information in SDP
- Add code to parse SDP codec info in MGCP responses
Change-Id: I78e72d41b73acfcb40599a0ff4823f17c3642059
Related: OS#2728
Related: OS#3334
The codec negotiation via SDP is currently in a neglected state. Also
osmo-mgw does some kind of codec decision wile the SDP is parsed, the
result is information for one codec, even when there are multiple codecs
negotiated. This is problematic because we loose all information about
alternate codecs while we parse. This should be untangled and the
information should be presevered. Also we are not really capable
picking a default. Wehen we do not supply any codec information (not
even LCO), then we should pick a sane default codec.
- separate the codec decision from the sdp parser and concentrate
codec related code in a separate c file
- add support for multiple codecs in one SDP negotiation
- do not initalize "magic" codec defaults during conn allocation
- do not allow invalid payload types, especially not 255. When
someone tries to select an invalid payload type, do not fail
hard, just pick a sane default.
- handle the codec decision in protocol.c, pick a sane default
codec when no (valid) codec has been negotiated (no LCO, no SDP)
Change-Id: If730d022ba6bdb217ad4e20b3fbbd1114dbb4b8f
Closes: OS#2658
Related: OS#3114
Related: OS#2728
Return the CI string allocated by the MGW and sent back during CRCX ACK.
So far the CI that identifies one connection of an MGW endpoint is "hidden"
behind mgcp_conn_* API. This CI string is however very interesting, for
logging, to be able to correlate with MGCP messages in network traces.
For osmo-bsc, there is an upcoming mgw_endpoint_fsm that will log the CI string
using this function.
Change-Id: I0c802c0cc3fa0aae9558bd7f15aad1cb9a8b12b2
At the moment osmo-mgw will accept multiple lco options. (e.g.
p:10, a:PCMU, p:10) If LCO appear multiple times, than the first
appearance of will be parsed and used, all following appearances
will be ignored. However, having multiple appearances of LCO is
illegal and affected requests should be rejected. Also osmo-mgw
should reject illegal formatted LCO strings
- make sure that multiple appearances of LCOs will be rejected
- make sure that illegal formated LCOs are rejected
- add testcases with garbeled LCO and valid LCO examples
Change-Id: Iae2fddfa5f2bcfc952f8ab217b3056694e5f7812
Closes: OS#3119
In the current implementation the LCO parameters are reset. This means
that an MDCX without LCO will reset the LCO that have previously set
via CRCX. But according to RFC 3435 6.8 LocalConnectionOptions, the
LCO parameters should be preserved or left at their defaults if missing.
- Make sure LCO are retained if no LCO string is present.
- Also preserve the values of individual parameters if missing.
Change-Id: Ia0d73f61516618317dcd1d49384818fd8de27aa6
in mgcp_rtp_codec_init() tallo_free is called after codec->subtype_name
and codec->audio_name are set to NULL. So talloc_free() always sees
NULL-pointers and never frees anything. This may cause a memory leak.
- call talloc_free() first, then set pointers to NULL
Change-Id: I7373819c3689d34811846f6f48f27568297b26e4
"unable to create connection resource error" sounds a bit strange.
Lets just output "unable to create connection".
Change-Id: Ibef16b455f2e122c8e5ff95240c4d7a654c56a39
It is legal to create connection without setting the destination
ip and port (this usually done later through MDCX). However, if
some other connection tries to deliver an RTP packet through a
a half open connection, then the fact that no destination ip is
set is logged as error even if it is a pretty normal situation.
- Check if destination ip and port are set to zero. If yes, we
assume that the destination connection details are intentionally
not set yet. Only when one value is set and the other one not,
we log an error. Otherweise we log a message to debug.
Change-Id: If96e5a60b8ab92259d3bddaa143121893bb6c525
Related OS#3104
Starting connections in loopback bode may cause confusion at the
receiving end when the connection is switched from looback into
an actual send-receive connection. The reason for this is by this
the SSRC of the RTP stream will suddenly change. For the majority
of usecases it is not necessary to loopback the incomming packets
back to the receiver in the beginning. So lets use receive-only
as a safe default.
- use MGCP_CONN_RECV_ONLY instead of MGCP_CONN_RECV_LOOPBACK
Change-Id: I44178434ee497bc1d5e9d5f6d92c13c1a09ae241
Related: OS#3104
The function allocate_port tryes at least 200 different ports when
a new port is allocated. Since after every allocation the port
number is incremented the allocation should be able to allocate
a port with the first attempt. However, the number 200 is an
arbitrary number and it will not cover the whole port range in
most cases.
- Make sure that in the worst case at each port in the range
is tryed once, not only the next 200
Change-Id: Ic47f09869eaddd4aea817bb2517362883d65d029
Related: OS#2825
The alt_codec field is not used anywhere in the code
- remove unused alt_codec field
Change-Id: I5ff2899e3e61f33eb86f284b50ad8a94a949ed16
Related: OS#3114
The VTY command that sets the RTP port range does not check if the data
entered by the user actually makes sens. Also it allwos to configur a
range that starts at 0.
- Make sure 0 can not be used as start or end of the range
- make sure the end port number is always greater then the begin
port number
- Autocorrect uneaven port range beginnings to one port number before to
ensure the range starts at an even port number
- Autocorrect even port range ends to the next odd port number to
ensure the range ends at an odd port number.
Change-Id: Ib1312acba4f03f378594dbbeb4f31afd891d68d7
Related: OS#2825
This commit actually doesn't fix the entire code, since anyway osmux
conns are not supported and mgcp_conn_get_rtp() will return NULL.
However, it makes the code more logical and easier to understand once
somebody refactors the code to make it work again.
Change-Id: Ib57e12e5a36b5842c40673c236907bbcbfc390f3
Older ones are being deprecated as they may generate interleaved
packets.
This commit is a forward-port of openbsc.git Change-Id
I189564fc63139c15314db8975afd423c7153ea32.
Change-Id: I9b8a19e5b8d62deaa9bbb92d49d99e8c33b7e345
Default usage values are defined in mgcp node, and can be per-BSC
overriden on each bsc node
This commit is a forward-port of openbsc.git Change-Id
Ibf3932adc07442fb5e9c7a06404853f9d0a20959.
Change-Id: Ie19a64ac09f9d51f2434ad0d7925610fc919a90e
The two counters: in_stream.err_ts_counter and out_stream.err_ts_counter
are still handcoded. To make them better accessible they should
be replaced with libosmocore rate counters.
- replace state.in_stream.err_ts_counter with libosmocore rate counter
- replace state.out_stream.err_ts_counter with libosmocore rate counter
Change-Id: I9fbd65bf2f4d1e015a05996db4c1f7ff20be2c95
Related: OS#2517
The struct state->out_stream.ssrc is initalized by first initalizing
state->in_stream and then copying state->in_stream over to
state->out_stream. This works as long as no pointers to other objects
are added to struct mgcp_rtp_stream_state but we may add pointers to
struct mgcp_rtp_stream_state in the future.
- Initalize out_stream and in_stream independently from each other
Change-Id: I5deb27e609448ee0b9f7034e644ae96f1e57887a
Related: OS#2517
The two counters: in_stream.err_ts_counter and out_stream.err_ts_counter
are still handcoded. To make them better accessible they should
be replaced with libosmocore rate counters.
- replace state.in_stream.err_ts_counter with libosmocore rate counter
- replace state.out_stream.err_ts_counter with libosmocore rate counter
Change-Id: I67aa7a8602f60366ef3ba2c5b1319b1b85719f64
Related: OS#2517
The function mgcp_conn_free() holds a few lines to de-initalize
members which are struct mgcp_conn_rtp specific. Since we already
have an mgcp_rtp_conn_init() that does the intialization, we should
have an mgcp_rtp_conn_cleanup() too.
- add function mgcp_rtp_conn_cleanup() and move rtp specific
code to that function.
Change-Id: Ib9bf6d2a3af4f1df1a4ab5ec789b39a2cee2532f
The function mgcp_rtp_codec_reset() is soley called from
mgcp_rtp_conn_init(), lets change the prefix here to _init too.
- rename mgcp_rtp_conn_reset() to mgcp_rtp_conn_init()
Change-Id: I246aabc896089c1f2b3d0409ec3422a85e43575c
The function mgcp_conn_alloc() calls mgcp_rtp_conn_init() to initalize
the RTP specific members (union u.rtp) but also touches u.rtp directly.
This should not be the case, only mgcp_rtp_conn_init() may touch the
union depending on which type of RTP connection is initialized
(currently there is only MGCP_CONN_TYPE_RTP).
- let mgcp_rtp_conn_init() set the backpointer to the generic
conn part.
Change-Id: I6f806f9bfa71b446c15bdc34ae59d2bc1cd10d7e
Note: This is merely a cosmetic change.
We do allocate connections dynamically and we initialize them
once by calling mgcp_rtp_conn_reset(). Calling this a reset
function implies that the reset happens multiple times while
the struct lives. This is not tha case, so lets change the
suffix to _init()
- rename mgcp_rtp_conn_reset() to mgcp_rtp_conn_init()
Change-Id: Ie48b575ff81c8f48afcc25f485967e011e90027b
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: Ia66aa48e957f4dcbdf8a7df3010b84f472c33f76
The enum defining the event and state identifiers is prefixed with
"bsc_".
- coose a more conceise prefix
Change-Id: I662d8e4328911610e7d1943f1b623e96c3a8b3c1
The FSM lacks a proper definition of the FSM event names. This causes
problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Change-Id: Ic0990abea2e9fd92546e7b337b5ff3d6f0866321
Related: OS#2924
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in libosmo-mgcp-client's VTY interface.
Change-Id: If772edc304a9f342a57fb548f26908256cc9e6e5
Related: OS#2967
After call to mgcp_find_section_end(), actually check the proper variable to
evaluate its return value.
Show in mgcp_client_test output that the parsing errors are fixed, and enable
the assertion that no tests should fail.
Change-Id: I62a2453cd9e2e7d5408423161fa65ec9c9989f98
The mgcp_response_parse_params() is in a jumble. Straighten out these cosmetic
issues:
- Move assertion of r->body close to its first use.
- Instead of a talloc_zero and osmo_strlcpy dance, simply use talloc_strdup().
- Drop the first unused invocation of mgcp_find_section_end().
- Drop unused assignment of data_ptr = data.
- In the log, mention "SDP" to clarify.
- Add a comment clarifying how we skip the section marker.
Change-Id: Icf1df761270777a142bc8ace75f2a10918314f73
To show how the current code fails, add test_sdp_section_start() to
mgcp_client_test.c, and temporarily accept failing output. This will be fixed
in change I62a2453cd9e2e7d5408423161fa65ec9c9989f98.
Change-Id: I5c6d3566b8f6dbf04c0cd8b127423f5295c19f8d
Otherwise we get Osmux stats during a session using RTP, which is
confusing.
Forward-ported from openbsc e39e18992a3b966581f06fa632d6342643996aaa.
Change-Id: I9031350242dd37ce255631c20eed33976887faa6
the client API is not very intuitive and requires a lot of extra
care when it is used from an osmo-fsm.
- Add an FSM that permits comfortable handling of an MGCP
connection.
Change-Id: I887ce0c15a831dffeb6251a975337b83942af566
Since we will support multiple different types of endpoints in the
future, all these endpoints will handle connections slightly different
and there will be possibly state that needs to be kept consistant
when a connection is deleted.
In mgcp_network.c where we implement the callback that is used to
create an rtp-bride-endpoint. In that callback we cache the pointer
of the connection we where we want to bride to (opposite connection).
When one of the connections is deleted using a DLCX operation, the
pointer is still there and the next incoming packet causes a use-
after-free segfault.
- introduce an endpoint specific callback function that is executed
before removing the connection.
- implement the endpoint specific callback for rtp bridge endpoints,
so that the use-after-free is prevented.
Change-Id: I921d9bbe58be1c3298e164a37f3c974880b3759f
When a wildcarded request is made with a DLCX or MDCX command
the MGW will search for a free endpoint and continues the command
execution with that endpoint.
- Catch the wildcarded request early on DLCX and MDCX and return
with an error code.
See also TTCN3 testcases:
MGCP_Test.TC_mdcx_wildcarded
MGCP_Test.TC_dlcx_wildcarded
Change-Id: Ia77d44a6a86083e62338e5845b553e5cf13ebd10
This is an internal library simmilar to 'libmsc' in osmo-msc, which
we don't expect to be used by other programs except osmo-mgw. Hence,
there's no need to install it as a shared library, which introduces
requirements about ABI/API stability and the like.
osmo-bsc_nat uses libosmo-legacy-mgcp, and once we should rewrite
osmo-bsc_nat, we might need some of the libosmo-mgcp related functions,
but at this point it's unclear what exactly would be needed and if
current libosmo-mgcp can provide that. As needed, we can introduce
a related shared library at that point.
Change-Id: Iba0a2c9c694e360356ac2ca584e97795281c6198
When a wildcarded CRCX is done flag "wildcarded_crcx" is set in the
endpoint struct. The flag tells other part of the code whether the
request was wildcarded or not since in some cases the behaviour
might be different for wildcarded requests. The implementation of
this mechanism is not entirely correct. The flag is set on wildcarded
requests but on non wildcarded requests it is not reset. Also the
name is misleading.
- rename wildcarded_crcx to wildcarded_req
- ensure the flag is refreshed with every new request
Change-Id: Ia5063ec65f5bc3a8a0943d1fd823aaeee20b8637
The connection mode setting (e.g. recvonly) is not checked on CRCX
and MDCX. This allows requests that set the connection mode to
sendrecv or sendonly without ever configuring the remote end of
the connection (half-open connection).
- reject sendrecv or sendonly on half open connections
See also TTCN3 Test:
MGCP_Test.TC_crcx_early_bidir_mode
Change-Id: I6ab01855d3b1faa36aebac357e7b97c563990678
Related: OS#2652
The final log lone in find_endpoint() lacks the \n causing a messed
up log output.
- Add missing \n
Change-Id: I97fca654b199dfb7aae2359322a56c6d0bae9599
When set_local_cx_options() returns an error code the MGCP command
execution is aborted and and the error code is returned, but on
CRCX the already seized eindpoint is not released.
- Do not generate the error response on the spot, jump to the
respective label and let the already existing error handling
do its work.
This patch is a follow-up page to:
Change-Id I02aaa3042f2a0e32eb4ec6b8753deab7082947a0
Change-Id: Iaef4ea6c6a2f24ac8b276966bda72d0b30f25cd5
Related: OS#2654
When an unsupported MGCP parameter (e.g. N) is used, then this
parameter is ignored and the command execution continues. However,
an MGCP command that contains an unsupported parameter should
be rejected.
- Make sure that MGCP commands DLCX, CRCX and MDCX are rejected,
when they contain unsupported parameters.
Change-Id: I8cd5987fc6befcd53a7c4916f77b1a24c904ba48
The short term of endpoint has always been "endp" througout the whole
project and not "ep".
- rename mcgp_ep.c to mgcp_endp.c
- rename mgcp_ep.h to mgcp_endp.h
Change-Id: Id52047bb2d0407655ac272c858ed3412b8ae9e6d
In order to allow clean prefixes for future endpoint related
functions the "rlease" should be moved to the end of the
function name.
- rename mgcp_release_endp to mgcp_endp_release
Change-Id: I22e938e702f57ad76d38c9f4a1370b110ac1ba11
The endpoint and the define that computes the endpoint number is
defined in mgcp_internal.h. Since we have a dedicated module for
endpoint related code it makes sense to move the endpoint related
parts there.
- move struct mgcp_endpoint to mgcp_ep.h
- move #define ENDPOINT_NUMBER(endp) to mgcp_ep.h
Change-Id: Ibae55e1859bd41e2d1918eda433418b4bf8365fe
The struct that holds the parsing results of the MGCP response is
allocated on the stack. However, it would make sense to allocate
the struct dynamically on the heap. This also would provide a
talloc context that is in reach on most places of the code.
- Allocate struct mgcp_response dynamically in mgcp_client_rx()
- Use struct mgcp_response as talloc context for temporary
allocated memory while parsing the response.
Change-Id: I5099abe68b580c75b47bc797bf93f01084f0c4db
The client library should be usable to all GPLv2/v3/AGPLv2/v3 programs,
so like our general project practises, let's put it under
GPLv2-or-later. I believe this was unintentional from the beginning.
Our general policy has been:
* libraries under GPLv2-or-later
* applications under AGPLv3-or-later
Change-Id: I29ed7edc510dba67d28b9247aecb4d6d5d25cc0c
When all endpoints are seized and a call agent tries to allocate
another one, then 500 is returned as response code, which means
that the endpoint was not found. This does not match.
- Return 403 which is defined as "Insufficient resources available
at this time"
Change-Id: Idf241b47e711e35e9f9b5a43f3cea5c0298ea30b
When a wildcarded CRCX is done, then the endpoint number is
returned as unsigned integer (%u). This results into problems
with endpoint numbers higher than 9.
- Return endpoint identifier with the endpoint number in
hexadecimal representation
Change-Id: I504f4658c193009347753b15256dbb46b32ad5a4
The function mgcp_msg_gen() does only check if the user supplied
an endpoint name or not. The user may still supply an endpoint
name that does not contain the separator (@) character.
- Refuse to generate the message if the endpoint name does not
contain any @ character.
Change-Id: I92dd1556e4a26b4bef8e1c8c57141552abf988ca
At the moment the client does not check if the endpoint identifier
that is returned from the MGW actually contains an @ character.
- Check if the endpoint id in the response contains an @ character.
Change-Id: I6073419a4b6cdcd31880672564f0861cb4bd02f5
When the client gets a specific endpoint identifier (Z) in a
MGCP response it just accepts the identifier even when it is
not specific (contsins wildcard characters). In those cases,
the client should refuse to parse the response.
- Check for wildcards in endpoint identifiers and stop
parsing when check is positive.
Change-Id: Ic94bd8c025b7b3eb006b639fecfd7282194e504a
When the local connection options in an MDCX or CRCX request
are parsed, then the packetization interval is not checked.
- Check if the packetization is a multiple of 20ms
see also TTCN3 test: MGCP_Test.TC_crcx_unsupp_packet_intv
Change-Id: I02aaa3042f2a0e32eb4ec6b8753deab7082947a0
Related: OS#2654
The parameter ordering of the client responses does not match the
ordering as proposed by by RFC2327, Chapter 6. SDP Specification
- reorder generated SDP parameters so that they match RFC2327
Change-Id: I63cac2ebc982ffead92703c22bf68c7aafa7936c
Some of the line breaks lack the \r character, which leads to an
inconsistancy. While our software and even wireshark does ignore
the problem, other third party implementations might reject those
messages.
- Add the missing \r characters to make the message format
consistant.
Change-Id: I0cd80afae65accd3b4ddc5d82e5d30385879141c
The SDP parameter block must be detached from the regular parameters
using an additional line break (empty line). At the moment this works
because the empty OSMOX variable is added and by this also adds a
line break. It breaks as soon as OSMUX is used again.
- Make clear that no OSMUX variable is added when OSMUX is not in
use.
- Add the extra line break independently
Change-Id: I6261971040db527b96fe79676520ccd7794bd327
While parsing the head of an MGCP response the r->body buffer is
manipulated in order to NUL terminate the extracted comment filed.
- Use a static buffer to store and manipulate the comment field.
Change-Id: Ib273c13d6fe7ee042fb4e3b8ed46ac02602226f6
The function mgcp_response_parse_params() that is used to parse the
SDP parameters edits the content of the r->body.
- Create a local copy of r->body and work on this copy to keep
the original r-body in its original state.
Change-Id: Ia475036f7f3802b1638e0511a5e9162fea1592eb
the virtual trunk is addressed without a prefix (just *@domain).
- reorganize find_endpoint() so that it accepts a prefix when
addressing the virtual trunk.
- do no longer accept wildcarded CRCX requests without prefix
(will not break anything, the feature of wildcarded CRCX is
not in use yet)
- keep the old prefix-less method but print a warning that it is
depreacted.
Change-Id: I2aac3ba0f1f3122dfbb3bf36f74198ecb2b21de5
The mgcp protocol in general allows wildcarded endpoints on CRCX.
osmo-mgw does not support this feature yet.
- when the endpoint name contains a wildcard character, search
a free endpoint automatically
- return the resulting endpoint name in the parameter section of
the mgcp response
- add parsing support for the returned endpoint names
- Be more concious about the parameters that are returned with
each response. Do not unnecessarily attach known parameters.
Return the connection ID only on CRCX commands. Only return
the endpoint ID on CRCX commands that are wildcarded.
Change-Id: Iebc95043569191b6f5fbc8fe266b13fcfcab2e48
related: OS#2631
The mcgp message generator function mgcp_msg_gen() lacks support
for the mandatory SDP fields (v)ersion, (o)rigin, (s)ession and
(t)ime.
- Automatically generate the missing fields when SDP is
generated.
Change-Id: I5fbc31a17e8ac10c7cc5dbc31357b61e8920aaa5
Related: OS#2837
An MDCX without call-id does not make much sense. The call-id is
an integral element of the MDCX message to ensure that the correct
call is modified.
- update the presence check bitmasks to mark the call-id field
mandatory for MDCX requests
Change-Id: Id2bcc3a68139e0d935790bcea2ef91eaf6291aa3
osmo-mgw does not display the IP/Port on which it is listening for
MGCP commands. However, this information can be very helpful when
working with multiple MGCP instances on one machine.
- print IP/Port on which we listen for MGCP commands on startup
Change-Id: Idf5e8b6a7344c4ebaf9b89940456a496b2c23334
The current implementation of mgcp_client.c requires MGCP
paragraphs to be separated wit a \n\n sequence. However,
when the client is used with servers other than osmo-mgcp,
the parapgraph may be formatted differently.
Also allow \n\r\n\r and \r\n\r\n as separator
Change-Id: Ie209fb71499e011e52f58575c6af118de2fdee88
Adding a NUL manually is a common idiom after calling strncpy() because
strncpy() does not always NUL-terminate the string. But snprintf() is
fine.
- remove NUL termination after snprintf in mgcp_send_reset_ep()
Change-Id: I5a1187b13b21b11674f13d3449c730616b0a4ddf
At the moment the MGW has a fixed domain name string that is not even
checked properly.
- Make domain name configurable, use the current "mgw" string as
defualt to maintain compatibility
- Check the domain name with each request. If the endpoint contains
an unexpected domain name, the request must be rejected.
Change-Id: Ia91ac428ba83ac1f9b52a0ec8dbf00ef7876da9e
MGCP_ENDPOINT_MAXLEN is currently only defined for the mgcp client,
since this is in general a common parameter it should be moved to
mgcp_common.h so that both sides can use it.
Change-Id: I9e1c52aa5ebd83b2d9e5178ea24cb27d96cb7ddd
there is a now obsolete constraint that endpoint numbers must
start at 1.
- remove the check to allow also endpoints starting at 0
Change-Id: Iec2f4e36e1ab01ff23875d99e4b0e04af7c1ad98
The osmo-mgw gerrit build is currently failing with the following error:
make[3]: Entering directory '/build/src/osmo-bsc_mgcp'
CC mgcp_main.o
In file included from ../../include/osmocom/legacy_mgcp/mgcp_internal.h:146:0,
from mgcp_main.c:36:
../../include/osmocom/legacy_mgcp/osmux.h:4:33: fatal error: osmocom/netif/osmux.h: No such file or directory
#include <osmocom/netif/osmux.h>
^
compilation terminated.
Let's make sure we're adding the required flags/libs for libosmonetif dependency
Related: OS#2829
Change-Id: I402314532590498a6340dc14101a32b605cd5e09
There's no need for us to use the sockets API directly: We have
pretty nice socket helper functions in libosmocore, let's make
use of them.
Change-Id: I39d47b8a27f683060a2facf2dbecff8d00c19ce9
Previously we
* did not distinguish between the cause of errors in mgcp_header_parse
* common errors were not handled in mgcp_handle_message() but in
individual per-verb functions
Let's centralize the handling of generating error responses and remove
that burden from the individual per-verb handler functions.
Change-Id: I463b27306e10ae3b021583ed102977e7299e5e66
The MGCP client uses hex numbers, while the server side parses it
as decimal. This results in the first 10 calls succeeding, but from
0x0a onwards it of course fails :/
Change-Id: I006f5f5325f0a5069d02fec8912a38d943cfc552
Closes: OS#2784
When a connection is created in loopback mode all incoming
packets should be reflected back to their origin. If the
user did not supply a destination address with the CRCX
command all incoming packets will be tossed because no
destination address is officially known yet.
If there is no destination address set and the connection
is in loopback mode. Then use the originating address of
the incoming packet as destination address.
Change-Id: I3d1abe56d016e28c97f60635eb574679d36e2c52
mgcp_msg_gen() does not check the contents of the prameters that
are handed over with the struct. This may lead to invalid mgcp
messages sent to the MGW, which can be difficult to debug.
Add some additional checks to make a possible problem
noticeable in an early stage.
- verify that the endpoint is not a nullstring
- verify that the connection id is not a nullstring
- verify that the ip-address is not a nullstring
- verify that the port number is a value greater 0
Change-Id: I15c464c4bcdf6e524f68acc62f44186dd7ad19a7
The returncode of get_conn_id_from_response() is unchecked, which
is intentional since some of the test messages will intentionally cause
this function to fail (the response does not inclde a connection
identifier). This means it makes no sense to assert this function
to a fixed value.
In order to spot regressions better print a log message depending
on the return code.
Change-Id: I9bce9ca39b7751b557374b7ab57c6c9005bcdb7d
Fixes: Coverity CID#180534
The CRCX string parameter lacks the quotes and the result of
the function call is not checked against zero. Also the
return code of get_conn_id_from_response() is not asserted.
Fixes: Coverity CID#180534
Change-Id: If4f3ed2c3572da196160569a9705b7a302b700a9
the assertions in the code that handles the connection
lists introduce a lot of unnecessary bloat.
Change-Id: I7badc729e97b76701abbce6a73a1ad1e46d3fee0
The test that tests the cancelation of a pending mgcp message
uses an integer as connection identifier, which leads to a
segfault since connection identifiers are represented as strings.
Use a string as connection identifier.
Change-Id: I395a23c1828cf216031d69d481ad35dd458ee7d4
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
OsmoMSC is in the odd situation that it is already using the new
libosmo-mgcp-client, which is targeted at osmo-mgw, to configure talking to the
old osmo-bsc_mgcp. By removing the bts_base, we break current OsmoMSC.
Removing bts_base makes sense, but let's revert this until OsmoMSC is ready
after merging Ieea9630358b3963261fa1993cf1f3b563ff23538 (which moves the
osmo-msc over to osmo-mgw).
This reverts commit 0be3ce66c0.
Change-Id: Ibce214c2bfc35623097abbb647619426ef3dcc94
The log prints the endpoint numbers as hexadecimal numbers, but
it does not prefix them with "0x".
Add "0x" prefixes to all endpoint number outputs in the log
Change-Id: I284627de02cd140a894445375e9152ff007a71e6
The MGCP connection identifier is allocated by the MGW while processing
the CRCX, see RFC3435 2.1.3.2:. Including/Accepting a connection
identifier in CRCX is "forbidden" as per RFC3435 Section 3.2.2.
So the MGW side must *reject* a CRCX message with 'I' parameter, and
allocate a connection identifier which is subsequently returned in the
response.
Closes: OS#2648
Change-Id: Iab6a6038e7610c62f34e642cd49c93d11151252c
The MGCP spec in RFC3435 is quite clear: Connection Identifiers are
hexadecimal strings of up to 32 characters. We should not print and
parse them as integers on either client or server.
Change the internal uint32_t representation of connection identifiers
to a string representation in the client and also in the server.
Closes: OS#2649
Change-Id: I0531a1b670d00cec50078423a2868207135b2436
There should not be any BTS base port to be configured at an MGCP client.
Possibly this is related to the legacy behavior of libosmo-legacy-mgcp, and
certainly has no place in libosmo-mgcp-client.
Further changes may be needed to follow up on removal of the BTS base port
concept, at least drop it from the VTY for now.
Change-Id: I36e46208d7b75611e5ade3c74d8e1c25870de511
The variable number_endpoints is used as a length indicator
for the array that contains the trunk endpoints at all times.
When osmo-mgw is startet up, the variable is set and osmo-mgw
will allocate the memory for the endpoints. However, it is
still possible to manipulate the variable via the telnet
interface. When the value is increased osmo-mgw might start
using unallocated memory at some point.
Store subsequent changes of number_enspoints in a separate
variable in order to write them to the config file. The
changes will then take effect after a restart.
Closes: OS#2632
Change-Id: I3994af016fb96427263edbba05f560743f85fdd4
mgcp_parse_config() uses a helper function allocate_trunk() to
perform the trunk allocation. This helper function only calls
mgcp_endpoints_allocate() and checks the return code.
Call mgcp_endpoints_allocate() directly from mgcp_parse_config()
Change-Id: Iefdc5b905d76d2cd97f26584261fe5cbefb699cf
osmo-mgw currently uses VTY port number constant of osmo-bsc_mgwp,
however, libosmore now offers a constant specifically for osmo_mgw,
which has the same value, but is intended to be used by osmo-mgw
use the new port number constant for osmo-mgw
Closes: OS#2628
Change-Id: I63c3b300cc9287d1755a3f2c5b5ade7fc6398f6e
Depends: libosmocore I1770787e697906322ce5815fcaadba06c01ddee9
Ensure that all msgb were cleaned up, then free the overall msgb_ctx, in order
to not leave any memory leaks the sanitizer build complains about.
Change-Id: I53373023a6c3f490d6d6cb1c283db5dfb915882c
Ensure that all msgb were cleaned up, then free the overall msgb_ctx, in order
to not leave any memory leaks the sanitizer build complains about.
Change-Id: I84e0ac7f0928f04ffddd7da18200466841589c25
The copyright statement and contribution notices were copied 1:1
from OpenBSC, which is of course not correct for OsmoMGW.
Change-Id: I6143becdd0da589451efcbda530a78f655b7ce0b
sysmocom (specifically Philipp) was doing all the new osmo-mgw
development, but that is not yet reflected in the Copyright statement
for some reason. Let's fix it.
Change-Id: I4cad29daaabec1caec1bd09088414e59fa15a17e
mgcp_conn.c: In function ‘mgcp_conn_dump’:
mgcp_conn.c:248:30: warning: ‘/rtp, id:’ directive output may be truncated writing 9 bytes into a region of size between 0 and 255 [-Wformat-truncation=]
snprintf(str, sizeof(str), "(%s/rtp, id:%u, ip:%s, "
^~~~~~~~~~~~~~~~~~~~~~~~~
mgcp_conn.c:248:30: note: directive argument in the range [0, 65535]
mgcp_conn.c:248:30: note: directive argument in the range [0, 65535]
mgcp_conn.c:248:3: note: ‘snprintf’ output 32 or more bytes (assuming 295) into a destination of size 256
snprintf(str, sizeof(str), "(%s/rtp, id:%u, ip:%s, "
as mgcp_conn->name can already be up to 256 bytes, a total buffer size
of 256 is insufficient!
Change-Id: I5d48132b1358d19fe72e3901117737b09a42c69c
When the library version was bump, the dependency of osmo-mgw
was forgotten.
Change-Id: I3eeafa3c294d9ec71a72fb2833fe3b2bdef05a50
Fixes: e7d27aeae1 ("Tag/Release Version 1.2.0")
Parse the endpoint index from the MGCP messages as base-10, not 16.
If osmo-mgw parses the endpoint IDs as base-16 numbers while OsmoMSC and
OsmoBSC pass in decimal endpoint numbers, the consequence is, for example:
- I configure 32 endpoints in osmo-mgw,
- I tell OsmoBSC to use endpoint range 1-32,
- At some point OsmoBSC may pass in, say, "30@mgw",
- "30" is parsed base-16 and ends up being endpoint index 48, instead of 32,
- OsmoMGW sees that 48 > number_endpoints and barfs.
Related: OS#2633
Change-Id: Ic18608ff23303c1564548a86d5f6bfa539fe555e
There the prefix "net" is a leftover from the time when
there was a bts and a net side. Now we do not distinguish
anymore between the two.
remove prefix "net"
Change-Id: Id627e2ef6f725979ed52a585ca09686e1a049adf
Since currently osmux is not available we decided to lock down the
respective VTY command with an early return CMD_WARNING, making
the code after this line unreachable.
Guard the dead code with an ifdef
Fixes: Coverity CID#178648
Change-Id: I2ad9579453f52fe129cf120801a2efa19a26304e
in point_lookup() the connection pointer is determined using
mgcp_conn_get_rtp() this function may return 0. At the moment
there are no nullpointer checks implemented
Add checks to test for nullpointer.
Fixes: Coverity CID#178662
Change-Id: If9a3c1ac002bc8adc90ca1c1c3dd1db4feea07ac
The function that forwards the tapped (voice ebug) traffic returns
its status (sendto) to the caller. However, none of the callers
seem need this info.
Remove the return code and print an error message on failure
Fixes: Coverity CID#178666
Change-Id: I16c12c4565bccbc0d75c412b43469bf70b6b7ea5
When sending rtp packets sizeof(buf) is used as length. This causes
all RTP packets to be the size of the buffer (4096) containing the
rtp payload and random excess data from previoes memory usage
Use the actual length of the received RTP data, rather then the
full buffer size.
Change-Id: I47a15701f9a7e7a492df183b67ec971f5be61069
Fix errors like "remote bind address", mention 'MGW' instead of 'MGCP gateway',
minor typos and wording tweaks.
Change-Id: Ie1a408f9e651c5fb3424a84ceaaa603e20ad595c
Commit 87203f2a37 renamed some cmds to use
mgw instead of mgcpgw, and added deprecated alias for the old commands,
but forgot to add one for 'mgcpgw bts-base'. This commit fixes
backawards compatibility with old config files that mentioned commit
introduced.
Change-Id: Ib1c58945f4203b05d79f367afb3082b9a6a2c4e3
'mgcpgw' was a working title for the osmo-mgw. Before this takes hold out
there, let's rename the VTY commands to 'mgw'. I'd rather have some local
fallout in our testing environments now than drag the stupid name along.
Keep deprecated 'mgcpgw' commands for backwards compat.
Change-Id: I1d43d42929dc9162e57640499526fb7cadbcfbe6
Currently there are two ways to set the rtp bind ip-address (local
ip address where the rtp streams are bound to). It is possible to
set no set an rtp bind ip, if none no address is configured, then
the ip address where the mgcp service is bound to is used.
On a system with multiple network interfaces it is likely that
there are the remote end is not reachable through the interface
that has been configured. In this case rtp ip-probing can be
enabled via vty option in order to automatically detect the
ip address of the interface that points towards the remote end.
The autodetection can only work if the ip-address is known when
a CRCX is performed. For this the remote entity must include the
remote ip address in the sdp trailer.
Implement probing to determine te right local ip address
Add debug log to display which ip address is actually used
Add a VTY option for the probing functionality.
Change-Id: Ia57cf7dab8421fd3ab6e1515727db0080373485e
The way how osmo-mgw decides when to send a dummy packet and
when not is not very obvious.
use more explicit if statements, and define constants. Also add
comments that explain how it works.
Change-Id: Ie7ee9409baec50a09fb357d655b5253434fae924
the network (mgcp_network.c) part and the protocol part
(mgcp_protoocl.c) share a single loglevel DLMGCP. This
makes debuging hard because when debugging the protocol
we also get the log output from the RTP packets.
assign the network part a private loglevel and keep DLMGCP
for the directly MGCP related code
Change-Id: I55a2711798d1d1c2c9ef2f3b7ebb8fdd78bd6ea2
the functions rtp_calculate_port(), mgcp_timeslot_to_endpoint(),
mgcp_endpoint_to_timeslot() were a hack to map CIC addresses
to endpoints and ports. This is no longer needed.
Remove the affected functions.
Change-Id: I9ef14396dc9f97e570d9bcfb4d9b4a94e650ad46
In many cases it is simpler to instruct the mgcp-gw to drop all
connections at once instead of removing each connection
individually.
drop all connections and release the endpoint in when no connection
id is supplied with the DLCX command.
Change-Id: Ib5fcc72775bf72b489ff79ade36fb345d8d20736
currently the only way to generate MGCP messages is to use
mgcp_msg_crcx(), mgcp_msg_mdcx() and mgcp_msg_dlcx(). All
three function take a fixed set of parameters via their
parameter list. There is no way to add or leave away optional
parameters.
add function mgcp_msg_gen(), this function takes a unified
message struct. The struct features a presence bitmask which
allows to enable and disable parameters as needed. It is also
possible to add new parameters in the future without breaking
the API.
Depends: libosmocore I15e1af68616309555d0ed9ac5da027c9833d42e3
Change-Id: I29c5e2fb972896faeb771ba040f015592487fcbe
When testing the file name and the line numbers are output to
stderr, this causes the test to fail when change moves the
lines.
Disable line numbers in the stderror log when testing, also
disable timestamps and colors. Make sure the log category
is print.
Change-Id: I7f1bd9454188f0ca869dada1fcc2877b789cc0ac
move SDP generator function write_response_sdp() from mgcp_protocol.c
to mgcp_sdp.c and use msgb_printf() instead of snprintf()
move prototypes for mgcp_parse_sdp_data() and mgcp_set_audio_info()
to mgcp_sdp.h
change parameter list of mgcp_parse_sdp_data() so that it takes the
rtp conn directly, rather than struct mgcp_rtp_end.
add doxygen comments to all public functions
Change-Id: I9f88c93872ff913bc211f560b26901267f577324
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I246853156c4bd2a47690e580e647105eb838ca92
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I5a64b305dff5387cbe2462b564051f807061086d
This marks the first release that includes the new libosmo-mgcp
as well as some updates to libosmo-mgcp-client. Hence, all programs
using those libraries can now depend on a proper minimum version
Change-Id: I1748ed230041930b4e9f49deb03341772ab02144
This fixes the following dpkg-shlibdeps warnings:
Change-Id: I648bbda50520808afcf2a6ce64fe710df918936c
dpkg-shlibdeps: warning: symbol install_element_ve used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol argv_concat used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_install_default used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_read_config_file used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_node used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
This fixes the following dpkg-shlibdeps warning:
Change-Id: I1eb079aa74a56b75e881b7abae0e5d9b4d7ae9c4
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bsc-mgcp/usr/bin/osmo-bsc_mgcp was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
This fixes the following dpkg-shlibdeps warning:
Change-Id: If60583b2bec344fc674af6f129787206540bc9fc
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libosmo-mgcp-client0/usr/lib/x86_64-linux-gnu/libosmo-mgcp-client.so.0.0.0 was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
This addresses the following dpkg-shlibdeps warnings:
Change-Id: I737c36402b7b88634b56725f2caab4f5f971ac51
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-mgcp-client0/usr/lib/x86_64-linux-gnu/libosmo-mgcp-client.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-mgcp-client0/usr/lib/x86_64-linux-gnu/libosmo-mgcp-client.so.0.0.0 found in none of the libraries
This addresses the following dpkg-shlibdeps warnings:
Change-Id: I518eb5e19cef5f261711b034d28337265c69f443
dpkg-shlibdeps: warning: symbol install_element_ve used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_read_config_file used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_install_default used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_node used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol argv_concat used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
Change-Id: Ic62efeb3c139016aa8a1e68651442edf2044eeef
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-mgw/usr/bin/osmo-mgw was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
This is the safe choice, as in absence of automatic testing we don't
know if we actually still build against the [sometimes] ancient
dependencies.
Change-Id: I8118defcd270bb487d9fd674fe30a74d379fda18
mgcp.h includes mgcp_ep.h but does not use anything from it. This
does not hurt the mgcp code internally, but when mgcp.h is included
by an application compilation fails because mgcp_ep.h is not
installed.
remove mgcp_ep.h from include list in mgcp.h
add mgcp_ep.h to include list in mgcp_conn.c where it is needed.
Change-Id: Ib58a8ed64f729055282c2b9673f7684cdfdb5936
The sendto() override in mgcp_test sends rtp packets out. This
might be a problem for some test hosts. e.g. on OBS, sending packets
fails with an error message, which exits sendto() early and hence fails
to send the expected amount of "Dummy Packets". Interestingly enough
calling the real sendto is not necessary to run the test at all.
Remove the execution of the real_sendto and just return len.
Related: OS#2561
Change-Id: Ia8fa0770f9bc75725cc6b0cd445e753f7e029ca5
I thought the BUILT_SOURCES also enters the files to CLEANFILES, but 'make
clean' leaves the copied header behind for me. Add to CLEANFILES to get it
removed.
Change-Id: I5a56f83289e32a09643047f0e779c9de3e4b39a6
Remove mgcp_common.c and replace with mgcp_common.h.
Move mgcp_common.h from mgcp_client/ to mgcp/;
Place a compile-time copy of it back in mgcp_client/.
Add builddir/include to compiler -I paths to find generated header.
Rationale:
- Keep separate copies of the file for each of the library to not require
debian dependencies between the two libraries.
- Avoid code dup by copying during 'make' (think: a generated header, BUILT_SOURCE).
- The copy does not have implications for linking (like mgcp_common.c did) nor
is it a source for build confusion or fallout in other projects, because it
does not reach across several git source trees (like gsm_data_shared.h did).
mgcp_connection_mode_strs are not actually used in libosmo-mgcp, so drop them.
(It would make semantic sense to have then in mgcp, but we can add it when it
is needed. A similar value string array remains in libosmo-mgcp-client.)
Change-Id: I7a5d3b9a2eb90be7e34b95efa529429f2e6c3ed8
Leave the old osmo-bsc_mgcp and libosmo-legacy-mgcp as it is; on a copy thereof
(added by a previous commit), apply changes to initially implement the new
osmo-mgw.
Adjust build system and debian packaging to accomodate the new libosmo-mgcp and
osmo-mgw.
The main differences:
*) use a list to manage rtp connections.
Aggregate all rtp related information inside a single struct.
Use a linked list to manage the both connections (net and bts).
The idea behind using a list is that we might support conference
calls at some later point.
Store the linked list in struct mgcp_endpoint, have a private linked
list for each endpoint. The list contains connection items which are
implemented in struct mgcp_conn. A connection is allocated and freed
using the functions in mgcp_conn.c. A connection is allocated on the
reception of a CRCX command and freed with the reception of a DLCX
command.
*) remove external transcoder feature
Fortunatelly the external transcoder feature is not needed
anymore. This patch removes the related code.
*) vty: get rid of CONN_BTS and CONN_NET
Since the new connection model does not make a difference
between BTS and NET connections the VTY should not use
the fixed CONN_BTS and CONN_NET constants.
- Handle the conns list inside the endpoint directly
- introduce function to dump basic rtp connection info
- introduce human readable names for connections
Parts of the code adjusted to use generalized connections instead of explicit
BTS/NET ones:
- teach mgcp_send_dummy() to send dummy packets to any RTP connection
- network: generalize mgcp_bind_net/bts_rtp_port()
- network: generalize mgcp_send()
- tap: generalize call tapping feature
- stat: generalize statistics
- Replace rtp_data_net() and rtp_data_bts() with generalized rtp_data_rx()
*) mgcp_protocol.c fixes:
- check ci string before it is converted:
In case of missing ci, a nullpointer is delivered to strtoul().
Add a function that takes ci, checks it and converts it to an
uint32_t. Use the return code to react on missing ci.
- output error message on missing CI.
- when parsing the mode, print log message when mode is missing.
- use mode_orig when mode is missing.
- fix ptime formatstring to use %u rather than %d.
- cosmetic: log when connection is deleted on DLCX.
- change loglevels of CRCX, MDCX, DLCX events from DEBUG to NOTICE.
*) mgcp_test
- apply rename of strline_r() to mgcp_strline().
- MGCP command macros:
- Add 'I: 1' parameters.
- Use proper port numbers:
from m=audio 0 RTP/AVP 126
to m=audio 16002 RTP/AVP 128
- Change ptime to 'a=ptime:40' because this is what the MGW currently
returns. CRCX generally feed a ptime:40 and this is expected to be
returned.
- struct mgcp_test: Use only one ptype, there are no explicit BTS and NET
endpoints anymore.
Hence remove one column from tests[].
- test_messages():
- Enable: remove '#if 0'
- Remove concept of BTS and NET endpoints: test only one conn, as they are
now interchangeable anyway.
- remove endpoint init, now done internally.
- add false asserts in error cases.
- test_retransmission():
- remove endpoint init, now done internally.
- add false asserts in error cases.
- test_packet_error_detection():
- Remove concept of BTS and NET endpoints: test only one conn, as they are
now interchangeable anyway. Use arbitrary conn ids (e.g. 4711).
- remove endpoint init, now done internally.
- add false assert in error case.
- Assert that a conn really vanishes on DLCX, previously the conn would
remain and just be unused, now it is actually discarded.
- test_no_cycle()
- Remove concept of BTS and NET endpoints: test only one conn, as they are
now interchangeable anyway. Use arbitrary conn ids (e.g. 4711).
- test_no_name()
- Enable: remove '#if 0'.
- remove endpoint init, now done internally.
- add false assert in error case.
- mgcp_test.ok: adjust expected results to status quo:
- We now see two dummy packets instead of one, now sent to both sides because
we don't know of BTS or NET side. (maybe drop dummy packets later...)
- packet duration, conn mode: now sane defaults show instead of unset.
- various whitespace and formatting changes from lindent.
Change-Id: Ie008599136c7ed8a0dfbb0cf803188975a499fc5
This a cosmetic commit, copying libosmo-legacy-mgcp to libosmo-mgcp and
osmo-bsc_mgcp to osmo-mgw 1:1 at first, to provide a basis for next patches
that highlight the changes from legacy to new code.
Until osmo-msc and osmo-bsc are adjusted to operate with the new code, we will
keep the legacy code alongside the new code. The legacy code might be dropped
later.
Change-Id: Idf54481754a1765bdb2d0d7033bc0d7dc2018024
libosmo-legacy-mgcp was not linked against libgsm
when built with --enable-mgcp-transcoding.
When afterwards a binary such as osmo-bsc is built and
tries to link against it, it will fail with an error
like the one below:
/home/pespin/dev/sysmocom/bin/../build/new/out/lib/libosmo-legacy-mgcp.so: undefined reference to `gsm_create'
Tested that building with this patch fixes the issue.
Also tested that it still builds fine without --enable-mgcp-transcoding.
Change-Id: I5ed356ac0c8f476e263fc6dcc5613d594890dfcd
With the upcoming addition of libosmo-mgcp, when we try the same scheme
of wildcards there, it would also include all of the other libraries:
*mgcp*.so.*
There we will have to clarify that we mean exactly:
libosmo-mgcp.so.*
This is a cosmetic change to also be less ambiguous for the current libs:
I prefer to state exactly which parts of the file names may vary, so that
we have a firmer understanding of what is being installed.
Change-Id: I6a3f3b9efa08eb9c5cdca3e02f8fab4a96c28ad5
Add mgcp_common.h to libosmo-mgcp-client, to not need to share a header file
with libosmo-legacy-mgcp (nor the upcoming libosmo-mgcp). Both libraries use
the enum mgcp_connection_mode (and a for-loop macro and a string mangling
function), so far declared in mgcp.h, and both mgcp-dev and mgcp-client-dev
debian packages would require this header file to be installed. So far the
mgcp-client-dev lacks this header file, which causes the osmo-msc debian
package to fail building. Ways to solve:
- If both -dev debian packages installed the same header file in the same
place, they would conflict if ever installed at the same time.
- mgcp-client-dev can depend on mgcp-dev, but it seems bad to keep such a large
dependency for just one enum and two helpers.
- Instead, this patch solves this by copying the few definitions to
libosmo-mgcp-client.
Once libosmo-mgcp-client has its own copy of those definitions, it is
fully self-contained and depending builds (osmo-msc deb) will succeed.
Copy the few actually common definitions to new header
<osmocom/mgcp_client/mgcp_common.h>. The nature of this .h is that it may be
shared with future libosmo-mgcp without causing linking problems.
Remove libosmo-legacy-mgcp/mgcp_common.c file from the build of
libosmo-mgcp-client, no longer needed.
Add to new mgcp_common.h:
- enum mgcp_connection_mode;
- for_each_non_empty_line() macro.
- mgcp_msg_terminate_nul() as static function. Its complexity is just above
your average static inline, but being inline is a way to use it in both mgcp
and mgcp_client without linking problems.
Replace for_each_line() use in mgcp_client with for_each_non_empty_line()
(for_each_non_empty_line() replaces for_each_line() and uses strtok_r() instead
of a local reinvention).
mgcp_connection_mode_strs are actually only used in libosmo-mgcp-client, so
rename to mgcp_client_ prefix and move to mgcp_client.c.
BTW, the future plan for upcoming libosmo-mgcp is to use the identical header
file, and keep only one copy in the git source tree. The second copy may be
generated during 'make', to avoid code dup while having two distinct headers.
Related: I8e3359bedf973077c0a038aa04f5371a00c48fa0 (fix osmo-msc after this),
I7a5d3b9a2eb90be7e34b95efa529429f2e6c3ed8 (mgcp_common.h)
Change-Id: Ifb8f3fc2b399662a9dbba174e942352a1a21df3f
Roll back the LIBVERSIONs to 0:0:0 -- the bumps so far have been confused and
wrong. Let's start over from scratch with API-current of 0 while we still can.
Rename the mgcp_client debian .install files back to 0 to match the API
version.
Change-Id: I3d81853f811f412b186621c3657bab6af397a980
Let's track the API/ABI changes in libosmo*mgcp the same way we do it in
other libosmo* libraries.
Change-Id: Id0b8d55ea58bdb3d72b4c131ac983d8895b55ef8
Use one space to indent mgcp.cfg, like all the other osmo*.cfg examples.
Tweak the header comment.
Remove the password and line vty commands.
Change-Id: I52e481dbf4778dd187ce6b67d879a04ef61e8b47
The name "mgcpgw_client" referred to an MGCP gateway, which is rather an MGW
(Media Gateway). But this client code is more generally a client for the MGCP
protocol, independently from what the server program is called.
Rename the files as well as the function prefixes to drop the "gw". It is
purely cosmetic and not strictly necessary, but a good point in time for fixes
like this.
osmo-msc build will be adjusted by I093ad02ca0e532f659447c785e09678b3e6f220d.
osmo-bsc build will be adjusted by I6402c7cbe58dacae7630f7f03819f8102e54c699.
These should be applied right after this here is merged to avoid fallout.
Change-Id: I99f7faab637cfcc22ece64a1dbcbe590f2042187
When osmo-mgw is built --with-mgcp-transcoding, linking the mgcp library
also requires linking libgsm, even though e.g. osmo-msc never use it.
Separate the MGCP client code from the MGCP server code to avoid this dep.
The mgcp client code does use some definitions from mgcp.h and mgcp_common.c.
For simplicity, link mgcp_common.c in both libosmo-legacy-mgcp as well as
libosmo-mgcp-client. That means it is not possible to link both
libosmo-legacy-mgcp and libosmo-mgcp-client in the same binary because of
duplicate symbols, but currently that is sufficient. (An alternative would be
code dup or yet another libosmo-mgcp-common library.)
Add libosmo-mgcp-client to debian packaging.
Related: OS#2488
Change-Id: I8e0b2d2a399b77086a36606f5e427271c6242df1
These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-mgw.
The ctrl_test_runner.py from openbsc.git still sticks around, but osmo-bsc_mgcp
has no CTRL interface (yet). If it gets one, we can re-add the
ctrl_test_runner.
Change-Id: I623ba8c053bef91a327e58de214e05f0d6768605
When a duplicate command is sent, the MGCP-GW will interpret this
as a retramsmission and will send the response of the already
executed command again. This response is not printed in the log.
Make sure that also responses, which are retrsnamitted are
displayed in the log
Change-Id: Ic41c2defb521e2f81762d932f8e29f7c8fed06a9
Add vty and logging previously used from libcommon
Rename libmgcp to libosmo-legacy-mgcp and install.
Use DLMGCP, not DMGCP.
Slim down the public mgcpgw_client API, move all elements not actually used by
current callers to private headers / static c.
Depends: libosmocore I09c587e2d59472cbde852d467d457254746d9e67
Change-Id: I71a0a16ebaaef881c34235849601fc40aa12cfd7
Remove libiu here, use the functions from libosmo-ranap instead, by applying
the ranap_ / RANAP_ prefix.
Corresponding change-id in osmo-iuh.git is I6a3f7ad15be03fb94689b4af6ccfa828c25f45c0
To be able to run the msc_vlr tests for RAN_UTRAN_IU without Iu client headers
available, add iu_dummy.h, containing mere function signatures that match
iu_dummy.c and a mostly empty struct ranap_ue_conn_ctx.
Make sure we can build with and without --enable-iu: include osmo-iuh headers
only with --enable-iu.
Change-Id: Ib8c4fcdb4766c5e575618b95ce16dce51063206b
In SGSN, actually place the port in the SGSN config by default, so that the
gsup port may now be omitted in the VTY config (the IP address suffices).
Adjust the osmo-sgsn.cfg example.
Depends: I4222e21686c823985be8ff1f16b1182be8ad6175 (libosmocore)
Change-Id: I50f2040e2eb0baacb43849e93cfed10cbc2fc156
Currently the force_realloc feature is turnd on and of in a
hardcoded way. This patch makes the option available via VTY.
Change-Id: Ic8740512c5ea0766ff6ceb1c28b9c2b3fe46e75f
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.
Implement AoIP in osmo-msc and osmo-bsc.
Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.
From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN
jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.
Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the NITB on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: Iea6804325a6575ceab5edfd28dd20249462f143b
This option was present in very early versions of the NITB, but
at least since 2011 it is no longer supported. It's still listed
in --help output, which is wrong.
Change-Id: I1d2cceb588ec5fb34ec5e2c05a7d8c93310bee88
Set the time on the status report to the time the message was delivered, as
this may not be the same as the time when we are delivering the report to the
originating MS.
Change-Id: I9056429d40bf02731f004b7833f1de45a0d1add8
libsmpp34 already converts received TLV integer values to native
endianess in libsmpp34_(un)pack.
Converting them again at receive time swaps the 2 bytes of
user_message_reference, then using a wrong value. As GSM03.40 spec
uses only 1 byte for the id, then only the high byte of the initial
value is used and eventually sent back to the ESME. Again, at that time,
htons() is not needed because libsmpp34 already handles that part.
See OS-#2429 for more details.
Change-Id: If748548a4a223e529a1110c89e483b599b406e8b
I already stumbled into 2 compilation environments which had Werror
enabled for -Wmaybe-uninitialized and the build failed, so let's
workaround this warning.
| smpp_openbsc.c: In function 'handle_smpp_submit':
| smpp_openbsc.c:216:9: error: 'sms_msg_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| memcpy(sms->user_data, sms_msg, sms_msg_len);
| ^
| smpp_openbsc.c💯15: note: 'sms_msg_len' was declared here
| unsigned int sms_msg_len;
| ^
| cc1: some warnings being treated as errors
Change-Id: I0901ddadb5f72e1585cb1797ac22c8ab95e83146
Commit 058cd573d8 added 2 new pointer parameters to
gprs_subscr_request_auth_info, but forgot to update wraps of the
function in sgsn_test.
I catched this today because openbsc build test sgsn_test was failing.
Closed look up to the logs showed:
Assert failed (auts != NULL) == (auts_rand != NULL) openbsc/openbsc/src/gprs/gprs_subscriber.c:791
Change-Id: Ie9e4af6da0339536fb20ca0b7bbcf6f485bd522c
gsm_04_11.c sms_report_alloc()
Use the sms->text, not the sms->user_data to construct the report body.
This also prevents the potential output of non printable characters to
the log and or vty.
Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu()
When we construct the status report PDU, use sms->src
instead of sms->dst as the destination address
This way we tell the MS that the message was delivered
to the destination and not to itself.
This is relevant for phones that display a textual
representation of the delivery report.
Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
Use new definitions in libsmpp34 to set the registered_delivery field
accordingly, as provided by I5b3afff1b3b77cccd949e0606914c7ac3ba6114c.
Moreover, do not set this header field to zero if status reports are
off, the deliver_t structure has been already zeroed so this not
required.
Change-Id: Ie78e17323796120f576b9c0e1bc5ccc32da8ee12
In 2015, Jacob moved/copied related functions to libosmocore, but
for some reason didn't remove the copies here. Let's follow-up on
that and remove duplicated code.
The libosmocore commit introducing osmo_apn_to_str() was
8114294bf29ac6e44822c0ae43d4b0819f11b022
Change-Id: I7315ffcbed8a54cca2056f313bb7783ad82d0ee9
We can only print libgtp pdp information if a library context is
attached to this pdp context. This is not always the case,
particuarly during some teardown scenarios.
Change-Id: Ia3184877f9709db65f5f93a98403f2ef5b04a8ca
When converting from GSM_PCHAN_PDCH, we should generate
a RSL channel number IE with the osmocom extension
RSL_CHAN_OSMO_PDCH rather than claiming it is a regular
TCH/F channel.
This is important as this function is used by
osmo-bts, too - and it decides which channel number IE is
put in the GSMTAP header for both GSMTAP tracing as well
as the GSMTAP based osmo-bts-virtual.
In order to avoid any unintended effect on libbsc,
we make sure to modify rsl_ipacc_pdch_activate() to
always use GSM_PCHAN_TCH_F in related RSL message.
Change-Id: Ie34219e64a6d89da4a79f2db8ec73d1909fb8280
In the PDP Context Create from SGSN to GGSN, we include information
about the RAN type (GERAN/UTRAN) and the Cell of the MS. This was
all hard-coded to GERAN, and wasn't updated when we added UTRAN
support to the SGSN.
Change-Id: I6c79e42c5e08b28fe8182555302a5505fbbaa313
Commit 5754206379 introduced
OSMUX_STATE_NEGOTIATING to fix a race condition present in osmo-bsc_nat.
However, after this change osmo-bsc_mgcp cannot switch to
OSMUX_STATE_ACTIVATING anymore, which means during osmux_send_dummy time
it won't call osmux_enable_endpoint(), which in turn won't set endp type
to MGCP_OSMUX_BSC.
If MGCP_OSMUX_BSC is not set, uplink streams are sent using regular RTP
instead of Osmux not matter it is enabled in config or not.
Change-Id: Ibcb59aa1ca25408f82cc88c2d5b81177b5f276dc
In case of successful completion of handover gsm_subscriber_connection could be moved from one bts to another,
so connection link to bts should be replaced by link to bts, which owns new_lchan.
This bug was detected, because conn->bts->nr is used in call control log messages
and wrong number of bts was observed in these messages after handover.
Change-Id: Idc7dd412b7580c451e716b73ef7549826c60b0d9
Fixes regression probably introduced in c696cc28.
For bts>0 logging doesn't show bts number correctly when printing lchan
identification string - it will always show it as "bts=0". The reason for
this is that the identification string is cached before bts->nr value is
set to a proper value.
This patch sets bts->nr as part of the first step of the bts structure
initialization, before caching happens thus making sure the cached
identification string is cached with the correct values.
Change-Id: I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
Replace magic numbers by esm_class definitions, which
have been added to latest libsmpp34 in Change-Id
I91afd8b462b8fd3b2c4c5b54f4eeb7ec5b730b65
Change-Id: I6c458690da60c8f3637680efbd718f6e8c6feb4c
submit_to_sms() now handles two TLVs, so find_tlv() is suboptiomal and
it can be removed, since it would result in two passes on the TLV list.
Use new smpp34_tlv_for_each() helper to iterate over the list of TLVs
that is available since I446929feed049d0411e1629ca263e2bc41f714cc.
Change-Id: I53a65164a6cc4abc6bf57d9a8dc275cf21c90222
The change-id I7276d356d805a83ebeec72b02c8563b7135ea0b6 added msg_ref to
the databse but forgot to remove the comment stating it's not being
stored.
Change-Id: I204f098c8f2a480405446113e2181b2c53700cf3
gsm340_gen_oa() returns a negative value if the output buffer that the
caller passes is too small, so we have to check the return value of this
function.
Fixes: CID 174178
Fixes: CID 174179
Change-Id: I47215d7d89771730a7f84efa8aeeb187a0911fdb
This patch adds gsm340_sms_send_status_report_tpdu() to build a
status-report. Moreover, set sms->report field if we see a SMPP
SUBMIT_SM with Delivery Acknowledgment esm_class, so this identifies
that this is a delivery report.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| | SUBMIT-SM |
| | esm_class = Delivery Ack |
| |<-------------------------------|
| | SUBMIT-SM-RESP |
| |------------------------------->|
| | |
| SMS-STATUS-REPORT | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | |
There is a FIXME message in this patch, that I just copied from
gsm340_gen_sms_deliver_tpdu() since TP-MMS is not supported by OpenBSC.
Change-Id: Ib70e534840308ed315f7add440351e649de3f907
Simple patch to test the new status-report support code, remove previous
code before Delivery Acknowledgement support was in place. Use
LOGL_DEBUG for logging messages here as suggested by Neels and Harald.
Change-Id: I877e228d8e174430f700631edbf9955972da7892
SMPP DELIVER_SM messages with esm_class = Delivery Receipt need to send
this message reference (that the mobile phone allocates) to the ESME.
Thus, the ESME propagates it via SUBMIT_SM with esm_class = Delivery
Acknoledgment so that the SMSC sends the GSM 03.40 status-report to the
origin including this. Given this field is useful for status-reports, we
need to store it in the HLR database.
Moreover, we need a new field that specifies if the entry represents a
SMS status-report, to do the right handling from the gsm411_send_sms() -
such new handling comes in a follow up patch entitled "libmsc: handle
delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report".
This patch includes the migration routines to the new database schema
revision 5, it's quite a bit of dbi boilerplate code - copied-pasted and
adapted.
Change-Id: I7276d356d805a83ebeec72b02c8563b7135ea0b6
If the mobile phone requests a status report via SMS, send a DELIVER_SM
with esm_class = Delivery Receipt to ESME to indicate that the SMS has
been already delivered to its destination.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-DELIVER | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | DELIVER-SM |
| | esm_class = Delivery Receipt |
| |------------------------------->|
| | DELIVER-SM-RESP |
| |<-------------------------------|
| | |
This patch implements "Appendix B. Delivery Receipt Format" as specified
in the SMPP 3.4 specs. This string is conveyed in the SMS message as
data, and it is only meaningful to the ESME, for logging purposes. The
"submit date" and "done date" are not yet set, and other fields are just
sent with dummy values, so they are left to be finished as future work.
The new SMPP TLV tag TLVID_user_message_reference is added to the SMPP
messages inconditionally now since this information is required by
delivery-reports to associate the status-report with the original SMS.
Change-Id: Ic1a9023074bfa938099377980b6aff9b262fab2a
Just munch and log SMPP delivery receipts by now, don't mirror this, it
is going to break things in openbsc.
Follow up patch removes this and mirrors this SMPP message as a
SUBMIT_SM with esm_class = Delivery Acknowledgement.
Change-Id: I78e93bc4034679e238c8642ccf6a0e844b1d6d8b
Propagate the status report request field to the SMPP message through
the registered_delivery field, so the ESME knows that the mobile phone
is asking for explicit delivery acknowledgment is required. See SMPP 3.4
specs section 5.2.17.
Change-Id: I59af60fa89cd10ae973c5e122789e3e03e3728ee
Rationale: allows seeing all timer defaults at once by doing
OsmoBSC(config-net)# timer ?
Before, defaults are visible only by doing on each timer:
OsmoBSC(config-net)# timer t1234 <tab>
Change-Id: I8259234e5c62e058dde56d531071440bbab11462
The VTY parsing already ensures the parameter range being 1..65535, no need to
check the range again.
Change-Id: I1cffa5b01cd5c589f1e42998e32135f1da8c960b
Move the sms message-type-identifier (mti) handling away from the
routing logic. This patch allows us to reuse the sms_route_mt_sms()
function in a follow up patch for sms reports send through SMPP
DELIVER_SM with esm_class = Delivery Receipt whose Change-Id is
Ic1a9023074bfa938099377980b6aff9b262fab2a.
Change-Id: I3f3d30e0762b91e2099243b0be1a4b67cbb5e9c0
No need to cache the sms object, just cache what we need into the
smpp_cmd structure. This simplifies what that I introduced in
93ffbd0029 ("libmsc: send RP-ACK to MS after ESME sends SMPP
DELIVER-SM-RESP").
Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
The following branch:
if (!rc && !gsms->receiver)
rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
at the end of sms_route_mt_sms() always evaluates false.
Just a bit before, in such function, we have this:
if (!gsms->receiver) {
...
#ifdef BUILD_SMPP
...
#else
...
#endif
return rc;
}
So, if there is no receiver, we just stop running code and return the RP
cause via the rc variable. Same applies to the smpp_first check under
the BUILD_SMPP ifdef (that I have removed in this snippet to keep this
commit message small).
Change-Id: Ic3502b5b169bc7a73a67fd6ff53d8b6c0dc045c8
libgtp is calling gtpie_tv2 which will convert this uint16_t from host
to network order. So far libosmogsm and the sgsn treated the charging
characteristics as opaque data. So when moving from byte array to the
uint16_t do the swapping.
Change-Id: I977aec2e2f8d57802e45f591754e5733562d5c2a
We no longer permit timers with a 0 value, so this case can never
happen. Also, if it should happen, I'd rather have a timter expiring
immediately (and breaking something) than not being started in the
first place.
Change-Id: Ibfcdd3ddc0155caee89c501498329bde247621a0
It typically doesn't make sense to configure any of the GSM RR timer
to 0 (Seconds). In fact, accidentially configuring any of the timers
to zero might have severe side effects, such as "stuck channels"
described in https://osmocom.org/issues/2380
Change-Id: I517828f2f0c80ec01cb63648db2626f17a67fe57
A number of the GSM timers (including T3109) had no reasonable
default values if not specified in the VTY / config file. Together
with unconditional writing to the config file, this created
config files with a persistent setting for important timers as '0'.
To make things worse, many of our example cofig files suffered from the
same problem.
Let's avoid this from happening by
* having reasonable defaults if nothing specified in the config file
* conditionally savingg timers only if they differ from default
* reject any timer values that state zero during start-up (see previous
commit)
Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8
Closes: OS#2380
Using this new command (introduced in OsmoBSC + OsmoNITB), you can
simulate the generation of TRAP events for testin purposes.
start the control interface monitor as an example client program:
./openbsc/contrib/bsc_control.py -m -d localhost -p 4249
then start OsmoBSC or OsmoNITB, telnet to the VTY and enter 'enable'
mode and issue the following (example) command:
ctrl-interface generate-trap my.foo.var 2342
As a result, on the bsc_control.py you will see:
Got message: TRAP 0 my.foo.var 2342
Change-Id: Ib1d2ec38290dc94797c1b365d9b733e5215ab7d1
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
The recent change (Id I7dad4a4d52fe05f6b990359841b4408df5990e21) seems
to have missed one instance, so let's follow-up.
Change-Id: I1ee9e3d26dcc18e7f979fd9a786162cbcc50942c
Related: OS#2361
If we previously had a given SI present/active, we must send a
zero-length BCCH FILLING for that SI type to the BTS to stop it from
further transmitting this SI.
Change-Id: I33e356e2fa3a69efac9080813e3e9ef4e6438ed1
Closes: OS#2368
If we want to instruct the BTS to stop sending a given SI, we must be
able to send the respective BCCH INFO / SACCH FILLING with a header but
without any L3 data IE. This patch enables the related functions to do
this whenever their data argument points to NULL.
Change-Id: I88b85614951a108574f05db3b706884afe7e87a9
In commit 8b1a2f8cd7 we started to
initialize bts->si_valid to 0. This means we are skipping the manually
configured static system information.
Instead, we have to initialize bts->si_valid to bts->si_mode_static,
i.e. start with those that are static and not to be auto-generated.
Found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo
Change-Id: Iab9cc93cf6d54560a72cc393cc3721a8d10e04bf
Closes: #2367
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
RelateD: OS#2361
Change-Id: I7dad4a4d52fe05f6b990359841b4408df5990e21
This is useful if you are updating some configuration parameters which
affect the content of the SYSTEM INFORMATION messages. Currently, we
only send them at the time the RSL connection is established (i.e. when
the BTS is initialized), so if you change something, you need to bring
down and re-start the BTS.
Using the newly-introduced "bts <0-255> resend-system-information"
command, you can re-generate + re-send SYSTEM INFORMATION without
bringing the BTS down, i.e. without any radio carrier downtime.
Change-Id: I326df47de98f6d36c9a4d2d5475225d1e62bafb5
A valid subscriber is indespensible when allocating a new
transaction. Return NULL if no subscriber is supplied. This
will cause unidentified subscribers to be rejected.
Note: Under normal conditions, the problem does not occour,
but it is still possible that a misbehaving MS might trigger
the problem by sending a SETUP command before authenticating
the subscriber. (unencrypted networks)
Change-Id: Ia8739b6e329ab02c0064270d02ad1d6ee245520d
* fix BTS numbers: use 0 to indicate given BTS and 0xFF to indicate all
BTS' as it's explained in 3GPP TS 52.021 §9.3.
* only request attributes from supported (OsmoBTS) types
Change-Id: I8f43055c38000248033a8ff9ddaf0910d68d794b
Related: OS#2317
TS 04.14 (TS 44.014) specifies a series of commands specific to
conformance testing. Let's add some VTY commands to play (at least
initially) with closing and opening voice loops in the MS.
Change-Id: I38b1ee9dbf26f5689c38cb83b1b3c5e9eaad7678
For some GGSNs we need to insert the PDP Charging Characteristics
that were returned. We receive these values from GSUP and will
fill them into the tlv structure when finding the ggsn context.
Change-Id: I1725bfd2403d29ce3550bfcd6fcc1498426ef906
Necessary since libosmocore I513835be2d931d0a931cdfc996f361a451bc1a15
removes the script from libosmocore/contrib.
Change-Id: I02d7e1c0151c687fd9341d21a09ca15cbf5a1938
For the vty tests, add osmo-sgsn-accept-all.cfg (that does not need an HLR) and
use in vty_test_runner.py, otherwise the 'show sgsn' command will reply that it
could not connect to the HLR, failing the vty test which expects empty.
Change-Id: Ie3b2013198d3e2b780a4e31c36b89b58129dcacd
This helps in providing 3G software packages for the sysmoNITB hardware, which
uses 10.23.24.1 for SGSN and 10.23.24.2 for GGSN.
However, in order to not break the python tests, the osmo-sgsn.cfg example
still uses 127.0.0.1 as local address.
Change the GGSN address to 127.0.0.2, because SGSN and GGSN cannot co-exist on
the same address (the GTP port number is fixed by spec: no IE to communicate a
differing port, so it has to be the standard GTP port for both).
Change-Id: Ie3a25f6771ed6e620cb2b315638c622a9a24e530
On incoming 04.08 messages, we log only the protocol discriminator in
decimal. Enhance: log pdisc and message type in hex, and also log the
protocol and message type as human readable string.
Also adjust the msc_vlr tests' log statements for wrapped rx/tx functions
of dtap from/to the MS.
Adjust the expected output of msc_vlr_tests.
Change-Id: Ida205d217e304337d816b14fd15e2ee435e7397d
Depends: libosmocore change-id I0fca8e95ed5c2148b1a7440eff3fc9c7583898df
The ip.access nano3G needs the first RTP payload's first two bytes to read hex
'e400', or it will reject the RAB assignment. Add flag
patched_first_rtp_payload to mgcp_rtp_state to detect the first RTP payload on
a stream, and overwrite its first bytes with e400. This should probably be
configurable, but seems to not harm other femto cells (as long as we patch only
the first RTP payload in each stream). Only do this when sending to the BTS
side.
Related: OS#2459
Change-Id: I5eff04dcb0936e21690e427ae5e49228cd459bd4
libosmocore change-id I4efdb1eaae43aced33961b64d4f14b0040321c10 changes the
gsm340_gen_scts() from gmtime to localtime, meaning that by feeding a mere zero
as timestamp, we get different results depending on the local machine's
timezone setting. Instead of calling gsm340_gen_scts() with zero, simply write
a bunch of bytes as time so that the tests get identical SMS bytes every time.
Change-Id: I8a50e8963dce80609749571b61fc6ffe1c54660c
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
In an upcoming commit, sgsn_vty_init() will require access to the global sgsn
config struct to initialize a generic VTY command with the proper config
destination address, see Change-Id I5b5b6a9678b458affa86800afb1ec726e66eed88.
Change-Id: Ie6b6e5422987586531a898e0c5b867623dbecb0f
Disable large parts of the code that depend on BSC presence. The code sections
disabled by #if BEFORE_MSCSPLIT shall be modified or dropped in the course of
adding the A-interface.
Don't set msg->lchan nor msg->dst.
Don't use lchan in libmsc.
Decouple lac from bts.
Prepare entry/exit point for MSC -> BSC and MSC -> RNC communication:
Add msc_ifaces.[hc], a_iface.c, with a general msc_tx_dtap() to redirect to
different interfaces depending on the actual subscriber connection.
While iu_tx() is going to be functional fairly soon, the a_tx() is going to be
just a dummy for some time (see comment).
Add Iu specific fields in gsm_subscriber_connection: the UE connection pointer
and an indicator for the Integrity Protection status on Iu (to be fully
implemented in later commits).
Add lac member to gsm_subscriber_connection, to allow decoupling from
bts->location_area_code. The conn->lac will actually be set in iu.c in an
upcoming commit ("add iucs.[hc]").
move to libcommon-cs: gsm48_extract_mi(), gsm48_paging_extract_mi().
libmsc: duplicate gsm0808 / gsm48 functions (towards BSC).
In osmo-nitb, libmsc would directly call the functions on the BSC level, not
always via the bsc_api. When separating libmsc from libbsc, some functions are
missing from the linkage.
Hence duplicate these functions to libmsc, add an msc_ prefix for clarity, also
add a _tx to gsm0808_cipher_mode():
* add msc_gsm0808_tx_cipher_mode() (dummy/stub)
* add msc_gsm48_tx_mm_serv_ack()
* add msc_gsm48_tx_mm_serv_rej()
Call these from libmsc instead of
* gsm0808_cipher_mode()
* gsm48_tx_mm_serv_ack()
* gsm48_tx_mm_serv_rej()
Also add a comment related to msc_gsm0808_tx_cipher_mode() in two places.
Remove internal RTP streaming code; OsmoNITB supported that, but for OsmoMSC,
this will be done with an external MGCP gateway.
Remove LCHAN_MODIFY from internal MNCC state machine.
Temporarily disable all paging to be able to link libmsc without libbsc.
Skip the paging part of channel_test because the paging is now disabled.
Employ fake paging shims in order for msc_vlr_tests to still work.
msc_compl_l3(): publish in .h, tweak return value. Use new libmsc enum values
for return val, to avoid dependency on libbsc headers. Make callable from
other scopes: publish in osmo_msc.h and remove 'static' in osmo_msc.c
add gsm_encr to subscr_conn
move subscr_request to gsm_subscriber.h
subscr_request_channel() -> subscr_request_conn()
move to libmsc: osmo_stats_vty_add_cmds()
gsm_04_08: remove apply_codec_restrictions()
gsm0408_test: use NULL for root ctx
move to libbsc: gsm_bts_neighbor()
move to libbsc: lchan_next_meas_rep()
move vty config for t3212 to network level (periodic lu)
remove unneccessary linking from some tests
remove handle_abisip_signal()
abis_rsl.c: don't use libvlr from libbsc
gsm_subscriber_connection: put the LAC here, so that it is available without
accessing conn->bts. In bsc_api.c, place this lac in conn for the sake of
transition: Iu and A will use this new field to pass the LAC around, but in a
completely separate OsmoBSC this is not actually needed. It can be removed
again from osmo-bsc.git when the time has come.
Siemens MRPCI: completely drop sending the MRPCI messages for now, they shall
be added in osmo-bsc once the A-Interface code has settled. See OS#2389.
Related: OS#1845 OS#2257 OS#2389
Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c
libvlr now delegates subscriber management to osmo-hlr, so the database no
longer represents a HLR. It basically only stores SMS, so reflect that fact in
the default database name.
Change-Id: I3289d68d3eb63aff940b48a25b584d5e83cd0197
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
SMS:
The SQL based lookup of SMS for attached subscribers no longer works since the
SQL database no longer has the subscriber data. Replace with a round-robin on
the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the
subscriber is currently attached.
If there are many SMS for not-attached subscribers in the SMS database, this
will become inefficient: a DB hit returns a pending SMS, the RAM lookup will
reveal that the subscriber is not attached, after which the DB is hit for the
next SMS. It would become more efficient e.g. by having an MSISDN based hash
list for the VLR subscribers and by marking non-attached SMS recipients in the
SMS database so that they can be excluded with the SQL query already.
There is a sanity limit to do at most 100 db hits per attempt to find a pending
SMS. So if there are more than 100 stored SMS waiting for their recipients to
actually attach to the MSC, it may take more than one SMS queue trigger to
deliver SMS for subscribers that are actually attached.
This is not very beautiful, but is merely intended to carry us over to a time
when we have a proper separate SMSC entity.
Introduce gsm_subscriber_connection ref-counting in libmsc.
Remove/Disable VTY and CTRL commands to create subscribers, which is now a task
of the OsmoHLR. Adjust the python tests accordingly.
Remove VTY cmd subscriber-keep-in-ram.
Use OSMO_GSUP_PORT = 4222 instead of 2222. See
I4222e21686c823985be8ff1f16b1182be8ad6175.
So far use the LAC from conn->bts, will be replaced by conn->lac in
Id3705236350d5f69e447046b0a764bbabc3d493c.
Related: OS#1592 OS#1974
Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
Related: OS#1592
Change-Id: Ie303c98f8c18e40c87c1b68474b35de332033622
Enable various components according to the build matrix during make distcheck.
Add python tests, osmo-bsc, nat, ...
Change-Id: Ic724cf61d44409337414dc58c8795896b4b97a8a
- bscs.config needed by the vty tests was not picked up as a dist file, because
its suffix is not 'cfg'. Rename to *.cfg. Apply this rename in
vty_test_runner.py and osmo-bsc_nat.cfg.
- Remove restart counters after external tests, otherwise distcheck complains
about uncleaned files.
- Add contrib/ipa.py to EXTRA_DIST, hence add a Makefile.am to contrib/.
Otherwise the python tests cannot find that dependency.
Change-Id: I42b55cb1125099afc3a8e3f87c0e398426b2e2a9
Before, each GSUP client would contact the HLR with an identical unit id, i.e.
"SGSN-00-00-00-00-00-00", with the result that some messages were sucked off by
the wrong client.
Pass explicit unit name from each gsup client user, so that OsmoMSC is "MSC"
and OsmoSGSN is "SGSN". Hence the HLR can properly route the messages.
Todo: also set some values instead of the zeros.
Unrelated cosmetic change while editing the arguments: gsup_client_create()'s
definition's oap client config arg name mismatched the one used in the
declaration. Use oapc_config in both.
Change-Id: I0a60681ab4a4d73e26fe8f0637447db4b6fe6eb2
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
We are building with libosmo-sccp tag 'old_sua' until the new sigtran has
been applied. Since osmo-iuh commit
0f88c110093935305143987638e46dc6db304a3e
"migrate osmo-hnbgw to libosmo-sigtran's SCCP/M3UA"
osmo-iuh requires libosmo-sccp master. A similar 'old_sua' tag is in place in
osmo-iuh.git, to match libosmo-sccp 'old_sua'. Do that to fix the jenkins
build of --enable-iu.
Change-Id: I70f731db0b74ed48ae6dd713ed4c3247222ef0de
* use LT_INIT instead of AC_PROG_RANLIB
* remove redundant libbsc entries
The default (for both manual and .deb builds) is to use shared build (as
before) - the static build is entirely optional.
Based on work by Sergey Kostanbaev <sergey.kostanbaev@gmail.com> and
Alexander Chemeris <Alexander.Chemeris@gmail.com>.
Change-Id: Ibcd1da98302413182c85e25c4cb7d69d9e38c35a
While fixing potentially incorrect memory access, the check for maximum
number of supported BTS features was incorrectly adjusted instead of
feature vectore length check next to it. Fix this by adjusting checks
properly and adding comments to avoid future confusion.
The error was introduced in a60bb3dd28.
Change-Id: I06d2498d730624d5da535f6add6fa98d004714ae
When we are performing Rx sensitivity testing on a BTS, we want to
deactivate the connection failure criterion / radio link timeout, i.e.
no matter how many SACCH frames in uplink are failed to decode, the BTS
should never close the channel.
OsmoBTS Change-Id I736f21f6528db5c16fa80cdb905af20673797be5 covers a way
how this behavior can be requested from the BTS via an OML attribute.
This patch adds support to the BSC to actually set that attribute.
Do not use this in production networks, as the BTS will keep open radio
channels indefinitely even if the phone is gone and no longer
transmitting anything. This is a pure testing feature.
Change-Id: I6cb94e0f024934f7baeeb728ca9ed3042fbf16d2
Previously the SI generation lead to setting the BCCH SIs for all TRX in
a multi-trx setup. This is because we create the SIs globally but
si_valid appears to be limited to the 'current' trx. Warn if we attempt
to set SIs for the BCCH on a trx that does not have a BCCH.
Change-Id: Ie0e288252a2e7709c4dae16b96a0b1512278847f
Tweaked-by: Max <msuraev@sysmocom.de>
To support segmented SI2quater as per 3GPP TS 44.018 we'll have to
support multiple SI messages (up to 16 for SI2q) for a given type in
contrast to existing 1:1 mapping:
* expand storage space to hold up to 16 SI messages (spec limit)
* add assertions for budget calculations
* generate multiple SI2q messages
* adjust SI2q-related tests
* use precise check for number of SIq messages instead of approximate
estimation
Change-Id: Ic516ec9f0b821557d9461ae9f1c0afdd786f3b05
Related: OS#1660
* move SI2quater related defines to shared header
* add define from OsmoBTS which checks for presence of a given SI
message in gsm_bts struct. Rename it to avoid conflicts with OsmoBTS
code and to match naming conventions of similar macros.
Change-Id: I11432c93c772d1ead6d45a7bb0f1d13d492c82f1
Related: OS#1660
Use sizeof target BTS feature storage to make sure we always fit into
pre-allocated memory. Also use it for log check.
Change-Id: Ib107daa6e8b9bc397a10756071849f8ff82455d5
Fixes: CID 170581
osmo_talloc_replace_string() was introducd into libosmocore in 2014, see
commit f3c7e85d05f7b2b7bf093162b776f71b2bc6420d
There's no reason for us to re-implement this as bsc_replace_string
here.
Change-Id: I6d2fcaabbc74730f6f491a2b2d5c784ccafc6602
In addition to compile-time defined BTS model features we also need
run-time BTS features reported by BTS via OML. This should be shared by
BSC and BTS. To accommodate for this, add following:
* features bitvec to gsm_bts struct
* features descriptions
* comments to avoid confusion between 2 feature sets
* helper functions to set/query particular feature
* upper boundary on number of supported features and assertion for it
Change-Id: I02bd317097ba66585c50ebd4e8fc348f6dc3dad9
Related: OS#1614
Rename gsm_bts_has_feature() -> gsm_btsmodel_has_feature() and adjust
type signature to match gsm_btsmodel_set_feature() function and avoid
confusion with upcoming functions to check/set BTS features reported
over OML.
Change-Id: I97abdedbef568e0c2fbd37c110f7d658cf20e100
Related: OS#1614
Since commit b4999b60d4 we created PCU
sockets at hard-coded paths in the filesystem by default for all BTSs.
This is inflexible and prevents the use of multiple BSC instances on a
single filesystem, or the placement of the sockets in a more secure
location than /tmp.
The new approach with this patch is that
* no PCU sockets are created by default
* only for those BTSs where a 'pcu-socket' is configured via VTY,
the socket will actually be created
Change-Id: Ie9079470584777dcc31f85f9bf0808f479156ccb
Closes: OS#2293
Using this command, one can modify the RTP stream associated with a
given logical channel and (re)direct it to a specified IP:Port.
Change-Id: I63e03b932038a4e2f6d51c5541b52e4a42df27bf
Sometimes it is useful to manually activate (or decativate) a given
logical channel from the VTY. Doing this on the BSC (rather than the
BTS) ensures that the BSC knows that this timeslot / channel is
allocated and there is no risk to have clashes between the BSC "owning"
the resources and the BTS allocating some by itself.
Change-Id: I44fc3904678eb48bd3ab1a3da8c0c265fa082e0d
We can also move the string-to-numeric conversion inside vty_get_ts() to
reduce the amount of work required in the caller.
Change-Id: I2a74ed06e90e39d39f53fff39bb96df172728c0e
Resolving a timeslot based on its numeric identities is a generally
useful function, so lets' factor that out.
Change-Id: Id2570232f82542487a1133be7efb1dc1eb3029a8
We generally use const pointers for input arguments. Also, document
input/output arguments of function and add spec reference.
Change-Id: I2532cde69a18e3b021f7371e68f67a28a43d8b5f
The pcu sends us an already made up MAC-Block that contains the
paging request. pcu_sock.c is parsing this paging request
wrongly and fails silently, which results into a dropping of the
request.
This commit fixes the parsing problems.
Change-Id: Iefef08123bdc351afd8287d3f27ebf0ae58a6e7d
The PCU sends imm.ass messages in response to a rach request. Those
messages need to be forwarded to RSL in order to get them send. This
commit introduces the required functionality for that
Change-Id: Ice099c4ed7008200ed179e581aba1899c6c29455
Ericsson allows to attach a reference to immediate assignments. A
confirmation of the transmission is then sent back, but only containing
the reference, not the whole RLC packet.
Change-Id: I945f49e62e2a74a7906e2d49940927773edd04a9
The BSC-located PCU case looks to the PCU like a BTS-located PCU with
"direct PHY" access, i.e. the data related primitives are communicated
from the PCU directly towards the TRAU Frames or whatever transport
method is used between CCU and PCU.
In order to make the PCU believe that, we need to pass in a 'layer 1
handle'. As we don't use it, we can just pass any non-zero value and be
happy.
Change-Id: I8170bd4134904702b6b272e496100361ba473cbc
Instead of 20, use the actual buffer sizes of struct sw_load, which are 255.
Previous code would truncate a longer string at 20 without(!) NUL termination.
In the _len members, store the actual length copied. In previous code, if the
source string were longer than 20, we would store only 20 (without NUL term)
but still reflect the longer length of the source string.
Fix both of these issues for sw_load.file_id / file_id_len and
sw_load.file_version / file_version_len.
Change-Id: I2e34a1348a290d3f58dd830d08da65b94b3270db
Send SMS RP ERROR with a failure cause that relates to
the status returned by the ESME in the deliver_sm_resp.
Actual mapping array is limited as most phones I tested
don't seem to care about the failure cause anyway,
although some will display a different notification for
GSM411_RP_CAUSE_MO_NUM_UNASSIGNED
Change-Id: I61fb2d9ef4f2d2eabdc49b53d9966ad328d15e51
The newline and $NULL manage to append a trailing space to the 'openbsc' dir.
This was broken in commit 7b6673fa06
"Consistenly format variables in */Makefile.am files"
by Change-Id Ifa21513c007072314097b7bec188579972dc1694
Add a comment to prevent this in the future.
Reported-by: Andreas Mueller <andreas.mueller@criticallabs.org>
Change-Id: I218027459e3b2aaa817d91eb3f69d9c0b10dcd4e
The gsm_data_shared.h header is installable and used by OsmoBTS so it
should not include any private (non-installable headers) to avoid
OsmoBTS' build failures.
Change-Id: Ic25031101fc01bd732fe691132c081ad05fa6a4b
Request BTS attributes via OML on connection and parse the response:
request/parse incoming response as sw-config.
Note: only basic BTS-wide KV attributes wrapped in sw-config are
supported for now.
Change-Id: I589be51daca0cb9e1f3473b93e910e46b06e23ae
Related: OS#1614
Previously only the existance of bts->si_common.si2quater_neigh_list was
checked but not the actual number of EARFCNs in it. Fix it by using
si2q_earfcn_count() and adjust tests accordingly. While at it - reformat
tests to include extra information.
The correctness was checked manually by inspecting GSMTAP output.
Change-Id: Ic4fb2a9e870db66cac58b1e8d113587b30d64ce2
Related: RT#8792
In preparation for extended SI2q messages:
* add SI2q-specific accessor macro
* add *_offset variables to gsm_bts struct
* internalize memory check while generating rest octets - introduce
budget concept (number of bits available in a given message)
* internalize *arfcn_size() functions as they are not needed outside of
si2q_num() anymore
* change rest octets generation to work with gsm_bts struct directly
* do not generate rest octets if no SI2q is necessary
* adjust unit tests accordingly (cosmetic changes only to avoid
regressions)
Requires: I92e12e91605bdab9916a3f665705287572434f74 in libosmocore
Change-Id: Ib554cf7ffc949a321571e1ae2ada1160e1b35fa6
Related: RT#8792
* use define for number of attributes instead of magic number
* add sub_model to gsm_bts struct
* expand number of BTS features
* mark attributes parameter to abis_nm_get_attr() as const
Change-Id: I7ecb0c4339530d3a8354a2f94b34063dda87e030
Related: OS#1614
The VTY config allows above 32bit range extensions, but
db_subscriber_alloc_exten() was unable to generate extensions outside of 32bit.
Add VTY regression test and fix the problem by using proper 64bit types.
Related: OS#2253
Change-Id: I9afe6a8833004ecd2f3f936b2d5aa4de8e7dbcb0
Fix parsing of the 'subscriber-create-on-demand random' VTY: atoi() is not
enough to include the specified range of 1-9999999999.
Use atoll() instead to ensure a large enough number space also on 32bit
systems.
(Note: for me, atoll() truncates at 32 bit when <stdlib.h> is not included.)
Add a VTY regression test for this.
Related: OS#2253
Change-Id: I353e04481ec567adca383d6b51ba8fb865eed73e
* move value_string definition and corresponding functions for BTS type
to shared header to make it re-usable by OsmoBTS
* use consistent function naming
* add similar functions for BTS variant
* add enum to be used by OML Attribute Reporting to distinguish between
type, variant and other info
Change-Id: Ida94725a6fce968443541e3526f48f13758031fd
Related: OS#1614
Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until
we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we
can route this sms somewhere we can reach indeed.
After this change, the conversation looks like this:
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-SUBMIT | |
|------------------->| |
| | DELIVER-SM |
| |---------------->|
| | |
| | DELIVER-SM-RESP |
| |<----------------|
| GSM 04.11 RP-ACK | |
|<-------------------| |
| | |
Before this patch, the RP-ACK was sent back straight forward to the MS,
no matter if the sms can be route by the ESME or not. Thus, the user
ends up getting a misleading "message delivered" in their phone screen,
when the message may just be unroutable by the ESME hence silently
dropped.
If we get no reply from the ESME, there is a hardcoded timer that will
expire to send back an RP-ERROR to the MS indicating that network is
out-of-order. Currently this timer is arbitrarily set to 5 seconds. I
found no specific good default value on the SMPP 3.4 specs, section 7.2,
where the response_timer is described. There must be a place that
describes a better default value for this. We could also expose this
timer through VTY for configurability reasons, to be done later.
Given all this needs to happen asyncronously, ie. block the SMSC, this
patch extends the gsm_sms structure with two new fields to annotate
useful information to send the RP-ACK/RP-ERROR back to the MS of origin.
These new fields are:
* the GSM 04.07 transaction id, to look up for the gsm_trans object.
* the GSM 04.11 message reference so the MS of origin can correlate this
response to its original request.
Tested here using python-libsmpp script that replies with
DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see
here on my motorola C155 that message cannot be delivered. I have tested
with the success status code in the SMPP DELIVER_SM_RESP too.
Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
Use textual representation for message type and protocol descriminator
in case of Gb parsing errors.
Change-Id: Ida925258be119619d8705361730c554a130b75bc
Related: SYS#3610
Previously vty always used additional checks even for GEA0 (no
encryption) which resulted in misleading warnings. Fix this by
adding explicit check for GEA0.
Related: SYS#3610
Change-Id: I1ee468ab3298076d4cb5c7b1f6293c07e272417b
Previously we required pcap.h unconditionally which causes embedded
build failure because it's not included in current version of out poky
toolchain. We can add it to toolchain but it's only necessary for
utils/osmo-meas-pcap2db which is not built for sysmobts anyway so it's
easier to just make this dependency optional and build osmo-meas-pcap2db
only if it's available - similar to the way we build osmo-meas-udp2db.
Related: SYS#3610
Change-Id: I77a5f7eafe0282abedacffad6a9bcb0a8f2b5caa
Previously it was only in gsm_bts_model which is not initialized on BTS
side. It's more convenient to have it in the struct which is available
to BTS as well.
Change-Id: I54fde8c4ccd5d994af08074f5864446e79a93a25
Related: OS#1614
Supporting SI2quater as per 3GPP TS 44.018 will require chnages to the
way System Information is stored because it uses 1:n instead of 1:1
mapping between SI type and generated SI content. This should not affect
other SI types though. To facilitate this transition:
* convert the code to always use GSM_BTS_SI helper instead of accessing
buffer directly
* make helper more robust by adding extra parenthesis
* add similar helper for gsm_lchan
* add function estimating number of SI2quater message to hold configured
number of (U|E)ARFCNs
* add SI2q index/count fields and pass them to rest_octets generator
explicitly
* internalize buffer access in generate_si* functions
Change-Id: I74e4e3cb86364cec869a1472a41b4a95af0d50dd
Related: RT#8792
OpenBSC does not produce any installable libraries, only header files so
this section is unnecessary.
Change-Id: I4c563d775a84f41f82404e0eaba1a25fdbaac1a5
* set proper flag when saving MS Timing Offset
* use gsm_subscriber's IMSI or lchan's name if bsc_subscriber is unknown
* add comments with spec reference
* store/display MS Timing Offset instead of raw Timing Offset field from
RSL
* Compute MS Timing Offset [-63; 192] from Timing Offset field [0; 255],
adjust structure gsm_meas_rep with proper type to store it
Change-Id: I7e003d23a6edb714c5f17688fd6a8edac131161d
Related: OS#1574
It is defined in the file and used twice in there, so let's use it for
all of them which makes code smaller and more clear.
Change-Id: I9fac7cabedff74f8f6293ad8b54420229b80aa71
* add version string to gsm_bts
* add PCU version string to gsm_bts
* rename GSM_BTS_TYPE_OSMO_SYSMO -> GSM_BTS_OSMOBTS to avoid confusion
between BTS model and variant
* add variant enum to gsm_bts_model using enum with variants for each
hw vendor of OsmoBTS
* show connected PCU version (if available) in vty via 'show bts'
This will come in handy when logging details regarding particular BTS
reported via OML, see:
Related: OS#1614
Change-Id: I6710d53115f34634a7b70969cc05fd5c72ff8ab2
This option allows to enable or disable TCH/F allocation on the
TCH/F_TCH/H_PDCH timeslots. Until now, source code modification
was required to enable this feature.
Related: OS#1778
Change-Id: Id18cab25844dc854a66b4e2713e90c3f43afa712
From a human admin viewpoint it doesn't make sense to count the messages sent:
When we use TMSIs, we first send a LU Accept with a new TMSI, and then expect
the MS to respond with a TMSI Realloc Complete message. When that fails to come
through, the LU actually ends in failure, even though a LU Accept was sent.
If a conn breaks/vanishes during LU, we cancel the LU without sending any reply
at all, so the failed LU would not be counted.
Instead, count Location Updating results, i.e. completion and failures.
(With the new VLR developments, LU counters need to be triggered in completely
different places, and this patch prepares for that by providing sensible
counters.)
Change-Id: I03f14c6a2f7ec5e1d3ba401e32082476fc7b0cc6
Explicitly check for and log PCU version received from BTS via OML alert
message.
Change-Id: I3c88663d4e2887a4038b4c3f1387128295b8934e
Related: OS#1614
Add python client which converts TRAP messages into SOAP requests and
perform corresponding actions.
It can be used as follows
./soap.py -d -w http://example.com/soapservice/htdocs/wsdl/test.wsdl
See ./soap.py -h for additional options.
Change-Id: I82844ec7a302bac30d6daee9ebca2188fd48ca46
Related: SYS#3028
ericsson can handle a reference at the end of a imm assign command which is used in
the confirm response. The confirm response is only sent if the trailer is present.
Change-Id: I88560291b5a3a3d7a0bac4d3c089b45f1f6b297f
When the BTS is configured to use a SuperChannel and it is using a
unix domain socket based transport towards the L2TP daemon, then
we must instruct the L2TP daemon to instruct the SIU to change the Abis
Lower Transport Mode using the ALTCRQ / ALTCRP L2TP signalling.
Change-Id: I672bfaa09c42fbeb0c8459f24b2222b952de954b
Do not print anything to stdout directly - use proper logger object
instead: either the one supplied by IPAFactory user or default to NO-OP
NullHandler logger.
Change-Id: Ic3417095a6e8848f0acabb46a9e64c0197b736e2
Related: SYS#3028
The VTY tests assume that $top_builddir == $top_srcdir. Use the script's
location from sys.path[0] to find the correct locations of example configs even
when building in another directory.
Change-Id: I2731f361e3b72d0980968e6cf83594ea450db7c2
Previously any OML NACK message will result in BSC dropping OML link to
BTS which makes it impossible to use optional OML messages which might
be unsupported by BTS. Fix this for 3GPP TS 52.021 §8.11.1 Get
Attributes message. Also, log human-readable NACK name to see what
exactly causing OML link drop.
Change-Id: Ib8af2872c27abb793172ec59bdc145b8d54f83da
Related: OS#1614
In change-id Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3, libosmocore changes
from incrementing SQN after tuple generation to incrementing SQN before tuple
generation. Thus we now need to pass desired_sqn - 1 to get the same tuples.
Change-Id: Ifeda71e713bb60dcd31ac651f461b714cfa39b5c
Related: OS#1968 OS#1969
The timer T3186, which is described in 3GPP TS 44.060, is using 3
bits of the si13 mac block. This requires special encoding. In the
case of T3186, the value is encoded by the formula: bits = t/500-1.
Our implementation uses the formula bits=t/500, which is incorrect.
Change-Id: Ifd340c536cff2d1c4b1b3677a358ea95438801eb
Option "logging level ... everything" is broken for quite some time and
might be deprecated in future. Replace it with "logging level ... debug"
in config examples.
Change-Id: I828ef7671b4fb38717526a18ff8e9a5428cd511e
Related: OS#71
bsc_control.py lacks a copyright header. This commit adds the
copyright header from ipa.py to bsc_control.py.
Change-Id: Ie70bf686ee9bb157198e02bf8d946abf56adc82a
Fix uninitialized memory access warning.
"Conditional jump or move depends on uninitialised value"
Found by valgrind.
Change-Id: Ibc2d585c5db899e6af20104211e32faf3822633a
osmo-python-tests now includes code that retries connecting the VTY socket and
needs no external sleep()ing. This flies through most tests without any sleep()
at all.
See osmo-python-tests.git change-id Icc337f52a93d5fe31fc4ff235ccaf4e0fe75fa39
Change-Id: I42161d9716fe5bb0ef1c56e4bfb770bb99bbca7a
In a future commit, gsm_subscriber will be replaced by vlr_subscr, and it will
not make sense to use vlr_subscr in libbsc. Thus we need a dedicated BSC
subscriber: struct bsc_subscr.
Add rf_policy arg to bsc_grace_paging_request() because the bsc_subscr will no
longer have a backpointer to gsm_network (used to be via subscr->group).
Create a separate logging filter for the new BSC subscriber. The implementation
of adjusting the filter context is added in libbsc to not introduce
bsc_subscr_get/_put() dependencies to libcommon.
During Paging Response, fetch a bsc_subscr from the mobile identity, like we do
for the gsm_subscriber. It looks like a duplication now, but will make sense
for the VLR as well as for future MSC split patches.
Naming: it was requested to not name the new struct bsc_sub, because 'sub' is
too ambiguous. At the same time it would be fine to have 'bsc_sub_' as function
prefix. Instead of struct bsc_subscriber and bsc_sub_ prefix, I decided to
match both up as struct bsc_subscr and bsc_subscr_ function prefix. It's fast
to type, relatively short, unambiguous, and the naming is consistent.
Add bsc_subscr unit test.
Related: OS#1592, OS#1594
Change-Id: Ia61cc00e8bb186b976939a4fc8f7cf9ce6aa3d8e
Add MS TIMING OFFSET (3GPP TS 48.058 § 8.4.8) and P offset (3GPP TS
45.010 § 1.2) which can be used to compute MS TO from known TA.
This will be used by osmo-bts (see
I4dfe5c48834a083e757d5de3236a02e15a238b28) to provide MS TO as part of
RSL MEASUREMENT RESULT.
Change-Id: I8bda57c8d6c15bbb803eca708931556dae118a00
Related: OS#1574
When the IMSI ACL is maintained via the VTY, users may enter IMSIs
without leading zeros. Especially in test environments, where
MCC=001 and MNC=01 is common, it is likely that someone enters the
corresponding IMSI (001010000000001) without the two zeros at the
beginning.
This patch fixes the problem by sanitizing the IMSI, eventually
missing zeros in the beginning will be automatically added.
Change-Id: I56ba0da61978bbdce71d0e320166c52b20b42517
* print pdp->address instead of mm->imsi if mm is NULL
* print mm->imsi in debug log (move it below NULL check)
Change-Id: I4fbf5a54019a46612fbc528d61120182738f9205
Add via_ran to gsm_subscriber_connection to indicate whether a conn is coming
in via 2G/GERAN/A-Interface or 3G/UTRAN/Iu-Interface. Prepares for Iu, but
also for libvlr to decide between GSM or UMTS Auth.
Until actual Iu support is merged to master, this indicator will aid VLR unit
testing.
At some point we may also add RAN_GERAN_IU; it's not on the agenda yet, but to
clearly distinguish the names if we want to add it, explicitly name the ones we
have RAN_GERAN_A and RAN_UTRAN_IU.
Change-Id: I93b870522f725170e4265a5543f6b680383d7465
Make NEIGH an array of Javascript objects, otherwise the JSON is not parseable
when neighbours exist
Change-Id: I42029f40bf357adbb2f3c71cdcbafbc21090e348
Remove the fuzzer interface that was partially implemented in
gsm_04_08.c and silent_call.c is causing problems when an
SMS is sent during an active silent call. The reason for this
is that gsm0408_dispatch() in gsm_04_08.c would decide to
rout all uplink traffic to silent_call_rx() in silent_call.c.
silent_call_rx() is a stub function that discards the data.
This patch removes the fuzzer interface code by placing ifdefs
around it, so that it can be re-activated by experimentators.
Change-Id: Id500197d58663b3f4b1756136343670388b0a4bc
Similar to a recent patch in osmo-python-tests for VTY based tests, but this is
for the Ctrl tests.
The TestCtrlBase tests gave a constant sleep(2) grace period for the process to
startup. This causes tests to take minutes for no reason at all.
Add code to TestCtrlBase to try and connect right away, retrying up to three
seconds in .1 second intervals. This flies through most tests without any
sleep() at all.
Change-Id: I06569767153838bd9cd3edac001df5f6c567874c
When running the testBSCreload test in close succession, I get a "Connection
refused" error because the socket is still in TIME_WAIT state. Passing the
SO_REUSEADDR flag allows reusing the addr despite a TIME_WAIT socket.
Change-Id: I941851b062999ab4b962430f7b27c19935993e0a
If a pdp context is created a xid request is sent right after
the pdp-context-ack message. The sending of the pdp-context-ack
and the xid message is triggered from the GGSN via the GTP
interface.
When the pdp-context-ack message is not received by the MS, it will
send the pdp-context-request again. A lost pdp-context-ack is resent
by the SGSN directly so that the mechanism described above does
not work for pdp-context-ack resents.
This commit adds code to trigger the sending of xid messages also
for resent pdp-context-ack messages.
Change-Id: Ice66790803154310a61a70a54be76cec539c97a7
On 'auth-policy remote', the SGSN requires GSUP server address and port. If it
was missing, the SGSN would print a VTY warning and run anyway. Make this error
more fatal: print an error (flattened a bit) to stderr and abort the program.
Move validation of the GSUP server data presence out of the VTY command itself
and into the config reading function. This way the GSUP server config can be
given anywhere, including below the auth-policy config (was required above).
Don't care about setting the auth-policy to remote with a telnet VTY, because
in that case the GSUP client won't be started anyway.
Change-Id: I4d8db910c32abd8579d3c9b9f0b2cb3a9a6dfe4c
The general infrastructure for UMTS AKA is already in place:
* GSUP with capability to send us auth_vectors that contain
either triplets or quintuples
* mm_context that holds such auth_vectors
Add:
* capability to send UMTS AUTN in GMM AUTH REQ
* parse extended UMTS RES
* on auth response, validate expected AKA with vector and received res/sres
* add Auth Failure message to receive resync AUTS token and
* send to HLR
* clear out-of-sync auth tuple
* enter new state for when we're waiting for HLR to resync and send new
tuples so that the next Auth Request will be handled
Original first half of this patch by: Harald Welte <laforge@gnumonks.org>
Full UMTS AKA procedure including AUTS resync tested to work against OsmoHLR
with R99 USIM and Milenage algorithm.
The sgsn_test.c needs adjustment because we're checking the vector's auth_types
now.
Depends: libosmocore change-ids
I277fb3d407396dffa5c07a9c5454d87a415d393f
If943731a78089f0aac3d55245de80596d01314a4
Related: OS#1956
Change-Id: Ie6a0cefba5e4e7f02cc2eaf6ec006ac07d5c1816
Each running test would open up another socket without ever closing unused
ones. Close the sockets after each test is done.
Change-Id: I0a42caab3bb8c9c9d04b033e4de9efe0ca8fd2af
Prepare for replacing gsm_subscriber with vlr_subscriber. vlr_subscriber will
not make sense to be used in gprs, so have a dedicated GPRS subscriber struct.
(Could change if the gprs code were to use libvlr; is currently independent).
Related: OS#1592
Change-Id: Ia8b391ee009c8545763cba04505be3947835120e
With the OsmoMSC program coming up, the name osmo_msc_data becomes even
more confusing than it already is. Clearly indicate it as libbsc's data of
a remote MSC by prefixing with bsc_.
Also, the Osmocom community has in the meantime agreed to have the osmo_
prefix only in libosmocore, to avoid naming conflicts in case things are
moved there. So while renaming anyway, also drop the osmo_ prefix.
Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
With the OsmoMSC program coming up, the name osmo_msc_data becomes even
more confusing than it already is. Clearly indicate it as libbsc's data of
a remote MSC by prefixing with bsc_.
Also, the Osmocom community has in the meantime agreed to have the osmo_
prefix only in libosmocore, to avoid naming conflicts in case things are
moved there. So while renaming anyway, also drop the osmo_ prefix.
Change-Id: I13554563ce9289de126ba0d4cf329bafcda35607
We're discarding the name OsmoCSCN for the benefit of OsmoMSC. But "CSCN" has
already crept into the master branch in two places; apply the rename.
See OS#1958
Change-Id: Ib4274eb3c172ada1fe7f05746740b456370bc93d
Each running test would open up another socket without ever closing unused
ones. Close the sockets after each test is done.
Change-Id: Ie433c8560de54f9a9d05fa07c44bae3126d19b30
Doesn't make sense to switch this to struct vlr_subscr when it isn't used at
all. So let's remove it.
Change-Id: Ifa5901f8bf1aed3981841d24d4ec8d659f3de7a9
In libosmocore, my patch was merged to master a bit too soon. To accomodate the
request for naming that matches the general "LOG" prefix instead of "LOGGING",
a fixup was committed to libosmocore. Adjust for that.
Original patch: change-id I5c343630020f4b108099696fd96c2111614c8067
The fixup: change-id I424fe3f12ea620338902b2bb8230544bde3f1a93
Change-Id: Ib2ec5e4884aa90f48051ee2f832af557aa525991
The LCHAN and BTS filter contexts are actually never used, so drop them until
someone adds them properly.
For now use only LOGGING_{FILTER,CTX}_VLR_SUBSCR. Some of these will change to
_BSC_SUBSCR once struct bsc_subscriber is introduced, and later on, struct
gsm_subscriber will be replaced by vlr_subscriber so that the names will match.
Depends: libosmocore change-id I5c343630020f4b108099696fd96c2111614c8067
Change-Id: Ifa82f6a461ad4c0eeddb8a38fb3833460432d16b
Handle Delete Subscriber Data GSUP message from HLR to disable Packet
Services for a given IMSI.
Change-Id: I6b9b494fa58bcb95bd550c49f8204f00f8fdf628
Related: OS#1645
To be paranoid, catch a NULL subscriber and/or bts in
subscr_update_expire_lu(): print an error log and avoid segfault.
(I'm not sure this would really happen in a normal situation.)
During aggressive testing of Paging timeout, I came across this segfault in
msc_release_connection() when conn->expire_timer_stopped is set but
conn->subscr is NULL, at the subscr dereference after:
if (conn->expire_timer_stopped)
subscr_update_expire_lu(conn->subscr, conn->bts);
I brought this situation about by a fabricated Paging fault, i.e. in
gsm48_rx_rr_pag_resp() return 0 and don't call gsm48_handle_paging_resp() at
all. Thus conn->subscr is still NULL when expire_timer_stopped is 1.
When looking at CM Service Request handling, the conn->subscr is set before
setting expire_timer_stopped = 1, which is a saner thing to do. But without my
mad 'return 0', there is in fact no way to have a NULL subscriber there.
It looks like all other code paths already do the same, but it's not that
obvious (e.g. _gsm48_rx_mm_serv_req_sec_cb()). So rather catch this case of
NULL conn->subscr, and while at it catch NULL bts as well.
Change-Id: I430dd952b2b928bea7f8360f1e01bb3cccb0a395
* add vty command to set E-UTRAN_PRIORITY, THRESH_E-UTRAN_low and
E-UTRAN_QRXLEVMIN according to 3GPP TS 44.018 Table 10.5.2.33b.1
* remove old command which does not support those parameters
Change-Id: I36dcc79f7b7a02036e74720923d0df1a2a2db504
Fixes: RT#8792
Log more data related to channel allocation:
- channel type
- number of paging attempts
- timers fired
Change-Id: Ib417a9c942c17b902dd80ff555cd9da5f91bff48
Since ce9fec3e896571835ac5bfd2980d6836f2b29f0d libosmocore ignores
parameters to log_vty_command_* functions. Hence parameter of
logging_vty_add_cmds() is ignored too. As we depend on much later
libosmocore version anyway, we can simplify code somewhat by removing
parameters which will be ignored anyway.
Change-Id: I62f752fd88f1d8fefa563648f9864c7c31f87991
Postfix the ran type to clarify the purpose.
Because of the new support of the Iu ran type, there are 2 functions to allocate a mm ctx.
For Iu it's sgsn_mm_ctx_alloc_iu(). For gb it should be named in the same way.
Change-Id: Ic49009e8c20c12308855e1409c09004698c79b95
The fix introduced in dac5867af5 did not
work because autotools in our OE are too old. Use alternative way to
include custom m4 macros to fix it.
Change-Id: I5fe6d1180c2624cfe1d3673314f6846527a43464
Parse the longer UMTS res from the extended Auth Response Parameter IE.
Parse the R99 Authentication Failure and AUTS in case of cause
GSM_REJECT_SYNCH_FAILURE which indicates a SQN re-sync request.
Both still end in 'not implemented' error logs, which are the places where the
upcoming VLR that supports UMTS AKA will integrate.
Depends on recently added constants in libosmocore in
commit 55a43b801385e07a484217925ecf2379b9f54fcf
aka change-id I745061ce8eb88aa23080dadcdbfe2d703c362a30
Change-Id: I4868bbeedc32fa7b8d03b9e3c66db618543d38ec
The currently unused function abis_om2000_vty.c:con_group_del()
allows deleting OM 2000 connection groups. This commit adds a
matching VTY command to make use of it.
Change-Id: I39a90b06e19356c536cacd1c923e195dd305ab80
'self' will not be accessible in that context, so this patch isn't
useful.
This reverts commit b39053ad6d.
Change-Id: Ic1a9ba5fdfd7bdc6c5cf0974e8c637ae23b81ece
To be able to do R99 UMTS authentication, we need to send along AUTN bytes in
the Authentication Request. Add autn parameter to gsm48_tx_mm_auth_req() and
conditionally append the R99 AUTN TLV to the Authentication Request message.
Change-Id: I0d644559088706aa06b42b9bfe1f8c21ca6fa4da
Add verbose logging as well as three retries around the place that often
fails on our build server with a 'Broken Pipe' error.
Change-Id: I8851b76b2d7b87dd500ae40f47e6bea716ef3fc4
Check conn->subscr against NULL.
gsm0408_rcv_cc() dereferences many conn members without checking presence: the
bts and lchan members may be expected to be NULL in the ongoing MSC split and
3G developments.
But the conn->subscr is initially NULL, so an MS sending a CC message before
something like a LU or CM Service Request will result in a segfault. Prevent
that.
Note: the upcoming VLR will be more restrictive on what messages are processed,
this is a "backport" to the situation on current master.
Change-Id: If067db7cc0dd3210d9eb1da15be6b637795a3ecf
Added in recent commit 42def7205b
"Implement VTY configuration to control Early Classmark Sending"
Change-Id: Iaf640fa6e1f234f594fb8dc06f716d3d3e95eb2a
all other objects always use the MO instance. The existing code
likely is due to copy+paste mistakes.
Change-Id: Ie0a31cd93993da10f31eecf530a5a05773c11eb1
It is one of these changes that should have never worked but did
for a long time. Only recently a corrupted GTP message was seen.
The code in ccd2312d10 tried to
solve the right problem but was deeply flawed.
* Make the code operate on the copied message and not the original
one that is deleted by the underlaying layers on return
* Add an out variable to determine if the msgb should be deleted
and assume that by default it will be deleted.
Change-Id: I564526e7cde2b8a2f0ce900492cd38fc23c176a7
It is generally not a good idea to add more and more external
dependencies unless absolutely needed. autoconf-archive is a good
example of that, as we need to update all build machines, and older
OpenEmbedded versions do not appear to have (the right?)
autoconf-archive recipe. Provide local copy of necessary m4 files to fix
the build there.
The dependency to autoconf-archive was introduced in Change-Id
Ied9c950dafa65f324cf31298b13b590f56139700
Change-Id: Iacc1958b471ec3fc65307259039e1d496845f528
The ABI of libgtp changed and we require a new library now. Drop
the SO_VERSION from the library name and just depend on libgtp-dev.
Change-Id: Ib301b27e2c08fda827b55820389247e27e5e8fc7
in gprs_gmm.c:gsm48_rx_gmm_ra_upd_req the variable reject_cause
is not initalized, which is ok, since it gets initalized before
the jump into the "rejected" path. However, the compiler still
throws a warning. This commit fixes the problem by preinitalizing
the reject_cause to GMM_CAUSE_PROTO_ERR_UNSPEC
Change-Id: I84cffb631e4cad3d4748512b47e3876208f53727
In some cases, when successive mobile originated calls are made, the LAPDm UA
message gets lost because the channel is relased to early. Too overcome the
problem we do not send release indications immediately. Instead a flag will be
set and the message stored and sent on the next TCH-RTS-IND.
This commit adds the required flag and the msg-buffer to struct gsm_lchan.
See also coresponding change in osmo-bts.git:
Change-Id Ie4f70c75f0137b4bd72d579b3a32575bac2fca38
This patch is is a slightly improved/reformatted version of:
95d1f15ad1
Change-Id: I15fc1ef8e9e83f009bde96de9a8e95702cffbce6
The SI3 rest octests contain a flag that indicates if early classmark
sending is allowed in this cell or not. So far we always set this to
one, now it is configurable using the 'early-classmark-sending' command
at the VTY node.
Change-Id: Ia0b1cc5ab45673f3da70c59ae8917eba343f9862
There were some members that we neither set nor read, so let's
shrink the struct size and remove those unused members.
Change-Id: I02136e3aa91e58b2afc923c09c8693095497fdd7
When displaying the PDP context, it is quite useful to also show IP
address and TEI information about the GTP side of that PDP context.
Change-Id: I56ea530240c15b26729e7a42e539020cb1e233e5
cosmetic ws in common_cs_vty.c, osmo_msc.c
comment: tiny typo fix in gsm_04_08.c
In comments, drop some unbalanced braces, because simplistic C file harvesters
will break at a single opening brace even if it is in a comment. This is aimed
at the fsm-to-dot.py script in libosmocore/contrib.
Change-Id: I3c1fa53195a1e57d6fe0a6791c346d30ceff1251
When the creation of a new compression entity fails, an error
message is created, this error message contains printf with
a dereferentiation of the compression entity, that is clearly
NULL at that point. This commit corrects that.
Change-Id: I87371ade0ccd6a93b446f2013c1747f486739518
Use CTRL_CMD_DEFINE_RO(), CTRL_CMD_DEFINE_WO() and
CTRL_CMD_DEFINE_WO_NOVRF() where appropriate to get rid of boilerplate
code.
Change-Id: I5bcea0b4f4b8f535bef2b423f2013b8b4a218b5b
osmo-bts consumes the gsm_data_shared.{h,c} files and assumes the
OpenBSC directory layout. Install the files into the specific
sub-directories to make the --with-openbsc=dir option work.
Change-Id: I3da21402dee3d6f1d812b232b0a3f13b8a462d5b
* Explicitly check when ARFCN array split is impossible and return
gracefully instead of using negative index.
* Separate range encoding into generic function and use it for all
SI-related things.
* Propagate the error into that function and to its callers.
* Add separate test-case for the segfault previously triggered by this bug.
Change-Id: I3e049ab2d7c1c4d6c791b148f37e10636a8e43e0
Related: RT#7379
Previously reading from socket would block if no data were sent by
the server. Use non-blocking read for set and get operations.
Change-Id: I706d54a4a7ceef62683bf9a2fe63fc9ab331c24e
* clearly separate report parts
* use textual representation for failure cause if possible
Change-Id: I7a98a77011463021d0edd6ecfab1680e211f7e16
Related: OS#1615
Use osmo_strlcpy() to fix unsafe invocation of strncpy(), which potentially
left the result unterminated.
Change-Id: I1a119b1760a3e3262538b4b012d476fdce505482
Re-apply the reverted commit 98bc7fa50d, this
time with a clear error message in case autoconf-archive is not installed.
Change-Id: I631bde22e79ec0318eb9c8114db5861a1d635816
Tweaked-by: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Add openbsc-dev with source and header files necessary for osmo-bts builds.
Max's note: extracted from Debian packaging work into separate commit.
Change-Id: I25f8c639d2dc525ca280a7cd09de3ca6358d2568
The code checked 'if (strcpy(..) != 0)' which is always true and thus always
copied twice -- luckily we want to copy anyway and so this is not an actual
functional failure.
We could correct to strcmp, but instead of iterating to compare, we might as
well copy right away.
Change-Id: I0ea035bd478f7022ed65e9e84d8aaf5e423309b7
This introduces a failure with ./configure on my machine:
../configure: line 6612: syntax error near unexpected token `-Werror=implicit,'
../configure: line 6612: `AX_CHECK_COMPILE_FLAG(-Werror=implicit, CFLAGS="$CFLAGS -Werror=implicit")'
Makefile:420: recipe for target 'config.status' failed
make[1]: *** [config.status] Error 2
Installing autoconf-archive did not fix the error.
So even though jenkins seems to accept this, I cannot build with this patch.
Let's find out how to do this in a way that all systems can still build
and then re-apply this patch.
This reverts commit fd161ccce8.
Change-Id: I2b368500b07f233882ef854eca1fa21f6df39e29
Make warnings (when available) related to common memory-related issues
into errors to harden the source and decrease chance of errors.
Change-Id: Ied9c950dafa65f324cf31298b13b590f56139700
* add missing spaces after comma and minus
* prevent useless recursion calls
* mark static functions as such
* name and explicitly use enum for ARFCN range
Change-Id: If5b717445c8b24668bad0e78fd5bb51f66c4d18e
Call vty_init() before handle_options() to make sure the host.app_info is
populated before --version potentially tries to print it.
The segfault was introduced by 2c05f75bbf in a
recent MSC-split merge.
Change-Id: Ice91256d72b9eabd52709352ba6cc6a42af2921b
The term "phone" is incorrect. Rename phone to "MS" (mobile station)
in the comments and log output of gprs_llc.c
Change-Id: I322d3d99452502da7555cc2af6bc8a192ca3c9c5
In some rare cases the modem might send a xid indication that does
not contain anything except the version number field. The sgsn
ignors such SNDCP-XID indications by stripping the entire field
from the response. We found a modem in the wild that started to
act problematic when the empty SNDCP-XID was missing in the
response. This patch changes the XID negotiation behaviour in
a way that if a modem should send empty SNDCP-XID indications,
the reply will also contain an empty SNDCP-XID indication. Apart
from that the SNDCP-XID version number is now parsed and echoed
in the response. This ensures that we always reply with the version
number that the modem expects. (The version was 0 in all cases we
observed so far)
Change-Id: I097a770cb4907418f53e620a051ebb8cd110c5f2
Related: OS#1794
libosmocore change-id I857af45ae602bb9a647ba26cf8b0d1b23403b54c adds
OSMO_VALUE_STRING to compose value_string arrays with the exact enum names as
entries. Use instead of identical local macros in two places.
Change-Id: I1b44d2a3f293785a01d6a587c78f9e0cbeec70c3
gsup_test_client was added in 4f8e34b226 and
moved to libcommon in 2c1f8c8ceb, both of
which forgot to adjust the .gitignore.
Change-Id: Idd0d29a2f5c5b9b038103c955e0027d9ee9fee73
debian/control:
* restructure to make it easier to incorporate further changes
* update package descriptions
* update project URL
debian/rules:
* use proper hardening syntax
* restructure to make it easier to incorporate further changes
* remove useless comment
debian/compat: update compatibility version
debian/coryright: update to match Debian format
Change-Id: I49cc9239b15dc77d782914ca2547e601d049acdc
Related: OS#1694
* log xid type as string instead of int
* log packet encryption status, algorithm and IOV-UI in debug mode
* print encryption parameters when dumping llme via vty
* log key propagation from MM to LLC
Related: OS#1794
Change-Id: I30c38fdeb0b88bb39bdb9928851300bc79e6aec6
This option only served to demonstrate possibility of manually selecting
<id> field in CTRL protocol. Since the transition to generic ipa module
this is no longer exposed so the option became a no-op. Correspondingly
there's no need to explicitly initialize the RNG - the Ctrl class
handles random <id> generation internally.
Change-Id: I10cc7c069354cced2bba84fe67c69c28b8596ded
When passing a NULL config to osmo_oap_client_init(), set OAP to disabled
state. Along with the previous fix that ensures message rejection in the
disabled state, this makes use of OAP in the GSUP client optional.
oap_client_test: expect null config to set state to disabled.
Related: OS#1592
Change-Id: Ie4d622fcfd24cb7d89d19f93e4b2571d8fadd1a3
Fixes the bug indicated in oap_client_test.c: adjust to actually expect the
proper behavior.
Also adjust for modified return value for message rejection. Instead of -1,
just expect < 0.
Adjust experr for new error messages.
Related: OS#1592
Change-Id: I16165d228653e8a2689f9df94b77b470c06480c6
There is a hole in OAP where a disabled OAP still accepts at least a
Registration Reject message, after which it will do things it shouldn't. Show
this by expecting the bugs, to be adjusted with the upcoming fix.
Related: OS#1592
Change-Id: I4a5fde308b876946fea2571ea1a550f0cc7ee136
Use libosmocore's DLOAP logging category for OAP.
oap_client_test.c: make sure DLOAP is in DEBUG level to not lose any logging
messages from experr.
Todo: we're using a "Library" logging category, which is not really what the
library category was intended for. Instead, the OAP client should probably be
given a logging category like DVLR or DGPRS in its initialization API.
Related: OS#1592
Change-Id: Ic765c19381b0d983da90a5d8aee9cd17e31cf34a
Mainly to differentiate the OAP messaging API (osmo_oap_ in libosmocore) from
the OAP client.
This is in preparation for moving the oap client to libcommon, which is in turn
preparation for libvlr. Add the osmo_ prefix, as all public Osmocom API should
have. We also have OAP messages code in libosmocore, so clarify by naming this
osmo_oap_client, and by also renaming the oap_test to oap_client_test. This
reshuffling will allow an easy move of OAP to libosmocore if we should want to
do that. A number of patches will follow up on this.
Related: OS#1592
Change-Id: Id447d2bebc026a375567654adafa5f82439ea7e1
This corresponds to change-id If5099e60681a215e798b6675f21813f26769c253 in
libosmocore, which is now required to build openbsc.
Related: OS#1592
Change-Id: I2f06aaa6eb54eafa860cfed8e72e41d82ff1c4cf
Use the DLGSUP logging category for GSUP.
Bump the required version of libosmocore to 0.9.5 to benefit from the DLGSUP
logging category fix in core/logging.[hc].
(Id974c7be158e4d60421a98110f5c807aefd31119)
Todo: we're using a "Library" logging category, which is not really what the
library category was intended for. Instead, the GSUP client should probably be
given a logging category like DVLR or DGPRS in its initialization API.
Related: OS#1592
Change-Id: Id3938267fa062e1a997d3704cd678874306f86ee
This is in preparation for moving gsup to libcommon, which is in turn
preparation for libvlr.
Related: OS#1592
Change-Id: I9c95d00f1a9420887a44c938b1d0ee3e20586f4c
Make sure everything is named gsup_client_ / GSUP_CLIENT_.
Rename static gsup_client_send() to client_send() to avoid clash with public
gprs_gsup_client_send() being renamed to gsup_client_send().
This is in preparation for moving gsup to libcommon, which is in turn
preparation for libvlr. libvlr and osmo-sgsn will use the same GSUP client
code. A number of patches will follow up on this, also for the the OAP client.
Related: OS#1592
Change-Id: I57433973b1c4f6cc1e12e7b1c96b5f719f418b51
GSUP was added to libosmocore in 0.9.4. We're using it here, so make up for a
previously missing bump.
(BTW: I'm pretty sure that other dependencies are also in dire need of a bump,
but leaving that for another patch)
Change-Id: I4f245a7d78d0889b37084c52478372bddb8289d6
* replace some tabs indent with spaces
* add comment to make sure no new tabs are used for indentation by emacs
* remove unnecessary parenthesis
Change-Id: Ib79fd4317d40ee4fd87b090b9faf8ebaf4bfca64
Replace hackish ipa_send_* routines with proper implementation from IPA
module thus making it part of extended tests.
Change-Id: If13ed7fd243ce3aeef505d2e8468e221aa62f79e
This reverts commit 1611df5226.
This is due to a segfault introduced to the asan build only. See:
http://lists.osmocom.org/pipermail/openbsc/2016-December/009966.html
Subject: new sanitizer breakage: SIGSEGV in sgsn_create_pdp_ctx()
Date: Tue Dec 13 12:08:32 UTC 2016
Change-Id: Ic926c0e6778947b516994822e3a21d4fde25bb02
Enable Deactivate PDP context based on the IMSI of the subscriber.
When there are PDP contexts present for a MM context,
PDP context will be deactivated along with GMM Detach(MM context deletion).
If there are no PDP present, MM context will be deleted to avoid
further PDP context request from the MS.
Test cases is added to check this functionality.
Change-Id: Ia0a41aa2218ec2fda4ea17a37c8cc55cba63dd13
GSM48_CMODE_DATA_6k0 was not properly terminated and thus resulted in a
bug.
Change-Id: I4000f06d0b49c4afb0446beddd150521c4ba3cf0
Fixes: Coverity CID 148207
For TCH/F_PDCH in PDCH mode, directly return the lchan to use, in order to
switch it to TCH/F. To check the pchan type in chan_alloc.c, make ts_pchan()
public in gsm_data_shared.h.
Commit c3f72f63af broke TCH/F_PDCH, as a fallout
of setting the GSM_PCHAN_PDCH subslots number to 0. This is sane and correct,
but the chan_alloc code failed to see a ts as available if it has no subslots.
Explanation:
_lc_find_trx() checks each timeslot. For normal, static TCH timeslots we
determine the number of logical subslots contained and check whether one of
them is free. For dynamic TS, we can do the same when in TCH mode, but when in
PDCH mode, we already know that it is available for immediate switchover for
voice and hence can return it right away. TCH/F_TCH/H_PDCH already has a
special check for that. TCH/F_PDCH doesn't, but this worked for TCH/F_PDCH as
long as ts_subslots() returned 1 for PDCH: the for-loop at the bottom of
_lc_find_trx() checked one subslot, which succeeded on an lchan in PDCH mode,
since PDCH lchans are always marked type == NONE and state == NONE. Now we more
accurately acknowledge that a PDCH timeslot has zero subslots and that a
dynamic timeslot in PDCH mode can always be switched to voice immediately,
without checking lchan type or state.
So, above mentioned commit set PDCH to zero subslots, and the for-loop to check
the (zero) subslots never ran and hence never returned the lchan. This fix adds
a special condition for TCH/F_PDCH in PDCH mode, same as TCH/F_TCH/H_PDCH.
(Todo: ts_pchan() can probably be used in other places as well to remove some
code dup. Leaving that for another patch.)
Fixes: OS#1868
Change-Id: I5d555d018a5bcb8d948e54059d32ec4c9b3070d0
Preparing cosmetically for a subsequent commit which will add another pchan
kind to be checked, rather use a "switch (pchan) {}". Also reverse one if()
branch to "early-exit" style.
Change-Id: Ie5eb0fa859c4f225616095dc56d52ce0f2dc8bdc
This is useful particularly in case where we deactivate PDCHs
which don't have a SACCH associated. The existin code would
always attempt to deactivate a SACCH even in those cases, leading
to the BTS responsding with related error messages.
Change-Id: Iaf46782329b38ba8f3d438e6c75c2d467b852734
When the LLC-XID request is constructed the order of the elements
in the TLV structure is reversed. This is in theory not a problem,
but differs from what we know from our practical experience. This
commit fixes the problem.
Change-Id: I1d71c947350d3c5a85ff36b71c1b8f036071d162
This is intended to prepare for splitting gsm_subscriber_connection into BSC
and MSC specific structs, to make the splitting patch more readable.
Change-Id: Ib9666225fb9bfec2cf1e364343560571869fe6a7
Rename current subscr_con_allocate() and subscr_con_free to bsc_*,
and add two separate msc_subscr_con_allocate() and _free().
The msc_subscr_con_free() ignores all lchan members.
In libbsc use bsc_*, in libmsc use msc_*.
Change-Id: I3cf7c7cafdf4672ec7b26058bba8a77159855257
Future: there will be distinct subscr conns for libbsc and libmsc.
Leave the timezone VTY output in libbsc's config_write_net(), until the BSC/MSC
separation of struct gsm_network is completed.
Change-Id: I9712b2e07b4f1ab8d2e4ad40a8d771e98ed25b20
Time zone used to be configurable per-BTS. In the upcoming MSC-split, no BTS
structures will be available on the MSC level. To simplify, drop the ability to
manage several time zones in a core network and place the time zone config on
the network VTY level, i.e. in gsm_network. If we are going to re-add fine
grained time zone settings, it should probably be tied to the LAC.
Adjust time zone VTY config code (to be moved to libcommon-cs in subsequent commit).
Adjust time zone Ctrl Interface code.
Change-Id: I69848887d92990f3d6f969be80f6ef91f6bdbbe8
Implement connection_for_subscr() from a completely different angle: instead of
looking up lchans in bts structs, look up the subscriber in the global list of
gsm_subscriber_connection. static lchan_find() is thus obsoleted.
All callers of connection_for_subscr() live in libmsc, so move to libmsc.
The move and edit are done in a single commit since the old and new
implementation have nothing in common.
Future: osmo-cscn will use this, without bts being present.
Remove implementation of connection_for_subscr() from channel_test.c -- it is
possible that the abort() in there was intended for a regression test, but
actually it seems the implementation was merely added for linking reasons, and
the abort() added to guard against the NULL return value: no comment nor the
commit log indicate that the abort() is test critical; the addition was the
only change in channel_test.c for that commit; at the same time a
connection_for_subscr() call was added in libmsc.
Change-Id: I5e0ba0ecf1726ebd540800f4e98fdfc937c904ff
Keep only BSC specific bits of the 'network' VTY node in bsc_vty.c, move more
general VTY commands to common_cs_vty.c.
Add arg to common_cs_vty_init() to pass a config_write_net() function. Pass a libbsc
specific config_write_net() function.
Future: upcoming omso-cscn will re-use the VTY bits moved to libcommon-cs and pass a
different config_write_net() function.
Change-Id: I871b7b32a0c56fdce983e409cf244ec487d24e71
Move gsmnet_from_vty() and the bsc_gsmnet global to common_cs_vty.c.
Rename bsc_gsmnet to vty_global_gsm_network and make it static to common_cs_vty.c, to
clearly mark the global variable for VTY use only.
Introduce common_cs_vty_init() to set vty_global_gsm_network.
Change-Id: I26c5c47de08f899b896813d09612d5cb2f8e42d6
Now that bsc_network_alloc() is separate, move it to before the VTY init (a
subsequent patch will pass the gsm_network instance as a parameter to
vty_init()).
bsc_hack.c: drop the comment that says about the VTY init: "This needs to
precede handle_options()" -- it is not accurate. Actually move the
handle_options() above both vty_init() and the bsc_network_alloc() calls, to be
able to decide which mncc callback to pass to bsc_network_alloc. It would make
sense to set this later on, but that would require further refactoring of the
bsc_network_init() and gsm_network_init() signatures, so not in this patch.
Change-Id: Ie6a7037e703b5a2d08ceeb20d35f197aaddc9d1b
For patch clarity, keep some code dup to be removed in a subsequent patch. In
the same sense don't change the fact that mncc_sock_init()'s return value is
ignored.
The global gsm_network instance 'bsc_gsmnet' is basically only used by the VTY,
and a future patch will "hide" that global in a vty .c file. In a nutshell, I
want to
- first allocate a gsm_network,
- then initialize the VTY passing the gsm_network pointer,
- and then read the config file using the initialized VTY.
So far, bsc_bootstrap_network() allocates the gsm_network and reads the config
file right away, which only works by sharing the extern bsc_gsmnet pointer,
which I would like to uncouple.
Change-Id: I480a09a31a79766ad07b627dd5238b7e37f3be7a
libbsc and libmsc will have separate subscriber connection structs. Hence don't
rely on gsm_subscriber_connection, but work on a direct pointer to the counter
for the next RP reference.
The only very thin function in gsm_04_11_helper.c thus becomes obsolete: drop
the entire file.
Change-Id: I2a2e9ba6a981a385d1f8f07acbe03536ffed0072
Factor out encryption info from struct gsm_lchan as struct gsm_encr, placed in
common_cs.h.
Change-Id: I94015fb9dd511c37c1e3058a0963c780b3f700ac
Future: this will be used by libmsc's subscriber connection, for osmo-cscn.
Both libmsc and libbsc will need distinct gsm0480_send_ussdNotify() and
gsm0480_send_releaseComplete() functions, since there will be distinct
subscriber connection structs.
Rename to msc_send_ussd_notify() and msc_send_ussd_release_complete(), and add
the same in libbsc with bsc_ prefix in new file gsm_04_80_utils.c.
In preparation of this patch, the message generation part of these functions
has been added to libosmocore as gsm0480_create_ussd_notify() and
gsm0480_create_ussd_release_complete(). Use these.
Adjust all libmsc and libbsc callers according to use the msc_* or bsc_*
implementation, respectively.
Change-Id: I33a84e3c28576ced91d2ea24103123431f551173
For new MM contexts, the ra_id was correctly obtained from the ue_ctx, but in
case an MM ctx is re-used and the ra_id changed, the new ra_id was not copied
to the MM context; instead, the ra_id was overwritten with uninitialized data.
Always initialize the local ra_id variable from the ue_ctx->ra_id for Iu
connections; it is used further below to update the ctx->ra_id.
For the case of a brand new Iu MM ctx, the ctx->ra_id then gets initialized a
second time. We could technically drop the init in sgsn_mm_ctx_alloc_iu(), but
it doesn't hurt either way.
Fixes: CID#57936
Change-Id: Ia06458758362e76925690b1757d8ced95e9609e4
Coverity scan detects a Null pointer deref (FORWARD_NULL) in
gprs_sndcp_comp.c: 67 in gprs_sndcp_comp_create().
The reason for this is that gprs_sndcp_dcomp_init() and also
gprs_sndcp_pcomp_init() rely on the comp_entity->algo algo
flag. If the program logic is correct a null pointer deref
should never occur.
This commit adds OSMO_ASSERT() statements to ensure a null
pointer deref is catched if if the ...comp_init() functions
are used with incorrect parameters.
Change-Id: I7748f06d1739a697edad5100a031e5aa1ef11ed1
Used by libbsc, libmsc as well as osmo-bsc and osmo-bsc_nat.
Moving gsm48_create* to libcommon-cs affects linking of osmo-bsc_nat, resulting in
undefined references to gsm48_extract_mi() and gsm48_paging_extract_mi(); fix
that by placing libfilter.a left of libbsc.a upon linker invocation.
Change-Id: I212c2567b56191022b683674c1c4daf842839946
Reincarnate gsm_network_init() as the parts not specific to libbsc.
Move from bsc_network_init() those bits that are not BSC specific (and useful
for upcoming osmo-cscn).
Add libcommon-cs to all linkages that use gsm_network_init().
Note: the only requirement to allow linking gsm_network_init() without libbsc
is to keep the call to gsm_net_update_ctype() out of libcommon-cs. The other items
are kept out of libcommon-cs because it makes sense semantically. But the separation
is not strong in that the BSC specific data members are of course still
omnipresent in struct gsm_network. If bsc_network_init() is not called, these
are not initialized properly -- for now no users of uninitialized members
exist.
So this is just a first step towards a sensible split of the BSC and MSC
gsm_network structs. The long term aim should be to have entirely separate
structs with some common general items.
Change-Id: If06316b97002390dc9a434686750cb96193ea63b
bsc_network_init() is more fit to live in a BSC specific header, move it to new
common_bsc.h. It will probably also absorb the BSC-specific part of gsm_network
in the future.
Adjust header includes across the board. Particularly, fix abis_nm.h by
explicitly including gsm_data.h: it so far relied on other headers to do that,
which now is no longer always given.
Change-Id: I9edfb1e748bb1cb484fadd48b0406f5b3098e89b
The gsm_network_init() function initializes a whole lot of BSC specific stuff.
Aiming to move some of it to libcommon-cs, first rename it to bsc_network_init().
This will retain the BSC specific stuff when the move is done.
Adjust all callers.
Future: osmo-cscn will call the more generic part and not the BSC specific
part.
Change-Id: I4816ae19374390fc5c64972f7cad2e9ec3d8bcc3
Put mncc_recv_cb_t in common_cs.h to avoid header include complications: if placing
right above struct gsm_network, one must include gsm_data.h to use
mncc_recv_cb_t as function parameter in a header, which will include
gsm_data_shared.h, which will include common_cs.h (future knowledge). Since I will
need to use mncc_recv_cb_t in common_cs.h, including gsm_data.h from there would
introduce an #include loop. Avoid that and define mncc_recv_cb_t in common_cs.h to
begin with.
Change-Id: I2e64cffa563750ce9f3172ffba6f9cf5b9280e9c
Timer T3395 starts at the transmission of Deactivate PDP request using
pdpctx_timer_start but there was no corresponding stop function.
The timer is stopped when Deactivate PDP Context Accept is received.
This according to 3gpp spec reference 24.008 section 6.1.3.4.2.
Change-Id: I825c0a47d39e784dd1b8251f564609262530a5c6
This is a speculative change for interrogateSS and by not answering
the request the radio connection would remain open long.
The SS/USSD code is from a time where none of knew much about GSM. We
do not support SS but should reject it. We have checked for an empty
string in the text field to guess if it is a result/release to not send
more information. The right way forward is to decode the ASN1 into the
fields REQUEST/RESULT(last).
Fix an issue and make the code worse. Assume ss_code > 0 to see if this
is a interrogate invoke. The issue is that code 0 is a well defined
value but unlikely to be used.
MAP ASN1 definition:
SS-Code ::= OCTET STRING (SIZE (1))
-- This type is used to represent the code identifying a single
-- supplementary service, a group of supplementary services, or
-- all supplementary services. The services and abbreviations
-- used are defined in TS 3GPP TS 22.004 [5]. The internal structure is
-- defined as follows:
--
-- bits 87654321: group (bits 8765), and specific service
-- (bits 4321)
allSS SS-Code ::= '00000000'B
Change-Id: Ib0dc4485388f030eb172fe21f5327b7ab94751f5
When OM2000 has confirmed that a TS is started, call dyn_ts_init()
on the timeslot to start the processing for fully dynamic (osmocom
style) TCH/F_TCH/H_PDCH. This should in turn trigger the activation of
idle timeslots as PDCH until we want to allocate any of them for TCH/F
or TCH/H.
Change-Id: I1a1fd61d6afd85449cacad4bacfb830252dab6b1
Ericsson has introduced a propritary format to issue the S13 BCCH
information. Normally the system info type field for SI13 would
be encoded as 0x28. Ericsson encodes that field as 0x02 and ads
a bcch mapping parameter, (IEI=F2) This patch sets the BCCH mapping
to 0x00 (=BCCH Normal) statically (0xF200)
The new constands are added to libosmocore, see commit:
f0f9c8c29daaefbf9cff19177ade4a13ffb2e36c
Change-Id: Ie0900f9b810744172b3090ce1b0ef7b7a1132946
function bts_model_rbs2k_start() in bts_ericsson_rbs2000.c lacks
the feature definition for GPRS and EGPRS.
Change-Id: I777a67862084aa6cca39cfc43f5708e47608b0e6
This test is to trigger the use-after free issue in commit bff7b0d80972. If
compiled with address-sanitizer the test will abort without the fix.
Change-Id: I5e8c6626ba43342740f08d699383bdded739079f
Ticket: OW#3049
Sponsored-by: On-Waves ehf
In case the link_info is deleted we have to stop handling the stored messages
inside link_info. Not doing so can lead to invalid memory being accessed.
Change-Id: Ieb8503e9e94e7a5ac450ad8aa1713ec4f21cdea5
Ticket: OW#3049
Sponsored-by: On-Waves ehf
it seesm more recent RBS2000 models have much larger CCP and CI value ranges
than those of older models.
Change-Id: Ib116c1fac901b293929fce34223d1fd0af15d2bc
The code for supporting the configuration of the OM2000 CON (LAPD
Concentrator) MO was so far incomplete and not used from the OM2000 FSM
initialization. This patch adds
* VTY commands for configuration of CON Groups and Paths
* The FSM integration to actually configure the CON MO
Change-Id: I56dc1b5e35adef3a2078bcf9536537eb0f454192
This happens e.g. with DAHDI driver, when the DAHDI device cannot be
opened. Let's not prematurely seg-fault early in the RBS2000 signal
handler, but take the proper error handlign for this.
Change-Id: I9223fb1568d3db7e278f07240c4be334c6602a13
talloc_ctx.c: In function ‘talloc_ctx_init’:
talloc_ctx.c:40:2: warning: implicit declaration of function ‘msgb_talloc_ctx_init’ [-Wimplicit-function-declaration]
msgb_talloc_ctx_init(ctx_root, 0);
^~~~~~~~~~~~~~~~~~~~
Change-Id: Ib8ebc02d5cf0d2b4019473d3750ae7c6f8a32896
For TCH/F_PDCH, return an invalid chan comb (0) and print an error message
that hints at the proper pchan type to use instead: TCH/F_TCH/H_PDCH
Change-Id: Ibe0f944573f0a6d1be4bf7cf4986c4b2b3bd6d0d
When OM2K sets up the timeslots with the BTS, the dynamic channel state
is not yet resolved to any particular pchan type. Instead of using the
dyn state, always advertise dynamic timeslots as pchan2comb(TCH/F).
In the past, the Ericsson dynamic timeslots were handled as pchan type
TCH/F_PDCH. This is a mistake, as this pchan type is intended for
the ip.access dynamic PDCH way of dynamic channels. In any case, in the
initial state of this pchan type, the timeslot was initialized as
pchan2comb(TCH/F) because the ts->flags do not reflect an active PDCH
yet. In short, this patch does not change the behavior of TCH/F_PDCH
timeslots, only clarifies it.
It would in fact make sense to disallow use of TCH/F_PDCH for OM2K,
but that should probably be a separate patch.
The proper pchan to use for Ericsson dynamic timeslots is
TCH/F_TCH/H_PDCH. These do not use ts->flags, but ts->dyn.* as state,
which first reflects pchan_want == pchan_is == GSM_PCHAN_NONE. Hence
the timeslot was initialized by OM2K as pchan type zero, which is
unknown / invalid. So, instead of using pchan_is, which is not yet
reflecting anything meaningful, always initialize as TCH/F chan comb,
as Ericsson hardware apparently expects it.
Change-Id: If0693f7c5c85977b0e4acbc701ee5d635434d0d1
talloc_free the cfg only after asserting num_bsc count sanity.
This caused a failure in the 'bsc-nat' test with -fsanitize build.
Should fix the Osmocom_Sanitizer build on jenkins.osmocom.org
https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/
Change-Id: Ic20aacaccffcaa58ccec6d24c884727dc1bc50e6
Throw warning message in case the MO state does not change
to enabled after sendeing an Enable-Request message.
Change-Id: Idfde8d6f71526e8acfea51835732515a4bee858e
This patch adds support for ericssons sambm negotiation.
This patch depends on libosmo-abis commit:
2788c7eacab91cd39d68e316fc8ee87763bbfeb4
Change-Id: I56b1c1cef07a61143fc0e8058480805cddfeff96
This patch adds parsing for OM2000 MO fault report map parsing,
the bits in the fault maps are counted out and displayed.
Change-Id: I6e2928f39b09bc08e9ab78bc10bc81e07f7eb55d
Contrary to standard A-bis, in the RBS2000 case the BSC connects
the signalling data links (LAPD) to the BTS. In case one of them
drop, we need to attempt to re-establish them.
This requires libosmo-abis with Change-Id I07f0f79e0cda09766f357032ffb4e7ad643d448a
Change-Id: I710b5af5d0acbdd3febd314849340f2adb7abd80
In case of the sysmoBTS and receiving a channel activation ack on a channel
that was marked as broken, release it again.
Use a normal release without SACCH deactivation and release the rqd_ta data.
Also add a local variable 'ts' to shorten some lines.
The typical situation where this would occur is with high latency between BTS
and BSC (or NITB). If a channel activation ack does not arrive in time, a
channel is marked broken, and never recovers after that. This patch will
release the channel again, which will remove the BROKEN_UNUSABLE state and
makes lchan available again. Reported by Rhizomatica.
However, in case of packet loss, i.e. when the channel activation ack never
arrives at the BSC, this patch does not provide a resolution of the
BROKEN_UNUSABLE state.
On dynamic timeslots: clearing the dyn ts state could possibly happen in
lchan_free() instead of in rsl_rx_chan_act_ack(). That's to be done in a
separate patch, if at all.
Tweaked-By: nhofmeyr
Change-Id: I63dc0deaf15ba7c21e20b1e0c7b85f0437e183ed
The GTP protocol specification requires us to include the MSISDN IE in
all non-secondary PDP context activations. However, when no real HLR is
used (e.g. via GSUP), we do not have the MSISDN information available
and so far simply sent a zero-length MSISDN IE in GTP. The latter is a
violation of the spec.
So to resolve this, we now send a 15-digit all-zero dummy MSISDN IE, as
described in TS 23.003.
Change-Id: I8d0a5d52d6cd2a00b5dda060bd41d45056dfa84d
When receiving the 'Start Result' message, for CF and TRXC MO
we directly transition to performing the Operational Info. In that
case, we need to return after sending the Operational Info and skip
the usual processing for the default case below.
Change-Id: I99860d198b337ffe461b240bda20dc10e1b5b2cb
Our existing OM2000 code for initializing all Managed Objects of a BTS
at startup was never complete. Rather than trying to fix the old-style
code, introudce a hierarchy of osmo_fsm's reflecting the full protocol
hand-shake and sequence of bringing up the individual MO's.
If this works out well, it mihgt make sense to convert the TS 12.21 OML
code for other BTS models, too.
Change-Id: I3e11b28ba22b8c227e0401e6207fdda5381dda8c
Extend both 'show lchan <bts> <trx> <lchan>' and 'show lchan summary' to
include information on dynamic timeslots.
Have one common function that prints " as foo" or " switching foo -> bar" to
the vty, use it in lchan_dump_full_vty() and lchan_dump_short_vty().
In lchan_dump_short_vty(), split the vty_out call in two in order to interleave
the dyn ts info right after the pchan.
The summary hence looks e.g. like this for osmocom style dyn ts:
BTS 0, TRX 0, Timeslot 5 TCH/F_TCH/H_PDCH as PDCH, Lchan 0, Type NONE, State ACTIVE - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
or
BTS 0, TRX 0, Timeslot 4 TCH/F_TCH/H_PDCH switching NONE -> PDCH, Lchan 0, Type NONE, State BROKEN UNUSABLE - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
Change-Id: I3eb72ac7f0a520a8eefe171b9fb357f149aa3fda
count_codecs() is called on every chan act ack, also for channels other than
TCH/F and TCH/H. So this logging happens a lot during normal operation but adds
no real information.
Also, RSL would be the wrong logging category for this -- RSL is about the RSL
communications, not whether our internal code tries to count lchan codecs for
the wrong channel types.
Change-Id: Ibdac3bbe48745fe6a1c31d6f87369c9066c0374a
As per TS 23.014, a GSM MSC must implement mobile-originated DTMF
generation. We gate the DTMF signalling messages to MNCC, and expect
the external MNCC handler to deal with it. However, the internal MNCC
handler simply ignored such singalling messages, rather than rejecting
DTMF altogether.
It turns out failure to respond to START DTMF will cause some phones to
behave in interesting ways, particularly with modem
firmware v6.01.00, see https://osmocom.org/issues/1817). In this case
the phone is not able to release the call as the pending response to the
START DTMF is probably keping a reference or lock of some sort.
Change-Id: I336f0cd0a6396b522d228479a417fd4d606157ac
GSM 04.18, which is the successor of GSM 04.08, describes
additional RR 3g specific message types. This commit adds
log output for those messages. The behaviour is not changed
all affected message types are still forwared to the MSC
as they were before.
See also 3GPP TS 04.18, section 10.4, table 10.4.1
The change requires to update libosmocore as well, see
also commit f48fdb3a108da0dc23d7af4ac021e98e11f07152 in
libosmocore.git for details.
Change-Id: I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa
the OML attribute tables are hardcoded. To set variable parameters,
the hardcoded data structure (tlv) is patched on byte level during
runtime. This patch replaces this mechanism.
- Replace hardcoded OML attribute tables with dynamically
generated TLV structures.
- Add unit tests to check if the OML attribute tables are
generated correctly
- Put OML attribute table generator code in a separate file:
bts_ipaccess_nanobts_omlattr.c
Change-Id: Ibeb34a84912d6cf695f553a34c69320fca7d08fa
Use channel type name instead of number and log it with DEBUG facility
otherwise it produces lots of irrelevant messages for SDCCH*
Change-Id: I11b04e0cb02bf6ed01f6076cb31a56d8921d735e
- missing break in gprs_sndcp_pcomp.c, line 143
- string overflow in slhc_test.c, line 211
- sizeof mismatch in gprs_sndcp_xid.c, line 1369 and 1378
- mismatching signedness in gprs_sndcp_xid.c, line 1377
- needless < 0 comparison in gprs_sndcp_xid.c, line 477
- needless < 0 comparison in gprs_sndcp_xid.c, line 209
- missing returncode check in v42bis_test.c, line 320
- wrong pointer dereferentialization in gprs_sndcp_comp.c, line 73
Change-Id: I4f9adf251f5119e67ffe76baad6f1f996ac8dbad
When DL DTX is active and silent period is in progress dtx.cache is
populated by SID UPDATE message which about to be scheduled next. If at
that moment FACCH message arrives (which have higher priority) we have
to send ONSET message to L1 but we can't invalidate cache with SID
UPDATE as it will be used for SID FIRST message to resume silent period
after FACCH transmission is over (provided there were no incoming voice
in between). Hence the necessity for separate buffer to store content of
FACCH message while we're sending ONSET to L1 while keeping SID UPDATE
cached.
Change-Id: I316e81af893b24766bf259baaed7a0be75a11694
Related: OS#1801
We count the codec when the channel was successful setted up
Using sign_link->trx->bts instead of msg->trx to get the bts.
Add OSMO_ASSERT for bts within count_codecs()
Change-Id: Ib49c7c337980a7d6f189d7a0551ca2e4c3822f45
Value 4 used as magic number by both OpenBSC and OsmoBTS so it make
sense to add it to shared header. See
ebb483b69a5319e522ba5f713e9cb6f68a814a6a in osmo-bts for details.
Change-Id: I9c6ad68f4c6aa72d39ec7e5a6968b36ec20e79f4
Drop extern definitions of talloc_msgb_ctx and use msgb_talloc_ctx_init()
instead.
In sgsn_test.c, use a local variable msgb_ctx to do the talloc report
from the return value of msgb_talloc_ctx_init().
Change-Id: I2f9ace855f0ecbdc9adf5d75bcb1a3d666570de4
There's "channel-descrption bs-ag-blks-res" vty command which sets
BS-AG-BLKS-RES which might be too high if CCCH is combined with
SDCCHs. Previously proper value was silently enforced. Log this
situation explicitly and add spec reference to the comment.
Change-Id: I53e2b881fc28472d6709f063fb265a4e6a0fffcd
- consolidate all DTX-specific things in a separate struct
- rename struct fields to better reflect meaning
- add pointer to DL FSM for AMR
- remove unused flag
- expand buffer to hold cached payload alongside with CMR/CMI
Change-Id: Idac8609faf9b5ced818fde899ccfc6ed0c42e8fd
Just as a general precaution deemed to fit such a convenience function that
lives in libcommon, no actual failure observed.
Change-Id: I8e77fe1abc402469fd037e2fde2f46e2c8114f59
Found this by coincidence, no actual failure case was observed.
lchan_lookup() does have a return NULL code path, so we should not blindly use
its returned pointer.
Change-Id: I34ce126d36420b8194c88c0faa865294334a6658
This reverts commit 38e9ea3f7f.
Introduced a reproducable segfault, because msg->trx is not actually set/used
in the openbsc code paths.
Program received signal SIGSEGV, Segmentation fault.
count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
104 rate_ctr_inc(&bts->network->bsc_ctrs->ctr[BSC_CTR_CODEC_V1_FR]);
(gdb) bt
#0 count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
#1 0x0000000000425661 in abis_rsl_rx_dchan (msg=<optimized out>) at ../../../src/libbsc/abis_rsl.c:1516
#2 abis_rsl_rcvmsg (msg=0x8143f0) at ../../../src/libbsc/abis_rsl.c:2611
#3 0x00007ffff71420d0 in handle_ts1_read (bfd=<optimized out>) at ../../src/input/ipaccess.c:271
#4 ipaccess_fd_cb (bfd=0x815af8, what=1) at ../../src/input/ipaccess.c:386
#5 0x00007ffff7779b62 in osmo_fd_disp_fds (_eset=0x7fffffffe590, _wset=0x7fffffffe510, _rset=0x7fffffffe490) at ../../src/select.c:149
#6 osmo_select_main (polling=polling@entry=0) at ../../src/select.c:189
#7 0x0000000000406fac in main (argc=<optimized out>, argv=0x7fffffffe738) at ../../../src/osmo-nitb/bsc_hack.c:385
Add flag to explicitly track the state of DTX DL for AMR HR whe
SID_FIRST_P1 has been sent to L1 already but no next frame available
yet: this can be followed by SID_FIRST_P2 or SID_FIRST_INH depending on
arrival of voice frame within next 60 ms.
Change-Id: Id28b07b8e83cfe5e84de48a2f124084036580cd4
In addition to RTP payload SID cache got to store CMR/CMI prefix. Extend
the buffer so it can fit in.
Change-Id: Ibd4a63604a82cad3ce65f0752bffefa4b083e1b3
Fixes: Coverity CID#149508
active_calls describe all calls in active state.
call.complete Call got terminated by disconnect requested either by MS or MSC.
call.incomplete Call got terminated by any other reason.
call.active Calls reached active state.
Change-Id: I49b93af2e6a0ba16c2fb00b7b83974e8a6a16df3
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I3b6d9ad4e5af44c2bdf3844c7bf8e8517bd61d8e
Tests for V.42bis, slhc, llc-xid and sndcp-xid are built and
executed on all build configurations, but are only needed when
the sgsn (gprs) is built. This patch adds conditions check
if the tests mentioned abvove are needed or not.
Change-Id: I6921e6198ea7f99fe5276f91cbc522091853bc4e
Most of this file uses four spaces of indenting. Replace all tabs with spaces.
Remove the erratic 'set' from the recently added vim comment at the bottom.
Change-Id: I4273b3314defb1e5b31b509c2ac7d7c6cd6834cf
Add option to TextTestRunner that shows print output on stdout.
It's better to see everything in our jenkins runs and not hide test output.
Change-Id: If4be1ad1c81c9ed4ab9b208b4c6d1e4b2cc8fdd5
After libosmocore 38d232ee5d2ceb045d9ad6d3a23afcb4972523f7 which outputs
'CTRL at <ip> <port>' from ctrl_interface_setup_dynip(), there's no need to log
the CTRL bind here anymore.
Change-Id: I1a874efe365a1ecf8ec37b058215b95b9a635ec2
Add a condition for GERAN Gb.
SNDCP and IuPS were developed on separate branches, and the merge results in
code trying to use an llme on a UTRAN Iu context where the llme is NULL,
leading to stack corruption upon PDP ctx act.
Change-Id: Ibb20d738c1b64d36630ce8eceb54c33ba4f1b003
In nat_msc_test(), upon socket timeout, retry up to six times. Reduce the
timeout between retries. This should get rid of sporadic test failures that
we've been seeing a lot on jenkins lately.
Raise an exception upon unexpected vty response.
Print more detail to stdout. Since we would actually want as much output as we
can get in a test suite, remove the 'if (verbose)' and just always print the
connection source. unittest is keeping all stdout silent by default anyway.
Change-Id: I2f83eef55592778e54164a90e1eabeb80fb918da
Use the recently added ts_is_tch() function instead of an explicit switch to
determine TCH pchan types. This is a cosmetic change since the bs11 does not
support dynamic channels (which was the main motivator behind ts_is_tch()).
Change-Id: Idf8ce51c76a83210fe3d70e18c51bbaffebb8ad5
Add ts_is_tch() in gsm_data_shared.h/.c and use it to replace a switch on the
pchan in e1_config.c.
This patch is not due to an actual observed failure. A general grep for switch
on pchan turned up this instance that doesn't handle dyn TS properly. Hence
this patch is not actually tested with real equipment.
Change-Id: Ide4f156034bab77140d2d9a8c462d68ae6f0d6a6
Add ts2comb() to switch on dyn TS so that dyn TS in TCH mode are also treated
like normal TCH/H or TCH/F pchans. Use ts2comb() instead of pchan2comb().
Change-Id: Iddc51a4409488d91db59228ca66aaab73ce3f1df
In gsm_data_shared.c, add ts_pchan() to determine actual pchan type for dynamic
and non-dynamic TS.
Use in ts_subslots() to fix the value returned for TCH/F_PDCH in PDCH mode.
Adjust the assertion in channel_test.c accordingly.
Drop GSM_PCHAN_TCH_F_PDCH, which is now handled in ts_pchan().
Explicitly add GSM_PCHAN_PDCH as zero in subslots_per_pchan[] (cosmetic).
Adjust the comment in subslots_per_pchan[].
The fix for the number of subslots affects only one caller: bts_chan_load() in
chan_alloc.c. Before this, it would always include a TCH/F_PDCH in the
load_counter->total, now it is skipped when in PDCH mode. Whether this is the
way bts_chan_load() should handle dynamic TS is a separate discussion, so far
I'm only making sure that the two dyn TS kinds act in the same way:
TCH/F_TCH/H_PDCH is only counted when in TCH mode, and TCH/F_PDCH should match.
Change-Id: Icd6668667ad2be7ad20866ffd185bf3b8711ccd6
This reverts commit 308cb0719d.
Problems in this commit:
openbsc/src/libbsc/chan_alloc.c:523: case GSM_PCHAN_TCH_F_PDCH:
This is actually wrong, GSM_PCHAN_TCH_F_PDCH use ts->flags, not ts->dyn below
(due to historical reasons and could be unified).
560: if (only_count_tch && !chan_is_tch(ts))
This has exactly one effect: it excludes GSM_PCHAN_TCH_F_PDCH when in PDCH
mode, because for all other PDCH (plain PDCH and TCH/F_TCH/H_PDCH in PDCH mode)
below ts_subslots() returns 0 and skips the for() loop. I consider this a bug
in TCH/F_PDCH, to be fixed in an upcoming commit.
I don't see why we need the only_count_tch argument, because this should
normally only count TCH, weren't it for the TCH/F_PDCH bug.
If dyn TS should be counted differently, we should do this in a different way.
Change-Id: I34dbbaf53a800115e3d03bd44028cad675f3b525
Add test_dyn_ts_subslots() and call from main(). Update channel_test.ok.
This includes erratic assert to show a bug for TCH/F_PDCH in PDCH mode: the nr
of subslots should be the same as for a normal PDCH, i.e. zero. This will be
adjusted along with the fix in an upcoming commit.
Change-Id: I09685be3fb3ed1ead4577b772a9fbc31967980d1
Move the main() guts to test_request_chan(), so that I can add another test in
an upcoming commit.
Change-Id: I1349d0f416806416080d4667ad697f7db1ea252d
After libosmocore 55dc2edc89c1a85187ef8aafc09f7d922383231f which outputs
'telnet at <ip> <port>' from telnet_init_dynif(), there's no need to log the
telnet VTY bind here anymore.
Change-Id: I97a730b28759df1d549a5049f47a3da1c16a3447
Instead of below error, raise an exception to describe what's happening.
Seen in a jenkins run on https://gerrit.osmocom.org/#/c/945/2:
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 787, in testBSCreload
msc = nat_msc_test(self, ip, port)
File "./vty_test_runner.py", line 1251, in nat_msc_test
return conn
UnboundLocalError: local variable 'conn' referenced before assignment
Change-Id: Iae26e7345267a21aed0b108b089453832889c9fa
The previous commit added a network backpointer to gsm_subscriber_connection.
Use it wherever it makes sense, to skip the step through the bts structure.
In some places, remove local variables that become unused.
Change-Id: I34537025986713291e14c8212a81539b497befd4
We want to be able to use a network backpointer without having to go through a
gsm_bts struct.
This commit adds the network pointer, the subsequent commit applies direct
access to the network structure from gsm_subscriber_connection.
Change-Id: If8870972f1b3e333c2a4cce97cdc95bdee0382a1
Add an explicit gsm_network pointer instead of using the bsc_gsmnet global.
This allows passing a gsm_network struct from the main() scope, which helps to
decouple libmsc from libbsc.
Change-Id: I9e2c0d9c18d4cebb5efb71565ad84df2bc2e0251
Decouple the talloc context allocations from global tall_bsc_ctx pointer.
It appears that talloc_ctx_init() was intended for general use, since it is
located in libcommon. It is currently used only by osmo-nitb; but the upcoming
osmo-cscn will use it as well.
Instead of defining in osmo-nitb main file, add definition in gsm_data.h.
Change-Id: I168106599b788f586be0ff0af4699b9746c1b103
Decouple the root talloc context from libbsc's global talloc_bsc_ctx.
This allows to define the root talloc ctx from a main() scope, which in turn
helps decouple libmsc from libbsc.
Change-Id: I92f6b47b1eeea2e8f3fba66f25d7e708e5659f8a
Replace the global sub_connections llist with gsm_network.subscr_conns.
Initialize and apply where applicable.
Remove bsc_api_sub_connections(), callers now access gsm_network->subscr_conns
directly.
This allows using the subscr_conns from libmsc without having to link libbsc.
Change-Id: Ice2a7ca04910bcfaaff22539abe68a6349e8631c
We want to create the telnet for VTY only after reading the config file, and
the dummy_conn was a workaround to be able to do so, but is not needed:
gsmnet_from_vty() used to expect vty->priv to point to a gsm_network struct,
but that is not actually the case anymore. It is using a static pointer to
store the gsm_network struct instead.
Change-Id: I51e7224c5a4cd5baf564bee871cf2fa6e885cda7
- Edit previously committed V.42bis implementation to function
outside IAXmodem.
- Add unit test to verify the correct function of V.42bis
Change-Id: I689413f2541b6def0625ce6bd96f1f488f05f99d
V.42bis is a data compression method found in modems. It has also
been specified for GPRS as data compression algorithm.
The implementation has been taken from IAXmodem:
https://sourceforge.net/p/iaxmodem/code/HEAD/tree/
svn checkout svn://svn.code.sf.net/p/iaxmodem/code/ iaxmodem-code
Revision: r36
Change-Id: Iabedece9f97ca944a1e3f747bb073e532c4e9dca
- Add module to handle compression entities
- Add module to control header compression
- Introduce VTY commands for heade compression configuration
- Add changes in sndcp and llc to integrate header compression
Change-Id: Ia00260dc09978844c2865957b4d43000b78b5e43
The previously pushed slhc implementation has been modified to compile
and function outside of the kernel. Also debug log messages were added
and datatypes ware matched. The implementation is now ready to be used
Change-Id: I7a638e88a43b3eb9d006751a03ef2570e36613f0
SLHC is an Implementation of RFC1144 TCP/IP header compression. We will need
RFC1144 compression to compress GPRS TCP/IP traffic. The implementation pushed
with this commit was taken from:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
commit 29b4817d4018df78086157ea3a55c1d9424a7cfc
Change-Id: Ied69c143678dc4a64cecc671f5c4dfebe19d8519
The SNDCP-XID (or layer-3 xid) is used to exchange layer-3 parameters
such as compression. The encoder encodes a bytestream that is then
sent as regular XID field from LLC.
We will need the SNDCP-XID to negotiate the parameters for our
upcomming GPRS data and header compression features
Change-Id: If2d63fe2550864cafef3156b1dc0629037c49c1e
gsm0408_dispatch() is the main entry point for receiving data from the BSC/RNC
level, so make sure callers pass valid pointers before using them all the way
down the code path (related to CID#93769, a fix before this was refactored).
For unknown/unimplemented packet discriminators, make sure to return error
codes.
Change-Id: Ieec39c74a53ef4dfa971dd935c8c9aa60fef58c1
Don't use quoted, local include, use <> style include.
Cosmetic: also move stdbool.h include to the top to keep osmocom and openbsc
includes grouped.
Change-Id: Iaa3dc36768f96f6b8c91010a2ba389fdc37f1503
Add vty function to explicitly set use of 4xRACH type of ack message for
PACKET CONTROL ACKNOWLEDGMENT. Previous hardcoded value (use RLC/MAC
control block) is used as a default.
This is handy for debugging issues related to Timing Advance in context
of GPRS.
Change-Id: Ie869ac0a82055110f1e3b875e246750c4e113336
Related: OS#1526
Add log_name to lchan_lookup() and pass such from the various RSL rx events
that call it to validate the RSL chan_nr.
Change-Id: Id81e7b8b9c27831923f050a78dfc7d650e687033
The message 'RF Channel Release due error 0' keeps catching my eye because
it says 'error' even though the error code is zero, i.e. no error.
This shall end now.
Change-Id: Ie0b9d62e8ce85a096c963931e0ae5527b8dc490a
smpp_try_deliver could fail with rc < 0. In such cases don't send the MS the rp
error sms rejected (cause 21). A rejected message should not be sent again. The
spec 04 11 recommends sending cause 41 Temporary failure in unknown cases.
Add also a log message and rate counter for such cases.
Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Change-Id: Ia03e50ce2bd9a7d1054cc5a6000fd73bd3497c03
This is where IuPS will redirect GTP-U endpoints in a subsequent commit.
Also add comprehensive logging of pmm_state transitions.
Change-Id: I7c2cd1abc1805659b01dffffff31c49fe5161086
DEVELOPMENT HACK: Our current HLR does not support 3G authentication tokens. A
new HLR/VLR implementation is being developed. Until it is ready and actual
milenage authentication is properly supported, we are hardcoding a fixed Ki and
use 2G auth.
Change-Id: Ieca45960fa941a3a706c6e479b04b9f2ef89d860
In gsm48_gmm_sendmsg(), redirect to iu_tx() for both cases of MM context
present or not.
In gsm48_rx_gmm_att_req(), compose an MM context marked as Iu for messages
coming in from a ue_conn_ctx (passed in msg->dst). Also make sure cid is
initialized to avoid introducing a compiler warning.
In gsm48_rx_gmm_ra_upd_req(), look up an Iu MM context based on the presence of
the ue_conn_ctx in msg->dst.
In sgsn-test, add libiu and libasn1c, libosmo-sigtran, libosmo-ranap, which are
now needed for an --enable-iu build.
Change-Id: Ia47ffbfa6fa0f5a0cd76a379c57ef42faa0d80e3
Add file iu_vty.c in libiu, and iu_vty_init() to initialize the new VTY
command:
log
logging asn1-debug (1|0)
Change-Id: If4e7d0ab3fc2ed0cdf4fb0a3fa077a9e34890918
As the NITB has an internal SIGABRT handler that prints a talloc report,
let's also print a stack backtrace at the same point.
Change-Id: Ia63aa5c39b26e27c3ee220d755c17d2c1ef636c5
For Iu connections, msg->dst will point to the ue_conn_ctx, and we need to make
sure to keep msg->dst intact when copying from/to msgb and from/to MM context.
Change-Id: I90c7ca6c3655d447aaca958e0086ae6ce6f6045a
Bit 4 is reserved in 3GPP TS 04.08 so exclude it from the type.
In 3GPP TS 24.008 it indicates if a follow-on request is pending by the
MS, but only in Iu mode. According to the spec it is not required to
react to that request with a follow-on proceed so this field can be
ignored for now.
See 3GPP TS 24.008 Ch. 4.4:
"Unless it has specific permission from the network (follow-on proceed)
the mobile station side should await the release of the RR connection
used for a MM specific procedure before a new MM specific procedure or
MM connection establishment is started."
as well as Ch. 4.4.4.6:
"If the network wishes to prolong the RR connection to allow the mobile
station to initiate MM connection establishment (for example if the
mobile station has indicated in the LOCATION UPDATING REQUEST that it
has a follow-on request pending) the network shall send "follow on
proceed" in the LOCATION UPDATING ACCEPT and start timer T3255."
Change-Id: If1dff960c406060e257dafc54132687ffc42ad8f
With this commit the already existing XID mechanism has been
modified to suit the needs for the upcomming SNDCP-XID patches.
This commit should not break anything since it does not alter
the current behaviour (incoming XID is still just echoed, on
GMM-Reset a basic XID message is still echoed)
Change-Id: I65b9d625e72d3d61c99abdc7041773701d694d52
For some reason gprs_sndcp.h is located in src/gprs. This commit moves
gprs_sndcp.h to include/openbsc and fixes the include path in
gprs_sndcp.c and gprs_sndcp_vty.c
Change-Id: If4e4f1252c81d7907c1b4d738c982bb172b128c9
The lle-xid encoder/decoder is needed to encode and decode llc
xid parameter messages. We need this to exchange sndcp-parameters
(SNDCP-XID) and also simple parameters such as encryption IOVs
Change-Id: Ia06e4cb08bf9b48c2a4682606d1b1a91d19a9d37
In rsl_lchan_mark_broken(), call rsl_lchan_set_state() so the state transition
gets logged in the debug log.
Remove logging for the broken channel at the callers, instead log the error
actually in rsl_lchan_mark_broken() itself, with the reason message passed by
the caller anyway. (Removes code dup and ensures it's always logged.)
Change-Id: I54ae9bbd3f193bae7b1bda1fef3e33e62b353bf5
Actually schedule an activation timer for the activation part of a dyn TS
switchover. It needs to be restarted because the channel release procedure in
the first part of a switchover actually removes the activation timer.
Change-Id: Ibf50d13ba10298464a8b07e34716763161438990
The dyn_ts_switchover_*() functions made the impression that they act on a
specific lchan of a timeslot. The assumption that we would remember to use e.g.
lchan[1] across a PDCH deactivation is brain damaged to begin with; and
factually we always use lchan[0] anyway (the only case for using lchan[1] would
be when switching to TCH/H, but the channel allocator will always return
lchan[0] for that).
Instead of the brain damaged lchan args, use a ts arg across all
dyn_ts_switchover_*() functions, with one exception: The
dyn_ts_switchover_complete() actually receives an RSL activation ack message on
a specific lchan and needs to evaluate its lchan type. This will always be
lchan[0] as it is now, but we should stick with the lchan the message was sent
for.
For PDCH, a check to use lchan[0] already existed, when composing the ACT
message in rsl_chan_activate_lchan_as_pdch(). Replace with an assertion.
Adjust all callers to pass ts instead of lchan.
In dyn_ts_switchover_start(), there was a dead code check that jumps to
switchover_complete() in case the pchan already matches. This never hits,
because we only call dyn_ts_switchover_start() when pchans mismatch. So avoid
guessing at passing lchan[0] to dyn_ts_switchover_complete() by not calling it
at all but logging an error instead.
In rsl_chan_activate_lchan(), we remember some values before going into
switchover from PDCH. Explicitly store them in lchan[0], because after a PDCH
release we have always and will activate no other than lchan[0].
In dyn_ts_switchover_continue(), move the check for any existing lchan->rqd_ref
further above, and more correctly check all lchans that were so far valid on
the TS, instead of just one.
This partly prepares for a subsequent commit to fix the act_timer use for dyn
TS: with the old lchan arg, we might schedule an activation timer on lchan[1]
but receive an ack on lchan[0] (for PDCH), leading to an act_timer expiry.
Change-Id: I3f5d48a9bdaa49a42a1908d4a03744638c59796a
new counters are:
llc.dl_bytes
llc.ul_bytes
llc.dl_packets
llc.ul_packets
The ip payload bytes are waiting for payload compression
because those data are known then.
Change-Id: I068376d35e84283cb98523cd3097a12c55cdb709
For TCH/F_TCH/H_PDCH dynamic timeslots, the ts->pchan does not lead to a
meaningful value from the subslots_per_pchan[] array. Use the ts_subslots()
function instead, which checks for dyn pchan.
Change-Id: I659acebca82dfb3e305433471be64e9d27439af8
Add web application exposing Control Interface over web. All of SET, GET
and TRAP are fully supported.
Notice: TRAP is converted into 'Server-sent events' according to RFC
6202, see also https://www.w3.org/TR/eventsource/ - this requires
corresponding client.
Due to use of special prefix modified version of python
eventsource-client is necessary ATM.
Change-Id: I87d40c80061f8b3d02d656ab8cadabbfb871b461
Related: OS#1646
Add get_var and set_var functions which handle requested variable while
checking for proper response and id. Split header handling into separate
function.
Change-Id: I08705963c277bd93a011193dd7451a626d606c21
Related: OS#1646
According to documentation for Control Interface Protocol <id> is "A
numeric identifier, uniquely identifying this particular operation",
hence it's best to be illustrated with random integer - use it as
default.
Fix override of id with previously used python-specific objects' id.
Change-Id: I32236c067360526f4e7ee4bbdba64c5137de696d
Related: OS#1646
Commit ec1b5a0e9e introduced an unset cbits
value for the 'special hack for BCCH', where I break out of the switch
without setting cbits. Fix that.
Also remove the comment part that says 'return 0', because I don't return 0.
Change-Id: I54129d921807971eeafc23f80c57666c67b71377
In https://gerrit.osmocom.org/589 , msuraev reports an assertion on octphy.
So disable this recently added assertion until we clarify the invocation in
question.
Change-Id: Ia0f7ae5b114e179ab56b98adbae9810e81b4b88f
Many years ago, there was no difference between the libbsc support for
nanobts and sysmobts. However, this is not the case for a long time
anymore, and there are some specifics in OsmoNITB when it comes to
sysmobts. Let's have an example config file
Change-Id: I94ae57c9a3cb497ca39d56270fa15ed65d7f147e
Introduce explicit __main__ function to facilitate re-use of defined
python functions for ctrl interface.
Change-Id: I9bad8f0dd1d69bd28816bf047d85840e3411bb9c
Related: OS#1646
To avoid two phones picking mismatching TCH pchans, never pick TCH/F on dynamic
TS in osmo-nitb.
Add gsm_network flag dyn_ts_allow_tch_f, set to true by default in
gsm_network_init().
Set this flag to false in osmo-nitb's main().
See http://osmocom.org/issues/1778
Reasoning about ways to solve this:
* a compile time switch doesn't work because libbsc is first compiled and then
linked to both osmo-nitb and osmo-bsc.
* we could test net->bsc_api == msc_bsc_api(), but I have the so-called MSC
split waiting on branch sysmocom/cscn, which will result in msc_bsc_api() not
being linked in the osmo-bsc binary.
* have a function am_i_nitb() with different implementations in osmo-nitb and
osmo-bsc, but then we'd need to add implementations to all tests and other
binaries linking lchan_alloc().
* have a flag in struct bsc_api, but so far there are only function pointers
there.
Having a "global" flag in gsm_network allows to add a VTY command in case we
decide to keep this feature (#1781), has no linking implications and is nicely
explicit.
Tested that osmo-bsc still picks TCH/F on dyn TS indirectly, since I have no
standalone MSC available: when compiling osmo-nitb with the line that sets
dyn_ts_allow_tch_f = false commented out, TCH/F is picked as described in
OS#1778; and by printf-verifying that dyn_ts_allow_tch_f == true in osmo-bsc
main(), only osmo-nitb should have TCH/F disabled.
Related: OS#1778, OS#1781
Change-Id: If7e4797a72815fc6e2bbef27756ea5df69f4bde7
It's no longer just for IPAC style TCH/F_PDCH, but also contains code for
TCH/F_TCH/H_PDCH, so pick a more general name.
Change-Id: Ic19db81eca03fd72738839ee3686b6b4c8b6b437
Init both TCH/F_PDCH and TCH/F_TCH/H_PDCH via dyn_ts_init(), which
refactors dyn_pdch_init().
Make dyn_ts_switchover_start from abis_rsl.c public in abis_rsl.h, so we can
start the initial switchover to PDCH from dyn_ts_init(); in abis_rsl.h include
gsm_utils.h for enum gsm_phys_chan_config.
Change-Id: I5c0b257ba8ff0e9c9a2268681a84b0681a778368
In struct gsm_lchan, add dyn.rqd_ref and dyn.rqd_ta. These save the Channel
Requested details across the PDCH deactivation dance.
abis_rsl.c: add static functions:
* dyn_ts_switchover*() for the various stages of switchover between pchans.
* pchan_for_lchant() to derive the desired pchan from the lchan type that was
set during lchan_alloc().
* rsl_chan_activate_lchan_as_pdch() to compose the simpler RSL CHAN ACT message
without introducing numerous special cases to the normal RSL CHAN ACT code.
In rsl_chan_activate_lchan(), detect and initiate required pchan switchovers if
requested pchan on a dyn TS differs.
In rsl_rx_rf_chan_rel_ack(), initiate or continue pchan switchovers after a
channel was released.
In rsl_rx_chan_act_ack(), notice that a switchover is complete.
In chan_alloc.c, add ts_subslots(): abis_rsl.c will need to know the number of
subslots per pchan, to verify that all lchans are free before dyn TS
switchover. The subslots_per_pchan[] array is static to lchan_alloc.c, and
since we need a non-trivial check for dyn TS anyway, add public ts_subslots()
to lchan_alloc.c, which also checks the current dyn pchan type.
Change-Id: I5c6bce13092a10204113d84678c587c65e35e4fd
Change _lc_find_bts() to _lc_dyn_find_bts() with added dyn_as_pchan arg to
pass exactly as which pchan we'd like to allocate on a dynamic TS. Add
_lc_find_bts() as wrapper so non-dynamic-TS callers remain unchanged.
Also add dyn_as_pchan arg to _lc_find_trx() (not renaming to dyn and wrapping
because there is only one caller).
Implement dynamic allocator logic in _lc_find_trx() and lchan_alloc().
A returned dynamic channel still needs to be switched to the proper mode, which
will follow in another commit.
Replace a fixme comment with a normal comment in subslots_per_pchan[], because
handling of dynamic TS is now defined.
Change-Id: I18da7679300c43220d9baa6a304e8df74d366249
Accept GSM_PCHAN_TCH_F_TCH_H_PDCH for TCH/F and TCH/H if in matching pchan mode
or switching to matching pchan.
Accept RSL_CHAN_OSMO_PDCH chan_nr cbits for GSM_PCHAN_TCH_F_TCH_H_PDCH pchan.
Change-Id: If8f7c118f69e5a9f370bfe25f82f3d5a8de75b51
In gsm_lchan2chan_nr() use the current pchan type.
In gsm_lchan_as_pchan2chan_nr(), add the special case of non-standard cbits for
activating PDCH on a TCH/F_TCH/H_PDCH dyn TS. This way, gsm_pchan2chan_nr()
conforms to the standard and does not need access to a ts struct.
Change-Id: If248b9073b9f397110a2003d8e1a04afdc1c0e20
For upcoming dynamic TS, the pchan choice for RSL De-/Activation is not
trivial. So in order to pass the desired pchan to generate the RSL chan_nr,
introduce gsm_lchan_as_pchan2chan_nr().
To avoid code dup, this requires decoupling the gsm_ts2chan_nr() pchan from the
actual ts struct, so refactor gsm_ts2chan_nr() to gsm_pchan2chan_nr() with
explicit pchan, ts_nr and lchan_nr arguments.
Change-Id: I1a40e8452fe8120d350a27973e56be0b8c8c517f
Dyn TS will add a new type of chan activation, which does not need a Channel
Mode IE. Incidentally, the dyn PDCH also doesn't need this IE if it opts for
sending a PDCH ACT instead. So it makes sense to compose the Channel Mode IE
only after the dynamic decisions are done.
Change-Id: I66d88ad6a4ae7bee1e552960fd4e92aff953125c
System Information 13 field EGPRS PACKET CHANNEL REQUEST is
modified to support 11 bit RACH. Further VTY configuration is added
to enable/disable 11 bit RACH support in EGPRS. By default 11 bit
RACH support is disabled.
Change-Id: I51357bec936c28a26ab9ff5d59e0e30ca3363297
This function outputs a debug log without line ending, which should be
completed by a subsequent DEBUGPC(), so complete the started log line where
missing in three of the switch cases.
The three cases do print another log message, but since these don't start on a
new line when RLL is in debug level, the log output for these is hard(er) to
read without this patch.
Change-Id: I355647e77e1b2d8e75ae1a167fe87a507a38d82d
Incorrect regular expression used by default to authorize all
subscribers to implement authorization policy 'accept-all' prevented MS
from camping on the open network.
Change-Id: I20284b3d40ecf4ca1e67d8cd25afb8d5e4ae3025
It is particularly interesting to see whether a given lchan type is allocated
on a dynamic timeslot.
Change-Id: I8a0bca6d9cd583a0988e5ee8f4e6f74f218f4185
lchan_lookup in abis_rsl.c and rsl_lchan_lookup() from osmo-bts rsl.c are the
same code, except for the log context, which is only set in abis_rsl.c.
Factor out the common code to rsl_lchan_lookup() in gsm_data_shared.c.
Openbsc and osmo-bts each define their own DRSL log constant, so add an int *rc
return code argument and keep the logging part in abis_rsl.c's thin lchan_lookup()
wrapper. Incidentally, this also removes code dup for logging.
To avoid duplicate symbols, the rsl_lchan_lookup() implementation needs to be
removed from osmo-bts, so older osmo-bts git revisions will not build with
this.
Change-Id: Ie89bc5bb9110a0e539d37991dedac6f913211b48
Add state fields osmo_bts_trx_ts->dyn.* to record dynamic timeslot state.
Initialize in gsm_bts_trx_alloc().
Change-Id: I0a4049df8500b4f7c864f1355c4e9238932d1b8f
A new type of dynamic channel will be introduced soon, so prepare some comments
to name the dynamic TS kind more specifically.
Change-Id: I51fa8c2ebba507299e55a5cb7e67e48a6c8471f7
f9f4387686 introduced a check for ran_type,
which potentially leaves reject_cause unset. Fix that.
Change-Id: I0220841ff796f949d00a1415d46b54a3eacc9493
We keep some random snippets of documentation here, but manuals are now
generally kept in osmo-gsm-manuals.git. Particularly the GSUP, OAP and
control interface are documented more extensively there.
To avoid having two sets of (diverging) documentation, let's remove it
from the openbsc.git repository.
Change-Id: I4a4c918587e236a7aa00cf2bb6aa05b090f7229b
Add GSM_PCHAN_TCH_F_TCH_H_PDCH in gsm_pchant_names and gsm_pchant_descs: the
VTY and CTRL can now handle the new pchan type.
Adjust the CTRL iface test to expect the new PCHAN type in the output.
Fixes make check with --enable-external-tests after libosmocore commit
fd80f5a04239c2ab7b561401476dd89f2861748b that adds GSM_PCHAN_TCH_F_TCH_H_PDCH.
Change-Id: I4ad9c972d7f76f7e20cf74d6fc3d1928b644a4f8
Since the osmo_unixsock_listen() was moved to libosmocore
it would be better to use the library's implementation
instead of reinventing the wheel again.
Change-Id: Iacfc39b6214c24084438f8fe04d03952cdc9ebc2
Skip PDCH activation if the GPRS mode is 'none' at:
* TCH/F_PDCH init after OML Enable (dyn_pdch_init())
* after TCH/F_PDCH is released, in TCH/F mode
* in the T3111 error timer callback after a TCH/F_PDCH was released in error
state
Assert the GPRS mode in rsl_ipacc_pdch_activate() to make sure all callers
check the GPRS mode.
Closes: OS#1765
Change-Id: I970e5f9dbcb1c625209e914a4c7696294ed34e62
Split out generation and application of GEA gamma into separate function
which can be used for both encryption and decryption.
Change-Id: I442f2ead57e40d9bcd24e7f1b261041371595360
Related: OS#1582
According to 3GPP TS 24.008 § 4.7.1.2 some GMM frames are not supposed
to be ciphered. Propagate information about the necessity for
encryption between MM <-> LLC to ensure only proper frames are
encrypted/decrypted/dropped.
Change-Id: I0358905e60d1b182f75caec81bfcc72bbbbb2aa1
Related: OS#1582
It is already functional enough to allow testing with real
phones. However, note - there are several limitations in the current
implementation:
* only default value for IOV-UI is supported at the moment
* AUTN-based key material is not supported
Related: OS#1582
Change-Id: I8900b906693496e4e6b35be5a86937c58039ed9e
The A&C reference number specified in 3GPP TS 24.008 § 10.5.5.19
identifies particular request sent by network with the related response
sent by MS. The value transparently copied from request to response by
MS: the spec do not specify what exactly should be in there so we use
rand() to decrease chance for collisions.
Note: variable named 'rand' clashes with standard function rand() so it
was renamed.
Change-Id: I3638821a9b4a0532b28dbbb50faa30c4082579f6
Related: OS#1582
Have a bash function to build each dependency with the same commands. There is
a tradeoff: having each dependency build with the same function means you can't
easily tweak one of the dependencies. OTOH having a unified function means a)
more readable script, b) that we're sure not to forget some steps and c) no
need to do the same edit n times.
Set the PKG_CONFIG_PATH globally. Also a tradeoff: if a future addition
wouldn't need the same PKG_CONFIG_PATH, this would make things ugly. But that
is actually quite unlikely, and the readability improvement is substantial.
Use env variables to remember local paths. That means we always are sure to cd
to the same absolute base path, which a 'cd ..' can't guarantee; also, we avoid
possible typos for e.g. "$deps/install".
Change-Id: Ib23f86c6cc1441d882de59bcdde5de87fa4e9fdf
Without this commit it is possible that osmux is disabled again on links with
high jitter. This happens when an MGCP response without X-Osmux header is
received before the NAT receives an Osmux dummy frame from the other side.
Ticket: SYS#2628, SYS#2627
Sponsored-by: On-Waves ehf
Change-Id: Id624b0279aee5e2412059a10296ce7896e2d4628
Previously it was possible to start osmo-sgsn with "auth-policy remote"
but without "gsup remote-*" which resulted in broken setup: no MS could
perform GPRS ATTACH. Add consistency check to vty code to fix this.
Related: OS#1582
Change-Id: Ie4296e7d99d7833f7d828b0196435ea81097cf6e
Previously if subscriber was automatically created it got assigned
random MSISDN number. Make it optional (defaulting to previous behavior)
by adding following:
* new optional no-extension argument for subscriber-create-on-demand vty
command
* db unit tests
* vty test
Note: using the db made with new code might result in subscribers with
empty extension. Such subscribers cannot be deleted using old
code. Make sure not to mix db versions or manually fix it by editing
sqlite with external program.
Fixes: OS#1658
Change-Id: Ibbc2e88e4722b08854ebc631485f19ed56443cbb
The state is directly overwritten by the next function. Because
there isn't any state transition, remove this state.
Change-Id: I7f287692dbd559268fb5e61d81ac19e5dd4827eb
Always set CN domain in outgoing GSUP packets to PS to make it
compatible with osmo-auc.
Change-Id: Ia6ee2e55a41a8ea9e465d7df1b2b3559b553fca8
Related: OS#1582
Use correct vty command for subscriber deletion, adjust assertions
accordingly. The error was cause by inconsistent syntax of vty commands
for subscriber creation and deletion.
Change-Id: I9b9376b4ac0ec066000545167de312ca4460493b
In rsl_rx_rf_chan_rel_ack(), only activate PDCH when in NONE state.
For the case of REL_ERR state, do the PDCH activation in the error timeout
callback after T3111 is done.
Change-Id: I4c55479b252a12039bb3d8c30a9cbf0199ca410e
In gsm_lchant_name(enum gsm_chan_t), use the gsm_chan_t_names value strings
from libosmocore instead of redefining the same strings. The list from
libosmocore is also more complete, including CCCH and PDTCH.
Add a todo comment to move to libosmocore.
In consequence, libosmogsm linkage needs to be added to osmo-bsc_mgcp,
mgcp_test, mgcp_transcoding_test and smpp_mirror, smpp_test.
Change-Id: If65ee7c0619cbc0acb0a15045bd5a969442c93cc
Fail in configure if libgsm is not found.
Before this, the --enable-mgcp-transcoding would gladly accept that libgsm is
missing and the build would fail later because of missing linking and undefined
references.
Change-Id: Ic23157cc5b75694f400a176c31f97d71e861ea02
Do the PDCH DE/ACT before we set the lchan->state to De-/Activation Requested.
It makes more sense semantically to change PDCH mode while the lchan is still
in NONE status. Thus slightly move some invocations:
PDCH ACT: Free the lchan before PDCH activation. Hence remove the lchan_free()
call from the rsl_rx_pdch_act_ack() code path; it used to do the PDCH
activation first and call lchan_free() in the callback.
PDCH DEACT: Set the (TCH) Activation Requested state only within
rsl_chan_activate_lchan(), after the PDCH deact is complete.
Channel allocator: don't pick channels that have a PDCH PENDING flag set, to
avoid using channels that are still in PDCH switchover (despite their state
being NONE).
The lchan_may_change_pdch() sanity checks are becoming a lot simpler.
Change-Id: I4206dd4808e21c3e59393ea7f5ab4f438afff066
Set and clear pending flags on the TS according to PDCH de-/activation.
This will allow changing the time we set the channel state to after PDCH
DEACT and before PDCH ACT, in a subsequent commit.
Also add a sanity check on whether we're sending conflicting or superfluous
PDCH de-/activations on the same TS.
Change-Id: Ieae73271df749ded3d90585116aae01f3ad4ee74
Rename TS_F_PDCH_MODE to TS_F_PDCH_ACTIVE, to more accurately reflect the truth
value's meaning.
Add TS_F_PDCH_ACT_PENDING and TS_F_PDCH_DEACT_PENDING for sysmoBTS (and
possibly other BTS implementations) to remember what to do when the PCU replies
with a channel de/activation. Also add TS_F_PDCH_PENDING_MASK to test for both.
Change from #define to an enum.
Note: These flags are also used in the upcoming osmo-bts-sysmo dyn PDCH
commits, so osmo-bts submission depends on this commit.
Change-Id: I391a103ab599648b0c5d4f3ad613a6d7c48834b3
Previously if subscriber was automatically created it got assigned
random MSISDN number between 20000 and 49999. Make it configurable with
new vty command "subscriber-create-on-demand random" and expand vty
tests to check it.
Change-Id: I040a1d227b0c7a1601dc7c33eccb0007941408a6
Related: OS#1658
Previously length check have not considered AMR format which requires
extra byte for in-band length leading to SIGABRT on incorrect payload
from BTS.
Change-Id: I800f756fc803accace8c7e0b4a42b3744fe78bb6
Fixes: OS#1731
Add dyn_pdch_init() in new file bsc_dyn_pdch.c (new file to avoid linking
issues; bsc_init.c would create undefined references, and putting in a new file
is the easiest solution).
Call dyn_pdch_init() from nm_statechg_event() whenever a TS is enabled.
Revert the |= TS_F_PDCH_MODE chunk from previous commit, since this flag will
now be set after dyn_pdch_init() sent out the PDCH ACT and when subsequently
the PDCH ACT ACK messages are received in rsl_rx_pdch_act_ack().
Change-Id: I0cad93dec59d546b3f3b19e332e0833496031575
Remove check for dyn PDCH in _lc_find_trx(), instead call _lc_find_trx() via
_lc_find_bts() several times, so that pure TCH/F is preferred to TCH/F_PDCH.
Add this logic next to the other channel match decisions in chan_alloc().
BTW, the removed check in _lc_find_trx() whether PDCH is active is not
necessary, as described in the added comment for lchan_alloc().
Original patch idea by jolly, but split in two and implemented differently by
nhofmeyr.
Change-Id: I0c728b922656be03588b775638b610a93f8187d5
For chan_alloc_reverse, _lc_find_trx() should return the last free slot instead
of the first.
Original patch by jolly, but split in two by nhofmeyr.
Change-Id: Iff980242b9b5cb39345aaad0350ee368537677cd
Add bit which can be set on BTS side to indicate that next RTP frame
should be marked as a beginning of speech.
Change-Id: I355a5ae275a2743b29071924c916c4f68c3b3e80
Related: OS#1562
DTXd: to schedule SID repetition we have to know when previous SID was
sent (fn) and if it was UPDATE or FIRST SID (is_update).
DTXu: to properly set Marker bit in outgoing RTP we have to know the
beginning of talkspurt. For codecs without explicit ONSET event we can
do it by setting the flag (ul_sid) upon receiving SID and unsetting it
on speech frames.
Change-Id: I79cbec3b6c6fed5de385f8e202ceaf0b13234778
Related: OS#22, OS#1701
It is necessary for proper reporting of DTXd status during the
measurement period.
Change-Id: I4a033b03fcd0deb4db7a38273b5407511dbf1d6c
Related: OS#1701
In lchan_alloc(), there are several decisions to fall back to another type of
channel, followed by setting the channel type to the fall back type. So far,
this was set regardless of allocation success or failure.
If such fall back type is not available, do not modify the local type variable
and thus report an S_CHALLOC_ALLOC_FAIL on the type originally requested
(report is at the end of lchan_alloc()).
Change-Id: Ie3d4cb74f91db0b8c4f5e595a963099de339ad1a
libosmo-abis do not consider DTX bits while processing TRAU frames. As I
do not have equipment to test it, I'm not sure if/how non-IP BTS will
work in case of DTX - warn users about it.
Change-Id: I94ee69cd309fc343a428ddc66942cd57f2a34c05
Related: OS#22
Add missing mmctx NULL check in gsm0408_rcv_gmm(). gsm48_tx_gmm_status() would
dereference mmctx without checking, so we can't call it if mmctx == NULL.
Follows up on recent e98ba82d2b:
"gprs_gmm.c: Don't try to de-reference NULL mmctx".
Change-Id: If59efbde86c76ffe91a0b33be87273783a2a4a02
Drop erroneous C from a DEBUGPC, should be on a new line.
Drop underscores from IPAC_PDCH_[DE]ACT: all other log messages for IPAC PDCH
are without underscores -- git grep "P(.*IPAC.PDCH.*ACT"
Change-Id: I8fb7a1c1beabb1f4388517383fd0bdc082d557ca
* extend "auth policy" vty command with new option "regexp"
* add vty command "authorized-regexp" for setting arbitrary POSIX
regular expression
* add basic vty test
* add optional "regexp" argument to subscriber-create-on-demand vty
command
With those in place we can now set the regexp against which MS's IMSI
will be matched.
If IMSI match the regexp than MS is allowed to access the network. If
subscriber is already marked as authorized in HLR than it'll be allowed
regardless of IMSI matching.
The same way we can decide whether to create subscribers on-demand
basesd on IMSI regexp match. Similar to authorization this restriction
can be overridden by manually creating subscriber via vty, ctrl
interface or directly in HLR.
Change-Id: I525f4b80676de47d1d422686da2ca012301b0129
Fixes: OS#1647
It's necessary to properly compute timestamp compensation for RTP
packets in case of DTX (or heavy packet loss).
Related: OS#22
Change-Id: Ib42c6a8614a4b73333a83181488dd4069cac14d7
Assert that llme is unused for non-Gb (Iu) connections, and clean up otherwise.
Make sure the cleanup is left below the sgsn_mm_ctx_free() call, as the comment
states.
Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f
In case the GMM message did not arrive over a Gb interface, there is no
LLME (and thus the associated pointer is NULL). Don't try to perform
operations on a NULL LLME.
Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e
Soem of the operations we perform in the GMM layer are specific to the
GPRS/EDGE radio access network and its Gb interface. Let's make them
conditional to that in preparation of supporting an Iu interface.
Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c
There was a comment in the code that certain GMM messages require a
valid mmctx pointer. However, nothing actually checked if that pointer
was in fact non-NULL. We plainly crashed if a MS would send us the
wrong message in the wrong state.
Original patch by Harald Welte, but it broke message validity checking,
resulting in sgsn_test failure. This re-implements the NULL check in a
different way, as explained by in-code comment.
Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8
This is the entry point for GMM from Gb. We will create a new one
for Iu, so let's be explicit rather than implicit.
Change-Id: I93c074bf99db041117c0dc03dc8255879845a875
Explicitly mark those sgsn_mm_ctx members that apply for Gb mode and (upcoming)
Iu mode, respectively.
Add some comments in sgsn_mm_ctx.
Change-Id: Ife9b02549f284e2547f16117cf43d7a36948fc4b
Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de>
libosmocore changed in bf990bb8 Update internal GPRS cipher API
from uint_64 to uint8_t*.
Fix a warning.
Change-Id: Ib5bfe1fb05c693347b11ff4faadd3fc2205ebd76
Previously si2quater SI messages were always scheduled. Check for
neighbor configuration and only schedule si2q when necessary. Add
corresponding unit test.
Change-Id: Ibe997803ffb894133fd4d838410fe735791d414f
Fixes: OS#1727
Reviewed-on: https://gerrit.osmocom.org/81
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In GSM R99 SI6 has mandatory SI6 rest octets and so far we did
not include them. Add minimal support to generate the right band
indicator.
Target a slightly older version of the SI6 rest octets as we neither
support MBMS nor Random bit stream but should include the band
indicator.
Change-Id: I417a40eb91f42a3416b4e07bb9fb4d7a01aaa36b
Fixes: OS#1698
Related: OS#1725
Reviewed-on: https://gerrit.osmocom.org/71
Tested-by: Jenkins Builder
Reviewed-by: Max <msuraev@sysmocom.de>
Reviewed-by: Holger Freyther <holger@freyther.de>
In c09f8a3b7f as part of a cleanup
I accidently changed the talloc context from "con" to "bsc". The
issue occurred at an earlier commit when assigning req.ctx to the
"wrong" context. The allocation needs to be scoped by the struct
nat_sccp_connection and not the connection from BSC to NAT.
Before we have a nat_sccp_connection we scope the copied imsi to
the bsc_connection and then steal it, but for the identity resp
we will always have a nat_sccp_connection and can already use the
right context.
Change-Id: I53789aad2809e19338ad3b2deb72c4757e7bd524
Related: OS#1733
Reviewed-on: https://gerrit.osmocom.org/102
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Reviewed-by: daniel <dwillmann@sysmocom.de>
Reviewed-by: Holger Freyther <holger@freyther.de>
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I838632e9e90378a03235c2aebd5bc9ed06627ec8
Reviewed-on: https://gerrit.osmocom.org/113
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In AMR 12.2 (mode 7), the actual RTP payload is 33 bytes. Howeerver,
as we store the length of the (dynamically-sized) AMR payload in the
first byte, our buffer needs at least 33+1 byte in size.
Change-Id: If1ad5d2d68c85733306c75ea62f67fe8fbc143b3
Reviewed-on: https://gerrit.osmocom.org/91
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
In gsm04_08_clear_request(), in_release == 1 anyway and
msc_release_connection() would exit immediately without any effect. Don't
confuse the reader by passing release=1 arg.
Change-Id: I5bf9eb4889d32ad5e42ac7d096bf62fa3a493e20
Reviewed-on: https://gerrit.osmocom.org/93
Reviewed-by: Holger Freyther <holger@freyther.de>
Tested-by: Jenkins Builder
subscr_name() was called from several places:
* either without a check for subscr being NULL, which for example
was causing a segfault if we hand-over a channel before identifying the
subscriber
* or with an explicit NULL check and the ternary operator (?).
We now simplify the code by checking for the NULL Subscriber in subscr_name()
itself.
Change-Id: Ide09f4a515222eb2ec6c25e7a6a8c5f6cc2ffd4b
Reviewed-on: https://gerrit.osmocom.org/92
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Drop unused linking of libmsc, and drop duplicate linking of libbsc.
Change-Id: If2d63adb832c72ff1a22c25a78e06b0c244628d2
Reviewed-on: https://gerrit.osmocom.org/88
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Previously *FULL measurements were always used for handover
decisions. Those are incorrect in case of DTX - check if it was enabled
and use *SUB instead.
Note: *SUB values have higher variance so there might be more "bad"
values compared to *FULL although real quality remains the same.
Change-Id: I95e8e544047a83a256e057a47458678f40a19a15
Related: OS#1701
Reviewed-on: https://gerrit.osmocom.org/66
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
* Add per-BTS DTX settings
* Configure Uplink and Downlink DTX separately
* Deprecate global DTX option (it was never tested/used anyway)
* Use libosmocore function for DTX indicator in System
Information (previously it was incorrectly assigned for half-rate
channels)
Related: OS#22
Change-Id: I3d55168475ad47044b6238b55846ea22bdd518a4
Reviewed-on: https://gerrit.osmocom.org/40
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Move copy-pasted code into separate function to make writing more tests
easier.
Related: OS#1658
Change-Id: I9e39af85718514dd0f081d41c234c9dda77c4b27
Reviewed-on: https://gerrit.osmocom.org/43
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In the past, normal migration was possible only if the actual
schema version differed from the version used in DB by 1. For
example, if DB uses an old version 3 and you need to use it
with the code written for version 5, the check_db_revision()
will convert it to 4 and DB will still use incompatible schema
version during Osmo-NITB running time. After next run it will
be converted to version 5.
This patch replaces a set of 'else-if' checks by a 'switch'
without 'break' statements between 'case' labels (waterfall).
It makes you able to migrate from current version to the
latest despite any difference between them.
Change-Id: Ia9c2aa86f96b88ad8a710d0a23879ce219bc82dc
Reviewed-on: https://gerrit.osmocom.org/62
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
In commit 4adb136da6 we introduced
a new authentication state SGSN_AUTH_AUTHENTICATE, but we didn't
add that to auth_state_names[] resulting in log messages printing
it abut 'unknown 0x1' rather than something more useful.
The existing GSUP code expected the subscriber data to be piggy-backed
onto the location update response, rather than a separate (and nested)
insert subscriber data request/response phase.
With this patch we should now support both the nested as well as the
piggy-backed version.
In general, if a function generates output data like a msgb (or in this
case filling an osmo_oap_message structure), the output argument
precedes the source. This is what we use all over libosmo*, and it is
modelled after memcpy(), where dst is the first argument, before src.
Let's align osmo_oap_decode(). Intestingly, osmo_oap_encode was already
correct, so the encode/decode functions used different conventions
before.
This rename is the first step of moving the associated functions into
libosmocore.
Also, rename gprs_match_* to osmo_match_shift_* to indicate that it is
not just matching the TLV, but also shifting the data portion.
This is a preparation to move the related code to libosmocore, whilst
at the same time generalizing it from GPRS Subscriber Update Protocol
to the Osmocom Generic Subscriber Update Protoco.
Rather than having a 'private' structure for kc, sres and rand, we
now finally (with 4 years delay) use osmo_auth_vector from libosmogsm,
which encapsulates authentication vectors that can be either GSM
triplets or UMTS quintuples or a combination of both.
gsm_auth_tuple becomes a wrapper around osmo_auth_vector, adding
use_count and key_seq to it.
key_seq is no longer initialized inside gprs_gsup_messages.c, as there
is no CKSN / key_seq inside the message anyway. If a usre of the code
needs key_seq, they need to manage it themselves.
In case both TCH/H and TCH/F or different codecs are configured and
internal MNCC handler is used we might end up in a situation where call
legs with incompatible channel types or codecs would be connected
resulting in a broken audio. Disconnect such calls with appropriate
error message.
Fixes: OS#1663
This adds a very basic, use once example in python on how to connect
and deal with the app specific payload and messages. The code is not
complete as the invokeId should be patched according to the initial
invoke. This excercise is left to future readers of that code.
* support for sending arbitrary static SI2quater.
* vty interface for neightbor EARFCNs specific to SI2quater.
* dynamic generation of SI2quater messages.
* unit test for SI2quater messages.
Fixes: OS#1630
Move define to header file.
Use inline functions where appropriate.
Change int variables which are used as boolean into actual bool to make
code easier to follow.
Use the simpler approach and just call encode('hex') on the str and
then convert it to lower case to keep the tests working.
reproduce:
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = '\0\0'
>>> d
'\x00\x00'
>>> "".join("{:02x}".format(ord(c)) for c in d)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <genexpr>
ValueError: zero length field name in format
fixes:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 658, in testBSCreload
b0 = nat_bsc_sock_test(0, "lol")
File "./vty_test_runner.py", line 1150, in nat_bsc_sock_test
ipa_handle_small(bsc, verbose)
File "./vty_test_runner.py", line 1116, in ipa_handle_small
s = data2str(x.recv(4))
File "./vty_test_runner.py", line 1100, in data2str
return "".join("{:02x}".format(ord(c)) for c in d)
File "./vty_test_runner.py", line 1100, in <genexpr>
return "".join("{:02x}".format(ord(c)) for c in d)
ValueError: zero length field name in format
----------------------------------------------------------------------
If we want to separate the BSCs we should separate based on
the source port and not the source ip (at least in the current
test setup).
Fixes:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 658, in testBSCreload
b0 = nat_bsc_sock_test(0, "lol")
File "./vty_test_runner.py", line 1145, in nat_bsc_sock_test
bsc.bind(('127.0.0.1' + str(nr), 0))
File "<string>", line 1, in bind
error: [Errno 99] Cannot assign requested address
----------------------------------------------------------------------
Update the comment to reflect that the NAT itself will bind to port
5000 and then the mock MSC will fail to bind to it. Try to move the
mock MSC to another port.
Could fix:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 654, in testBSCreload
msc = nat_msc_test(self, ip)
File "./vty_test_runner.py", line 1101, in nat_msc_test
msc.bind((ip, 5000))
File "<string>", line 1, in bind
error: [Errno 98] Address already in use
----------------------------------------------------------------------
Don't assume that one can just bind to a local address that has
not been configured. Remove the unspecific comment as I don't know
to which other tests it is referred to.
This should fix:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 655, in testBSCreload
msc = nat_msc_test(self, ip)
File "./vty_test_runner.py", line 1102, in nat_msc_test
msc.bind((ip, 5000))
File "<string>", line 1, in bind
error: [Errno 99] Cannot assign requested address
----------------------------------------------------------------------
Add vty tests for BSC configuration reloading.
Load BSCs configuration on bscs-config-file command:
* remove all runtime configured BSC not in the config file
* close connections to all BSC with updated token value
Fixes: OS#1670
Sponsored-by: On-Waves ehf
Introduce new configuration option bscs-config-file which includes BSC
configuration from the given file. Both absolute and relative (to the
main config file) paths are supported.
Add 'show bscs-config' command to display current BSC configuration.
Note: it is still possible to have BSC configuration in the main
file (provided proper index number is used) and in runtime but BSC
configuration is no longer saved automatically. The management of
included configuration file is left to external tools.
Update configuration examples.
Fixes: OS#1669
Sponsored-by: On-Waves ehf
Factor out 2, add 3 functions. Those functions are simple wrappers
around hex strings specific to IPA protocol. Not all of them are
utilized at the moment but they were checked with wireshark while
working on the tests. It might come in handy if we'd like to further
expand related test harness in future. The same goes for optional
verbosity argument which is not used right now but will be handy for
future debugging.
Extend the existing ctrl command to be able to specify the
algorithm and Ki. In contrast to the VTY no size check is
done. Together with the VTY this code only supports a small
part of what is supported by libosmocore.
The algorithm and ki are considered optional but if a valid
algorithm other than "none" is passed, a KI must be passed as
well.
Extend the test coverage by passing the potential values. It
is not verified that the KI/algorithm is stored.
We should not return a subscriber in case it was not written to
the database. Instead free the memory allocated and return NULL.
Callers in gsm_04_08.c are prepared to have the creation fail.
Related: OS Issue #1657
The issue of db_create_subscriber updating an already existing subscr
is that the same subscriber will then have two entries in the active
subscribers list. In general this will break assumptions that a subscr
can be compared by comparing the pointer.
In the case of the VTY this was not an issue as the created subscr
was immediately destroyed again but it is better to avoid this problem.
Change the VTY command to find the subscriber and then call sync to
have the updated time set. The side-effect is we will now have two
queries for the subscriber. Once through subscr_get_by_imsi and once
through db_create_subscriber.
Change the db_create_subscriber to fail if a subscriber already exists,
and add a testcase for this behavior and do not updated the 'updated'
timestamp of an already existing subscriber.
Add a testcase for this behavior.
Related: OS Issue #1657
Add testcase to issue the subscriber create twice. db_create_subscriber
in db.c will first try to find the subscriber and if it exists, it will
update the "updated" column in the database.
Related: OS Issue #1657
The ip.access nanoBTS seems to have severe issues with BSSGP when
changing the country code and/or network code. It is unlikely that
the proprietary code is getting fixed so we extend the parameter
for the apply-configuration command to carry the 'restart' param.
The nanoBTS continues to be buggy and seems to have broken BSSGP
when changing SIs across new OML connections. Add an easy command
to force the reboot of the system through OML.
Make sure a new auth tuple is initialized after
db_get_lastauthtuple_for_subscr() returns an error, i.e. if no tuple is present
for the subscriber yet.
Before this patch, the first key_seq depended on the typically uninitialized
value that was present in auth tuple's key_seq upon calling
auth_get_tuple_for_subscr().
The very first key_seq used for a new subscriber will now always be 0. Before,
it used to be mostly 1 ("(0 + 1) % 7"), but depended on whether the key_seq was
indeed initialized with 0, actually by random.
In auth_get_tuple_for_subscr(), add missing condition to match incoming
key_seq with stored key_seq, so that re-authentication is requested for
mismatching key_seqs.
Add test for this issue.
Instead of using hardcoded -1 for errors, include -1 in the enum auth_action
type; apply its use.
In the mm_auth test, the string output changes from '(internal error)' to
'AUTH_ERROR', since now the proper enum value is used in auth_action_names[].
Test two situations for AUTH_DO_AUTH_THEN_CIPH:
- when no auth tuple is available
- when the key sequence from LU is marked invalid
Add convenience auth tuple comparison function using stringification.
Add basic MM Authentication test setup, with fake DB access and RAND_bytes().
So far implement simple tests for IO error during DB access and missing auth
entry.
To print the auth action during tests, add struct auth_action_names and
auth_action_str() inline function in auth.[hc].
Don't store an MSC index number in the vty->index void* value. Instead,
store the osmo_msc_data struct directly. Thus avoid warnings about
differences in int vs void* sizes, and save some index lookups.
In OpenBSC, we traditionally displayed a TMSI in its integer
representation, which is quite unusual in the telecom world. A TMSI is
normally printed as a series of 8 hex digits.
This patch aligns OpenBSC with the telecom industry standard.
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
mgcp_transcode.c: In function 'decode_audio':
mgcp_transcode.c:332:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_ERROR,
^
mgcp_transcode.c:332:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'long unsigned int' [-Wformat=]
mgcp_transcode.c: In function 'encode_audio':
mgcp_transcode.c:390:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_INFO,
^
mgcp_transcode.c:390:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'size_t' [-Wformat=]
mgcp_transcode.c: In function 'mgcp_transcoding_process_rtp':
mgcp_transcode.c:542:5: warning: format '%d' expects argument of type 'int', but argument 9 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_NOTICE,
^
mgcp_transcode.c:571:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_NOTICE,
^
There is no concurrency involved and if it failed the first time,
it will fail the second, third, ... time as well. Simply print that
we will leak the database instance.
libosmocore recently added inline functions to relieve callers from applying
bitmasks and bit shifts to access the transaction id of a GSM 04.08 header.
Apply these functions.
Replace hardcoded protocol discriminator and message type bitmasks with
function calls recently introduced in libosmocore.
Note that the release 98 bitmasks slightly differ from the release 99 bitmasks.
This patch uses the "default" gsm48_hdr_msg_type invocation, thus it depends on
libosmocore whether 98 or 99 bitmasks are used.
In some places, use of the bitmask was erratic. Fix these implicitly by
employing the bitmask functions:
* silent_call.c: silent_call_reroute(): add missing bitmask for MM.
* bsc_msg_filter.c: bsc_msg_filter_initial(): RR vs. MM messages.
* osmo_bsc_filter.c: bsc_find_msc() and bsc_scan_bts_msg(): RR vs. MM
messages.
* bsc_nat_rewrite.c: bsc_nat_rewrite_msg(): SMS vs. CC messages.
* bsc_ussd.c: no bitmask is applicable for the message types used here.
* gb_proxy.c: gbproxy_imsi_acquisition(): missing bit mask for pdisc.
In gprs_gb_parse.c: gprs_gb_parse_dtap(), add a log notice for unexpected
message types.
Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0").
Add VTY command
smpp
local-tcp A.B.C.D <1-65535>
while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the
new command immediately change the SMPP listening address and port.
Add a LOGL_NOTICE log when the SMPP listening address and/or port change.
However, to be useful, this patch has to go somewhat further: refactor the
initialization procedure, because it was impossible to run the VTY commands
without an already established connection.
The SMPP initialization procedure was weird. It would first open a connection
on the default port, and a subsequent VTY port reconfiguration while reading
the config file would try to re-establish a connection on a different port. If
that failed, smpp would switch back to the default port instead of failing the
program launch as the user would expect. If anything else ran on port 2775,
SMPP would thus refuse to launch despite the config file having a different
port: the first bind would always happen on 0.0.0.0:2775. Change that.
In the VTY commands, merely store address and port if no fd is established yet.
Introduce several SMPP initialization stages:
* allocate struct and initialize pointers,
* then read config file without immediately starting to listen,
* and once the main program is ready, start listening.
After that, the VTY command behaves as before: try to re-establish the old
connection if the newly supplied address and port don't work out. I'm not
actually sure why this switch-back behavior is needed, but fair enough.
In detail, replace the function
smpp_smsc_init()
with the various steps
smpp_smsc_alloc_init() -- prepare struct for VTY commands
smpp_smsc_conf() -- set addr an port only, for reading the config file
smpp_smsc_start() -- establish a first connection, for main()
smpp_smsc_restart() -- switch running connection, for telnet VTY
smpp_smsc_stop() -- tear down connection, used by _start() twice
And replace
smpp_openbsc_init()
smpp_openbsc_set_net()
with
smpp_openbsc_alloc_init()
smpp_openbsc_start()
I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol
there is also a bind/unbind process, so instead I chose the names "_start",
"_restart" and "_stop".
The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc
code internally uses talloc anyway and employs the smsc struct as talloc
context, I decided to enforce talloc allocation within smpp_smsc_alloc_init().
Be stricter about osmo_signal_register_handler() return codes.
Add ctrl_vty_init() calls and feed the ctrl_vty_get_bind_addr() return value to
ctrl_interface_setup() in the following programs:
osmo-bsc
osmo-bsc_nat
osmo-nitb
osmo-sgsn
For osmo-sgsn, move the control interface setup invocation below the config
parsing, so that the ctrl_vty_get_bind_addr() can return the configured
address.
Abort upon unknown options and missing option arguments. This came to my
attention while rewiring the -m and -M options: passing -M without argument
would launch nitb with wrong configuration. So, rather exit immediately.
If there are legacy options that should be ignored, they deserve an own 'case:'
in the option switch. There are none that I'm aware of though.
Strictly speaking, the unix domain socket location is not a name but a path.
The MNCC socket is called path, so it is confusing to call the ctrl socket
a 'name'.
Following the 'line vty'/'bind A.B.C.D' command added in libosmocore, use the
configured address to set the telnet bind for the VTY line. It is now possible
to publish the VTY on a specific local interface (including 0.0.0.0 aka "any").
Implement in all of:
osmo-gbproxy
osmo-gtphub
osmo-sgsn
osmo-bsc
osmo-bsc_nat
osmo-bsc_mgcp
osmo-nitb
In some of these main programs, move the telnet initialization below the
configuration parsing.
Historically, this was not a good idea for programs using bsc_init.c (aka
bsc_bootstrap_network()), since they expected a gsm_network struct pointer in
((struct telnet_connection*)vty->priv)->priv, so that telnet had to be either
initialized or replaced by a dummy struct. In the meantime, the gsm_network
struct is not actually looked up in a priv pointer but in the static bsc_vty.c
scope (bsc_gsmnet), so this limitation is mere legacy (even though said legacy
is still there in an "#if 0" chunk).
In the other binaries I have briefly looked at the init sequence dependencies
and found no reason to initialize telnet above the config file parsing. In any
case, I have tested every single one of abovementioned binaries to verify that
they still parse the example config successfully and launch, allowing VTY
connections on the configured address(es). I hope this suffices.
In all of the above, log VTY address and port. LOGL_INFO is disabled by default
in some of the logging scopes, and since it is a single log message right at
program launch, I decided for the slightly more aggressive LOGL_NOTICE.
Remove unused talloc.h from bsc_vty.c.
In bsc_nat.c, use OSMO_CTRL_PORT_BSC_NAT instead of hardcoding port number, and
include ctrl/ports.h for that.
Fix comment typo "COMAMND"
Remove the assert in the llme by avoiding the usage of foreign to local
mappings of TLLIs. The asserts had been hit at 32C3 and the fixes were
created by Jacob and had been tested at the convention.
If an MM context cannot be found based on BBSGP info and a RA UPDATE
REQUEST is received, try to find an MM context with an P-TMSI from
which the TLLI could have been derived. This also checks, whether the
routing area matches.
This is similar to the old behaviour removed by the commits
"sgsn: Only look at TLLIs in sgsn_mm_ctx_by_tlli" and
"sgsn: Remove tlli_foreign2local", except that this will only
be done for RA UPDATE REQUESTs now.
Sponsored-by: On-Waves ehf
Currently the MM context is just overwritten by a call to
sgsn_mm_ctx_by_tlli(msgb_tlli(msg), &old_ra_id) even if it
has already been found by using the BSSGP info. With the changes
made to sgsn_mm_ctx_by_tlli this will never find a MM context if
the routing area has changed. If the routing area has not changed,
the mmctx has already been found if it exists.
This commit splits searching for an MM context (if it hasn't been
found already) from checking, whether a found one can really be
used. The actual search is removed, so that the MS will be forced to
restart the attach procedure, which is less efficient but safe.
Sponsored-by: On-Waves ehf
Currently the code also matches the TLLI against LOCAL and FOREIGN
mappings of the P-TMSI, thus eventually finding MM contexts not
consistent with the TLLI (both tlli and tlli_new differ). On
the other hand, tlli_new is not checked at all.
This commit changes the function to only look at mmctx->tlli,
mmctx->tlli_new, and the routing area.
Sponsored-by: On-Waves ehf
The BSSGP cell identifier is used to get the RA for the TLLI lookup.
The send_0408_message function used in the tests does not set this,
so the RA identifier is always 0-0-0-0.
This commit adds a parameters to pass the RAID and adds missing
dummy RAIDs.
Note that the CI can still not be set and thus is always 0.
Sponsored-by: On-Waves ehf
Currently foreign TLLI are sometimes mapped to local TLLI in the
hope that they will match. This seems to sometimes introduce
inconsisties, possibly leading to a failing assertion in
_bssgp_tx_dl_ud.
This mapping should probably reduce the allocation of additional
LLME during routing area changes.
This commit removes tlli_foreign2local.
Sponsored-by: On-Waves ehf
This patch lets the build script for openbsc find the libsmpp34 installation
with the help of pkg-config instead of assuming the header files are in
/usr/include.
In 'show running-config', timeslot appears as a sub-element of rsl, but it is a
direct child of trx. Fix the timeslot section in vty_out by removing one space
of idention.
Adjust various config examples.
Rationale: it's not relevant for function, but confuses human operators. Fixing
it will save the next hacker some time.
Even if fclose fails the stream is inaccessible and the second fclose
might cause memory violation.
Linux manpage says:
Upon successful completion 0 is returned. Otherwise, EOF is returned
and errno is set to indicate the error. In either case any further
access (including another call to fclose()) to the stream results in
undefined behavior.
Fixes: CID#57958
memcpy has both the source and destination marked as non-null and
we were still passing NULL (with a zero size) to it. While this
makes sense it violates the constraints of the function. Add the
check to see if these values are NULL or not.
+db.c:583:2: runtime error: null pointer passed as argument 2, which is declared to never be null
+ #0 0x40d7f7 in get_equipment_by_subscr (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40d7f7)
+ #1 0x40f6d2 in db_get_subscriber (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40f6d2)
+ #2 0x40bfaa in sms_from_result_v3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40bfaa)
+ #3 0x40c847 in update_db_revision_3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40c847)
+ #4 0x40cbc3 in check_db_revision (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cbc3)
+ #5 0x40cf85 in db_prepare (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cf85)
+ #6 0x406f18 in main /home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test.c:179
+ #7 0x7fd625638a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
+ #8 0x405598 in _start (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x405598)
+
+db.c:590:2: runtime error: null pointer passed as argument 2, which is declared to never be null
+ #0 0x40da23 in get_equipment_by_subscr (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40da23)
+ #1 0x40f6d2 in db_get_subscriber (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40f6d2)
+ #2 0x40bfaa in sms_from_result_v3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40bfaa)
+ #3 0x40c847 in update_db_revision_3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40c847)
+ #4 0x40cbc3 in check_db_revision (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cbc3)
+ #5 0x40cf85 in db_prepare (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cf85)
+ #6 0x406f18 in main /home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test.c:179
+ #7 0x7fd625638a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
+ #8 0x405598 in _start (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x405598)
When a MNCC handler wants to issue the MNCC_BRIDGE primitive
overt the MNCC interface, this was not possible so far via the
MNCC socket. This primitive was so far only available from the
internal MNCC handler, more or less by accident I suppose. The reason
for this is in the way the array of two call references had been passed
into mncc_tx_to_cc().
The debug log prints the received/sent bytes in hex. When this data surpasses
the buffer size available for the log string (4096), the log is truncated
and lacks a newline character. Limit the amount of dumped bytes to 1000.
Sponsored-by: On-Waves ehi
Handle peer restart earlier, so that all the tunnels are deleted by the restart
code path, instead of the first one being deleted due to reused TEI. That
caused confusing logging messages.
Also, when receiving Delete confirmations from the peer that didn't restart,
don't complain about unknown peer, but acknowledge and remove the half
invalidated tunnel. This means that the pending delete entry from the restart
code path is not needed / not used, so don't bother to add pending delete
entries upon peer restart.
The test test_peer_restarted_reusing_tei() hits the situation where a tunnel is
removed because of a reused TEI rather than the restart counter. Adjust the
test to expect the "out-of-band" delete request earlier on, and to still see
the half invalidated tunnel around. Enhance the test by adding the delete
response from the peer that didn't restart, and add a final tunnels_are()
verification.
Sponsored-by: On-Waves ehi
Because the sender is known, one unique TEI per tunnel suffices to map the TEIs
that the peers are sending to gtphub, instead of previously 4 (SGSN<->GGSN
interaction on User and Ctrl plane, where each had an own unique TEI).
Also, previously, a tunnel's endpoints should also have been checked against
each other for TEI reuse, not only against the endpoints of other tunnels. This
simplification fixes that problem for free.
Thus simplify TEI reuse detection and improve VTY show readability and
debugging.
Adjust log and VTY output for tunnels.
Adjust tests accordingly.
Suggested-by: Holger Hans Peter Freyther <holger@moiji-mobile.com>
Sponsored-by: On-Waves ehi
Some logging was multiline to ease human reading of debug output. However,
in the VTY output, these newlines lack a CR motion. Split multiline logs into
separate lines.
Also add one missing space.
Sponsored-by: On-Waves ehi
We now store the pre-printed lchan name in lchan->name to avoid having
to call sprintf every time there is a debug statement somewhere,
particularly as most of those debug statements are going to be inactive
most of the time.
Don't route User message back by sequence number, rather test that a
completely unrelated User message is routed back properly.
Sponsored-by: On-Waves ehi
If an SGSN is behind NAT, we cannot rely on the default ports. Specifically,
if a GGSN sends a message, the forwarding to the SGSN should go to whichever
port the SGSN last sent from (whether sequence nr is known or not).
Add sgsn_use_sender config and VTY command, and store the sender instead
of the GSN Address IE and default port if set.
Sponsored-by: On-Waves ehi
Rather than passing a tunnel pointer as function arguments, keep it in the
gtp_packet_desc struct passed around anyway.
Reason: in the next commit (will add sgsn_use_sender), I need the tunnel to be
passed back out to gtphub_handle_buf(), and besides simplifying existing code,
this also makes passing the tunnel back out trivial.
Sponsored-by: On-Waves ehi
During the peer review session with Holger, these things were deemed fixable.
No need to have a static gtp_packet_desc in gtphub_handle_buf.
No need to memcpy, direct assignment does the job.
Remove obsolete comments.
Fix a stray space.
Sponsored-by: On-Waves ehi
If a GSN indicates that it has reset, tear down each known tunnel for that GSN
individually (don't send the GSNs on the other side a different restart
counter, because they represent more than just this GSN).
Sponsored-by: On-Waves ehi
During resolution of the header TEI, also return the tunnel struct that
resolved the TEI, so the Delete PDP Ctx code does not need to look it up
again.
Upon Delete PDP Ctx Request, remember the IEs and that a request was made.
Upon Delete PDP Ctx Response, find the pending delete and remove the
corresponding tunnel, iff the response indicates success.
Add a context deletion to regression tests, rename the test appropriately.
Sponsored-by: On-Waves ehi
gsn_addr_from_str(): return error upon NULL string.
Add some debug logging.
With an empty config, no bind addresses were set, and the address parser
did not check for a NULL pointer, resulting in a segfault.
Sponsored-by: On-Waves ehi
This is a mostly cosmetic change. Instead of separate buffer handling
functions, reduce some code duplication by using a side_idx just like the
plane_idx, with arrays.
Sponsored-by: On-Waves ehi
This could be done way better, discussion is pending/ongoing. It is indeed
quite unlikely that any user will ever hit this situation, so there is no
strong drive to invest effort in a more comprehensive implementation.
Sponsored-by: On-Waves ehi
There's no need to keep two separate number pools when both can be fed
from the same pool. User and Ctrl plane TEIs can technically overlap without
colliding, but it doesn't hurt if they don't overlap, either.
Sponsored-by: On-Waves ehi
Force passing a restart counter, by adding such arg to gtphub_start() (test
suite is not affected by this).
In gtphub_main.c, add -r,--restart-file <path> and next_restart_count() to
maintain the counter file. While at it, tweak the cmdline help to unify the
formatting (mostly commas and a missing line break).
Send gtphub's own restart counter. So far, the sender's restart counter was
copied through, which would break as soon as more than one GSN would talk to
the same peer with differing restart counters.
Also fix the in-mem restart counter data type (one octet, not two).
Sponsored-by: On-Waves ehi
So far, gtphub worked perfectly by only tracking single TEIs ... for probably
most uses. But a Ctrl plane tunnel may have expired despite a still active
corresponding User plane tunnel. The User plane would continue to work
indefinitely, but if any Ctrl messages followed after more than six hours of
Ctrl silence, they would have been dropped due to an expired TEI mapping.
We want to
- combine expiry of a user TEI with its ctrl TEI. (done in this patch)
- upon delete PDP context, remove both user and ctrl TEI mappings. (future)
- when a peer indicates a restart counter bump, invalidate its tunnels.
(future)
To facilitate these, track tunnels, complete with both SGSN's and GGSN's
address, original and replaced TEIs, all for both user and ctrl plane, in a
single struct. A single expiry entry handles the entire tunnel, instead of
previously four separate expiries for each endpoint identifier.
Add the concept of a "side", being either GGSN or SGSN, to index tunnel
endpoint structs, and so on.
Track the originating side in the gtp_packet_desc.
Add header_tei_rx: set_tei() overwrites header_tei, but the originally received
header TEI is still needed to match a Create PDP Context Response up with its
Request (and for logging).
Adjust the test suite to expect tunnel listing strings instead of TEI mappings,
with a bonus of making it a lot easier to grok, and including the IP addresses.
Add regression test for refreshing tunnel expiry upon use.
Note: the current implementation is as slow as can possibly be, iterating all
the tunnels all the time. Optimizations are kept for a future commit, on
purpose.
BTW, the sequence number mapping/unmapping structures remain unchanged.
Sponsored-by: On-Waves ehi
The expiry queues are already used for resolved GGSN addresses, and will
soon enlist tunnel structs. Hence the naming should be more general.
Sponsored-by: On-Waves ehi
Make 100% sure the user adds expiring_items in chronological order by asserting
that a newly added expiry is >= the last expiry in the queue. Add llist_last()
to facilitate.
Sponsored-by: On-Waves ehi
Instead of passing the current time around in function arguments ('now'),
rather store the current time once upon decoding a GTP packet in the
gtp_packet_desc passed around anyway ('p->timestamp').
Sponsored-by: On-Waves ehi
Some gtphub_bind pointers point to an array of binds, some point directly at
instances. Make the distinction between the two more obvious by adding an
'_arr' suffix to the array ones.
Partly in preparation for upcoming rate counters.
Sponsored-by: On-Waves ehi
Clean up functionality is added for the test suite only, to be able to clean
out all allocations and test against memory leaks.
So far, it was sufficient to expire everything to free a gtphub. In preparation
for the upcoming rate counters, which will need to be freed explicitly, add
gtphub functions to clean up everything.
As added bonus, also close the sockets explicitly -- not really needed upon
program exit, neither by the test suite, but *if* we have a cleanup function,
it should clean up everything properly.
Closing the sockets is however kept separate, for the test suite.
gtphub_start() and gtphub_stop() are for normal use (published in gtphub.h),
and gtphub_init() and gtphub_free() are for the test suite, without sockets.
(gtphub_stop() will probably never be called by anyone, but its existence
completes the picture.)
In gtphub_test.c, have a function to clean up the testing gtphub struct. First,
expire everything by timeout, assert emptiness, then call the cleanup function.
Call from each test in the end.
Sponsored-by: On-Waves ehi
Upon calling gtphub_peer_del(), all addresses and ports should already have
expired (by force). Make sure the code heeds that with a so far missing
assertion.
Sponsored-by: On-Waves ehi
From sgsn_vty.c, copy the cfg_grx_ggsn_cmd to add an ares server to the static
sgsn_instance.
This is sort of preliminary. As described in comments, the sgsn_ares functions
should actually be separated from the static sgsn structure. gtphub keeps such
an sgsn structure just for the sgsn_ares functions.
Sponsored-by: On-Waves ehi
gtphub_ext.c's initial purpose was to wrap a specific function. The file
then turned into everything related to DNS, which fits pretty well. Rename
to gtphub_ares.c.
Tweak the header comment to reflect the new file name.
Sponsored-by: On-Waves ehi
Implement min/max bounds for nr_pool, adjust nr_pool_init() and current tests,
and create unit tests for nr_map wrapping.
Sequence numbers range from 0 to 65535, while TEIs range from 1 to 0xffffffff.
Both cause problems when the nr_pool surpasses the range: seq exit their valid
range, causing unmappings to fail, and a TEI would be mapped as zero (invalid).
Add a comment about TEI wrapping, and lose the comment about random TEIs (not
really important).
Sponsored-by: On-Waves ehi
Use unsigned int for nr_map, just large enough to fit the TEI space.
Adjust log output formats and casts accordingly.
Fixes: TEIs are uint32_t, but the nr_map so far used int. This would cause TEIs
from 0x80000000 on to be handled and printed as a negative value.
Sponsored-by: On-Waves ehi
The del_cb is now also used for ares (GGSN resolution) timeouts, and expiry is
anyway separated from nr_map, so this comment is void.
Sponsored-by: On-Waves ehi
This fixes a bug in the following circumstances:
* BSIC is set to 0 in the config file
* No TSC is explicitly specified at the BST level in the config file
In this case, we ended up using BSIC=0 and TSC=7, as TSC=7 is our
default initialization value.
The TSC of the CCCH/BCCH must always be the BCC, which is the lower 3
bits of the BSIC. Having configuration options for both the BSIC _and_
the TSC at the BTS level therefore makes no sense, as it only adds ways
in which users can configure non-oprational configurations. So we
remove the bts->tsc member, and keep only the ts->tsc members that allow
us to configure a timeslot-specific TSC that's different from the BTS
TSC (= BCC).
s_db.c: In function ‘_insert_ud’:
meas_db.c:65:6: warning: implicit declaration of function ‘rxlev2dbm’ [-Wimplicit-function-declaration]
rxlev2dbm(ud->full.rx_lev)));
^
- an unnecessary if-not-NULL check (1339764);
- a missing nul termination safety net (1339768);
- a typo resulting in the wrong proxy being logged (1339767).
Sponsored-by: On-Waves ehi
gtphub always wants to know the sender, hence make the from_addr pointer
mandatory.
Fixes two coverity complaints (1339766, 1339764).
Sponsored-by: On-Waves ehi
Fit most of the code in 80 chars width. Some instances still leak past 80
characters because of long function names, inline comments or the like, "the
exception proves the rule."
Sponsored-by: On-Waves ehi
For maintenance, it is convenient to have the log level explicit at each
log statement.
Tweak some log levels / message formatting while at it.
Sponsored-by: On-Waves ehi
Allow logging the plane (Ctrl/User) and side (SGSN/GGSN) in functions that only
have a gtphub_bind* to work with, by adding a constant label to each bind.
Sponsored-by: On-Waves ehi
If a GGSN is already known from unmapping, don't invoke a host resolution.
In a live working environment, it wouldn't hurt, because the lookups would
mostly return from the cache. But in a testing environment without a name
server, it barfs on every packet.
Sponsored-by: On-Waves ehi
Initialize llist_heads to empty (2 were missing). Move those for struct gtphub
instances to gtphub_zero() (one moved, one added).
In from_[gs]gsns_read_cb(), use a return type that can actually reflect
negative return values.
resolved_addr.buf: no need to take the address of a byte array var
(cosmetic).
Pass the proper user data address to sgsn_ares_query(), not the address of
the pointer holding the user data address.
Initialize ggsn_lookup->expiry_entry (was missing). Publish the function for that
in gtphub.h so gtphub_ext.c can use it.
Sponsored-by: On-Waves ehi
Looking for a segfault, I added a lot of logging. This may be useful for
live testing ares, leaving it in there for now.
Note: I still want to clean up the logging concerning log levels etc. once
we're out of alpha.
Sponsored-by: On-Waves ehi
Allow a peer sending from an unknown port but a known address, and just
create the port (and unmap the seq nr back to this port later to return
the response to the sender).
Only an SGSN on the Ctrl plane is allowed to make the very first contact
from an unknown address.
Sponsored-by: On-Waves ehi
Split decoding return code GTP_RC_PDU in GTP_RC_PDU_C and GTP_RC_PDU_U.
Don't do IEs in GTP_RC_PDU_U.
Add a unit test for User plane data, expected to fail (nonstandard port case).
In gtphub_test.c, tweak logging so that it is easily visible which test
produced which output. Also add the global resolved_sgsn_addr and ggsn_sender,
symmetrically to resolved_ggsn_add and sgsn_sender.
Sponsored-by: On-Waves ehi
Generalize to make the PDP ctx message definitions and "sending" of messages
from SGSN->gtphub->GGSN and back reusable in future tests.
Publish gsn_addr_from_sockaddr() in gtphub.h for use in gtphub_test.c.
Use an osmo_sockaddr for resolved_ggsn_addr, because one is needed for
comparison in probably every future test.
Add LVL2_ASSERT() to print assertion message and return instead of abort,
so that functions can be called from several tests without losing the
info of which test caused it from which line.
Use globals for struct gtphub and time_t now, to reduce nr of args that need to
be passed around when writing tests. Add a default test setup function.
Sponsored-by: On-Waves ehi
Up to now I used the Echo as a test for sequence nr mappings. But Echos
should be handled differently: they are scoped on the link and an Echo
response should be sent right back to the requester.
Sponsored-by: On-Waves ehi
For the resolving function, change the function signature to return a
gtphub_peer_port. In consequence, publish two functions concerned with
gtphub_peer_port instances for use in test and gtphub_ext.c.
Add GGSN resolution queue, callback and cache. Simple implementation: if an
SGSN asks for a GGSN, it will first get no answer, and I hope it will ask again
once the GGSN is in the cache.
Within gtphub_ext.c, have a dummy sgsn struct, as the sgsn_ares code currently
depends on it (half the functions pass an sgsn instance pointer around, but the
other half use the global one).
In the unit tests, wrap away the ares initialization so that they can work
without a DNS server around. The netcat test breaks because of this, will
remove it.
Using sgsn_ares, implement the gtphub_resolve_ggsn_addr() function, I hope:
untested.
Minor cosmetics just to see if you're paying attention... ;)
Sponsored-by: On-Waves ehi
First steps towards a new GTP hub. The aim is to mux GTP connections, so that
multiple SGSN <--> GGSN links can pass through a single point. Background:
allow having more than one SGSN, possibly in various remote locations.
The recent addition of OAP to GSUP is related to the same background idea.
(This is a collapsed patch of various changes that do not make sense to review
in chronological order anymore, since a lot of it has thorougly transmorphed
after it was first committed.)
Sponsored-by: On-Waves ehf
Extend the ul/dl counting to count the usual messages on the
Gb interface. Add counters for the attach, routing area update,
pdp context activation and deactivation procedures. Update the
test result with the new counters.
RPM post-build-checks found some issue and marks these as error:
[ 38s] I: Program returns random data in a function
[ 38s] E: openbsc no-return-in-nonvoid-function meas_vis.c:118
Holger reports that the bitmap that accounts for available Osmux circuit
IDs is limited to 128, when the maximum number of circuit IDs are
determined by the uint8_t field in the header (ie. 256 circuits).
[hfreyther: Update the testcase now that we have more ids to allocate]
Trigger an OAP registration upon IPA connect. Feed incoming OAP messages to
oap_handle() and send replies returned by it.
Add oap_config to sgsn_config (todo: vty).
Sponsored-by: On-Waves ehf
[hfreyther: Fix coding style]
Add new kitchen sink openbsc/utils.h and libcommon/utils.c to make three so far
static functions public (so I can use them in the upcoming OAP code).
A place to put them could have been the gprs_utils.h, but all general functions
in there have a gprs_ prefix, and todo markings to move them away. All other
libcommon headers are too specific, so I opened up this kitchen sink header.
Replace the implementation of encode_big_endian() with a call to
osmo_store64be_ext(). See comments.
Apply the change in Makefiles and C files.
This change has some implications for the test case. It manipulated
bss_ptmsi_state and sgsn_tlli_state variables to make the output of
rand_r() and thus the TLLI/TMSI used predictable.
This possibility is gone when using RAND_bytes() so instead it is
overridden by a function that returns a deterministic sequence of values
(0x00dead00, 0x00dead01, ...). The test cases are adapted to expect
these values instead of the pseudo random values before.
The gbproxy_test stdout file changes as well, but only where the
TLLI/TMSI is displayed (in the hex dumps as well as the TLLI cache
entries). All other output is the same.
This (currently empty) function is meant to contain code that cleans
up the left-overs of the test functions. This is needed by the next
commit to reset the RAND_bytes sequence.
Currently just the number of intercepted downlink messages is counted
and eventually checked. The contents of the messages is lost. The
PTMSI contained in ATTACH/RAU Accept messages is just 'guessed' by
resetting the random number generator after reference PTMSIs have
been generated. While this works with rand_r, RAND_bytes cannot be
forced to recreate a certain number sequence this way (unless the
backend is replaced).
This commit changes that behaviour so that the last received msgb is
kept and decoded. The PTMSI that has been assigned by the SGSN is
then taken in the affected test cases and used instead of a 'guessed'
one. This is similar to how a real MS would react to the Accept
message.
Sponsored-by: On-Waves ehf
This (currently empty) function is meant to contain code that cleans
up the left-overs of the test functions. This will be needed by the
next commit that will store the last received msgb for later inspection.
Sponsored-by: On-Waves ehf
This API is a bit unfortunate as the caller will also
access the endpoint directly. E.g. like this:
output = bsc_mgcp_rewrite(...,
mgcp_net_src_addr(endp),
endp->net_end.local_port, -1,
In terms of "terminology" the "net" was meant to be bad
internet and the "bts" is the local and trusted network
segment. With this terminology the "bts" would be the
call-agent/MGW and "net" where the BSCs will send data
to but that is not the case and terminology actuallys
refers to:
* net: The addresses exposed to the entity that
made the MGCP call
* bts: The system where we get our data for the
local audio flow.
Fix the method but leave the API as it is. Use the net_end
in the net_src method and the bts_end in the bts_src method.
We put a signed integer into this string but did not account
for the newline and for the terminating NUL of the string. Add
the newline to the string and add one for NUL. Spotted while
accidently having a CID of 255.
There appears to be a leak of CIDs:
<000b> mgcp_osmux.c:544 All Osmux circuits are in use!
There are paths that a CID had been requested and never released
of the NAT. Remember the allocated CID inside the endpoint so it
can always be released. It is using a new variable as the behavior
for the NAT and MGCP MGW is different.
The allocated_cid must be signed so that we can assign outside
of the 0-255 range of it.
Fixes: OW#1493
Extend the osmux only setting from the MGCP MGW to the NAT. This
is applied when an endpoint is allocated and/or when the allocation
is confirmed by the remote system.
Not tested. The impact should only be when the new option is
being used.
Fixes: OW#1492
Some systems only want to use Osmux. In case only Osmux
should be used fail if it has not be offered/acked.
Client:
Verified On, Off and Only with X-Osmux: 3 and without this field.
<000b> mgcp_protocol.c:823 Osmux only and no osmux offered on 0x14
<000b> mgcp_protocol.c:884 Resource error on 0x14
NAT:
Not tested and implemented
Fixes: OW#1492
sizeof(uint8_t) == 1 and there is no need to create an array
with 16 bytes and then only use the first two of them. This
means the CID range is from 0 to 127 and we should be able
to extend this to 256 by changing the array size to 32. Update
the testcase now that we can have more than 16 calls with Osmux.
* Test that one can get an id
* That they are assigned predicatble right now
* That returning them will make the number of used ones go down
* That allocating more will fail
The log message does not help and says where the data is
being sent to. This is because we have both a RTP and RTCP
port. Remember if we failed with RTCP or RTP and improve
the log message.
I was searching a case where the port was bound to a local
address (e.g. 127.0.0.1) and tried to send the data to a
public one (e.g. 8.8.8.8).
The signature of mr_config and the BSC implementation didn't
match and the compiler was warning about it:
osmo_bsc_api.c:530:2: warning: initialization from incompatible pointer type
.mr_config = bsc_mr_config,
^
osmo_bsc_api.c:530:2: warning: (near initialization for ‘bsc_handler.mr_config’)
Change the mr_config again and provide an implementation
that will set the ms and bts data structure. It would be
better to put the size outside of the IE but I am not going
to change it right now. It would also be nice to either move
the AMR setting into the "nitb" structure or have the msc
data be used _after_ the bts settings. This needs to be
cleaned up in the next step.
Manually verified by placing a MO call and checking that
both the channel mode modify and the mode modify request
contain the multi rate config with the rate mr config
(length two bytes, version 1, icmi==1, no start mode being
set).
This way a lot of if/else can just be killed by the caller deciding
which of the two instances to use.
I have copied both branches to new files, replace bts for ms in one
of them and ran diff on it. There is no difference.
Merge two copies into a local static helper function. The format
of the message will change and then it is easier to modify it in
one place than in two.
Sadly the original patch was merged before this clean-up so do
the clean-up as second step.
Conflicts:
openbsc/src/libbsc/abis_rsl.c
openbsc/src/libbsc/gsm_04_08_utils.c
The pre-release didn't add a newline after the apn and the patching
pattern command. Create a quirk command that combines both. The
pre-release didn't include a differentation between routing and
patching.
The TLLI handling has a different and more generic name now. Make
it handle the old one that is actively used.
Add a file with the broken format and the standard config file
test should pick it up.
* Implement the rtp-bridge mode for MNCC
* Audio doesn't flow through the NITB at all
* It only works with IPv4 BTSes right now
* We need to select an audio codec way too early
* No tandem free operation
* Early assignment always equals TCH/F
In case of the RTP bridge mode we need to select the codec
ourselves. Rely on the same (incomplete) codec selection that
can be done using the mncc-int configuration node. This might
gain bearer capabilities support.
In case of a SDCCH a TCH/F will be attempted to be assigned.
This is an open issue for both modes and there should be a
preference for full or half-rate channels somewhere.
Implement sending MDCX on the newly allocated channel and send
the data to the same destination as the currently connected one.
This way the receiver can implement RTP RFC Appendix A.1 and
deal with the new source.
For the LCR rtp-bridge audio should directly flow to the
remote system. In contrast to the original patch audio
will now flow directly from the BTS to the remote system.
This assumes that BTS and the remote system are in the
same network segment and can directly communicate.
There are various limitations in the first iteration of
the implementation:
We could (and in the future) should delay the assignment
but currently we are forced to pick the channel and move
it to the audio state. In case we are located on a SDCCH
we always need to change but if we are on a TCH we could
send the ipa.CRCX and change the audio state a lot later.
The net effect is that the audio codec selection needs to
be done in the NITB code and not in the system connected
to it.
This only works with ip based systems. For E1 systems one
could still use the RTP socket or even try to move this
out of the process.
There is no code for handover handling and it relies on
the remote system dealing with the SSRC change of the
system.
This adds the protocol definition for the RTP bridge extension
of Andreas Eversberg and bumps the protocol version.
I added the missing mncc mappings from value to string.
[ 5cf8fb10ea3addcae74d37f4dbf1c1be664df53e protocol extension
5dac90de38990b188f499c602bf18a4f232070e8 payload extension]
Mike's patch included clean-ups I want to apply separately and
change them a bit. If we return from an else we don't need to
put the else.
* Try the E1 trunk first
* Then try a local virtual trunk
* Fail if none of the above returned
Remove the host portion of the endpoint Id. This requires less
configuration and we are probably fine to trust that MGCP only
received messages designated for it.
When using multiple interfaces on a system one can now configure
which will be served for the BTS ports and which will be served
for the network. The direct usage of source_addr is now only to
initialize the MGCP receiving port itself.
Make it possible to bind the call-agent to a specific IP address
and the network and bts end to different ip addresses. Begin by
clarifying which source ip address we want to have.
Use the existing ulaw encode/decode to support PCMU as well.
The MERA VoIP switch has some severe issues with the GSM codec
and it appears easier to enable transcoding for it.
The mera switch doesn't appear to cope with codec change
between a SIP 180 trying and the 200 ok connection result.
Inserting the codec is touching too many places. Ideally we
should have the transcoding function as pointer in the struct
as well but the arguments differ.. so it is not a direct way
forward.
Iridium is a satellite network which operates a GPRS-like that allows you to
get speeds up to 128kbit/s. However, it takes from 5 to 6 secs to get the
bandwidth allocated, so the conversation is garbled during the time.
This patch uses the new dummy padding support in libosmo-netif that is
controlled through the osmux osmux_xfrm_input_open_circuit().
This includes a new VTY option for osmux.
I guess none of our users knows what a mi_type=0x02 is, but most would
know what an IMSI or a TMSI is. So let's use the newly introduced
gsm48_mi_type_name() function to fix this.
For some odd reasons the XID is not a separate SAPI but has been kludged into
the GMM SAPI. This means we ahve to be careful not to dispatch XID frames into
GMM. We do this by introducing an explicit check for UI frames before the
dispatch to GMM.
The previous code already was doing "the right thing" but printed occasional
messages like "gprs_gmm.c:2082 Unknown GSM 04.08 discriminator 0x01: 01 00 0e
00 32 11 03 16 01 90 63 28 0b". Those should be gone after this patch.
Traffic cannot sent to BTS, if there is (currently) no logical channel
associated with the transaction.
This happens, if TCH traffic is received from upper layer, but there is
no lchan available before completing immediate assignment, handover or
assignment process.
[hfreyther: The code has not been moved to tch_frame_down
but the issue looks similiar]
The NAT sends an incomplete SDP file for the purpose of informing
the BSC about the remote IP/PORT early. The case of an incomplete
SDP file was not considered. Check if there is a codec and if not
skip it.
TODO: We need to have a better end-point life cycle test.
Move forward while preserving the legacy handling. Beging to
extract SDP rtpmap information and select codecs atfer this.
It is a foundation we can now build further and better check
ons.
We have a lot of legacy that I am afraid to break. We have
everything in place to make a good codec selection (e.g. if
we can avoid transcoding, pick the one with best quality or
the lowest speed). Right now I have a specific case where
from all options I want to pick GSM. Guard the codec compat
check behind the disallow transcoding option to make sure
to not break legacy application.
First collect everything we know and the mapping. E.g. a genuis
could remap "3" to "AMR" so we only know the codecs once we are
at the end of the SDP file. Once we have collected everything we
can select the audio codecs. The current code is compatible in
that two codecs will be selected regardless of if they make any
sense or not.
mgcp_set_audio_info could re-use some of our codec information
but then the caller in the MGCP protocol needs to be updated as
well as we use the "I: GSM" information to derive the codec from
there.
The SDP file handling will get more complicated in terms of
codec selection so let's remove it from the protocol handling
before we start blowing it up in size.
The parsing code assumed that there will be a single payload
type and this assumption is clearly wrong. Forward all of the
payload types. The code is still only extracting the first
type from the list. The variable name has been renamed to
reflect this.
Using the talloc leak report we see that there are some msgb's
that are allocated for SMS but we don't have transactions or
SMS around. We need to improve the name of the messages to
uniquely dscribe where they are from but the obvious leak does
occur in this routine.
The no available transaction id is most likely the case where
we leak memory. This should not occur and shows another issue
with the smsqueue/smpp handling. It doesn't explain the subscr
reference count issue either.
Extract of the leak report:
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x2517dc0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x24b56e0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x23e7930
At the rhizomatica sites some unauthorized subscribers have a
last used from long time ago but a bigger reference count. This
means that we have an unbalanced subscr_get/subscr_put that we
need to investigate. These two fixes are genuine fixes but are
unlikely to fix the issue I am not understanding yet.
In case the subscriber is currently busy we would omit the
subscr_put. This seems to be very hard to hit as the subscr
need to be active and at the same time be selected for the
purge operation.
Various paging clean-ups. I couldn't re-produce the assert that
was hit by Rhizomatica in the subscriber code. Let's clean things
up a bit to avoid some of the potential issues this code had.
Always stop paging regardless of where the subscriber is at the
time of the cancellation.
As the comment says we should not rely that the paging
occurs on the current LAC. We might page at more BTS.
Walk all the BTS to stop paging. No callbacks will be
issued by this stop operation.
In case we can't page on a BTS then stop it everywhere. The
callers of paging_request assume that this is kind of an
atomic operation and we should help with that.
Coordinate with the normal subscriber channel requests instead
of going to page ourselves. This might lead to getting a channel
that is of a different type though.
vty_interface_layer3.c:584:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=]
sizeof(subscr->extension)-1, VTY_NEWLINE);
When two phones use the same TMSI and no A3A8 is possible
we could end in a hard to detect issue. Assume that the IMSI
will not clash and we have issues for foreign simcards.
In case foreign simcards are used we can not do authentication
and ciphering. In case a TMSI is re-used too early and we do
page using TMSI we can't know which of the two MS is responding
to us. We could change the "secure channel" routine to ask for
the IMSI and only then stop the paging.
As we don't have ciphering there is not much use in using the
TMSI. Add a mode "no assign-tmsi" that will not assign the TMSI
during LU. Now CM Service Request and Paging Response will
work using the IMSI. There can't be a clash with that.
[ciaby fixed the vty write to use the right name]
When we can't find the TMSI then the subscriber is not in our
VLR. We have not consulted with the HLR and it is better to not
use such a severe error code.
in_address is not 'accidently' included by FreeBSD when we include
the osmocom/core/select.h header file. We need to include a bit
more.
In file included from mgcp_protocol.c:38:
../../include/openbsc/mgcp_internal.h:134:21: error: field has incomplete type 'struct sockaddr_in'
struct sockaddr_in forward;
List needs to be executed from within the right configuration
node to see if it is available or not. list on the toplevel
will uncoditionally show "smpp" as part of the logging config.
Struct osmo_msc_data contains int core_ncc, which is actually the
MNC part of the PLMN, not to be confused with the Network Colour
Code.
The following patch renames this field for clarity and consistency
with the standards.
If we have tried SMPP first and it was not routable, and then
tried the local delivery there is no point in trying SMPP with
the same parameters again. Leave early and return unknown sub
to the caller.
default-route would only be looked at after there has been
no subscriber in the local database. Depending on the setup
this is not what one wants. This has been discussed at the
OsmoDevCon and there have been hacks in some branches. Let's
introduce a VTY command to select if SMPP should be consulted
first and then fallback to the current behavior.
Even if it is using BSC/NITB types let's put it in the header
file than just declaring it at a place that could bitrot in a
way that doesn't lead a warning.
The "default-route" for SMPP will be used after a local
subscriber look-up. Sometimes we want to route everything
to SMPP. Make this possible by changing this routine.
We just link to libosmovty and if it requires crypt internally it
needs to link to that (and not us). This looks like a left-over
from when we moved the VTY code out of OpenBSC
We don't need to consume all the entropy of the kernel but can
use libcrypto (OpenSSL) to generate random data. It is not clear
if we need to call RAND_load_file but I think we can assume that
our Unices have a /dev/urandom.
This takes less CPU time, provides good enough entropy (in theory)
and leaves some in the kernel entropy pool.
We are using the token to find the right bsc_config and
then we can use the last_rand of the bsc_connection to
calculate the expected result and try to compare it with
a time constant(???) memcmp.
Check if the NAT has sent 16 bytes of RAND and if a key
has been configured in the system and then generate a
result using milenage. The milenage res will be sent and
noth the four byte GSM SRES derivation.
Generate 16 byte of random data to be used for A3A8 by
the BSC in the response. We can't know which BSC it is
at this point and I don't want to send another message
once the token has been received so always send the data
with an undefined code. The old BSCs don't parse the
message and will happily ignore the RAND.
/dev/urandom can give short reads on Linux so loop
around it until the bytes have been read from the kernel.
Instead of doing open/read/close all the time, open the
FD in the beginning and keep it open. To scare me even
more I have seen /dev/urandom actually providing a short
read and then blocking but it seems to be the best way
to get the random byes we need for authentication.
So one should/could run the cheap random generator on
the system (e.g. haveged) or deal with the NAT process
to block.
Unfortunately the basic structure of the response is broken.
There is a two byte length followed by data. The concept of
a 'tag' happens to be the first byte of the data.
This means we want to write strlen of the token, then we
want to write the NUL and then we need to account for the
tag in front.
Introduce a flag if the new or old format should be used.
This will allow to have new BSCs talk to old NATs without
an additional change. In the long run we can clean that up.
In case the token was not correct, just close the connection.
It is not clear that forcing a new TCP connection is going to
give us any extra security here. But with the upcoming auth
handling it does make sense to have both case look similar.
In the libfilter source code, which is built regardless of --enable-nat,
headers from libosmo-sccp were used, thus causing a build failure (see
below) when building without --enable-nat, and libosmo-sccp not being
installed (or being installed in a prefix not otherwise included in the
build).
The build fails like this:
In file included from ../../../src/libfilter/bsc_msg_filter.c:27:0:
../../../include/openbsc/bsc_nat_sccp.h:27:37: fatal error: osmocom/sccp/sccp_types.h: No such file or directory
As the includes seem not to be actually needed, this change fixes the
issue by just omitting them.
Running "make distcheck" failed trying to generate ".version" into the
read-only unpacked source directory. Actually shipping ".version" in the
tarball fixes that.
There was no context for the SCCP CREF message and this means
that the msc_con was a plain NULL pointer that was dereferenced
and the application would crash.
Use the new API to pass the incoming MSC Connection which sould
be used for the SCCP CREF message as context. The code has not
been fed with an actual SCCP CR message.
The loop was used to print all returned addresses but we can
simply pick the first one. This is fixing a coverity issue that
the loop will be executed eaxactly once (and that was on
purpose).
Simplify the code and just take the first element (which might
be NULL).
Fixes: Coverity CID#1302852
We can't do much in case the fd is failing to be registered.
There should be a timeout that is catching this and it might
be able to repair it self.
Fixes: Coverity CID#1302854
The code to do that doesn't belong to the control interface, so
abstract it out to a separate function gsm_bts_set_system_infos().
[hfreyther: Fix the coding style...]
In case the query for "hostname" will fail c-ares will append the
domain name of /etc/resolv.conf and query again. We don't want that
so claim we provide a list of domain names and then don't provide
any.
I didn't intend to have pushed the c-ares code to master yet.
For real networks we need to check if the requested APN string
is allowed and then resolve the GGSN address through DNS. There
are countries with two or three digit MNCs and one could either
try to keep a list of countries that have two/three digits or
just try both of them. I have opted for the later for the ease
of the implementation.
C-Ares doesn't allow to cancel a request so we will need to
have the MMCTX and the Lookup have different lifetimes. We simply
set ->mmctx to NULL in case the MMCTX dies more early.
The selected and verified apn_str will be copied into the out
parameter. In case no static APN/GGSN config is present and the
dynamic mode is enabled a request will be made.
c-ares is an asynchronous DNS resolver and we need it to
resolve the GGSN address. This is integrating the library
into our infrastructure. We will create and maintain a list
of registered FDs (c-ares is currently only using one of
them) and (re-)schedule the timer after events occurred.
When needing to do an asynchronous DNS query we need
to keep the TLV data around. So create a wrapper that
takes a copy of it and frees it after the call. I can
change the code to add an out parameter to decide if
the msgb should be freed or not.
Pick network failure in case the msgb could not be
cloned in the hope the MS will retry then.
A real SGSN will dynamically resolve the APN name into the
GGSN IP Address. This means that after we have collected all
information we need to start to resolve the GGSN and then
can continue.
This is a left-over from the initial system where no PDP
was provided by the system. For now if there is a subscr
attached and no PDP context provisioned. He is not allowed
to have a data connection.
Update the testcase to create the pdp list entry more
early with a wildcard and then change it to a specific
match.
Include the hlr-Number of the subscriber in the CDR. This is useful
for debugging and understanding which equipment was used during the
test. In contrast to the MSISDN the '+' is emitted as the number
must be in international format already.
Copy the hlr-Number into the sgsn_data and use it during
the purgeMS. There is no unit test that looks at the data
we send so I manually verified this by looking at the output.
Below is the output of the test that purges the subscriber.
<000f> gprs_subscriber.c:170 SUBSCR(123456789012345) Sending GSUP, will send: 0c 01 08 21 43 65 87 09 21 43 f5 09 07 91 83 61 26 31 23 f3
We have verified/selected the APN. Either based on the subscriber
data, a global APN match. But at least this SGSN has looked at
what the MS has asked for and then selected a matching GGSN.
Clear LAC/RAC with pre-defined value in the RAI.
3GPP 29.060 v7.17.0 section 7.3.1 page 23:
"The SGSN may include the Routeing Area Identity (RAI) of the
SGSN where the MS is registered. The MCC and MNC components shall
be populated with the MCC and MNC, respectively, of the SGSN
where the MS is registered. The LAC and RAC components shall be
populated by the SGSN with the value of 'FFFE' and 'FF',
respectively.”
Most SGSNs pass the IMEI(SV). We currently only enquire about
the IMEI and then pad the 'SV' with 1111b (thanks to the encoding
routine). Sadly it insists on always writing the length which
means we have to memmove the data around by a single octet.
Manually verified using the pcu-emu and looking at the trace
using wireshark.
Give the GGSN another opportunity to determine which tarif
to apply for the SGSN/subscriber. This code assumes tha the
RAN is a GERAN system but the assumption has been made in
other places as well.
For PDP context creation we always want to include the RAI
for the current mmctx. This might help commercial GGSNs to
determine which charging to apply.
The charging_id is provided by the GGSN. Copy it into the CDR
part of the data structure so it will remain present until after
the pdp context has been deleted.
Make it possible to set a filename to use for the CDR. By
default no CDR will be generated. Forbid to set the interval
of 0 seconds as this will cause a lot of work. Add a very
basic VTY test.
This is consuming the new signals and allows to install several
different CDR/observing/event/audit modules in the future. For
getting the bytes in/out the code would have had to undo what the
rate counter is doing and at the same time adding a "total" to
the ratecounter didn't look like a good idea, the same went for
making it a plain counter.
Begin writing the values one by one and open/closing a new FILE
for every log messages. This is not efficient but easily deals
with external truncation/rotation of the file (no fstat for and
checking the links and size). As usual we will wait and see if
this is an issue.
Add some new members to our PDP context structure to see what it
is about.
In case there is a subscr attached to the MM context and there
is an encoded MSISDN we will attempt to decode it and in case
of an international number prepend a '+'. Assume that the array
size of gsm_mmcc_called->number is as big as ctx->msisdn for the
strncpy.
When communicating with a GGSN that is not the OpenGGSN
the PDP context activation does fail. This is because on
the activation of the first PDP context we need to supply
a MSISDN. Extend the protocol, parse the MSISDN and then
send it to the GGSN. The second item is that we have only
forwarded the requested QoS of the subscriber. In most
cases this is 0x0, 0x0, ... which means one requests a
rate 0 byte/sec which the GGSN will not allow. Make it
possible to receive, store and use the subscribed QoS of
the Subscriber.
If QoS is only three bytes it does not include the allocation/
retention policy. Otherwise it does. Copy it depending on that.
We should have a macro for the clamping to reduce code duplication.
The insanity does come from the MAP data and this seems to be
the easiest in terms of complexity. It is an array of bytes that
is transported from MAPProxy to the SGSN and then simply forwarded.
The case of more than three bytes is neither unit nor manually
tested so far.
sgsn_create_pdp_ctx should use the subscribed QoS. When selecting
the PDP context we inject the QoS to be used into the TLV structure
and use it during the request. Assume a "qos-Subscribed" structure
only with three bytes and prepend the Allocation/Retention policy
to the request.
The MSISDN should be present for "security" reasons in the first
activation of a PDP context. Take the encoded MSISDN, store it for
future use and then put it into the PDP activation request.
The MM Context contains a field for a decoded MSISDN already. As
we need to forward the data to the GGSN I want to avoid having to
store TON and NPI in another place. Simply store the data in the
encoded form.
QoS is a mess. In MAP there is qos-Subscribed which is then extended
using ext-QoS-Subscribed, ext2-QoS-Subscribed, ext3-QoS-Subscribed
and maybe even ext4-QoS-Subscribed by now. The MAP ASN1 files defined
how these need to be "linearized". Instead of copying this I have
decided to include the two semantics with/without the Allocation/Retention
policy using the size of the data.
It is a bit arbitary to decide which one is the global
and which one is the local one. We might change it around.
I don't think we want to introduce it based on BTS.
For the BSC we will have the gsm48_hdr and don't need to
find data within SCCP. For legacy reasons we need to
initialize con_type, imsi, reject causes early on and
need to do the same in the filter method.
This means we need to require a talloc context and
simply operate on the list. I had considered creating
a structure to hold the list head but I didn't find
any other members so omitted it for now.
Move the filter methods to the filter module. This is
still only usable for the NAT and the _dt/_cr filter
routines need to move back to the bsc_nat in the long
run.
For customer requirements we want to be able to do
filtering on the BSC as well. The same messages need
to be scanned and the same access-lists will be looked
at. In the future we might even split traffic based
on the IMSI. Begin with moving the code to a new top
level directory and then renaming and removing the
nat dependency.
ENDPOINT_NUMBER takes the difference of two pointers. On 64bit
builds the difference is a long and the compiler then complains
about the usage of abs. We will never have thousands of endpoints
so silence the warning by casting the ENDPOINT_NUMBER to int.
mgcp_vty.c:1381:34: warning: absolute value function 'abs' given an argument of type 'long' but has parameter of
type 'int' which may cause truncation of value [-Wabsolute-value]
rtp_port = rtp_calculate_port(ENDPOINT_NUMBER(endp),
^
../../include/openbsc/mgcp_internal.h:206:31: note: expanded from macro 'ENDPOINT_NUMBER'
#define ENDPOINT_NUMBER(endp) abs(endp - endp->tcfg->endpoints)
^
mgcp_vty.c:1381:34: note: use function 'labs' instead
The idea of "subscriber_get_channel" was that different
requests would be coordinated. At the same time we have
seen that the "queue" can get stuck at both 31C3 and the
rhizomatica installations.
Voice calls and SMS do not need coordination. We should
be able to send SMS on a voice channel and switch the MS
from a SDCCH to a TCH in case we establish a voice call.
The SMS code itself needs to coordinate to obey the limit
of one SMS per direction but this should be enforced in
the sms layer and not on the subscriber.
Modify the code to have a simple paging coordination. The
subscriber code will schedule the paging and register who
would like to know about success/failure.
This allowed to greatly simplify the paging response
handling for the transaction code (and in fact we could
move the transaction list into the subscriber structure
now). The code gained to support to cancel the notification
of a request (but not the paging itself yet).
TODO: Cancel paging request in case no one cares about it
anymore.
In case the default TCH/F codec is "EFR" and we do an early
assignment from SDCCH to a TCH we would assign the TCH/H
codec. This is because the lchan_type will be neither a
TCH/H nor a TCH/F.
At the same time the _gsm48_lchan_modify code to check for
half vs. full-rate is the other way around. Align both.
It is full-rate if it is not a TCH_H. This will have some
other complications down the way (early assignment on
cells with only TCH/H). So the mode should not depend on
the _current_ channel but the kind of channel we want.
The debian shlibs:depends macro will add the depends
according to the needed libraries for us. We only need
this for the sqlite3 plugin of libdbi-drivers as there
is no direct linkage.
In test_rtp_seq_state an assignment is accidently done within an
assertion.
This commit changes that into a comparison as it was intended.
Fixes: Coverity CID 1295457, 1295458
Sponsored-by: On-Waves ehf
Currently the src_codec const variable is set to &src_end->codec
before src_end is checked against NULL. Since the assigment is just
an address operation and the memory where it points to is only
accessed after the NULL check, this does not harm technically.
Nevertheless this is potential source for errors if that code is
changed.
This commit moves the definition below the NULL check. This does not
comply with the coding style, but it cannot be split into definition
and a later assignment due to the const qualifier.
Sponsored-by: On-Waves ehf
We might have compiled transcoding into the MGW but
we don't want to enable it for a given user. Add a new
switch that should allow that.
I had manually tested the allow-transcoding/no allow
VTY interface for the primary interface and a new trunk
using show running-config.
It is unlikely that GSM, gsm and GsM refer to different codecs.
The mera mvts does send the audio codecs in lower case even if
RFC 3551 has them in upper case (but copy and paste is sometimes
too hard).
Currently the handling of the buffers is not done consistently. Some
code assumes that the whole buffer may be used to store the string
while at other places, the last buffer byte is left untouched in the
assumption that it contains a terminating NUL-character. The latter
is the correct behaviour.
This commit changes to code to not touch the last byte in the buffers
and to rely on the last byte being NUL. So the maximum IMSI/IMEI
length is GSM_IMSI_LENGTH-1/GSM_IMEI_LENGTH-1.
For information: We assume that we allocate the structure with
talloc_zero. This means we have NULed the entire imsi array and then
only write sizeof - 1 characters to it. So the last byte remains NUL.
Fixes: Coverity CID 1206568, 1206567
Sponsored-by: On-Waves ehf
Currently some VTY command do neither check the length of the source
string before calling strncpy nor ensure NUL-termination afterwards.
This can to destination string buffers whose contents are not
NUL-teminated.
This commit adds checks and corresponding warnings to the VTY
commands 'subscriber TYPE ID name .NAME" and "subscriber TYPE ID
extension EXTENSION".
Fixes: Coverity CID 1206570, 1206569
Sponsored-by: On-Waves ehf
When handling an incoming GSUP cancellation request, the cancel_type
if effectively ignored, such that is always handled as
GPRS_GSUP_CANCEL_TYPE_UPDATE and never as WITHDRAW.
This commit fixes the expression used to set the variable
is_update_procedure.
Fixes: Coverity CID 1267739
Sponsored-by: On-Waves ehf
Currently the inner loop in show_bsc_mgcp iterates of the timeslot
interval [0, 31]. Timeslot 0 is not valid, which causes
mgcp_timeslot_to_endpoint to generate a corresponding warning and to
return an invalid endp value. That value causes an out-of-bound
read access, possibly hitting unallocated memory.
This patch fixes the loop range by starting with timeslot 1.
Note that this does not prevent mgcp_timeslot_to_endpoint from
returning an invalid endpoint index when called with arguments not
within its domain.
Addresses:
<000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0
[...]
vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256
max = 1
con = 0xb4a004f0
i = 0
j = 0
[...]
==15700== ERROR: AddressSanitizer: heap-use-after-free on address
0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c
Sponsored-by: On-Waves ehf
I omitted the check as this was already done by the verify
function for this command. Please Coverity and do the check
again even if it is not necessary. I begin to doubt the
usage of a "dedicated" verify method as well.
Silences: Coverity CID 1293150
On DT messages we directly write into the tracked SCCP
connection. This means "imsi" will always be NULL at
this check. Change the code to use con->imsi
Fixes: Coverity CID 1293151
We want to have a program add entries to the allow list
this can be done using:
$ bsc_control.py -d localhost -p 4250 -s net.0.add.allow.access-list.NAME "^IMSI$"
bsc_stat_reject is treating -1 as parsing failure but for the
global barring. Change it to another return value so it is
not counted as parsing failure.
We had issues with odd behavior on the nanoBTS which lead
to the introduction of the "broken" state. On busy multi
BTS cells (e.g. rhizomatica) with wifi backhaul the timeout
we set to wait for a RF Channe Release ACK is sometimes too
little and channels are marked broken that look to be okay
(besides the still to be determined delay).
In case of a sysmoBTS we now know that we can change the
state of a broken channel back to normal in case we do
receive the right response.
Manually verified using the Smalltalk BTS code
PackageLoader fileInPackage: 'FakeBTS'
bts := FakeBTS.BTS new.
bts btsId: '1903/0/0'.
bts connect: 'localhost'.
bts waitForBTSReady.
test := FakeBTS.OpenBSCTest new.
test bts: bts.
test requireAnyChannel
... wait for NITB output
<0004> abis_rsl.c:223 (bts=0,trx=0,ts=0,ss=0) Timeout during deactivation! Marked as broken.
... process pending messages
stdin next
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=0,ss=0) CHAN REL ACK for broken channel. Releasing it.
So the channel went from broken to unallocated.
Change the paging strategy based on on if a LAC override
is in place or not. In case we had changed the LAC we need
to page on all the BTS. Change the "grace" handling to
iterate over the BTS and filter out all non matching ones
LAC in case no LAC handling is active.
Manually verified all four cases with a single BTS:
* No LAC handling and grace period
* LAC handling and grace period
* No LAC handling and not lock
* LAC handling and lock.
Related: SYS#1398
For MT we can't page per lac as we don't know which BTS was
the original one. Split the grace period and normal mode into
two methods so we can bloat both of them later.
We need to use different LAC/CI towards the core network.
It is a bit problematic as LAC/CI is a per BTS attribute
so this feature only works if a BSC manages everything in
the same LAC.
Related: SYS#1398
The write_queue is designed to have a maximum amount of pending
messages and will refuse to take new messages when it has been
reached. The caller can decide if it wants to flush the queue
and add the message again, create a log. But in all cases the
ownership of the msgb has not been transferred. Fix the potential
memory leak in the failure situation.
When reading from RTP socket, the first read() may fail right after
connecting to remote socket. Subsequent read() will work as it should.
If the remote socket does not open fast enough, the transmitted RTP
payload can cause an ICMP (connection refused) packet reply. This causes
the read to fail with errno=111. In all other error cases, the errno is
logged at debug level. In all error cases, reading is not disabled.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Fix typo, stop reading in all cases but ECONNREFUSED]
If a bad TRAU frame is received, it is forwarded to MNCC application
as GSM_BAD_FRAME. The application can now handle the GAP of missing
audio. (e.g. by extrapolation)
If TRAU frames are forwarded via RTP, bad frames are dropped, but frame
counter and timestamp of RTP sender state is incremented.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Merge without testcase, fix typo]
In case:
* No message_payload and a 0 sm_length was used
* esm_class indicates UDH being present
* 7bit encoding was requested
The code would execute:
ud_len = *sms_msg + 1;
Which is a NULL pointer dereference and would lead
to a crash of the NITB. Enforce the limits of the
sm_length parameter and reject the messae otherwise.
Fixes: Coverity CID 1042373
I used strdup in case the data would not be valid from after
the call to getopt and this creates a potential leak if a user
is specifying multiple configuration files. If I depend on the
fact that the string is a pointer into the argv[] array I can
kill the strdup and fix the unlikely leak.
Fixes: Coverity CID 1206578
We are deferencing conn earlier in this function without doing
a null check. At the time deliver_to_esme is called the conn
will always exist and even the lchan is likely to be present.
Remove the null check for conn right now.
Fixes: Coverity CID 1210594
For most configurations we don't address multiple GGSNs but
only want to enforce a list of APNs. In the future we might
add a special global GGSN context but not right now.
Fixes: SYS#593
This reverts commit f81cacc681.
Since the PURGE MS retry mechanism had been removed, this feature
is not used anymore. It just makes the code more complex.
Conflicts:
openbsc/include/openbsc/gprs_sgsn.h
openbsc/src/gprs/gprs_subscriber.c
openbsc/tests/sgsn/sgsn_test.c
Currently the APN IE in the Activate PDP Contex Request and the PDP
data that is stored with the subscriber is ignored completely.
This commit adds the sgsn_mm_ctx_find_ggsn_ctx that checks the APN IE
against the subscriber's PDP data entries if both are present. If
there is no match, the request is rejected.
If an APN IE has not been included but PDP data entries are present,
the function checks all of these entries against the static 'apn'
configuration to find a suitable entry.
If an APN has not been determined so far and any APN is allowed, the
configuration is checked with an empty APN string, to allow for
default configurations based on the IMSI prefix only.
If nothing of this succeeded but the request wasn't rejected either,
and there is no 'apn' configuration at all or if any APN is allowed
but a default configuration ist not present, the GGSN with id 0 is
used (if present).
Otherwise the request is rejected ('missing APN').
Ticket: OW#1334
Sponsored-by: On-Waves ehf
This commit adds the exported functions apn_ctx_find_alloc,
apn_ctx_free, apn_ctx_by_name, and apn_ctx_match to manage and
retrieve APN to GGSN mappings.
The following VTY commands are added to 'config-sgsn':
- apn APN ggsn <0-255>
- apn APN imsi-prefix PREFIX ggsn <0-255>
which maps an APN gateway string to an SGSN id. The SGSN must be
configured in advance. When matching an APN string, entries with a
leading '*' are used for suffix matching, otherwise an exact match is
done. When a prefix is given, it is matched against the IMSI. If
several entries match, a longer matching IMSI prefix has precedence.
If there are several matching entries with the same PREFIX, the entry
with longest matching APN is returned.
Ticket: OW#1334
Sponsored-by: On-Waves ehf
Currently the PDP info that is transmitted via GSUP is just parsed
and then discarded.
This commit adds a new data structure sgsn_subscriber_pdp_data and
maintains a list of those in sgsn_subscriber_data. The PDP data is
copied from an incoming GSUP UpdateLocationResult message. If that
message contains the PDPInfoComplete flag, the list is cleared before
new entries are added. The 'show subscriber cache' output now also
shows the PDP data entries.
Note that the InsertSubscriberData message is still not supported.
[hfreyther: Added talloc_free in gprs_subscr_pdp_data_clear]
Sponsored-by: On-Waves ehf
Keep track if the power level has been "fixed" by the BSC,
otherwise keep track of the currently ordered one. The ms_power
is the initial value set by the BSC and continues to be used.
Create a control command to read and modify the gprs mode. Use
the get_string_value to indicate if the value was found or not.
This is useful for the ctrl interface where I didn't want to
replicate "none", "gprs" and "egprs". Share code to verify that
a BTS supports the mode.
Related: SYS#591
30f1f37638 introduced new channel
combinations but had a copy and paste error in the description.
The jenkins system didn't run the external tests so this issue
and others were not noticed until now.
Fix the copy and paste and update the test result.
Currently the MM context is not deleted when a GSUP location
cancellation message is processed, because the real
sgsn_update_subscriber_data function has been wrapped to a dummy
implementation.
This commit adds an explicit call to sgsn_mm_ctx_cleanup_free which
also unassigns the LLME, so the call to gprs_llgmm_assign is removed.
It also adds an assertion to check that there are no talloc'ed blocks
left in tall_bsc_ctx.
Addresses:
== 372 bytes in 1 blocks are possibly lost in loss record 7 of 9
== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
== by 0x4059FB8: _talloc_zero (talloc.c:354)
== by 0x8055B82: sgsn_mm_ctx_alloc (gprs_sgsn.c:167)
== by 0x804A336: alloc_mm_ctx (sgsn_test.c:140)
== by 0x804B24D: test_subscriber_gsup (sgsn_test.c:503)
== by 0x804EC99: main (sgsn_test.c:1853)
Sponsored-by: On-Waves ehf
This commit adds a check after a GSUP message has been decoded
whether it is an error message and does not contain a cause value.
If his is the case, the cause value is set to 'Network failure', so
that this cause if effectively the default value for error messages.
Sponsored-by: On-Waves ehf
Currently there are not any test cases for PurgeMS GSUP messages in
test_subscriber_gsup.
This commit adds tests for incoming PurgeMSResult and -Error
messages.
Sponsored-by: On-Waves ehf
Currently gprs_subscr_rx_gsup_message returns immediately after it
detects that an IMSI has not been given in the received GSUP message.
While this is ok for responses (result or error), a request should
always be answered.
This commit adds code to reply with a corresponding error message
("Invalid mandatory information") when it receives a request without
an IMSI.
Note that the generated error message will not contain an IMSI either.
Sponsored-by: On-Waves ehf
The cancellation type that is part of the UpdateCancellation message
is currently ignored.
This patch adds the missing glue between the existing GSUP and GMM
support. If the type is not present or has the value updateProcedure
the subcriber and MM context are siliently removed. Otherwise, a
message with cause 'implicitly detached' is sent to the MS. Since the
real cause is not known (the specification neither added a cause IE
nor defined a static cause value), the MS may get the real cause in
the following AttachRej.
Added VTY commands:
- update-subscriber imsi IMSI cancel update-procedure
- update-subscriber imsi IMSI cancel subscription-withdraw
the old form without the cause is no longer supported.
Sponsored-by: On-Waves ehf
Currently the subscr entry is no longer present, when PURGE MS
ERROR/RESULT arrives. In this case, an unspecific notice is logged
('unknown IMSI'). This clutters up the logfile with notices even in
perfectly normal operation.
This commit changes the code path that is used when a subscr cannot
be found for an incoming GSUP message. A check for PURGE MS RESULT
and ERROR is added and gprs_subscr_handle_gsup_purge_no_subscr is
called for these messages instead of gprs_subscr_handle_unknown_imsi.
Sponsored-by: On-Waves ehf
Currently the keep_in_ram flag is explicitely reset in
gprs_subscr_cleanup to cover the case, that the VTY 'create'
sub-command has been used to create the subscriber entry.
This commit completely removes keep_in_ram handling from
gprs_subscriber.c and adds a VTY 'destroy' sub-command to reset the
flag and remove the entry. So 'create' and 'destroy' can be used to
manager sticky entries that are kept even when a location
cancellation is done.
Added VTY command:
- update-subscriber imsi IMSI destroy
Sponsored-by: On-Waves ehf
Currently the MM context cleanup code is distributed over several
functions. sgsn_mm_ctx_free not only frees data structure but also
eventually stops the timer and does the subscriber clean-up.
mm_ctx_cleanup_free (gprs_gmm.c) cleans up the PDP contexts and
unassign the TLLI.
This commit moves the cleanup code from both functions into a new
unifying function sgsn_mm_ctx_cleanup_free that cares about the
clean-up of all related sub-systems.
Sponsored-by: On-Waves ehf
Currently, sgsn_update_subscriber_data can be called with mmctx ==
NULL and will find and associate the right context (if present) based
on the subscriber's IMSI. This will not happen in regular use
any more, since sgsn_update_subscriber_data will only be called when
subscribers are used (auth mode 'remote') and in this case
gprs_subscr_get_or_create_by_mmctx will already be called by
sgsn_auth_request. Therefore, MM context and subscriber are always
associated except for some test cases and experimental VTY usage.
The current implementation of sgsn_update_subscriber_data also causes
additional complexity for the deletion on MM contexts to avoid a
ipossible double-free MM contexts.
This commit removes the MM context <-> subscriber association code
from sgsn_update_subscriber_data. That function must always be called
with mmctx != NULL, now. To avoid problems with VTY and test usage,
the calling subscriber function now only call
sgsn_update_subscriber_data when mmctx != NULL, since the purpose of
that function is to update that state of an existing MM context after
subscriber data has been changed.
Sponsored-by: On-Waves ehf
The definition of subscr_put in gb_proxy_main.c will break linking if
symbols from libcommon are used. Since subscr_put is in libcommon,
there is no need for this dummy definition anymore.
This patch removes the dummy definition.
Adresses:
../../src/libcommon/libcommon.a(gsm_subscriber_base.o): In function `subscr_put':
/home/jerlbeck/git/build/openbsc/openbsc/src/libcommon/gsm_subscriber_base.c:90: multiple definition of `subscr_put'
gb_proxy_main.o:/home/jerlbeck/git/build/openbsc/openbsc/src/gprs/gb_proxy_main.c:56: first defined here
Sponsored-by: On-Waves ehf
Currently the sgsn_mm_ctx_free contains code to reset the mm->subscr
field that is also present in gprs_subscr_cleanup, which is called
directly afterwards.
This commit modifies the code path, so that the cleanup is done by
the gprs_subscr_cleanup function. The additional reference counter
increment is needed, since mm->subscr->mm->subscr (which is the same
like mm->subscr) will be reset (and unref'd) within
gprs_subscr_cleanup. Because the local variable subscr in
sgsn_mm_ctx_free is an additional pointer to the subscriber object,
it is consequent to adjust the reference counter when the assignment
is done.
Sponsored-by: On-Waves ehf
The old name is somewhat misleading. The function is rather preparing
the subscriber for a subsequent subscr_free, that is possibly invoked
by a subscr_put. It detaches the subscriber from the MM context and
optionally invokes a PURGE_MS procedure. Therefore the _cleanup
suffix is chosen (see mm_ctx_cleanup_free).
Sponsored-by: On-Waves ehf
Currently, the return value of gsup_client_connect is checked whether
it is < 0 and != -EINPROGESS. Since gsup_client_connect will only
return a negative value on a few permanent errors (not including
EINPROGRESS), rc is always != EINPROGRESS.
This patch removes the explicit check againt -EINPROGRESS and just
leaves the check rc < 0.
Sponsored-by: On-Waves ehf
Currently the size argument of strncpy is set to sizeof(mm->imsi) in
some places. If the source IMSI string is too long, the terminating
NUL byte in the static mm->imsi field gets overwritten.
This patch limits the size to sizeof(mm->imsi)-1, so that the last
byte of the buffer (that has been initialized to 0) is not
overwritten.
Fixes: Coverity CID 12065751, 12065754, 1206575
Sponsored-by: On-Waves ehf
Currently gprs_subscr_delete implicitely calls subscr_put, which
makes the code more complex than necessary (additional subscr_get) in
a few places. It also makes it more difficult to see, whether get/put
are balanced within a function. In addition, the functions are not
named consistently (gprs_subscr_delete vs.
gprs_subscr_put_and_cancel).
This commit changes the semantics of gprs_subscr_delete and
indirectly of gprs_subscr_put_and_cancel to not call subscr_put on
their argument, but to leave that for the caller to do it
explicitely.
It renames gprs_subscr_put_and_cancel to gprs_subscr_cancel to
reflect that change in the name, too.
Sponsored-by: On-Waves ehf
The subscriber cache would help in case:
* GPRS DETACH, GPRS ATTACH. In that case we might still
have some cached authentication tuples we avoid another
sendAuthenticationInfo request.
* After a detach the cache expiry would make sure to
eventually send a purgeMS to the HLR (which might be
ignored).
At the same time to make the cache work we will need to
make sure to start and stop timers. In case we don't
start we might accumulate subscribers. I am afraid that
the above two benefits do not outweight the complexity
of this implementation.
Currently old LLMEs and MM contexts that haven't been explicitly
detached or cancelled are not removed until another request with the
same IMSI is made. These stale entries may accumulate over time and
severely compromise the operation of the SGSN.
This patch implements age based LLME expiry, when the maximum age has
been reached, the corresponding MM context is cancelled. If such an MM
context doesn't exist, the LLME is unassigned directly.
The implementation works as follows.
- llme->age_timestamp is reset on each received PTP LLC message
- sgsn_llme_check_cb is invoked periodically (each 30s)
- sgsn_llme_check_cb sets the age_timestamp to the current time if
it has been reset
- sgsn_llme_check_cb computes the age and expires the LLME if
it exceeds gprs_max_time_to_idle()
Ticket: OW#1364
Sponsored-by: On-Waves ehf
[hfreyther: Fix typo in comment LMME -> LLME]
Currently the T3312 timer is directly set as encoded value when
generating the Attach/RAU Accept messages.
This patch adds GSM0408_T3312_SECS and uses it to set the
information element's value.
Sponsored-by: On-Waves ehf
Currently this optional IE is omitted, so that the optional
'Requested READY timer value' of the corresponding Request message
is used by the MS (or the default value if this IE is not used).
This patch extends gsm48_tx_gmm_att_ack and gsm48_tx_gmm_ra_upd_ack
to always include the IE set to the default value of T3312 (44s,
see GSM 04.08, table 11.4a).
Ticket: OW#1364
Sponsored-by: On-Waves ehf
Currently, all GPRS timer values are hard-coded. To make these values
configurable in seconds and to show them, conversion functions from
and to seconds are needed.
This patch adds gprs_tmr_to_secs and gprs_secs_to_tmr_floor. Due to
the limited number of bits used to encode GPRS timer values, only a
few durations can be represented. gprs_secs_to_tmr_floor therefore
always returns the timer value that represents either the exact
number (if an exact representation exists) or the next lower number
for that an exact representation exists.
Sponsored-by: On-Waves ehf
Currently the gsup_client_connect return 0 if the call to
ipa_client_conn_open was successful and -errno otherwise. This makes
it difficult for the caller to determine, whether the the whole
operation has been cancelled (currently on EBADF, ENOTSOCK,
EAFNOSUPPORT, EINVAL) or whether the GSUP client will retry to
connect after a timeout. This will cause gprs_gsup_client_create to
destroy the GSUP client object, even if the error might be temporary.
This patch changes the function to return 0 if (and only if)
ipa_client_conn_open was successful or the retry timer has been
started. Since the return value 0 doesn't guarantee, that a
subsequent call to gprs_gsup_client_send will succeed, this shouldn't
break anything.
Sponsored-by: On-Waves ehf
The per BSC code didn't guard against the init already having
been executed. This lead to:
Adding a osmo_fd that is already in the list.
<000b> bsc_nat_vty.c:1200 Setting up OSMUX socket
So a new socket got created and the old one leaked. Luckily
Linux appears to allow to bind multiple times so we were able
to just read from the new one. Use the same guard that is used
on the MGCP MGW. Re-order the log message to say "Setting up"
before we actually do that. I manually verified that osmux_init
is called at most once.
The log message was spotted by Roch
The dependecies do not match the current package names or are
missing:
Build-Depends:
- renamed libgtp-dev -> libgtp0-dev
- added libosmo-netif-dev
Depends:
- renamed libgtp -> libgtp0
Other run time dependencies might still be missing and have to be
installed manually.
This is taken from Holger's e744ebd17c3761b5cad81d718d0349f2f820ec66.
In addition, the build-dependency on libgtp-dev is replaced by
libgtp0-dev.
This patch drops the following commands:
- update-subscriber imsi IMSI insert authorized <0-1>
- update-subscriber imsi IMSI commit
since they are already covered by the 'update-location-result'
sub-command, except that this command doesn't create an new entry if
none is found with the given IMSI.
It adds the following command:
- update-subscriber imsi IMSI create
which can be used to create a new entry.
Sponsored-by: On-Waves ehf
Currently '\n' is used to end lines in the VTY output string
constants instead of inserting VTY_NEWLINE. This leads to incorrect
line starts in error messages.
This patch fixes that accordingly.
Sponsored-by: On-Waves ehf
Currently an error_cause of 0 is being used to indicate normal
operation. Albeit this is not a defined GMM cause, the value is not
explicitly reserved.
This commit adds the macro SGSN_ERROR_CAUSE_NONE and uses it for
initialisation (instead of relying on talloc_zero) and comparisons.
The value is set to -1 to be on the safe side. The VTY code is
updated to set the error_cause when using the
'update-subscriber imsi IMSI update-location-result CAUSE' command.
Sponsored-by: On-Waves ehf
Currently the access to subscr->sgsn_data->error_cause is not
protected against subscr == NULL like it is done in other code paths
of sgsn_auth_update.
This commit adds a conditional to avoid a NULL-dereference.
Fixes: Coverity CID 1264589
Sponsored-by: On-Waves ehf
Currently, if assert_subscr were called with subscr == NULL, the
later call to subscr_put might fail, as Coverity has complained. In
addition, the call to subscr_put would free the subscr object if it
were in the cache with a refcount of 0 at the time assert_substr was
called.
This patch adds a check for the subscr being non-NULL and reorders
the checks, so that the subscr_put comes last.
Fixes: Coverity CID 1264590
Sponsored-by: On-Waves ehf
Currently sgsn_alloc_ptmsi uses rand() to get a new P-TMSI and then
sets to upper 2 MSB. Therefore there is no lower limit of the
distance between 2 identical P-TMSI.
This patch changes the implementation to discard any random value
above 2^30 and to generate a new random number in that case until a
fitting number is found (or a repetition limit is reached). This way,
all number below 2^30 within the PRNG's period are used.
Ticket: OW#1362
Sponsored-by: On-Waves ehf
Currently no GSUP LocationCancellationResult message is sent back to
the peer (HLR), if the procedure succeeded at the SGSN's side.
This patch adds the missing message and put the whole request
handling of this procedure into a separate function.
Ticket: OW#1338
Sponsored-by: On-Waves ehf
Currently gprs_subscr_rx_gsup_message creates a subscriber entry if
such an entry doesn't exist for the IMSI within an
InsertSubscriberData GSUP message. This behaviour is not compliant to
GSM 09.02, 20.3.3.2 (Subscriber data management/SGSN) where it is
defined, that an error ("Unidentified subscriber") shall be returned.
This patch removes the case distinction, so that an existing
subscriber entry is required for all incoming GSUP messages.
Sponsored-by: On-Waves ehf
Currently, an incoming GSUP request message isn't answered at all if
it is not handled due to an error or missing implementation.
This patch adds GSUP error replies for these requests (and only for
requests). It also adds tests for these cases.
Note that several of these tests check for
GMM_CAUSE_MSGT_NOTEXIST_NOTIMPL, which will have to be changed, when
the features are implemented.
Sponsored-by: On-Waves ehf
GSM 09.02, 19.4.1.4 mandates that no other MAP procedures shall be
started until the PURGE_MS procedure has been completed.
This patch implements this by adding corresponding state and checks
to gprs_subscr_purge, gprs_subscr_location_update, and
gprs_subscr_update_auth_info. If an Update Location or a Send Auth
Info Req procedure is not started because of blocking, the retry
mechanism is aborted to shorten the blocking time. The outstanding
Purge MS procedure itself is not aborted.
Sponsored-by: On-Waves ehf
Currently, when the PURGE_MS_REQ to the HLR gets lost (e.g. by a
connection or peer failure), the expired subscriber entry will not get
deleted.
This commit adds a retry mechanism then restarts the procedure after
a timeout (currently 10s). The maximum number of retries is limited
(currently to 3 PURGE_MS messages). If none of these procedures is
completed (either with success or error), the subscriber data is
deleted.
Sponsored-by: On-Waves ehf
When a subscriber entry is going to be deleted by SGSN and when the
subscriber info has been obtained from a remote peer via GSUP, the
peer should be informed before the entry is really deleted. For this
purpose, MAP defines the PURGE MS procedure (see GSM 09.02, 19.1.4).
This patch adds support for the PURGE_MS_REQ/_ERR/_RES messages and
invokes the procedure when the subscriber entry is going to be
removed. This only applies if GSUP is being used, the Update
Location procedure has been completed successfully, and the
subscriber has not been cancelled. The removal of the entry is
delayed until a PURGE_MS_RES or PURGE_MS_ERR message is received.
Note that GSM 09.02, 19.1.4.4 implies that the subscriber data is not
to be removed when the procedure fails which is not the way the
feature has been implemented.
Note that handling 'P-TMSI freezing' is not implemented.
Ticket: OW#1338
Sponsored-by: On-Waves ehf
This commit implements the encoding and decoding of the messages
- Purge MS Request
- Purge MS Error
- Purge MS Result
and adds corresponding tests.
Sponsored-by: On-Waves ehf
Currently the definitions of the message PURGE_MS_RES and
PURGE_MS_ERR are missing in the specification.
This patch adds those definitions.
Sponsored-by: On-Waves ehf
This commit adds talloc reports to log remaining NULL chunks after the
terminates. It also adds explicit checks for empty subscriber lists.
Sponsored-by: On-Waves ehf
This test replaces gprs_gsup_client_send by a custom function, that
emulates a GSUP remote peer by calling gprs_subscr_rx_gsup_message
with responses for all requests. It then executes a full
Attach/Detach cycle.
Sponsored-by: On-Waves ehf
Set the expiry delay after the subscriber has been deleted (e.g. by
freeing the MM context). If cancelled, the subscriber will be deleted
immediately and no timeout will be set. If the expiry time is set to
SGSN_TIMEOUT_NEVER, no timer will be started and the subscriber entry
will be kept until it is cancelled.
The following VTY command is added to the sgsn node:
- subscriber-expiry-time <0-999999> set expiry time in seconds
- no subscriber-expiry-time set to SGSN_TIMEOUT_NEVER
The default is an expiry time of 0 seconds, which means that the
subscriber entries are wiped out immediately after an MM context is
destroyed.
Note that unused MM contexts are not expired yet. Therefore the
subscriber will only be expired after a successful MM detach.
Sponsored-by: On-Waves ehf
The code sequence that checks, whether a subscriber is still
reachable for a given IMSI, is repeated several times.
This patch puts this code sequence into a single function and adds a
check for the IMSI after the entry has been found. In addition,
some comments are extended.
Sponsored-by: On-Waves ehf
Currently the subscribers are not really deleted by
cleanup_subscr_by_imsi, but kept in RAM instead.
This patch fixes this and adds a test to verify, that the subscriber
is really deleted afterwards.
Sponsored-by: On-Waves ehf
Currently the error causes MSC_TEMP_NOTREACH, NET_FAIL, and
CONGESTION are silently dropped to force the MS to continue. On the
other hand, GSM 04.08/24.008, 4.7.3.1.4 in combination with 4.7.3.1.5,
require the MS to retry the attachment procedure for cause codes
above 15 instead of disabling GPRS. All of the mentioned GMM causes
have codes above 15, so using a REJECT message including the cause
code is a better choice. This way, the retry algorithm based on T3311
(15s, 5 times) and T3302 (default 12min) could be used.
This patch modifies gprs_subscr_handle_gsup_auth_err and
gprs_subscr_handle_gsup_upd_loc_err to proceed like when the access
has beed denied, except that the corresponding subscriber's
information fields are not cleared.
This has been successfully tested which an iphone which enters a
retry loop as it is being described in the specification.
Sponsored-by: On-Waves ehf
To unify the layout of the logging messages in gprs_subscriber.c,
this patch replaces each LOGP by LOGGSUBSCRP, unless a non-NULL
pointer to a subscr is not available. In those cases, it uses
LOGMMCTXP if a pointer to an MM context is available or LOGP
otherwise.
Sponsored-by: On-Waves ehf
This patch adds a new logging macro, that logs to DGPRS and provides
a uniform prefix containing the IMSI without using the mm reference.
This is an improvement over using LOGMMCTXP, since the new macro also
provides an IMSI if no MM context is attached.
Sponsored-by: On-Waves ehf
Currently the GSUP message handling function in gprs_subscriber.c and
the functions in gprs_gsup_messages.c are not consistent with respect
to the return codes if an error happens. Albeit all error return
codes are negative, the semantics of the absolute value are not
clearly defined. In addition, some return codes are not passed to the
calling function.
This path changes these functions to always return a negated GMM
cause value in case of errors. Return values of called parser
functions are not longer ignored.
Sponsored-by: On-Waves ehf
Currently always a cause with the meaning of 'access denied' is
assumed. gprs_subscr_handle_gsup_auth_err just clears the auth
triplets and the authorized flag before calling the update function.
gprs_subscr_handle_gsup_upd_loc_err only clears the authorized flag
and calls the update function. This means, that an MS will not retry
to attach even on temporary network errors.
This patch changes these functions to use the GSUP error cause value
to decide, whether to clear the corresponding subscriber fields, to
just continue with the corresponding update function, or to log,
ignore and not pass the cause to the MS in case the error is directly
related to the GSUP protocol. The subscriber's error_cause field is
updated, if the update function is going to be called. The
error_cause fielt is reset on non-error GSUP messages.
Sponsored-by: On-Waves ehf
This patch extends gsm0408_gprs_access_denied and
gsm0408_gprs_access_cancelled to accept GMM cause codes. These are
then passed to the MS, unless gsm0408_gprs_access_cancelled is called
with cause 0 (no error -> updateProcedure).
Since gsm0408_gprs_access_denied uses GMM_CAUSE_GPRS_NOTALLOWED if
the cause is not set, and the subscriber's error_cause is never set
(and thus always 0), the SGSN's behaviour does not change with this
patch.
Sponsored-by: On-Waves ehf
Conflicts:
openbsc/include/openbsc/gprs_sgsn.h
[hfreyther: Conflict due the removal of the unused
authenticate flag]
Currently the mapping between GSM 04.08 (GPRS) protocol specific
numbers and their textual description was put into gprs_gmm.c and not
exported.
This commit moves the mappings to a new file gsm_04_08_gprs.c,
renames some of them, and exports them via gsm_04_08_gprs.h.
The following identifiers are renamed to match the corresponding type
names:
- gmm_cause_names -> gsm48_gmm_cause_names
- gsm_cause_names -> gsm48_gsm_cause_names
Sponsored-by: On-Waves ehf
This commit adds a line to the output of 'show sgsn' if the GSUP
client has been initialized:
- Remote authorization: [not] connected to HOST:PORT via GSUP
Sponsored-by: On-Waves ehf
Currently, the reconnect mechanism relies on gsup_client_updown_cb
which in turn gets called based on the OS' view of connection state.
This patch adds a timer based PING mechanism that regularly sends
PING messages and forces a reconnect if a PONG message won't be
received until the next PING message is scheduled. The current ping
interval is 20s.
Sponsored-by: On-Waves ehf
Conflicts:
openbsc/src/gprs/gprs_gsup_client.c
[hfreyther: Conflicts due the potential memleak fix by me. Removed
another TODO from the code as we stop the ping/pong timer]
Currently the IPA CCM messages are not handled by the GSUP client.
This means, that the client doesn't answer to PING and ID_GET and
logs notices when receiving PONG or ID_ACK. At least the PING
functionality (remotely originated PING) shall be supported.
This patch extends gsup_client_read_cb by a call to
ipaccess_bts_handle_ccm. Only when the return code is 0, the message
is processed further and checked for an OSMO/GSUP message. ID_GET
messages are answered by a dummy description, where only the
unit_name is set to 'SGSN'.
Sponsored-by: On-Waves ehf
The ipa_client_conn_open function does not distinguish between a
connection being already established or waiting for establishment.
In either case, the application gets informed about the connection
state via the updown_cb. The 'up' parameter is only set, if
poll/select consider the socket as writable.
This patch handles both cases equally and fully relies on the
updown_cb to adjust the gsupc obejct state.
Sponsored-by: On-Waves ehf
Currently, messages are added to the tx queue even if the connection
is down for some reason and all of these messages are eventually sent
after a re-connect. The MS has probably sent several Attach Requests
while the connection was down and will continue doing so. Therefore
these stored messages could be dropped.
This patch clears the queue before re-connecting and also extends
gprs_gsup_client_send to return immediately, when the connection is
not established instead of calling ipa_client_conn_send.
Sponsored-by: On-Waves ehf
[hfreyther: Replaced
while (!llist_empty(&gsupc->link->tx_queue))
llist_del(gsupc->link->tx_queue.next);
with new libosmo-abis API]
Currently the GSUP connection to a server is not restarted if the
connection cannot be established or is terminated during operation.
This commit adds a timer based connection mechanism, basically
consisting of a timer callback that calls gsup_client_connect. The
timer is eventually triggered (up == 0) or cleared (up != 0) by
gsup_client_updown_cb. It adds calls to osmo_timer_del() to
gsup_client_connect and gprs_gsup_client_destroy. The latter is now
called instead of talloc_free in gprs_gsup_client_create on error to
be on the safe side.
Sponsored-by: On-Waves ehf
This patch extends test_gmm_attach to optionally resend Attach
Requests until the SGSN responds to it instead of calling
OSMO_ASSERT at a few places. The test_gmm_attach_subscr_gsup_auth
test optionally uses this feature. It is called once in either mode.
Sponsored-by: On-Waves ehf
This test calls test_gmm_attach() where the mocked subscriber
functions insert GSUP messages instead of manipulating the
subscriber structure directly.
Sponsored-by: On-Waves ehf
Currently, several lines of boiler plate are needed around a call to
gprs_subscr_rx_gsup_message.
This patch puts all of this (including the call to
gprs_subscr_rx_gsup_message) into a separate function.
Sponsored-by: On-Waves ehf
This flag is used to determine, whether the Update Location procedure
shall be invoked. This is currently only set, when the 'remote'
authorization policy is set. When the flag is set, sgsn_auth_update
will not never be called directly by sgsn_auth_request, if an Attach
Request procedure is pending, even if the remote connection fails for
some reason.
Sponsored-by: On-Waves ehf
Currently the flag 'authenticate' is managed per subscriber.
This patch replaces that flag by a global cfg.require_authentication
flag that enables/disables the use of the Auth & Ciph procedure for
every subscriber. The flag is set by the VTY, if and only if the
authorization policy is 'remote'.
The VTY command
- update-subscriber imsi IMSI insert authenticate <0-1>
is removed.
Sponsored-by: On-Waves ehf
This commit adds GSUP client configuration (via VTY), connection set
up, and real message sending.
The following configuration commands are added:
- gsup remote-ip A.B.C.D set server IP address
- gsup remote-port PORT set server TCP port
Ticket: OW#1338
Sponsored-by: On-Waves ehf
This commit adds the client code to get subscriber information from a
remote server. It provides an IPA over TCP connection to transmit and
receive GSUP messages.
Sponsored-by: On-Waves ehf
Currently the message structure is not cleared before the message is
parsed which can cause information leaking between messages if the
same gprs_gsup_message object is used. Especially list elements (auth
tuples and pdp info) are not replaced by an IE, but the IE is
appended.
This patch uses the assignment operator to clear gprs_gsup_message,
gsm_auth_tuple, and gprs_gsup_pdp_info before using them. This also
replaces the use of memcpy of the latter.
Sponsored-by: On-Waves ehf
Currently auth tuples are always appended to the lists when
gprs_gsup_decode is called with a gsup_msg structure. This makes a
test case fail, where the same gsup_msg is used again and again
without clearing it after each use.
Sponsored-by: On-Waves ehf
Currently, the gprs_gsup_decode function doesn't check the return
value of gprs_shift_v_fixed before using the value pointer. The
function fails, if the GSUP message length (not including IPA
headers) is 0. In this case, a segfault can happen, depending on the
value of the uninitialized 'value' pointer. The test case doesn't
trigger a segfault, but valgrind complains about reading
uninitialized data.
This patch adds a check for the return value that would return with
an error code if the shift function failed.
Sponsored-by: On-Waves ehf
Currently, the tests only use valid GSUP messages. This does not
check the robustness of the parser.
This commit adds a test for truncated messages and another for
modified messages.
Thanks to Holger for the basic truncation test.
Sponsored-by: On-Waves ehf
Currently the mocked bssgp_tx_dl_ud function used for testing in
sgsn_test.c does not free the msg as it is done by the original
function. This leads to a msgb leak in the test.
This patch fixes the test code accordingly and uncomments the
assertion that checks for left-over msgbs.
Sponsored-by: On-Waves ehf
This commit adds talloc reports to log remaining chunks after the
testing has been finished. It also adds a (currently disabled) check,
that no msgbs are allocated after running the tests.
Sponsored-by: On-Waves ehf
This patch extends gprs_subscr_query_auth_info and
gprs_subscr_location_update to create GSUP messages with the help of
a static gprs_subscr_tx_gsup_message function. A corresponding
gprs_subscr_rx_gsup_message is added which takes a messages, gets the
subscr, and updates it accordingly.
Sponsored-by: On-Waves ehf
[hfreyther: Added a msgb_free gprs_subscr_tx_gsup_message]
This patch adds functions to encode and decode GSUP messages. This
does not include the layer 1 framing (IPA). The messages so far
supported are: send_auth_info_*, update_location_*,
location_cancellation_*.
Sponsored-by: On-Waves ehf
Currently the result of the osmo_hexparse function in
update_subscr_insert_auth_triplet is not handled correctly. There is
a misplaced leading exclamation mark in a few conditional
expressions. This effectively disables the error checks, as it is
noticed by Coverity ("Missing parentheses" followed by "Logically
dead code").
This patch removes the exclamation marks.
Fixes: Coverity CID 1260435 and CID 1260434
Sponsored-by: On-Waves ehf
The code assumes that sqlite3.h is in the standard include
path. Maybe sqlite3 wasn't installed or resides in a non
standard (/usr/local) location? Fix the build as it has been
broken since 1st of January.
This is a normal situation under high load: The BTS is out of resources
and the BSC cannot allocate any dedicated channel. We may send an IMM
ASS REJECT back to the MS. All well within normal parameters, not an
error that needs to be reported back to the caller, who propagates it
all the way up to libosmo-abis.
Move the "logging filter imsi IMSI" into the BTS/NITB code to
allow to set the gsm_subscriber and only compare it. This way
we simply compare the subscriber address and don't have to care
if the subscriber data is still valid.
Most of the "fixes" have nothing to do with gcc-4.9.2 but are a
question of ABI/Architecture (e.g. x86 vs. AMD64). Revert these
for now.
This partially reverts commit 7b1d25a11e.
abis_test.c: In function ‘test_simple_sw_config’:
abis_test.c:68:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[0].start - simple_config, descr[0].len);
^
abis_test.c: In function ‘test_dual_sw_config’:
abis_test.c:111:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[0].start - dual_config, descr[0].len);
^
abis_test.c:115:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[1].start - dual_config, descr[1].len);
^
abis_test.c: In function ‘test_sw_selection’:
abis_test.c:132:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[0].start - load_config, descr[0].len);
^
abis_test.c:136:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[1].start - load_config, descr[1].len);
I'm merging this code, as it is proven to be very useful. The only
reason to keep it out of master was the fact that the UDP data
structures it sends are non-portable, so you can only run it reliably on
localhost or between identical systems (hardware/compiler/os).
As this hasn't been fixed in the past >= 2 years, I am merging the code
now anyway. We can still introduce a portable protocol by increasing
the protocol version at a later point.
There are two options:
a) we make 'struct gsm_meas_rep' portable. This requires an ABI
change with libosmocore, as it contains struct gsm_meas_rep_unidir :(
b) we introduce a completely separate wire format with corresponding
encoding and decoding functions.
In fact, the DB write code has been split out so we could later also
have a binary that would listen to realtime meas_feed packets and stuff
them into a database without any intermediate PCAP step.
The database schema contains a couple of convenience wrapper views, most
notably the "overview" view.
This extends osmo_nitb to offer a UDP feed of real-time measurement
reports, which can be used by (a variety of) external tools for
visualization or other processing.
We also add a small ncurses based tool (meas_vis) which shows a
baragraph display of the last few mobile stations that were active,
indicating their uplink/downlink receive level and quality.
<WARNING>
This sends non-portable structures like gsm_meas_rep over UDP
and assumes the receiver has identical alignment and endianness! Before
this feature is merged, it either needs to be converted to a unix domain
socket (but they don't do multicast, which would be nice) or the wire
format needs to change into something portable with defined alignment
and encoding
</WARNING>
The idea of ts_alloc()/ts_free() dates back to the very early days of
OpenBSC, where we didn't yet have a fixed PCHAN type assigned for every
lchan in a BTS. However, ever since, PCHAN types (channel combinations)
are configured by OML in a certain way, and we only allocate LCHANs
inside PCHANs of a matching type. There should be no PCHANs with
type GSM_PCHAN_NONE, unless those that you don't want to use for
administraive reasons or the like.
show net with an CCCH+SDCCH/4+CBCH channel active caused bts_chan_load to read
from invalid memory. Fix this by making sure the pchan array is large enough.
==30346==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff9bdc5dc8 at pc 0x5aeece bp 0x7fff9bdc5350 sp 0x7fff9bdc5348
READ of size 4 at 0x7fff9bdc5dc8 thread T0
#0 0x5aeecd in bts_chan_load /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/chan_alloc.c:490
#1 0x5af706 in network_chan_load /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/chan_alloc.c:511
#2 0x4b7410 in net_dump_vty /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bsc_vty.c:208
#3 0x4b5f23 in show_net /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bsc_vty.c:227
#4 0x7fdabaa425bd in cmd_execute_command_real /home/alphaone/scm/osmo/libosmocore/src/vty/command.c:2042
#5 0x7fdabaa3f124 in cmd_execute_command /home/alphaone/scm/osmo/libosmocore/src/vty/command.c:2077
#6 0x7fdabaa850e9 in vty_command /home/alphaone/scm/osmo/libosmocore/src/vty/vty.c:402
#7 0x7fdabaa75962 in vty_execute /home/alphaone/scm/osmo/libosmocore/src/vty/vty.c:666
#8 0x7fdabaa6d947 in vty_read /home/alphaone/scm/osmo/libosmocore/src/vty/vty.c:1408
#9 0x7fdabaa9165f in client_data /home/alphaone/scm/osmo/libosmocore/src/vty/telnet_interface.c:119
#10 0x7fdaba7860b6 in osmo_select_main /home/alphaone/scm/osmo/libosmocore/src/select.c:160
#11 0x43c656 in main /home/alphaone/scm/osmo/openbsc/openbsc/src/osmo-nitb/bsc_hack.c:355
#12 0x7fdab92604bc (/lib64/libc.so.6+0x224bc)
#13 0x43b6cc (/home/alphaone/local/osmo-asan/bin/osmo-nitb+0x43b6cc)
Address 0x7fff9bdc5dc8 is located in stack of thread T0 at offset 232 in frame
#0 0x4b5faf in net_dump_vty /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bsc_vty.c:182
This frame has 3 object(s):
[32, 40) ''
[96, 104) ''
[160, 224) 'pl'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/chan_alloc.c:490 bts_chan_load
==25637==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff3f587c43 at pc 0x5bf591 bp 0x7fff3f587630 sp 0x7fff3f587628
READ of size 4 at 0x7fff3f587c43 thread T0
#0 0x5bf590 in tv_fixed_put /home/alphaone/local/osmo-asan/include/osmocom/gsm/tlv.h:237
#1 0x5b7e14 in generate_si4 /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/system_information.c:607
#2 0x5b488b in gsm_generate_si /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/system_information.c:882
#3 0x4cb247 in gsm_bts_trx_set_system_infos /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bsc_init.c:166
#4 0x4d3c26 in bootstrap_rsl /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bsc_init.c:272
#5 0x4ced44 in inp_sig_cb /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bsc_init.c:316
#6 0x7f4f15b563d7 in osmo_signal_dispatch /home/alphaone/scm/osmo/libosmocore/src/signal.c:105
#7 0x7f4f156c0e3f in e1inp_int_snd_event (/home/alphaone/local/osmo-asan/lib/libosmoabis.so.4+0x17e3f)
#8 0x7f4f156be7e5 in e1inp_event (/home/alphaone/local/osmo-asan/lib/libosmoabis.so.4+0x157e5)
#9 0x583a6a in ipaccess_sign_link /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/bts_ipaccess_nanobts.c:675
#10 0x7f4f156e63b0 in handle_ts1_read (/home/alphaone/local/osmo-asan/lib/libosmoabis.so.4+0x3d3b0)
#11 0x7f4f156e4f4e in ipaccess_fd_cb (/home/alphaone/local/osmo-asan/lib/libosmoabis.so.4+0x3bf4e)
#12 0x7f4f15b540b6 in osmo_select_main /home/alphaone/scm/osmo/libosmocore/src/select.c:160
#13 0x43c656 in main /home/alphaone/scm/osmo/openbsc/openbsc/src/osmo-nitb/bsc_hack.c:355
#14 0x7f4f1462e4bc (/lib64/libc.so.6+0x224bc)
#15 0x43b6cc (/home/alphaone/local/osmo-asan/bin/osmo-nitb+0x43b6cc)
Address 0x7fff3f587c43 is located in stack of thread T0 at offset 483 in frame
#0 0x5b712f in generate_si4 /home/alphaone/scm/osmo/openbsc/openbsc/src/libbsc/system_information.c:580
This frame has 8 object(s):
[32, 40) ''
[96, 104) ''
[160, 164) 'rc'
[224, 232) 'si4'
[288, 296) 'cbch_lchan'
[352, 360) 'restoct'
[416, 420) 'l2_plen'
[480, 483) 'cd'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/alphaone/local/osmo-asan/include/osmocom/gsm/tlv.h:237 tv_fixed_put
We can now configure the pyisical channel types for CBCH either in the
CCCH+SDCCH4 or in the SDCCH8 chanel combination.
Depending on whether a CBCH exists on the BTS, we also generate the SI4
with matching CBCH channel description to notify the phones of the
existance of the CBCH.
There is now a VTY command how a SMS-CB message can be sent to a given
BTS.
We do not yet have any logic at all for actual scheduling of multiple
CBCH RSL messages towards one or multiple BTSs yet, though.
We tend to comment out this code every XXC3, let's just get rid
off it. The nanoBTS has a rather odd timing behavior. Jacob has
spent hours this summer to trial/document/fix it in the MGCP code
and this code is not getting close to working around the ip.access
audio issues.
If someobody still wants to use the nanoBTS then he should help
to have the MGCP MGW use/share code with the rtp_proxy.c
This implements the MAP way of subscriber validation when the MS
tries to perform an Attach Request:
1. perform authentication (optionally invoke the sendAuthInfo
procedure), starts the Auth & Ciph procedure
2. perform update location
3. insert subscriber data
4. finish the update location
5. Attach Accept / Attach Reject
The authentication triplets are used and eventually updated if all of
them have been used.
This is currently accessible via the VTY interface by the following
commands:
- update-subscriber imsi IMSI update-auth-info
- update-subscriber imsi IMSI update-location-result (ok|ERR-CAUSE)
Sponsored-by: On-Waves ehf
This commit add data structures, functions, initialization, and VTY
commands for per subscriber authentication triplets.
The following VTY command is added:
- update-subscriber imsi IMSI \
insert auth-triplet <1-5> sres SRES rand RAND kc KC
Note that the triplets are not really used by the SGSN yet.
Sponsored-by: On-Waves ehf
Currently, when a BSSGP SUSPEND is received and the corresponding MM
context is already in the state GMM_REGISTERED_SUSPENDED, a
SUSPEND_NACK is returned which is not covered by GSM 08.18, 7.4.1.
The same goes for RESUME in the state GMM_REGISTERED_NORMAL.
This commit changes gprs_gmm_rx_suspend and gprs_gmm_rx_resume to not
complain (and thus answer a NACK) when the MM context is either in
GMM_REGISTERED_SUSPENDED or GMM_REGISTERED_NORMAL.
Note that GSM 08.18, 7.4.1 and 7.5.1 only mention to send an NACK if
the MS is not known. Even with this patch, the SGSN returns a NACK if
either the MS is unknown _or_ the MM context ist not in one of the
state GMM_REGISTERED_SUSPENDED and GMM_REGISTERED_NORMAL.
Sponsored-by: On-Waves ehf
Currently the parser functions for single information elements are
defined within gprs_gb_parse.c and not exported explicitely. In
addition they are named like libosmocore's TLV parser functions and
do not have a proper name prefix. Since it is planned to use them for
other protocols, they need to be globally accessible.
This patch moves them to gprs_utils.c and renames them.
The new names are:
lv_shift -> gprs_shift_lv
v_fixed_shift -> gprs_shift_v_fixed
lv_shift -> gprs_shift_lv
v_fixed_shift -> gprs_shift_v_fixed
In the long term, these functions should be moved to libosmocore (and
renamed again).
Sponsored-by: On-Waves ehf
The new lchan will be in speech mode already but for AMR we will
need to provide a working multirate config in the channel activation,
otherwise the channel act might be nacked.
Copy the config from the current lchan into the new lchan. The
abis code simply added the mrconf if the speech mode was amr.
Before this commit the invalidate mrconf with all zeroes was
copied/sent.
In case of a ho_chan_activ_nack (sent due another bug inside
both sysmobts and openbsc) the code would not stop the timer
but free the datastructure. This can lead to a clear segfault
when the timer has expired. Create a "free" function which is
responsible to detach the handover structure, stop the timer
(which is idempotent) and free the structure.
In case a BTS is dropped, iterate over the list of BTS and check
if a dependency is now missing and then drop the BTS. This check
could lead to check of 256*256 checks (e.g. all BTS on each other
in the chain and the master is being dropped). The performance
aspect of it doesn't matter for our usecase. We expect to have
pairs of BTS right now.
E.g. for the sysmoBTS2050 we have the requirement that the first
board connects before the second due clocking. The easiest point
to enforce this is the BSC. Add a simple bitmask based system to
allow to express dependencies for IP based systems.
This commit mainly extends sgsn_auth.c to use and support the
auth_state SGSN_AUTH_AUTHENTICATE. It will be activated when IMSI and
IMEI are available, authentication is required
(subscr->sgsn_data->authenticate is set), but the MM context is not
marked as authenticated. If the state has been set to
SGSN_AUTH_AUTHENTICATE and sgsn_auth_update() is called, the GMM
layer will be informed by invoking gsm0408_gprs_authenticate().
Sponsored-by: On-Waves ehf
Currently the Authentication and Ciphering procedure is not yet
invoked by the GMM layer.
This patch starts this procedure from within gsm48_gmm_authorize when
the mm->auth_state has been set to SGSN_AUTH_AUTHENTICATE and a call
to gsm0408_gprs_authenticate has been issued directly or indirectly
by the call to sgsn_auth_request.
Sponsored-by: On-Waves ehf
Currently the gprs_subscr_update function is called when the
'update-subscriber ... insert ...' command is executed. This will
eventually notify the GMM layer which is rather the purpose of the
'commit' command.
This patch removes the call from update_subscr_insert.
Sponsored-by: On-Waves ehf
There will be an increasing number of SGSN related fields per
subscriber. Instead of extending gsm_subscriber accordingly, a single
struct sgsn_subscriber_data object is assigned to it. The talloc
context used to allocated that object is the subscr object itself.
Therefore it will be freed automatically along with the subscr
object.
Sponsored-by: On-Waves ehf
This adds the following commands to the ENABLE node:
- show subscriber cache
- update-subscriber imsi IMSI insert authorized (0|1)
- update-subscriber imsi IMSI cancel
- update-subscriber imsi IMSI commit
These commands are mainly testing tools and maintenance helpers. The
update commands work asynchronously and can be used to complete a
pending update request or to terminate an existing connection. The
'insert' command just update the subscriber records but does not
notify the GMM layer. Invoke the 'commit' command to continue with
pending procedures.
Note that the subscriber cache is not stored persistently and will
always be empty after an SGSN restart.
Sponsored-by: On-Waves ehf
This function is called to delete an established MM context
silently without invoking a detach procedure.
It is called when a subscriber is cancelled by the HLR. This
generally happens, when an MS has moved to another routing area and
has to use another SGSN.
Sponsored-by: On-Waves ehf
This commit adds a new authorization policy 'remote' and uses
the subscriber cache for authorization when this policy is being used.
Note that there is no remote backend implemented yet. After the
IMSI/IMEI have been acquired, a request would be sent to the remote
peer. The attach/auth-ciph procedure continues when authorization
info has been received from the peer. This means, that
gprs_subscr_update() must be called then to tell the GMM layer
that it can proceed. A later commit will add VTY commands to do this
manually.
Sponsored-by: On-Waves ehf
This patch adds GPRS specific functions for gsm_subscriber objects
(allocation, retrieval, deletion) and subscriber data
requests/updates. The sgsn_update_subscriber_data callback is used to
notify the sgsn about updates and is extended by a parameter that
passes a reference to a gsm_subscriber.
Sponsored-by: On-Waves ehf
Currently the keep_subscr flag in gsm_subscriber_group refers to a
whole group of subscribers which makes it difficult to really delete
single entries if the flag is set.
This patch adds a keep_in_ram field to gsm_subscriber which allows for
keeping subscriber objects in RAM while deleting others.
Note that really deleting an entry requires that both flags
(subscr_group->keep_subscr and subscr->keep_in_ram) are set to 0. So
only the latter should be used if a specification requires the
deletion of a subscriber entry.
Sponsored-by: On-Waves ehf
The trans_alloc function still uses the subscr object to access the
network object.
This patch adds an explicit net parameter to this function and
removes the access to subscr to obtain it.
Sponsored-by: On-Waves ehf
Currently the SRES value in the Auth & Ciph Response is ignored.
This patch checks the SRES value in response against the value stored
in mm->auth_triplet.sres. If they don't match, an Auth & Ciph Reject
message is sent to the MS. If they match, the mm->is_authenticated
flag is set.
Note that the procedure will not be started yet.
Sponsored-by: On-Waves ehf
Currently mmctx_timer_start is called from within
gsm48_tx_gmm_auth_ciph_req which differs from the way e.g. the
identification procedure is implemented. It also makes it more
difficult to restart the procedure after timeout, which is not
implemented yet. In addition, the timer is not properly stopped when
an AUTH & CIPH response is received.
This patch removes this timer start from gsm48_tx_gmm_auth_ciph_req,
adds the retransmission of Auth & Ciph requests to the timer callback
function, and properly stops the timer in
gsm48_rx_gmm_auth_ciph_resp.
Sponsored-by: On-Waves ehf
Currently gsm48_tx_gmm_auth_ciph_req/_rej are commented out. In
addition, gsm48_tx_gmm_auth_ciph_req uses a wrong encoding (two byte TV instead of two nibbles TV) of the CKSN information element.
This patch fixes the encoding of the CKSN IE and enables the
functions mentioned above.
Sponsored-by: On-Waves ehf
Currently every subcriber object directly refers to the gsm_network
which contains a flag shared by every related subscriber
(keep_subscr). This adds a dependency on gsm_network even if only the
function defined in gsm_subscriber_base.c are used.
This patch adds a new struct gsm_subscriber_group which contains the
keep_subscr flag and a back reference to the network object. The
latter is not dereferenced in gsm_subscriber_base.c, so it can safely
be set to NULL when only that part of the gsm_subscriber API is being
used. It also changes that API to use gsm_subscriber_group instead of
gsm_network parameters.
Since there are some places where a pointer to the gsm_network is
needed but where only a gsm_subscriber is available, a 'net' back
pointer is added to the group struct, too. Nevertheless subscr group
and network could be separated completely, but this is not the topic
of this commit.
Sponsored-by: On-Waves ehf
Currently the net pointer is obtained from trans->subscr->net. On the
other hand, the list gsm_trans object is managed by the net object.
This patch adds the back pointer to the structure and replaces all
trans->subscr->net by trans->net expressions. In trans_alloc() the
trans->net pointer is obtained from the subscr object.
Sponsored-by: On-Waves ehf
The commit "sgsn: Don't send XID reset after Detach Accept" fixed the
SGSN to not respond to a Detach Accept message when there is no MM
context.
This patch adds a test case to verify, that there is really no
message sent in that case.
The test fails when the commit mentioned aboved is reverted.
Sponsored-by: On-Waves ehf
Currently the expected P-TMSI generated by the SGSN is hard-coded
into the test. This adds a dependency on the implementation of rand()
and thus the libc used. This breaks the test e.g. on FreeBSD.
This patch modifies test_gmm_attach() to srand(1) first, generate the
P-TMSI, and finally srand(1) again before starting the test.
Sponsored-by: On-Waves ehf
Currently when the MS does a re-attach without doing a proper detach
first, the gbproxy uses the old local TLLI if patching and the keep
mode are enabled. This leads to a failing attachment procedure when
TLLI patching is also enabled.
This patch changes gbproxy_update_link_state_ul to reset all TLLIs
within the link_info if the message contains an unknown TLLI and an
MI. This is generally the case with Attach Request messages.
The gbproxy_get_link_info_ul gets an additional tlli_is_valid
output parameter that is set, when a TLLI was present and found.
This flag is then used instead of checking tlli.current == 0 to
set TLLI/P-TMSI e.g. Attach Requests when a link_info was already
present for the P-TMSI/IMSI used in such a request.
Ticket: OW#1324
Sponsored-by: On-Waves ehf
Increase the bcch_change_mark and generate a new copy of the
system information. Make the method public, add a small test
case. Manually verified using the FakeBTS. I don't know if
the MS will re-read these SIs.
Related: SYS#739
The session name must be present in a SDP file. The RFC proposes
to use a space for it but the other equipment is using the dash
so I have picked that as well.
RFC 4566:
The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the
alue "s= " SHOULD be used (i.e., a single space as the session
name).
Fixes: RT#2196
To implement subscriber based authorization a data structure is
needed that keeps the subscriber data. The MSC already uses a similar
struct named gsm_subscriber whose implementation is split into a
generic part (allocation, retrieval, reference counting, list
maintenance) and MSC related parts. For GPRS, only the generic part
will be used and specific fields may be added when needed.
This patch adds a field mm to struct gsm_subscriber that will be used
by the SGSN to store a reference to the current MM context (or NULL
if there is none). This also adds a field subscr to struct
sgsn_mm_ctx that reversely points to a gsm_subscriber (or NULL if
there is none). Either both fields are NULL or both fields are
non-NULL. Note that subscr is being reference counted.
Sponsored-by: On-Waves ehf
Currently the function in sgsn_auth.c either have an sgsn_config or
an sgsn_instance parameter. Since then global sgsn variable is
already being used in that file and since other parts of the SGSN
related code also rely on a global sgsn singleton, these parameters
pretend to provide a flexibility that is not really supported.
Therefore this patch removes these parameters except for the ACL
related functions, which do not call code that uses the sgsn
variable.
Sponsored-by: On-Waves ehf
Currently the authorization is done in sgsn_auth_request for ACL
based authorization. This doesn't match the way remote authorization
would work, so that there is a second call to sgsn_auth_state already
present in sgsn_auth_update.
This patch removes the autorization check completely from
sgsn_auth_request which in turn calls sgsn_auth_update directly now.
Sponsored-by: On-Waves ehf
Currently every time an RA Update Req or an Attach Req is processed, a
new P-TMSI is allocated. When an MS issues another of these messages
before it has completed the first procedure, old_ptmsi is replaced by
ptmsi (and thus lost) and ptmsi is replaced by the newly allocated
P-TMSI. This can confuse the gbproxy, which can loose track of the
logical link then. At least a Blackberry emits a double set of RA Upd
Req messages from time to time which may be just 20ms apart.
This patch adds a check whether mm->ptmsi or mm->old_ptmsi are set.
If both are set, the P-TMSI is not re-allocated. This is only the
case, when the Complete message has not been received yet, since that
message will reset old_ptmsi.
Sponsored-by: On-Waves ehf
Currently when a Detach Accept is received for an unknown TLLI (which
is in general the case afer the SGSN has requested the detachment),
an XID reset is sent to the BSS, causing a BSSGP Status message. This
happens in gsm0408_rcv_gmm.
This patch moves the corresponding call to gprs_llgmm_reset downwards
so that it is not being called in that case.
Addresses:
SGSN->BSS TLLI: 0xd75b91d9 SAPI: LLGMM, UI (DTAP) (GMM) Detach Request
BSS->SGSN TLLI: 0xd75b91d9 SAPI: LLGMM, UI (DTAP) (GMM) Detach Accept
SGSN->BSS TLLI: 0xd75b91d9 SAPI: LLGMM, U, XID (Reset, IOV-UI)
BSS->SGSN TLLI: --- BSSGP STATUS (Unknown MS)
Sponsored-by: On-Waves ehf
Currently, the LLME is not cleaned up after sending an RA Update
Reject. This happens after entering a routing area from outside,
since in that case the SGSN sends an RA Update Reject (implicitly
detached) which causes the MS to restart the attach procedure.
The LLME is also not updated if an Attach Request with message errors
(encoding, invalid MI type) is received or if an MM context cannot be
allocated.
This patch changes gsm48_rx_gmm_ra_upd_req and gsm48_rx_gmm_att_req
to unassign the LLME or free the MM context (if available) after a
Reject message has been sent.
Ticket: OW#1324
Sponsored-by: On-Waves ehf
Currently the VTY 'auth-policy' command results in setting or clearing
the acl_enabled flag. This also enables the matching of the MCC/MNC
prefix of the IMSI.
This patch adds an additional policy 'acl-only' which disables the
MCC/MNC matching and relies on the ACL only.
Sponsored-by: On-Waves ehf
Currently the authorization of an IMSI is done by checking ACLs
synchronously which is not feasible when the subscriber data has to
be retrieved from an external source.
This patch changes this by using a callback when the information is
available. This is also done when only ACL are checked, in this case
the callback is invoked from within sgsn_auth_request(). The callback
function sgsn_update_subscriber_data calls sgsn_auth_update which
in turn calls either gsm0408_gprs_access_granted or
gsm0408_gprs_access_denied. gsm48_gmm_authorize is extended by a call
to sgsn_auth_request when IMSI and IMEI are available but the
auth_state is unknown.
The change has been successfully tested with single phones (E71 and
IPhone 5c).
Sponsored-by: On-Waves ehf
Currently the IMSI is only checked immediately when an Attach Request
is received that contains an IMSI IE. If it contains a P-TMSI
instead, access is always granted.
This commit moves the IMSI check to gsm48_gmm_authorize where it is
applied when IMSI and IMEI have been acquired. This fixes the
authorization when the Attach Accept doesn't contain an IMSI.
Sponsored-by: On-Waves ehf
Currently when forceing a reattach by sending a Detach
Request (reattach), the SGSN waits for the Detach Accept until it
frees the MM context (if present) and the LLME. If that message gets
lost or isn't sent by the MS, the LLME is never freed if it isn't
bound to an MM context.
This patch adds code to free the MM context/LLME when forcing a
reattachment.
Sponsored-by: On-Waves ehf
This patch replaces gsm0408_gprs_force_reattach(msg, mmctx) by two
functions
- gsm0408_gprs_force_reattach(mmctx)
- gsm0408_gprs_force_reattach_oldmsg(msg)
The old function basically consists of the code of the two new
functions, where the code path selected depends on mmctx == NULL,
which is harder to maintain, less obvious to use, and not consistent
with many other SGSN functions.
Sponsored-by: On-Waves ehf
Currently the MM context isn't always removed when it is
de-registered (mmctx_timer_cb), mm_state is set to GMM_DEREGISTERED
instead. This can lead to left-over MM contexts which are only
cleaned up if the MS reattaches.
This patch replaces all of these assignments by a call to
mm_ctx_cleanup_free.
Ticket: OW#1324
Sponsored-by: On-Waves ehf
Currently the GMM state is set to GMM-REGISTERED when an Attach
Accept or a RA Update Accept message is sent, even if a new P-TMSI is
included. In this case 04.08 requires (see 4.7.3.1.3 and 4.7.5.1.3),
that the state is set to GMM-COMMON-PROCEDURE-INITIATED when the
Accept is sent. When the Complete is received, the SGSN shall set
the state to GMM-REGISTERED.
This patch modifies the state updates accordingly.
Sponsored-by: On-Waves ehf
Currently the order of the 'if' clauses in gsm48_gmm_authorize
doesn't match the order in which the conditional parts are entered.
This makes it difficult to maintain. In addition the t3350_mode is
not stored in every path, so that this information is lost when the
identification procedure is started. Since the default value
coincidentally is GMM_T3350_MODE_ATT, this doesn't hurt for Attach
Requests which are the only messages that initially trigger the
authentication yet.
This patch changes the order of the 'if' clause to match the
processing order, it removes the t3350_mode parameter entirely and
introduces a mm->pending_req field. The latter must be set when the
request that causes the authorization before calling
gsm48_gmm_authorize. The gprs_t3350_mode enum is extended by
GMM_T3350_MODE_NONE (value 0, which is the default) to make it
possible to detect related initialisation errors or race conditions.
Sponsored-by: On-Waves ehf
Since it is planned to use struct gsm_subscriber to manage subscriber
data in the SGSN, this file which contains the generic subscriber
related methods is moved to libcommon.
Sponsored-by: On-Waves ehf
Currently libcommon depends on libbsc, because gsm_network_init
(libcommon/gsm_data.c) directly calls gsm_net_update_ctype
(libbsc/gsm_04_08_utils.c).
This patch moves gsm_network_init to a new file libbsc/net_init.c.
Sponsored-by: On-Waves ehf
This test checks the attach procedure until the Attach Complete is
received.
Note that authorization and GMM state updates are not working
properly yet.
Sponsored-by: On-Waves ehf
This replaces serveral occurences of duplicated code for message
creation and sending (passing to gsm0408_gprs_rcvmsg) into a single
function. In addition, the sgsn_tx_counter is always reset within
send_0408_message to simplify the code that checks for the number of
messages sent.
Sponsored-by: On-Waves ehf
Currently gbproxy_make_sgsn_tlli always returns a foreign TLLI when
it uses the (SGSN) P-TMSI to generate one.
This patch changes the implementation to return a SGSN TLLI of the
same type like the BSS TLLI in that case.
Sponsored-by: On-Waves ehf
Currently the sign_link pointer is dereferenced after a call to
osmo_signal_dispatch, which can indirectly call
e1inp_sign_link_destroy. If that happens, accessing *sign_link is
illegal and can lead to a segmentation violation.
Since only the bts pointer is needed from sign_link after the call to
osmo_signal_dispatch, this patch changes abis_nm_rcvmsg_fom to save
that pointer to a local variable earlier.
Addresses:
<0019> input/ipa.c:250 accept()ed new link from 192.168.1.101 to port 3002
SET ATTR NACK CAUSE=Message cannot be performed
<0005> bsc_init.c:52 Got a NACK going to drop the OML links.
<001b> bsc_init.c:319 Lost some E1 TEI link: 1 0xb351a830
=================================================================
==13198== ERROR: AddressSanitizer: heap-use-after-free on address 0xb5d1bc70 at pc 0x80a6e3d bp 0xbfbb33d8 sp 0xbfbb33cc
Sponsored-by: On-Waves ehf
In case a BTS is being bootstrapped and one TS can not be
activated prevent the whole BTS from coming up.
When the OML activation is not being done the rest of the BSC
code still assumes these logical channel(s) to be available
and one will see channel activation issues that might be hard
to debug.
Instead of having a half-configured system up and running,
keep the BTS offline.
Currently the LLME is not deleted when a GMM Status message is
received for which a mmctx cannot be found. This can fill the LLME
list with unneeded entries.
This patch adds code to unassign the LLME in that case.
Ticket: OW#1324
Sponsored-by: On-Waves ehf
The following functions are not being used:
- gsm48_tx_gmm_status_oldmsg
- gsm48_tx_sm_status_oldmsg
This patch removes the function definitions.
Sponsored-by: On-Waves ehf
Some switches do not like to receive the IPA PING/PONG messages.
Allow to disable the handling with "no timeout-ping" and create
test cases that verify the switching between the modes. Change the
code to trat <= 0 as an invalid timeout.
Fixes: SYS#713
Currently the temporary string 'tmp' is freed before parts of it are
referenced. This lets address sanitizer complain when evaluating
strlen(imsi), where imsi points into the 'tmp' data block.
This patch moves the talloc_free to the end of the function and uses
a rc variable instead of using early returns.
Addresses:
testSubscriberAddRemove (__main__.TestCtrlNITB) ... Launch:
./src/osmo-nitb/osmo-nitb -c
./doc/examples/osmo-nitb/nanobts/openbsc.cfg -l test_hlr.sqlite3
Connecting to host 127.0.0.1:4249
Sending "SET 1000 subscriber-modify-v1 2620345,445566"
Decoded replies: {}
ERROR
Sponsored-by: On-Waves ehf
Currently, when a Detach Request is received with an unknown TLLI,
it is answered by another Detach Request (!), even when a power_off
Type is used.
This patch uses gsm48_rx_gmm_det_req to handle the message instead.
So this function is changed to cope with a NULL mmctx. In that case
it doesn't unassign the llme, so this must be done manually
afterwards.
Sponsored-by: On-Waves ehf
Currently, every time the SGSN received a Detach Request from the MS
via an established logical link, it is answered by a Detach Accept.
This violates the specification (GSM 04.08, 4.7.4.1.2 and .3), which
states, that it should only be sent, if "the detach type IE value
indicates that the detach request has not been sent due to switching
off".
This patch adds a conditional to limit the sending of Detach Accept
accordingly.
Sponsored-by: On-Waves ehf
Currently only a Detach Request (MO) message with power_off = 0 is
checked.
This commit adds a new test case with power_off set to 1. It also
adds checks for the number of messages generated by the SGSN to
verify that these messages are handled differently.
Note that the handling of power_off isn't implemented yet. Therefore
the corresponding assertion is being disabled yet.
Sponsored-by: On-Waves ehf
Currently the ACL code is located in sgsn_vty.c.
This commit moves this to a new file sgsn_auth.c as a first step to
make authorization more flexible in order to implement remote
acquisition on subsciber data.
Sponsored-by: On-Waves ehf
Currently each received Ident Resp triggers an Attach Accept/Reject
if IMSI and IMEI are known. This has led to duplicated Attach Accept
messages when used with the gbproxy (IMSI acquisition active) and
with certain mobile equipment (iOS).
This patch modifies gsm48_rx_gmm_id_resp to discard Ident Resp messages
if all required information (IMEI and IMSI) has been gathered.
Ticket: OW#1322
Sponsored-by: On-Waves ehf
Currently the P-TMSI IE in PAGING_PS is not patched.
This commit adds code to patch BSSGP P-TMSI IE in
gbproxy_patch_bssgp independently from the P-TMSI patching at the LLC
layer. It also extends gbproxy_update_link_state_dl to use the IMSI
to find the link_info if the TLLI is not present in the message.
Note that the spec (GSM 08.18, 7.2) requires to use of the P-TMSI
instead of the IMSI to select the MS if that IE is available.
Nevertheless as long as the IMSI is always present in downlink BSSGP
messages and as long as the optional P-TMSI refers to the same MS
(which is the case currently), this is not an issue.
Sponsored-by: On-Waves ehf
Currently, when P-TMSI patching is enabled, a new BSS P-TMSI is
generated for each Attach Accept. So two duplicated, subsequent
Attach Accept messages will be mapped to different BSS side P-TMSI.
Because the last one will replace former ones in the link_info
struct, the MS will fail to access the SGSN if it uses the former
P-TMSI to derive the new TLLI.
This patch checks the SGSN P-TMSI already assigned to the link_info
and only generates a new BSS P-TMSI on mismatch (or if the BSS P-TMSI
hasn't been set yet).
Ticket: OW#1322
Sponsored-by: On-Waves ehf
This adds a test case to check gbproxy's behaviour when processing
two subsequent but identical Attach Accept messages.
Ticket: OW#1322
Sponsored-by: On-Waves ehf
This patch adds assertions to check the LLC/GMM message received from
the gbproxy by the test framework within the function
test_gbproxy_keep_info.
It also fixes the source address of the DETACH ACC messages.
Sponsored-by: On-Waves ehf
The osmo-sgsn sends Status messages (or nothing in case of non
GMM/GSM) when the TLLI is unknown. This prevents the MS from
reconnecting.
This patch adds the initiation of an MT detach procedure to force a
re-attach to set up a valid LLE context if an LLE or an MM context
cannot be found. Since this can also be triggered by non-GMM SAPI
messages, a GPRS application callback sgsn_force_reattach_oldmsg is
added which in turn calls the GMM layer to generate the GSM 04.08
specific messages.
Note that the MS can be left in REGISTERED state after initially
wanting to detach itself, since it will receive a Detach Req
(re-attach) when sending a DEACT PDP CTX REQ after the SGSN or
gbproxy (P-TMSI patching enabled) has been restarted. This same
behaviour has been observed with another SGSN.
Sponsored-by: On-Waves ehf
Currently the PDP contexts are hard freed (via sgsn_pdp_ctx_free)
at some places in gprs_gmm.c on the reception of a Detach Req and on
re-use of an IMSI that is already associated with an MM context. This
can lead to segfaults when there is a pending request or a data
indication at libgtp.
This patch add a new function sgsn_pdp_ctx_terminate that de-associates
the PTP context from the MM context, deactivates SNDCP, sets pdp->mm
to NULL and then calls sgsn_delete_pdp_ctx. sgsn_libgtp is updated to
check for pdp->mm being non-NULL before dereferencing it. The
sgsn_pdp_ctx_terminate function will be called for each PDP context of
an MM context before this context is going to be deleted via
sgsn_mm_ctx_free. To ensure, that the ctx->llme (which is accessed
during the deactivation of SNDCP) remains valid, the call to
gprs_llgmm_assign is moved after the call to sgsn_mm_ctx_free. The
handling of re-used IMSIs is changed to mimic the processing of a
Detach Req.
Addresses:
<0002> gprs_gmm.c:654 MM(/f6b31ab0) Deleting old MM Context for same
IMSI p_tmsi_old=0xc6f19134
<000f> gprs_sgsn.c:259 PDP freeing PDP context that still has a
libgtp handle attached to it, this shouldn't happen!
[...]
SEGFAULT
Ticket: OW#1311
Sponsored-by: On-Waves ehf
Currently the timer is not stopped before the MM context is freed
which can lead to failure if sgsn_mm_ctx_free is called while timer
protected procedures are active.
This patch add code to cancel the timer if necessary from within
sgsn_mm_ctx_free.
Ticket: OW#1322
Sponsored-by: On-Waves ehf
Currently the code segfaults when the link shall be deleted by IMSI
when the IMSI has not been set yet.
This patch adds a NULL check to skip the entry before calling
gsm48_mi_to_string,
Adresses:
Program received signal SIGSEGV, Segmentation fault.
0xb693af77 in gsm48_mi_to_string (string=0xbfffe020 "", str_len=200,
mi=0x0, mi_len=0) at gsm48.c:360
360 mi_type = mi[0] & GSM_MI_TYPE_MASK;
str_len=200, mi=0x0, mi_len=0) at gsm48.c:360
self=0x807c9a0 <delete_gb_link_by_id_cmd>, vty=0xb4303c70,
argc=3, argv=0xbfffe1c0) at gb_proxy_vty.c:670
...
Sponsored-by: On-Waves ehf
Coverity complains about having side effects in OSMO_ASSERT argument
expressions. This would be an issue in this case, because that
variable is only reference in other OSMO_ASSERT expressions.
Nevertheless this patch changes this to assign the variable outside
of OSMO_ASSERT.
Fixes: Coverity CID 1244239
Sponsored-by: On-Waves ehf
Currently all PTP messages are in general forwarded to the SGSN even
when the BVCI is not known to the gbproxy. Only if message patching
is active and the peer cannot be determined, a log message is
generated, a STATUS message returned, and the message discarded.
The intention for this was to keep the old gbproxy's behaviour if
patching is disabled. But the code gets much more complex this way.
Another drawback is that when the SGSN returns a corresponding STATUS
message, it cannot be routed to the BSS where the original message
came from.
This patch therefore changes the behaviour to reject BSSGP PTP uplink
messages immediately if the BVCI is not known.
Fixes: Coverity CID 1244240
Ticket: OW#1317
Sponsored-by: On-Waves ehf
This has been re-produced using the "osmo-pcu emulator" code
and a ping to force segmented SNDCP messages. When the NS link
enters the DEAD/BLOCKED state the msgb would be freed twice.
Once inside gprs_ns_sendmsg and once by the caller. Based on the
return one can not see if the parameter has been deleted.
I changed libosmocore/libosmogb to always free the msgb in case
of an error on the way to gprs_ns_sendmsg. Catch up, avoid the
double free and fix some memory leaks. In case the sending fails
assume the entire segmented message is at end and free the
original input data.
This has been tested by posix suspending/resuming the emulator
process to have the GPRS-NS link go to dead/blocked to alive
and unblocked. The ping recovers and "SIGUSR1" to the SGSN does
not show active memory allocations.
The SGSN calls bssgp_tx_dl_ud at the lowest level and has the
following callchains. Most of them allocate the msgb and have
no early return and transfer ownership already:
<- gprs_llc_tx_u
<- gprs_llc_tx_ui
<- gsm48_gmm_sendmsg (all callers sane)
<- _tx_status
<- _tx_detach_req
<- gprs_llc_tx_xid (all callers sane)
<- sndcp_unitdata_req
<- sndcp_send_ud_frag
To get a clue which message caused the error without having to enable
LOGL_DEBUG, information about how far the parser came (message name,
parsed fields) is logged with LOGL_NOTICE along with a full hexdump
of the message.
Ticket: OW#1307
Sponsored-by: On-Waves ehf
Currently, the log level is always LOGL_DEBUG. In case of errors it
would be helpful to use a higher log level.
This patch adds a log_level parameter to gprs_gb_log_parse_context to
let the caller decide about the level.
Ticket: OW#1307
Sponsored-by: On-Waves ehf
This function tries to get an accurate name for the message even if
the parsing has been aborted due to message errors.
The patch also moves the settings of the BSSGP related fields in
parse_ctx from behind to the front of bssgp_tlv_parse, to get more
information in the case of failure. This is now consistent with the
handling of the llc and g48_hdr fields.
Id addition, gprs_gb_log_parse_context now uses the new function to
derive a more accurate message name.
Ticket: OW#1307
Sponsored-by: On-Waves ehf
Currently it is possible to set the secondary SGSN NSEI to the same
value like the (primary) SGSN NSEI. This leads to undefined behaviour
and is hard to recognize.
This patch adds checks to either NSEI configuration command to refuse
conflicting values.
Ticket: OW#1306
Sponsored-by: On-Waves ehf
Currently, ptmsi_enc and new_ptmsi_enc point to the beginning of the
mobile identity. Since all P-TMSI in 04.08 (MM) are encoded this way (1
byte header + 4 byte P-TMSI value). This is different to the P-TMSI
encoding in 08.18 (BSSGP), where the P-TMSI is encoded into 4 byte
without MI header.
This patch changes the code to use pointers to the P-TMSI value,
which is encoded in the same way in both specifications.
Sponsored-by: On-Waves ehf
Currently BSSGP PTP messages are silently dropped when the BVCI is
not known and patching is enabled. The nanoBTS will not recognize
this and continue to send messages on the BVCI. If it receives a
STATUS(BVCI unknown) instead, it will start a BVC reset procedure
instead.
This patch modifies gbprox_rx_ptp_from_bss() to return a
STATUS(BVCI unknown) to the BSS instead of dropping the message.
Sponsored-by: On-Waves ehf
Currently the parse expects a 'MS network capability' IE with
2 <= length <= 3 which is compliant to GSM 04.08, 9.4.1 but not to
GSM 24.008, 9.4.1 which specifies 3 <= length <= 9. Thus the parser
rejects messages with a length >= 4 (including length field).
This patch relaxes the length check to accept either range by
requiring 2 <= length <= 9.
Ticket: OW#1258
Sponsored-by: On-Waves ehf
Currently one regexp ('patching') is used for all matching.
This patch adds a second category 'routing' which is exclusively used
for SGSN selection. It also adds a corresponding VTY command:
- match-imsi patching RE : MS related patching (currently APN)
- match-imsi routing RE : Select secondary SGSN on match only
- no match-imsi : Clear all filter expressions
Ticket: OW#1258
Sponsored-by: On-Waves ehf
This patch modifies the match-imsi command to allow for different
match categories (currently only 'patching' is provided).
- match-imsi patching RE : Filter APN patching and routing
- no match-imsi : Clear all filter expressions
Sponsored-by: On-Waves ehf
Currently, patch filter configurations are leaking between tests.
This adds a call to gbproxy_clear_patch_filter() to the end of each
test that calls gbproxy_set_patch_filter().
Sponsored-by: On-Waves ehf
The current implementation makes it difficult to add further match
expressions.
This patch adds a new struct gbproxy_match that contains the fields
needed for each match expression. The matches (config) and the
results (link_info) are stored in arrays. All related functions are
updated to use them. The old fields in the config structure are
removed.
Sponsored-by: On-Waves ehf
This patch adds assertions to check the LLC/GMM message received from
the gbproxy by the test framework within the function
test_gbproxy_ra_patching.
Sponsored-by: On-Waves ehf
Currently the only way to check, whether the right message have been
generated is to look into the generated text output. This is
error-prone if there are many messages.
This patch adds a way to optionally store all received messages into
a FIFO. They can then be checked by calling expect_msg() which
removes the first message from the FIFO and returns a pointer to it
or NULL if there is none. The pointer is only valid until the next
call to this function.
A few convenience functions are added to check for common message
types:
- expect_gmm_msg checks for certain GSM 04.08 messages in LLC/GMM
- expect_llc_msg checks for arbitrary LLC messages in BSSGP/UD
- expect_bssgp_msg checks for arbitrary BSSG messages
Each of their arguments can be set by MATCH_ANY to ignore it while
matching. On success, they return a pointer to a statically
allocated struct containing the pointer to the msg and the full parse
context.
Recording is enabled by setting the global variable received_messages
to a pointer to a struct llist_head. It can be disabled again by
setting it to NULL.
Sponsored-by: On-Waves ehf
Currently the pointers are computed by adding an offset to the new
message's _data pointer even when the original pointer is NULL.
This leads to invalid pointers in the copied msgb.
This patch adds a NULL check to each computation such that NULL
pointers are not adjusted.
Sponsored-by: On-Waves ehf
This patch adds und uses the function gbproxy_gsm48_to_peer() which
takes a GSM 04.08 message, encapsulates it in BSSGP and LLC, and
sends it to the BSS peer. This function increments vu_gen_tx_bss
which is now used instead of imsi_acq_retries to set the N(U) of the
outgoing message.
Since imsi_acq_retries isn't currently incremented before a Detach
Accept is generated, this patch also fixes the N(U) of such messages.
Sponsored-by: On-Waves ehf
Currently then link_info is not cleaned up completely, when
gbproxy_unregister_link_info is called.
This patch adds a function gbproxy_reset_link that must be defined
externally. This is done in gb_proxy.c, where it resets the IMSI
acquisition.
Sponsored-by: On-Waves ehf
That message is currently ignored but should invalidate the TLLI and
de-register the logical link instead.
This patch extends the parser to recognize such messages and to set
the invalidate_tlli flag.
Sponsored-by: On-Waves ehf
The TLLI should also be invalidated:
- when an Attach Reject info is received from the SGSN
- when an Attach Req is immediately followed by a Detach Req
- when an Attach Req is immediately followed by an MT detach
procedure
To verify that, this patch adds corresponding message sequences to
the test.
Sponsored-by: On-Waves ehf
This fixes the IMSI length assertion, which currently uses a
greater-or-equal than zero comparison which always yields true. It is
replaced by a greater than zero check.
Fixes: Coverity CID 1239442
Sponsored-by: On-Waves ehf
A single test case still uses time() to obtain the reference time.
This commit fixes this by using the 'now' variable instead, that
contains a fixed time value and does therefore not depend on when the
test is executed.
Sponsored-by: On-Waves ehf
Currently time() is used for age calculations. This time source
may jump either forwards or backwards in time (NTP update, leap
seconds).
This patch replaces the use of time() by using
clock_gettime(CLOCK_MONOTONIC) instead.
Sponsored-by: On-Waves ehf
Don't return a link_info if TLLI is 0 resp. P-TMSI is 0xffff. These
values are used for uninitialised or cleared fields and can possibly
match several entries.
Sponsored-by: On-Waves ehf
Since the (former) TLLI list has developed into a logical link list,
related commands are renamed accordingly.
- tlli-list * -> link-list *
- delete-gbproxy-tlli * -> delete-gbproxy-link *
- show gbproxy tllis -> show gbproxy links
Sponsored-by: On-Waves ehf
This field in struct gbproxy_patch_state has involved and holds a
list of all tracked logical links now. Thus the name is modified
accordingly.
Sponsored-by: On-Waves ehf
Currently in many places where 'tlli' (Temporary Logical Link
Identifier) within identifiers is used, the logical link itself is
meant instead. For instance, the tlli_info contain information about
an LLC logical link including up to four individual TLLI.
To avoid confusion between these concepts, this patch replaces all
'tlli_info' by 'link_info' and a few 'tlli' by 'link'.
Sponsored-by: On-Waves ehf
This patch replaces 'tlli' by 'tlli_info' within the following
function identifiers:
- gbproxy_delete_tlli
- gbproxy_delete_tllis
- gbproxy_remove_stale_tllis
- gbproxy_touch_tlli
- gbproxy_unregister_tlli
- gbproxy_remove_matching_tllis
- gbproxy_find_tlli -> gbproxy_tlli_info_by_tlli
- gbproxy_find_tlli_by_* -> gbproxy_tlli_info_by_*
These functions refer to the whole logical link info rather than to a
certain TLLI. So they are renamed to be named consistently with
gbproxy_attach_tlli_info and others.
Sponsored-by: On-Waves ehf
The function gbproxy_imsi_acquisition() has a parameter sgsn_nsei
that is alyways equal to tlli_info->sgsn_nsei (if tlli_info is not
NULL).
This patch removes this parameter from gbproxy_imsi_acquisition() and
gbproxy_flush_stored_messages() and accesses tlli_info->sgsn_nsei
instead within these functions.
Sponsored-by: On-Waves ehf
This patch renames gbproxy_check_tlli() to
gbproxy_imsi_matches() and struct tlli_info's
enable_patching to imsi_matches.
It's meant to be more obvious and consistent this way.
Sponsored-by: On-Waves ehf
Currently the number of iterations when creating a P-TMSI/TLLI is not
limited. It is nevertheless very unlikely that the loop will not
terminate. On the other hand, the number of iterations of every loop
should have an upper bound (loop variant) which wouldn't be the case
here if an arbitrary random generator was used.
This patch limits the number of iterations to 23 and logs an error if
the creation of the indentifier was aborted due to this limit.
Sponsored-by: On-Waves ehf
Currently the IMSI acquisition is not restarted when a RA Update
Request is received. This leads to repeated N(U) in the generated
Ident Request message, which in turn causes the MS to drop the
second of these message. This is bad, when the first Ident Response
has been lost between MS and gbproxy.
This patch changes gbproxy_imsi_acquisition() to handle RA Update
Request messages like Attach Requests.
Sponsored-by: On-Waves ehf
When a MS is state GMM_REGISTERED enters a new RA, it sends a RA
Update Request which is then handled by a gbproxy that possibly
doesn't have a matching tlli_info. In this case, depending on the
configuration an identification procedure to acquire the IMSI must be
started.
This adds tests to test_gbproxy_imsi_acquisition():
- IMSI acquisition triggered by a RA Update Request message
- Reaction to repeated RA Update Request messages, like it could be
caused by packet loss between PCU and gbproxy.
Sponsored-by: On-Waves ehf
On a Detach/Re-attach cycle the Address Sanitizer detected a
use-after-free kind of problem. That is because we tried to
destroy the LLME twice. The first time it is destroyed as part
of the Detach handling ans the second time it is destroyed as
part of destroying the old MM context.
In case the GPRS GMM detach message is lost the SGSN needs
to reply besides not having a MM entry.
The alternative would have been to add NULL checks for all
usages of ctx->llme which would not have helped with the
readability.
Sponsored-by: On-Waves ehf
For jitter, transit and packet loss we should count the data
that arrived and not the data we send towards the remote. This
is changing the jitter timings to what they were before the
re-factoring.
For forced timing we might willingly add jumps in the sequence
number but for jitter and packet loss we are more interested
in the data that traveled through the wire/air.
The Annex A code has a probation period but we don't have it. When
starting with seq_no==0 do not assume that the sequence numbers
have wrapped. Do it by moving the entire checking code into the
else.
mgcp_patch_and_count has grown due supporting linearizing timestamps,
ssrc and other things for equipment like the ip.access nanoBTS. Fight
back and move the Annex A code into a dedicated method.
The result is updated as we now count after all the patching and for
the Annex A code no change in SSRC can be detected.
Before the old code allowed to specify "timeout-ping bla" which
would be parsed as '0' which would trigger a flood of pings. Use
the VTY code to parse it as a number.
Currently when gprs_llgmm_reset() is invoked an XID reset is sent but
the local LLC parameters (e.g. V(U)) are not cleared (see GSM 04.64,
8.5.3.1). This can lead to discarded messages on the SGSN side.
This patch modifies gprs_llgmm_reset to clear vu_send, vu_recv,
oc_ui_send, oc_ui_recv.
Sponsored-by: On-Waves ehf
Currently the SGSN side message's TLLI are searched without checking
the originating SGSN. This leads to collisions if both SGSN use the
same P-TMSI for different MS.
With this patch, the SGSN NSEI is stored within the tlli_info and is
used in comparisons to separate the namespaces.
Note that this type of collision cannot happen with BSS numbers,
since the tlli_info are already separated and stored per (BSS) peer.
Sponsored-by: On-Waves ehf
This patch extends test_gbproxy_secondary_sgsn() by the establishment
of a third MS connection using a P-TMSI that has been assigned by the
other SGSN already. It is expected that the entries do not
interfere and are properly retrieved.
Note that these collisions are not handled properly yet.
Sponsored-by: On-Waves ehf
Currently it is possible to create serveral entries referring to the
same P-TMSI/TLLI by using P-TMSI assigment via Attach Accept or
RA Update Accept messages. This can lead to the use of the wrong
tlli_info.
This patch adds gbproxy_remove_matching_tllis() that removes all
conflicting entries. This function is called after the P-TMSIs and
the resulting TLLIs has been set up.
Sponsored-by: On-Waves ehf
This tests P-TMSI assignment when P-TMSI patching is disabled. A test
with colliding P-TMSI in Attach Accept messages is included.
Note that P-TMSI collisions are not handled properly yet.
Sponsored-by: On-Waves ehf
Since this message puts the MS into DEREGISTERED state (like a detach
procedure), this message is parsed and the invalidate_tlli field is
set accordingly.
Sponsored-by: On-Waves ehf
This commit adds/modifies the following VTY commands:
- delete-gbproxy-tlli <NSEI> de-registered : Delete all
de-registered entries
- show gbproxy tllis : Display 'DE-REGISTERED' when appropriate
In addition, the implementation of the delete-gbproxy-tlli command
has been split into two functions (with and without TLLI/IMSI
value).
Sponsored-by: On-Waves ehf
gprs_gb_log_parse_context() uses a sequence of LOGP calls to compose
a single message line. This leads to cluttered log output.
This patch replaces all but the first LOGP applications in this
function by applications of LOGPC.
Sponsored-by: On-Waves ehf
Currently it is possible to create several tlli_info entries with the
same IMSI.
This patch disables this by adding a check before the imsi field
is updated.
Sponsored-by: On-Waves ehf
Currently a tlli_info entry is deleted when the TLLI gets invalidated
by a Detach message.
This patch introduces the possibility to keep tlli_info entries in
the list. Those entries then have cleared TLLI fields, are marked as
de-registered, and can only be retrieved by a message containing an
IMSI or a P-TMSI.
The following VTY configuration commands are added to the gbproxy
node:
- tlli-list keep-mode never : Don't keep the entries (default)
- tlli-list keep-mode re-attach : Only keep them, when a Detach
message with re-attach required has been received
- tlli-list keep-mode identified : Only keep entries which are
associated with an IMSI
- tlli-list keep-mode always : Keep all entries
Note that at least one of max-length or max-age should be set when
this feature is used to limit the number of entries.
Sponsored-by: On-Waves ehf
Currently when patching is basically enabled P-TMSI and TLLI gets
patched even when P-TMSI patching is not enabled. Albeit the result
is correct in this case (the same value is re-written), the counter
shows unexpected results.
This patch adds configuration checks for P-TMSI and TLLI patching. It
also reorders the code of gbproxy_patch_raid to return early if there
is nothing to patch.
Sponsored-by: On-Waves ehf
This test case consists of a sequence of several attach and detach
procedures. The kind of detach varies (mobile originated, mobile
terminated re-attach required, mobile terminated re-attach not
required, routing area update reject). To main focus is to check that
the tlli_info is de-registered correctly (not accessible via the
TLLI) and that can be re-used afterwards (which is not implemented
yet).
Sponsored-by: On-Waves ehf
This function is a remainder of the initial implemenation that was
not meant for TLLI patching and can be used for the BSS side only.
The SGSN side is already using a composition of more flexible
single purpose functions.
This patch changes the implementation to use a similar approach. The
function is moved to gbproxy_test.c and renamed to register_tlli to
keep the tests intact.
Sponsored-by: On-Waves ehf
If IMSI acquisition is enabled and the gbproxy receives a Detach
request from the MS, it cannot pass it to the SGSN since the
acquisition has not yet been completed.
This patch implements the generation of a Detach Accept message and
for this case and updates the TLLI state accordingly.
Sponsored-by: On-Waves ehf
Currently the RAI in the LLC part of the message is not updated if
the message has been taken from the list of stored messages. The
reason is, that old_raid_matches is update in
gbprox_process_bssgp_ul() but not in gbproxy_flush_stored_messages().
This patch moves the check to gprs_gb_parse_bssgp() which is called
at both places and where other fields like parse_ctx->tlli are set,
too.
In addition, old_raid_matches is replaced by old_raid_is_foreign
since this is clearer in the case when there is no old RAI at all.
Several RAI patch counter assertions are also added to
test_gbproxy_ra_patching().
Sponsored-by: On-Waves ehf
Add a Attach Request message to test_gbproxy_ra_patching, where the
BSSGP RAI differs from the old RAI signalled in the LLC part. This
case had not been tested explicitely yet.
Change the RAI in the first Attach Request in
test_gbproxy_imsi_acquisition from rai_unknown to rai_bss.
Add Detach Requests to test_gbproxy_imsi_acquisition, one for a
incomplete attach procedure and one for an unknown (fresh) TLLI.
In these cases, the acquisition of a IMSI is not necessary and also
doesn't work properly with an E71.
Sponsored-by: On-Waves ehf
Since at all places where mi_data/mi_data_len is used it will always
contain an IMSI. Thus the names of the identifiers have been updated
accordingly for clarity.
Sponsored-by: On-Waves ehf
This commit changes gbproxy_imsi_acquisition as follows:
tlli_info->mi_data_len is used instead of parse_ctx->imsi to check,
whether the IMSI is known already. Since the function is always
called after gbproxy_update_tlli_ul(), the two values are already
synchronized.
Messages are always flushed when the IMSI gets known, if the current
message is IDENT RESP discard it, otherwise continue processing as
usual.
The 'if' clauses are simplified for better readability.
Sponsored-by: On-Waves ehf
gbprox_process_bssgp_ul has grown quite large mainly by the addition
of IMSI acquisition.
This patch moves that code into several smaller functions. In
addition, the peer resolution which is similar to that in
gbprox_process_bssgp_dl is moved into a separate function, too.
Sponsored-by: On-Waves ehf
This allows us to know what number of messages and bytes has been
received per active osmux endpoint.
Note that an Osmux message is composed of several chunks. Each chunk
contains an osmux header plus several voice data frames.
P: PS=385, OS=11188, PR=195, OR=5655, PL=0, JI=49
X-Osmo-CP: EC TIS=0, TOS=0, TIR=0, TOR=0
X-Osmux-ST: CR=51, BR=3129
The new 'X-Osmux-ST:' notifies the received chunks and bytes.
This patch removes the patch_mode feature including the related VTY
command patch-mode. Where sensible, the other configuration flags are
queried instead.
In addition, this initial checks in gbprox_process_bssgp_dl() and
gbprox_process_bssgp_ul() have been updated.
The patch mode feature has not been used and was increasingly
difficult to maintain.
Sponsored-by: On-Waves ehf
This patch add explicit tests for
- gbproxy_peer_by_bvci
- gbproxy_peer_by_nsei
- gbproxy_cleanup_peers
- gbproxy_peer_by_rai
- gbproxy_peer_by_lai
- gbproxy_peer_by_lac
and for messages with an unknown TLLI sent by the SGSN.
Sponsored-by: On-Waves ehf
Currently the stored messages are only removed, when IMSI acquisition
has succeeded. In addition, receiving two ATTACH_REQ messages in
sequence (e.g. due to loss of a Identity Req/Resp message) will not
restart the IMSI acquisition procedure.
This patch adds gbproxy_tlli_info_discard_messages() to clean up the
message list and calls it from gbproxy_delete_tlli() fixing a
potential memory leak. It is also called when an Attach Request
message has been received. In that case the imsi_acq_pending flag is
cleared, too. This would (re-)trigger the IMSI acquisition procedure
at each of these messages. If an Ident Response has been lost,
resending the Ident Request with the same N(U) will not work.
Therefore the N(U) gets incremented on each Ident Request generated
by the gbproxy. The first N(U) used is 256 which shouldn't collide
with the V(UT) used by the SGSN given that P-TMSI patching is enabled
(since a new random TLLI is used initially on every new (no
tlli_info) connection and V(U) starts with zero then).
Ticket: OW#1261
Sponsored-by: On-Waves ehf
If the Attach Request procedure gets restarted e.g. because of a lost
message, all of these messages are stored if IMSI acquisition is in
progress.
This patch adds a test for this case and modifies the dump_peers
function to output the number of stored messages.
Note that the number of stored messages currently increases with each
(repeatedly) received Attach Request which is not the desired behaviour.
Sponsored-by: On-Waves ehf
Currently, a new P-TMSI within an Attach Accept or within an RA
Update Request is applied to the TLLI mapping (gbproxy_reassign_tlli)
_before_ patching is done. This can lead to inconsistent behaviour
when the TLLI validation has not been completed, which is the case
when subsequent RA UDP REQ are received. The new TLLI must not be
applied to the message itself yet, it should only be considered for
following messages.
This patch moves the TLLI reassignment to
gbproxy_update_tlli_state_after() to fix that.
It also separates the implementation of the feature that a new
tlli_info can be created when such a message is received from the
SGSN. This makes sense, when P-TMSI patching is not active and the
tlli_info entry has expired.
Sponsored-by: On-Waves ehf
Currently tlli_info are created for SGSN originated messages when
the SGSN TLLI cannot be found and P-TMSI patching is active. This
doesn't make much sense, since the BSS side TLLI is not known in this
case. Given that the SGSN is working properly, that can only happen
if either the tlli_info has expired or the gbproxy has been
restarted.
This patch disables the creation of a tlli_info in this case.
Note that these messages are passed unmodified to the MS so far.
Sponsored-by: On-Waves ehf
This adds a sequence of two RA update procedures to
test_gbproxy_ptmsi_patching(). Each of them assigns a new P-TMSI.
Note that the implementation fails to patch the RAI within the
message labelled 'RA UDP ACC (P-TMSI 3)' and logs 'TLLI sent by the
SGSN is unknown'.
Sponsored-by: On-Waves ehf
Since the secondary SGSN selection and APN patching can both be
enable/disabled by IMSI matching, this patch introduces a separate
match-imsi command and removes the corresponding variant of the
core-access-point-name command.
P-TMSI patching and IMSI acquisition are enabled/disabled by
match-imsi resp. secondary-sgsn. The patch-ptmsi and acquire-imsi
commands are still available for internal testing but are subject to
being removed.
Sponsored-by: On-Waves ehf
This patch extends the 'show gbproxy tllis' command to display the
number of stored messages per tlli_info if there are any.
Sponsored-by: On-Waves ehf
Currently all STATUS messages coming from the SGSN are just logged
and dropped. This prevents the PCU from recognising that the
(secondary) SGSN doesn't know about a certain BVCI and might require
a reset procedure.
This patch changes gbprox_rx_sig_from_bss() to forward STATUS
messages with cause "Invalid BVCI" containing a BVCI to the BSS.
Note that this will not forward broken "Invalid BVCI"
messages which do not include a BVCI IE.
Sponsored-by: On-Waves ehf
Currently the gbproxy sends STATUS messages that are not compliant to
GSM 08.18, 10.4.14.1: The BVCI must be included if (and only if) the
cause is either "BVCI blocked" or "BVCI unknown".
This patch adds a missing BVCI to UNKNOWN_BVCI and BVCI_BLOCKED
status messages if the BVCI is available. Otherwise, INV_MAND_INF is
used instead.
Sponsored-by: On-Waves ehf
Currently the numeric TLLI or tlli_info's enable_patching flag is
used to decide, whether a APN shall be patched or the secondary SGSN
shall be used. Using the numeric TLLI imposes a problem, when
TLLI/P-TMSI patching is used, since gbproxy_check_tlli uses the BSS
side TLLI namespace when trying to get the tlli_info.
This patch modifies the gbproxy_check_tlli() function to accept a
tlli_info pointer instead of a numeric TLLI. The tlli_info is already
available when the function is called. Since this a similar approach
has been used by accessing the enable_patching flag directly, this
commit unifies checking by always using this function instead of the
flag outside of gb_proxy_tlli.c.
This fixes the APN patching that doesn't work currently when P-TMSI
patching is enabled.
Sponsored-by: On-Waves ehf
This commit adds a single ACT PDP CTX REQ message to
test_gbproxy_ptmsi_patching() to check whether APN patching works in
this case, too.
Note that this doesn't work currently, the APN patch count is not
incremented.
Sponsored-by: On-Waves ehf
Currently the new command acquire-imsi and secondary-sgsn are not
included into the write command's output.
This is fixed by this commit.
Sponsored-by: On-Waves ehf
Some messages that are related to the BVC itself must be forwarded to
the secondary SGSN, too.
This patch implements this for BVC-RESET (BVCI != 0) and FLOW-CONTROL-BVC
messages. The resulting acknowledgement messages from the secondary
SGSN are silently dropped. The idea behind this is that the primary
SGSN is responsible for setting up and maintaining the BVC whereas
the secondary SGSN is rather passive and just has to accept it.
Ticket: OW#1258
Sponsored-by: On-Waves ehf
This patch modifies gbprox_process_bssgp_ul() to send the message to
the secondary SGSN if the IMSI has matched and routing to the
secondary SGSN is enabled. The destination for stored messages is
modified accordingly.
Ticket: OW#1261
Sponsored-by: On-Waves ehf
This patch adds a case to test the establishment (and shutdown) of
connection between 2 MS and 2 SGSN, where the assignment is based
on each IMSI. Since BVC-RESET and FLOW-CONTROL-BVC will have to be
sent to both SGSN, an ACK is simulated for both.
New functions to generate FLOW-CONTROL-BVC(-ACK) messages are
provided.
It modifies dump_peers to add the string "IMSI matches" to a TLLI dump
line if appropriate.
Note that there is no real support to use a secondary SGSN in the
gbproxy yet, but the test code reflects the expected behaviour when
the feature is implemented.
Sponsored-by: On-Waves ehf
This patch refactors SGSN NSEI handling to support a secondary SGSN.
It adds the following VTY commands:
- secondary-sgsn nsei <0-65534>
- no secondary-sgsn
Sending messages to the secondary SGSN is not yet implemented, but
received messages from such a SGSN would be forwarded to the BSS
peers.
Sponsored-by: On-Waves ehf
This should have been part of the 'Implement IMSI acquisition'
commit, where a similar change has been made for BSS originated PTP
messages.
Sponsored-by: On-Waves ehf
We want to reduce the background traffic and might set the ping
interval to be in the range of minutes. But this means that if
the TCP connection is frozen several "SCCP CR CM Service Requests"
will be stuck in the send queue without ever being answered. I
could have used the logic of not receiving the "SCCP CC" to close
the connection but instead I am introducing an overload to schedule
the ping as part of the normal SCCP connection establishment.
The VTY write case has been manually verified, I have also looked
at a single trace to see that the SCCP CR and the IPA PING is
transfered in the same ethernet frame.
Jacob ran the tests with ASAN and noticed that the state is
dead. This is on purpose as we have forced a change in the
transcoding. Re-load the state and verify that it has not
changed in the other cases.
To modify or route messages based on the IMSI the latter must be known
when the action shall take place.
This patch modifies the gbproxy to optionally retain and enqueue
messages from the MS while initiating an identification procedure.
Further message processing of the LLC PTP link towards the SGSN will
be done, when the identity of the MS has been acquired.
Note that the N(U) of the LLC GMM SAPI are not adjusted, so it is
possible that adjacent messages of a single LLC link arriving either
at the BSS or the SGSN have the same N(U) and might get discarded,
leading to retransmissions and additional delay.
Note also that retransmissions and packet loss are not yet handled
explicitely. If for instance the generated IDENT REQ gets lost, the
gbproxy will not act on its own. In this case, the MS will time out
and eventually resend the Attach Request on which the gbproxy will
act exactly like before (thus having two Attach Req messages in its
queue, which will both be sent after the Ident Resp arrives).
This has been tested successfully with an E71, needing one
retransmission by the SGSN due to an N(U) collision.
Ticket: OW#1261
Sponsored-by: On-Waves ehf
This patch copies test_gbproxy_ptmsi_patching to
test_gbproxy_imsi_acquisition as a base for a later test for IMSI
acquisition (which is not yet implemented). The idea behind this is
to make the different behaviour visible in the ok file without
compromising the P-TMSI test.
Sponsored-by: On-Waves ehf
Currently when patching is enabled and an error happens when
receiving a message from the SGSN, the patched message is sent back
with the PDU_IN_ERROR IE.
This patch modifies gbprox_rx_sig_from_sgsn() to copy the message
before it is patched, so that the original message can be used with
the STATUS message. gbprox_rx_ptp_from_sgsn() does all checks before
the message is patched, so copying is not necessary.
Since gbprox_rx_sig_from_sgsn() is not called for BSSGP UNITDATA
messages and the msgb is already been copied in the gbprox_relay2peer
function, the relative performance impact is expected to be low.
Note that the PDU IE of STATUS messages received from an MS and
forwarded to the SGSN will not be patched. STATUS messages from the
SGSN are only logged and not forwarded to the MS.
Sponsored-by: On-Waves ehf
Currently messages like these with a TLLI IE (BSSGP) are not
tested (properly) with TLLI patching.
This patch extends the send_bssgp_suspend* functions to accept a
TLLI as argument and adds the send_bssgp_llc_discarded function.
These are then used in test_gbproxy_ptmsi_patching() with a valid
TLLI.
Note that the TLLI IE patching doesn't work currently.
Sponsored-by: On-Waves ehf
This patch adds gbprox_rx_data_from_sgsn() and
gbprox_rx_ptp_from_bss() which contain the PTP message processing
of gbprox_rcvmsg(). The calls to gbprox_process_bssgp_ul() are moved
from gbprox_relay2sgsn() to gbprox_rx_ptp_from_bss() and
gbprox_rx_sig_from_bss().
The goal is, to do all patching (and calls to gbprox_process_bssgp_*)
from within the gbprox_rx_* functions. Doing the patching from within
gbprox_relay2sgsn has the drawback, that the patching code cannot
call gbprox_relay2sgsn() which is needed if a single message shall
trigger a sequence of messages.
Sponsored-by: On-Waves ehf
The compiler also uses this attribute for code elimination. If the
nonnull attribute has been given erroneously for an parameter, that
is later been checked against NULL, this check is removed silently
by the gcc if optimization is enabled. This can lead to hard-to-find
segmentation violation faults.
To be on the safe side, this patch removes all uses of the nonnull
attribute in openbsc.
Compiler:
- gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1): no warning, segfault
- clang 3.4 (3.4-1ubuntu3): no warning, no segfault, asm ok
Example:
/* foo.c */
int f(int* p) __attribute((nonnull));
int f(int *p) {
if (!p)
return 0;
return *p;
}
/* main.c */
int f(int* p) __attribute((nonnull));
int g () {
return f(arg);
}
int main() {
return g(NULL);
}
When these files are compiled into an executable, no warnungs are
issued but it will fail with a segfault when -O2 is used (unless LTO
is active).
Compiler output (gcc -O2):
int f(int *p) {
0: 8b 44 24 04 mov 0x4(%esp),%eax
4: 8b 00 mov (%eax),%eax
6: c3 ret
}
Sponsored-by: On-Waves ehf
In case we get offered G729 and G711 we might have selected
G729 as the audio codec. The first packet we receive might be
G711 though. In that case we will need to change. But only if
we have a matching alternate codec payload_type. E.g. in the
case of comfort noise we will receive the PT=11 and we don't
want to change.
In case of some RTP proxy from time to time we are offered both
G729 and G711 but only one of them will work. I intend to adjust
the codec at runtime in case we receive the wrong codec.
We might be offered multiple codecs by the remote and need to
switch between them once we receive data. Do this by moving it
to a struct so we can separate between proposed and current
codec. In SDP we can have multiple codecs but a global ptime.
The current code doesn't separate that clearly instead we write
it to the main codec.
Use the rtp_hdr structure. The basic alignment issue remains
and I need to merge/cherry-pick Jacob's getters for the ts,
sequence number and other attributes.
./configure --help indicates:
--enable-external-tests Include the VTY/CTRL tests in make check
[default=no]
but
./configure ... --enable-external-tests
configure: WARNING: unrecognized options: --enable-external-tests
the name of the option seems to be --enable-ext-tests.
The library allows to indicate zero as batch size if you want to use
the default size, however openbsc saves 'osmux batch-size 0' which is
not good as input.
Use OSMUX_BATCH_DEFAULT_MAX to explicitly initialize the batch size
from mgcp_parse_config().
The talloc_free on the nat lead to the freeing of the bsc_config
which lead to freeing of the rate_ctr_group. The rate_ctr_group
remained in a global list and the next creation of a bsc_config
would access dead memory. Fix it.
The free routine is only meant to be used by the test, for the
real nat we would need to make sure that all connections and
other state that refers to the cfg is removed/closed first.
Fix various memleaks in the test while we are at it. There are
still some to fix.
==7195== Invalid write of size 4
==7195== at 0x4043171: rate_ctr_group_alloc (linuxlist.h:65)
==7195== by 0x804D893: bsc_config_alloc (bsc_nat_utils.c:174)
==7195== by 0x804B5D2: main (bsc_nat_test.c:954)
==7195== Address 0x4311cbc is 52 bytes inside a block of size 208 free'd
==7195== at 0x4029D28: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==7195== by 0x4048D98: _talloc_free (talloc.c:609)
==7195== by 0x4052806: talloc_free (talloc.c:578)
==7195== by 0x804B58A: main (bsc_nat_test.c:940)
bsc_nat_ctrl.c: In function ‘set_net_cfg_cmd’:
bsc_nat_ctrl.c:360:3: warning: implicit declaration of function ‘bsc_replace_string’ [-Wimplicit-function-declaration]
bsc_replace_string(bsc_cfg, &bsc_cfg->acc_lst_name, cmd->value);
^
gbproxy_patch_bssgp: Move a check for tlli_info in front of the first
conditional that depends on it, and return immediately if it is NULL.
gbproxy_register_tlli: Initialize tlli_already_known to 0.
Fixes: Coverity CID 1232691
Fixes: Coverity CID 1232692
Sponsored-by: On-Waves ehf
Remove redundant information log message:
<000b> bsc_mgcp_utils.c:647 BSC doesn't want to use Osmux, failing back to RTP
<000b> bsc_mgcp_utils.c:669 bsc didn't accept to use Osmux (cid=0)
One single log message is just fine. The error path already indicates
the precise reason not to accept the request to use Osmux.
This patch includes several osmux fixes that are interdependent:
1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This
announces the circuit ID in the CRCX MGCP message. This aims to resolve
the lack of uniqueness due to the use of endp->ci, which is local to
the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux
circuit ID.
2) The dummy load routines are now used to setup osmux both in bsc and
bsc-nat to resolve source port NAT issues as suggested by Holger. The
source port that is used from the bsc is not known until the first
voice message is sent to the bsc-nat, therefore enabling osmux from
the MGCP plane breaks when a different source port is used.
3) Add refcnt to struct osmux_handle, several endpoints can be using the
same input RTP osmux handle to perform the batching. Remove it from the
osmux handle list once nobody is using it anymore to clean it up.
4) Add a simple Osmux state-machine with three states. The initial state
is disabled, then if the bsc-nat requests Osmux, both sides enters
activating. The final enabled state is reached once the bsc-nat sees
the dummy load message that tells what source port is used by the bsc.
5) The osmux input handle (which transforms RTP messages to one Osmux batch)
is now permanently attached to the endpoint when Osmux is set up from the
dummy load path, so we skip a lookup for each message. This simplifies
osmux_xfrm_to_osmux().
After this patch, the workflow to setup Osmux is the following:
bsc bsc-nat
| |
|<------ CRCX ----------|
| X-Osmux: 3 | (where 3 is the Osmux circuit ID
| | that the bsc-nat has allocated)
|------- resp --------->|
| X-Osmux: 3 | (the bsc confirm that it can
| | use Osmux).
. .
| |
setup osmux |----- dummy load ----->| setup osmux
| Osmux CID: 3 |
In two steps:
1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique
Osmux CID that is notified to the bsc through the 'X-Osmux:' extension.
The bsc-nat annotates this circuit ID in the endpoint object. The bsc
replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux.
If the bsc doesn't want to use Osmux, it doesn't include the extension
so the bsc-nat knows that it has to use to RTP.
2nd) The dummy load is used to convey the Osmux CID. This needs to happen
at this stage since the bsc-nat needs to know what source port the bsc
uses to get this working since the bsc may use a different source
port due to NAT. Unfortunately, this can't be done from the MGCP signal
plane since the real source port is not known that the bsc uses is not
known.
This patch also reverts the MDCX handling until it is clear that we need
this special handling for this case.
In the bsc-nat side, the osmux socket initialization can be done from
the vty. This ensure that the osmux socket is available by the time the
bsc-nt receives the dummy load that confirms that the osmux flow has
been set up.
This change is required by the follow up patch. This change ensures that
the Osmux socket in the bsc-nat is already in place by the time this
receives the dummy load.
Back in March 2013, some structures and defines related to decoded
measurement reports have been moved from openbsc to libosmocore
(libosmocore e128f4663104ed64e33e362cff2566f36d65e658) so that they can
be used also from osmo-bts. This finally makes gsm_lchan follow suit
for osmo-bts.
The gb_proxy shouldn't start to open the box of pandora by including the
gsm_data_shared.h file, particularly not without defining the BSC role.
In any case, as the reserved TMSI is something that's part of the GSM
specs, and not specific to the OpenBSC implementation, it should be part
of libosmocore.
All review feedback will be addressed _after_ the split of the
files. This is the only reasonable approach to get the split of
files merged. I didn't have the time to review all of the code
before the point of splitting.
This patch moves the peer related definitions from gb_proxy.c to
gb_proxy_peer.c and adjusts the prefix of each global symbol to
gbproxy_:
Peer definitions (prefix adjusted to gbproxy_):
peer_ctr_description -> gprs/gb_proxy_peer.c (static)
peer_ctrg_desc -> gprs/gb_proxy_peer.c (static)
*peer_by_* -> gprs/gb_proxy_peer.c
gbproxy_peer_alloc -> gprs/gb_proxy_peer.c
gbproxy_peer_free -> gprs/gb_proxy_peer.c
gbprox_cleanup_peers -> gprs/gb_proxy_peer.c
Sponsored-by: On-Waves ehf
This patch moves several functions and declarations out of gb_proxy.c
to make them reusable by other components and to separate them by
context and task.
Counter enums (prefix is changed to gbproxy_):
enum gbprox_global_ctr -> gprs/gb_proxy.h
enum gbprox_peer_ctr -> gprs/gb_proxy.h
Generic Gb parsing (prefix is changed to gprs_gb_):
struct gbproxy_parse_context -> openbsc/gprs_gb_parse.h
gbprox_parse_dtap() -> gprs/gprs_gb_parse.c
gbprox_parse_llc() -> gprs/gprs_gb_parse.c
gbprox_parse_bssgp() -> gprs/gprs_gb_parse.c
gbprox_log_parse_context() -> gprs/gprs_gb_parse.c
*_shift(), *_match() -> gprs/gprs_gb_parse.c (no prefix)
gbprox_parse_gmm_* -> gprs/gprs_gb_parse.c (static)
gbprox_parse_gsm_* -> gprs/gprs_gb_parse.c (static)
MI testing/parsing (prefix gprs_ added):
is_mi_tmsi() -> gprs/gprs_utils.c
is_mi_imsi() -> gprs/gprs_utils.c
parse_mi_tmsi() -> gprs/gprs_utils.c
TLLI state handling (prefix is changed to gbproxy_):
gbprox_*tlli* -> gprs/gb_proxy_tlli.c
(except gbprox_patch_tlli, gbproxy_make_sgsn_tlli)
Message patching (prefix is changed to gbproxy_):
gbprox_*patch* -> gprs/gb_proxy_patch.c
gbprox_check_imsi -> gprs/gb_proxy_patch.c
Sponsored-by: On-Waves ehf
Add LLC test messages containing XID (SAPI LLGMM, U frame) and IP traffic
(SAPI LL11, UI frame).
Add a test case containing a complete SGSN session with TLLI/PTMSI
patching enabled.
Sponsored-by: On-Waves ehf
This patch modifies gbprox_make_bss_ptmsi() to generate a new P-TMSI
when patch_ptmsi is set in the configuration instead of using the
P-TMSI assigned by the SGSN. It modifies gbprox_make_sgsn_tlli() to
either use a foreign TLLI based on the SGSN side P-TMSI or (if there
is none) generate a random TLLI if patch_ptmsi is set. Otherwise, the
TLLI used by the BSS is used.
The seeds for the pseudo-random sequences sre set based on time
initially. Note that these are neither cryptographically safe nor
protected against collisions.
Ticket: OW#1259
Sponsored-by: On-Waves ehf
This patch contains fixes for the TLLI tracking and handling.
It adds and uses gbprox_map_tlli() the map the source TLLI to the
destination TLLI while respecting whether it is current or assigned.
It removes gbprox_register_tlli() from the downlink path. It fixes
TLLI validation and disables the use of the BSSGP TLLI IE.
Sponsored-by: On-Waves ehf
Currently, these messages lead to a parsing error which prevents them
from being processed any further.
This patch sets the return value of gbprox_parse_llc to 1 in these
cases and fixes a segfault which is triggered by any non-04.08
message.
Sponsored-by: On-Waves ehf
Currently gbprox_patch_raid() updates the local MCC/MNC with every
BSS originated message, even if the RAI is an 'old' one.
This patch separates state updating and patching into 2 functions
gbprox_update_current_raid and gbprox_patch_raid. In addition, a
field named old_raid_enc is added to gbproxy_parse_context, which is
used for 'old RAI' IEs in Attach Requests and RA Update Requests.
Only the bssg_raid_enc in BSS originated message is used to update
the BSS side 'local' MCC/MNC.
Sponsored-by: On-Waves ehf
This patch splits the functionality of gbprox_get_detached_tlli_info
into 2 new functions:
- gbprox_tlli_info_alloc to allocate an intialized and detached
tlli_info
- gbprox_detach_tlli_info to detach an already attached tlli_info
Sponsored-by: On-Waves ehf
This VTY command add the following commands to the gbproxy node:
- patch-ptmsi: Enables P-TMSI/TLLI patching
- no patch-ptmsi: Disables P-TMSI/TLLI patching
Note that using these commands interactively can load to undefined
behavior of existing LLC connections.
Sponsored-by: On-Waves ehf
This patch separates BSS side from SGSN side TLLI/PTMSI tracking. When
TLLI/PTMSI patching is not enabled, the corresponding states shall be
identical. The TLLI/PTMSI state has been moved into the struct
gbproxy_tlli_state and is used twice in gbproxy_tlli_info.
Since the state handling for uplink and downlink messages is
diverging, gbprox_update_state() is replaced by two functions
gbprox_update_state_dl/gbprox_update_state_ul and
gbprox_process_bssgp_message() is replaced by
gbprox_process_bssgp_dl/gbprox_process_bssgp_ul.
Sponsored-by: On-Waves ehf
This patch adds the functions send_bssgp_ul_unitdata(),
send_bssgp_dl_unitdata(), send_llc_ul_ui(), and send_llc_dl_ui().
They are used instead of send_ns_unitdata() in
test_gbproxy_ra_patching(). This make it easier to modify TLLI, N(U),
and other parameters.
Sponsored-by: On-Waves ehf
The following parts of the messages have been fixed
- Attach Accept: checksum
- Attach Complete: checksum
- RA Update Accept: Use the same MS Radio Access Capabilities and
DRX Parameters like the other messages
The N(U) of most messages have not been fixed.
Sponsored-by: On-Waves ehf
Don't replace the current TLLI immediately, store it in an additional
'assigned_tlli' field and discard the old TLLI when both sides have
used the new one (see GSM 04.08, 4.7.1.5).
Add an Attach Complete message to test and check, whether the related
field of the corresponding tlli_info struct are set as expected
during the local TLLI validation cycle.
Sponsored-by: On-Waves ehf
Currently the enable_patching field in tlli_info is not updated,
when an IMSI is assigned to a TLLI that is already known.
This patch fixes this in gbprox_update_state() after the call to
gbprox_update_tlli_info().
The number of APN increases and the test output file is updated
accordingly.
Sponsored-by: On-Waves ehf
GSM 24.008 also allows a P-TMSI field in Detach request messages.
This patch adds gbprox_parse_gmm_detach_req() to parse Detach Request
messages which sets the ptmsi field if the IE is present.
In addition, when power_off is set to 1 (MO only), the
invalidate_tlli field is set, since Detach Request message is
expected in this case.
The second detach test (see 'RA update') is modified to use
power_off instead of relying on a Detach Accept from the network.
To make this work, the PTMSI of the RA Update Accept is fixed to
match the TLLI of the Detach Request.
Sponsored-by: On-Waves ehf
We started with only testing the VTY but now test VTY and CTRL
interface with this python framework and might even extend this
to SMPP. So add and "--enable-external-tests" directive which
enables the external interface tests.
Add a separate function to clear the IMSI filter to be used instead of
gbprox_set_patch_filter(cfg, NULL, ...). Albeit it fixes a Coverity
issue (Unchecked return value), it is a false positive, since the
return value is always 0 in these cases. Nevertheless it is more
obvious what happens when an explicit clear function is called. Using
NULL as filter argument of gbprox_set_patch_filter still clears the
filter.
Fixes: Coverity CID 1231255
Sponsored-by: On-Waves ehf
As bsc_ctrl_node_lookup() is called for each iteration,
the variables 'bts' and 'trx' are no longer static accross multiple
calls, which means we need a different way to determine if we are in the
right node while matching for a trx or a ts.
Now that the bulk of the control interface node lookup has
no reference to the BSC specific data structures, we are
moving it into libosmocore.
A control interface user now only registers an optional small
node lookup function like bsc_ctrl_node_lookup()
The idea here is that bsc_ctrl_cmd_handle now has no dependency
at all to the BSC related data structures and thus can actually become
part of libctrl.
The new function bsc_ctrl_node_lookup however will remain bsc-specific.
This patch modifies the code to pass a pointer to the tlli_info
around once it has been acquired. To achieve this,
gbprox_register_tlli() and gbprox_update_state() are modified to
return it (if it has been found or created), and gbprox_patch_llc(),
gbprox_patch_bssgp(), and gbprox_update_state_after() are modified to
take it as parameter.
Add a new function gbprox_touch_tlli() to update timestamp and list
ordering for existing tlli_infos.
The motivation behind this patch is to make the tlli_info available to
the patching code and to avoid repeated searches for the same TLLI.
Sponsored-by: On-Waves ehf
The current implementation of this function is O(N), where N is the
number of entries.
The new implementation is O(D), where D is the number of entries that
are going to be deleted.
Sponsored-by: On-Waves ehf
This patch adds a combined expiry test to remove one entry by list
length and another by age.
This patch also modifies the existing age based test to register both
TLLI with a different timestamp and to remove only one of the TLLI
entries by age based expiration.
Sponsored-by: On-Waves ehf
Currently time() is called at several places to control TLLI aging.
Beside calling time() more often than necessary, the decision which
timesource is to be used is coded into the TLLI handling, and testing
complex aging scenarios is cumbersome.
This patch passes the current time as a parameter instead. The call
to time() is moved to gbprox_process_bssgp_message().
Sponsored-by: On-Waves ehf
This patches removes the call to gbprox_remove_stale_tllis()
from gbprox_register_tlli(), so it must be called explicitly now.
The call is now done from within gbprox_update_state_after().
In addition, the TLLI cache size counter is also kept in sync when
gbprox_remove_stale_tllis is called manually. The call to
gbproxy_peer_free() in gbproxy_peer_free() is moved behind the TLLI
to allow for counter updates in gbprox_delete_tlli().
Sponsored-by: On-Waves ehf
This patch refactors that function by separating the actual patch
code into a new function gbproxy_patch_bssgp(), similar to
gbproxy_patch_llc(). The remaining function is renamed to
gbproxy_process_bssgp_message. The existing function
gbproxy_parse_bssgp_message() is renamed to
gbproxy_process_bssgp_message to match gbproxy_parse_llc.
Sponsored-by: On-Waves ehf
This adds a test for gbprox_set_patch_filter() and
gbprox_check_imsi().
It also fixes the masking of the type field when IMSIs are checked by
using GSM_MI_TYPE_MASK (0x07) instead of 0x0f.
Sponsored-by: On-Waves ehf
Currently only TLLIs for which it is known that they may be patched
are put into the TLLI list.
This patch changes this to add TLLIs even when the IMSI is not yet
known. A enable_patching flag is added to the gbproxy_tlli_info
structure to control patching.
Note that this puts every active TLLI into the list where accesses
are O(N) currently.
Sponsored-by: On-Waves ehf
This adds parsing support for the following messages:
- Attach Request: IMSI/PTMSI
- Identity Response: IMSI/PTMSI
- BSSGP: Optional TLLI IE
- BSSGP/PAGING_PS: PTMSI
A new new_ptmsi_enc field is added for newly assigned PTMSI in
SGSN->BSS messages (instead of ptmsi_enc). The ptmsi_enc field is now
used for informational PTMSI IE in messages.
Sponsored-by: On-Waves ehf
This adds a gbprox_parse_bssgp_message() function that contains the
parsing part of the former gbprox_patch_bssgp_message(). This
includes a call to gbprox_parse_llc().
The calls to gbprox_patch_llc(), gbprox_update_state() and
gbprox_update_state_after() have therefore been moved to
gbprox_patch_bssgp_message().
Sponsored-by: On-Waves ehf
This patch unifies the TLLI tracking for all LLC messages. The TLLI
state handling is moved into separate functions.
Only Detach Accept messages are taken into account to release a TLLI,
which is safe but not optimal.
Sponsored-by: On-Waves ehf
Currently, parsing and optionally patching is done in the same
functions (e.g. gbprox_patch_gmm_attach_req()).
This patch moves the patching code out of these functions into
gbprox_patch_llc() and just stores pointers to the relevant data
areas into parse_ctx. Consequently the len_change parameter is
removed and the _patch_ in the function's names is renamed to
_parse_. In addition, the patching_is_enabled checks and counter
increments are moved out of these functions, too.
Sponsored-by: On-Waves ehf
Send a non-call related SS message for an active call indentified
by the CIC of that call. As an ugly hack the order of the SS
release and the invocation are changed. That was necessary for the
E71 on a TCH. The time between notify and release was just too short.
The right would be to wait for the returnResultLast but this would
involve keeping more local state. Let's see how far we get here. It
might be necessary to change the order in the other call sites as
well.
Some broken equipment does not convert the P-TMSI to a Local TLLI.
This leads to the SGSN ignoring the GPRS Attach Complete message
from the phone. Proprietary SGSNs and some documentation we found
state that one should always set the two highest bits of a P-TMSI
to one. This will help broken equipment and will avoid a potential
P-TMSI/TLLI clash. The P-TMSI/Local TLLI mapping is now bijective.
Currently gbprox_register_tlli() is a rather complex function.
This patch splits it into several smaller functions to ease reviewing
and maintaining it.
Sponsored-by: On-Waves ehf
This adds a unit test for gbprox_register_tlli() and
gbprox_remove_stale_tllis().
The dump_peers() function is extended by a cfg parameter to support
a non-global gbproxy_config.
Done with Jacob
This comparison bit-ored the TLLI with 0xc000 instead of 0xc000000.
Since this has never worked properly yet and since normalizing to
local TLLIs doesn't seem sensible here, the comparison is removed
entirely.
Sponsored-by: On-Waves ehf
In these functions we assume that peer is not NULL. Add a compiler
attribute in the hope that either coverity or GCC/Clang will help
us to find a misusage.
Done with Jacob
Global state prevents us from writing simple units tests for
single routines. Go through the code and add pointers to the
gbproxy configuration. Only the vty and the test code remain
using the global gbproxy instance.
Create a testcase for the gprs_str_to_apn and gprs_apn_to_str
routines. While writing the testcase we noticed it is possible to
write more bytes than should have been allowed. This is fixed by
checking that the max_len is at least 1 (needed to write the first
length octet) and to do the size check before writing to the output.
Modify the signature of gprs_str_to_apn to put the length/size next
to the parameter that requires a size.
Done with Jacob
We intend to move some of these routines to libosmocore but to avoid
a feature symbol clash we are prefixing these routines with gprs_.
Done with Jacob
The application is called gbproxy but the structures and functions
were inconsistently named as either gbprox or gbproxy. Rename all
structures to use gbproxy.
Done with Jacob
Move the global data into the struct and use it. gbprox_reset will
first free data and then re-initialize the structure. This code is
used by the unit test.
Done with Jacob
Timing advance is stored inside lchan structure, so it is removed from
arguments. This is useful, if other actions are required prior calling
rsl_chan_activate_lchan. (like deactivating PDCH first)
The "shifted TA value" that is required by BS11 is now calculated inside
rsl_chan_activate_lchan and not by each user.
[Rebased by Holger. So some hunks were skipped as the patch
depended on Jolly's HO code]
rtp_proxy.c: In function ‘rtp_decode’:
rtp_proxy.c:199:8: warning: assignment from incompatible pointer type
frame = msgb_put(new_msg, sizeof(struct gsm_data_frame));
This commit moves the fixing code of the length field of the LLC
information element to the BSSGP patching level since that is not a
part of LLC itself.
Sponsored-by: On-Waves ehf
This commit adds code to parse the PTMSI in network originated
messages
- Attach Accept,
- Routing Area Update Accept, and
- P-TMSI Reallocation Command (see below)
to keep track of the TLLI identifying the LLC connection.
The P_TMSI Realloc Command specific code is not being tested yet, so
a corresponding notice is logged when such a message will be
received.
NOTE:
The gbproxy will lose the TLLI when the MS doesn't receive/use
the message (normally the SGSN remembers the old TLLI for some time
to avoid this kind of problem). If this happens the MS will
probably restart the procedure and the network will have to answer
again eventually using one of the above messages which will
re-associate the IMSI with the TLLI before the MS can send a
PDP Context Request message.
Ticket: OW#1192
Sponsored-by: On-Waves ehf
Add a struct containing context information from the parts of the
message that have been parsed already. A pointer to this (temporary)
struct is passed to parse/patch functions.
Sponsored-by: On-Waves ehf
Currently the patching code directly accesses the single bytes to
parse the LLC/DTAP messages.
This patch uses the shift functions instead to parse tlv and similar
structures.
Sponsored-by: On-Waves ehf
This adds a set of function that parse a single tlv, lv, tv, or v
encoded information element. They are complementary to the *_put
functions defined in libosmocore's tlv.h file. The functions update
the data and data_len fields unless they are a 'match' function and
the tag field doesn't match.
Sponsored-by: On-Waves ehf
Currently the enabled_tllis_count field isn't always decremented when
an element is removed from the TLLI cache list.
This patch adds the missing update and also adjusts the counter
accordingly.
Sponsored-by: On-Waves ehf
Add TLLI cache output to gbprox_dump_peers() to include this info
into the test output.
Separate RA Update Req message handling from Attach Request handling.
Note: There is no test case for the P-TMSI Reallocation Command yet.
Sponsored-by: On-Waves ehf
This commit adds the following counters:
- attach-reqs: Number of Attach Request messages
- attach-rejs: Number of Attach Reject messages
- tlli-cache: Size of the TLLI cache
Sponsored-by: On-Waves ehf
These commands manage the TLLI list used to decide whether an APN
shall be patched or not. Note that this list is (currently) only
maintained if IMSI matching is used.
VTY commands (enable node):
show gbproxy tllis show all TLLI entries
delete-gbproxy-tlli NSEI stale purge all stale entries
delete-gbproxy-tlli NSEI imsi IMSI purge entry with the IMSI given
delete-gbproxy-tlli NSEI tlli TLLI purge entry with the TLLI given
Sponsored-by: On-Waves ehf
This patch adds IMSI/TLLI connection tracking and uses it to control
APN patching based on the IMSI. TLLI entries can expire based on age
and/or by limiting the TLLI list size.
VTY config-gbproxy:
no core-access-point-name disable APN patching
core-access-point-name none remove APN if present
core-access-point-name APN replace APN if present
core-access-point-name none match-imsi RE remove if IMSI matches
core-access-point-name APN match-imsi RE replace if IMSI matches
tlli-list max-age SECONDS expire after SECONDS
no tlli-list max-age don't expire by age
tlli-list max-length N keep N entries only
no tlli-list max-length don't limit list length
RE is an extended regular expression, e.g. ^12345|^23456
Ticket: OW#1192
Sponsored-by: On-Waves ehf
Currently, all patching state is stored globally in the gbproxy. Thus
the feature cannot be used safely with a concentrating gbproxy (NAT).
This patch moves the state and relevant counters to the gbprox_peer
structure. It adds code to resolve the corresponding peer when
packets are received by looking at BVCI, NSEI, and BSSGP IEs (BVCI,
RAI/LAI/LAC) when the peer is not passed to the
gbprox_patch_bssgp_message() function.
Test cases are also added for the SGSN->BSS case including test cases
with invalid identifiers.
Note that this patch should make it possible to use RAI patching at a
NAT gbproxy as long as the messages are not encrypted.
Ticket: OW#1185
Sponsored-by: On-Waves ehf
This patch adds a Detach Request (MO) / Detach Accept sequence to the
test, followed by another (here invalid) Act PDP Context Req which
should be APN patched.
Sponsored-by: On-Waves ehf
Add a DTAP GMM Information message with an IMSI in the BSSGP header
to enable the association between IMSI and TLLI.
The TLLI of the Routing Area Update messages is set to foreign.
Sponsored-by: On-Waves ehf
Patch the APN in every 'Activate PDP Context Request' message to the
value given by the 'core-access-point-name' command. If the command is
given without an APN, the whole APN IE will be removed. If the
command is being prefixed by a 'no', the APN IE remains unmodified.
The patch mode 'llc-gsm' is added to selectively enable the patching
of LLC session management messages. This is enabled implicitely by
the patch mode 'llc'.
Note that the patch mode should not be set to a value not enabling
the patching of LLC GSM messages ('llc-gsm', 'llc', and 'default' are
sufficient to patch 'Activate PDP Context Request' messages).
Ticket: OW#1192
Sponsored-by: On-Waves ehf
This patch extends the BSSGP patch code to also patch LLC information
elements along with MCC/MNC patching support for the following messages:
- Attach Request
- Attach Accept
- Routing Area Update Request
- Routing Area Update Accept
- P-TMSI reallocation command
Note that encrypted packets will not be patched.
Ticket: OW#1185
Sponsored-by: On-Waves ehf
This adds a feature to patch the BSSGP MNC/MCC fields of messages going
to and coming from the SGSN. To enable this feature, the gbproxy's
VTY commands 'core-mobile-country-code' and/or
'core-mobile-network-code' must be used. All packets to the SGSN are
patched to match the configured values. Packets received from the
SGSN are patched to the corresponding values as last seen from the BSS
side.
Note that this will probably not work with a gbproxy used for several
BSS simultaneously.
Note also, that MCC/MNC contained in a LLC IE will not be patched.
Ticket: OW#1185
Sponsored-by: On-Waves ehf
The wrong field has been use for the field length computation. This
hadn't any impact so far, since
sizeof(ctx->imei) == sizeof(ctx->imsi)
This patch fixes the computation to use the right field.
Sponsored-by: On-Waves ehf
This patch makes a few changes to improve readability:
- change the sendto() hexdump to start with NS instead of BSSGP
- use more specific message descriptions instead of 'UNITDATA'
- add a title line per test
Sponsored-by: On-Waves ehf
The osmux code doesn't work if the MGCP MGW is behind a NAT (which
is likely to be the case). The usage of endp->ci is troublesome too
not only because of the uint8_t vs. uint32_t mismatch but because
this identity is generated by the MGCP MGW and can clash. This means
that with two clients the wrong call might be connected.
The next bigger thing is that old handles are never cleared. This
code is clearly not ready for deployment.
We need to discover the remote port as we are likely behind a NAT.
Right now the NAT code will just send to port 1984 on the BSC but
this might not arrive at the BSC. Include the CI (in the future we
need to include the endpoint address or send the dummy to the net
port). This is just an interim solution.
The CI is a MGCP value that is counted from 0 upwards. The code
is comparing a uint8_t with a uint32_t. This will only work for
up to UINT8_MAX calls and then will silently break. The code should
probably work with the endpoint number and not the CI. For now
truncate things and hope things work.
Jacob pointed out that "free_endp" refers to the memory of
the endpoint being freed. What we want is actually a way to
release an endpoint (and the resource it allocated) or in
the case of the testcase/testapp initialize the data structure
correctly. Introduce two names for that.
In case the sender didn't send a couple of frames we will have
a time gap that is bigger than the accepted delta. Add a new
testcase for this and update the next_time.
Transcoding from GSM to PCMA can lead to the MGCP MGW sending
two PCMA packages with the same sequence number and timestamp.
Once with the encoded audio and once completely empty.
This is because "state->dst_packet_duration" is 0 in most cases
(unless a ptime is forced) and we attempt to encode audio even
if there are not enough samples. The encode_audio return will
return 0 in that case which is not trated as an error by the
mgcp network code.
Handle rc == 0 specially and document the semantic.
The sequence number was read from the wrong place and then
the wrong byte order conversion routine was used so we ended
up wirting 0x00, 0x00 into the patched sequence number. Add
a testcase for that.
When going from a ptime of 10 to 20 a lot of alignment errors
are reported. In fact the alignment check should be done before
and after the transcoding. As this is not possible right now
only do it _after_ the patching.
It took me a long time to figure out that errx just exits and
the test output didn't indicate that the application was exited
early. Use a printf and good old abort in case of a failure.
The GSM handle was never released. This was found using valgrind
and the leak check.
==14933== 752 bytes in 1 blocks are definitely lost in loss record 15 of 19
==14933== at 0x4028B4C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==14933== by 0x4130201: gsm_create (in /usr/lib/i386-linux-gnu/libgsm.so.1.0.12)
==14933== by 0x80517AE: mgcp_transcoding_setup (mgcp_transcode.c:199)
==14933== by 0x8049691: given_configured_endpoint.isra.1 (mgcp_transcoding_test.c:198)
==14933== by 0x8049C11: test_transcode_result (mgcp_transcoding_test.c:328)
==14933== by 0x8049418: main (mgcp_transcoding_test.c:582)
<000b> osmux.c:177 Cannot find endpoint with cid=7
!
<000b> osmux.c:253 Cannot find an endpoint for circuit_id=7
The extra newline and '!' do not provide any extra value and
make reading the output more difficult. Just remove it.
An empty log_info is not enough. We need to make sure that at least
DLGLOBAL is present. Instead of doing that make sure that we have
enough entries.
==26163== Conditional jump or move depends on uninitialised value(s)
==26163== at 0x403B289: osmo_vlogp (logging.c:290)
==26163== by 0x403B3DA: logp2 (logging.c:339)
==26163== by 0x804D027: gbprox_relay2bvci (gb_proxy.c:347)
==26163== by 0x804D3CF: gbprox_rx_sig_from_sgsn (gb_proxy.c:589)
==26163== by 0x804DBFC: gbprox_rcvmsg (gb_proxy.c:685)
==26163== by 0x4052CB0: gprs_ns_process_msg (gprs_ns.c:669)
==26163== by 0x4052F70: gprs_ns_rcvmsg (gprs_ns.c:1053)
==26163== by 0x804BB49: gprs_process_message (gbproxy_test.c:488)
==26163== by 0x804BC4C: send_ns_unitdata (gbproxy_test.c:210)
==26163== by 0x804BDE8: send_bssgp_reset_ack (gbproxy_test.c:243)
==26163== by 0x804B54F: main (gbproxy_test.c:863)
==26163==
The peers are (talloc) children of the GPRS NS. This means the
peers (and the rate counters) are currently being deleted twice.
==23446== Invalid write of size 4
==23446== at 0x403C243: rate_ctr_group_alloc (linuxlist.h:66)
==23446== by 0x4050974: gprs_nsvc_create (gprs_ns.c:209)
==23446== by 0x405320D: gprs_ns_instantiate (gprs_ns.c:1330)
==23446== by 0x804ABEB: main (gbproxy_test.c:666)
==23446== Address 0x4300694 is 52 bytes inside a block of size 784 free'd
==23446== at 0x4029DA8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23446== by 0x4041B9D: _talloc_free (talloc.c:609)
==23446== by 0x4043292: talloc_free (talloc.c:578)
==23446== by 0x40532D3: gprs_ns_destroy (gprs_ns.c:1363)
==23446== by 0x804ABD7: main (gbproxy_test.c:660)
Make the llc_default_params structure from which data is initialized
large enough. Otherwise address sanitizer complains with out-of-bounds
reads.
Only SAPIs 1, 2, 3, 5, 7, 8, 9, 11 are defined for GPRS but the
struct gprs_llc_llme includes NUM_SAPIS lle's and they are populated
from the llc_default_params structure.
This adds a test case with several messages to test BSSGP patching.
New messages:
- BSSGP/DTAP Attach Request
- BSSGP/DTAP Attach Accept
- BSSGP/DTAP Routing Area Update Request
- BSSGP/DTAP Routing Area Update Accept
- BSSGP/DTAP Activate PDP Context Request
- BSSGP SUSPEND
- BSSGP SUSPEND ACK
Sponsored-by: On-Waves ehf
This parameter is not used (the methods are always called with an
argument of 1 in the third position). Thus the parameter is removed
completely.
Sponsored-by: On-Waves ehf
The type in the schema is integer but we need to use ulonglong to
read it as otherwise the read will fail.
DBI: -7: The requested variable type does not match what libdbi thinks it should be
Currently the terms 'Routing area code' (RAC) and 'Location area
code' (LAC) are used in several places where 'Routing area
identification' (RAI) or 'Location area identification' (LAI) are
meant in fact.
This patch replaces RAC/LAC by RAI/LAI and 'code' by 'identification'
at these places.
Note that RAI := MCC MNC LAC RAC, and LAI := MCC MNC LAC (see GSM
03.03, sections 4.1 and 4.2).
Sponsored-by: On-Waves ehf
Currently when ftmp_extra is set, a doubled a=rtpmap line is emitted
instead of the fmtp_extra info.
This patch fixes replaces the formerly copied and pasted but not
modified snprintf parameters by the correct ones.
Fixes: Coverity CID 1220873
Sponsored-by: On-Waves ehf
Add tests setting the fmtp_extra field to check the response
generation. This triggers a bug found by Coverity.
Addresses: Coverity CID 1220873
Sponsored-by: On-Waves ehf
Currently, if there is no SDP data in the MGCP message received from
the net, the fields containing audio encoding information are not set
in net_end. So in recvonly mode transcoding would not be set up
correctly.
This patch changes the implementation of the code handling CRCX and
MDCX to use the codec signalled in the MGCP local connection options
(field 'a:') if there isn't any SDP data. This is only halfway
negotiation, because the codec is used blindly and not matched
against the supported ones.
Sponsored-by: On-Waves ehf
This patch moves the files relevant to transcoding from
src/osmo-bsc_mgcp to src/libmgcp and src/include/openbsc. Makefiles
and include directives are being updated accordingly.
Sponsored-by: On-Waves ehf
The current transcoder implemenation always does a 1:1 recoding
concerning the duration of a packet. So RTP timestamps and sequence
numbers are not modified.
This is not sufficient in some cases, e.g. when the BTS does only
allow for a single fixed ptime.
This patch decouples encoding from decoding and moves the decoded
samples to the state structure so that samples can be combined or
drain according to the packaging of incoming and outgoing packets.
This patch incorporates parts of Holger's experimental fixes in
0e669e05^..9eba68f9.
Ticket: OW#1111
Sponsored-by: On-Waves ehf
This patch implements audio transcoding between the formats GSM,
PCMA, L16, and optionally G.729.
The feature needs to be enabled by using the autoconf option
'--enable-mgcp-transcoding'. In this case mgcp_transcode.c will
be compiled and linked to osmo-bsc_mgcp, and the transcoding
functions provided will be registered as processing callbacks.
If G.729 support is required, libcg729 needs to be installed and
'--with-g729' must be passed to ./configure.
Ticket: OW#1111
Sponsored-by: On-Waves ehf
Don't show media related lines if the payload type has not been set.
Don't show a 'a=rtpmap' line if the audio_name has not been set.
This patch unifies the SDP generation of create_response_with_sdp()
and send_msg().
Sponsored-by: On-Waves ehf
This patch adds the get_net_downlink_format_cb() callback to provide
payload_type, subtype_name, and fmtp_extra suitable for use in a MGCP
response sent to the network. Per default, the BTS side values are
returned since these must be honoured by the net peer when sending
audio to the media gateway (unless transcoding is done).
Sponsored-by: On-Waves ehf
This patch adds the fields channels, subtype_name, and audio_name to
the struct. The field audio_name contains the full string that has
been used for the last part of a SDP a=rtpmap line. The others contain
decoded parts of that string. If no a=rtpmap line has been given
(e.g. because dynamic payload types are not used), values are
assigned when the payload type matches one of the predefined ones
(GSM, G729, PCMA).
The patch also moves the audio_name parsing code to a dedicated
set_audio_info() function.
Sponsored-by: On-Waves ehf
This patch adds the callbacks rtp_processing_cb and
setup_rtp_processing_cb to mgcp_config to support arbitrary RTP
payload processing.
Sponsored-by: On-Waves ehf
Currently LLC parsing is part of gprs_llc.c which needs large parts
of the SGSN code parsing to fulfill its link dependencies.
This patch moves the functions that just do plain parsing, dumping,
and FCS computation to a different file to avoid these dependencies
if LLC stateful processing is not needed. It also exposes
struct gprs_llc_hdr_parsed and enum gprs_llc_cmd publically.
Sponsored-by: On-Waves ehf
The code currently uses an encoded sequence of (hex) 10 20 30 40 50
60 as RAI, for which no bijective mapping to the set of
representations MCC-MNC-LAC-RAC exists.
This patch changes the hard-coded RAI to 11 22 33 40 50 60 which maps
to 112-332-16464-96 (and vice-versa).
Sponsored-by: On-Waves ehf
The patches were posted to the ML but didn't receive review
there. At the time I merge the change I did a Location Updating
Request and the channel was released in a successful way.
In case we receive ERROR INDICATION and CONNECTION FAILURE we only
want to RF Channel Release the lchan once. This code is more simple
and should work as reliable as the previous commit.
When we receive an ERROR INDICATION and CONNECTION FAILURE we
might call rsl_rf_chan_release multiple times. The channel release
handling is still a bit messy and there too many paths that lead
to the call.
1.) In case we receive an ERROR INDICATION for SAPI=3. A RLL
error signal will be emitted that leads to the release of the
channel through the SMS code in case of the NITB. The call to
rsl_rf_chan_release might be a double release.
2.) In case a CONNECTION FAILURE is received when the release
process has already been started we would unconditionally
call rsl_rf_chan_release as well.
Because the lchan state is changed by the callers of the
rsl_rf_chan_release we can not move the state checking into this
code but need to do it in the caller. The issue was seen in a trace
from Rhizomatica and I created the DoubleRelease.st to re-produce
the issue and verified that we have no duplicate RF Channel Releses.
The other option would be to introduce a new state to track
the release process and see if we have already released SAPIs
deactivated the SACCH or such. We can not simply look at these
as for a channel that fails to activate they will be null already.
Looking at the code it seemed possible that a channel would
transition from BROKEN to NONE. Or worse from NONE to BROKEN.
Start the timer _after_ the channel has been released.
Make it possible to inform local CTRL connections about some state.
The TRAP will be only sent to local connections. The notification
text may not contain spaces.
Use the right size for scanf.
=================================================================
==6106== ERROR: AddressSanitizer: unknown-crash on address 0xbffff4b0 at pc 0xb69d87fd bp 0xbffff248 sp 0xbffff21c
WRITE of size 65 at 0xbffff4b0 thread T0
#0 0xb69d87fc (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xa7fc)
#1 0xb69d9239 (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xb239)
#2 0xb69d92d6 (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xb2d6)
#3 0x804f151 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x804f151)
#4 0x80531e8 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x80531e8)
#5 0x8051e6f (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8051e6f)
#6 0x8049b0a (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8049b0a)
#7 0x804bd9e (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x804bd9e)
#8 0xb6778a62 (/lib/i386-linux-gnu/i686/cmov/libc-2.18.so+0x19a62)
#9 0x8049330 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8049330)
Address 0xbffff4b0 is located at offset 416 in frame <parse_sdp_data> of T0's stack:
This frame has 8 object(s):
[32, 36) 'audio_payload'
[96, 100) 'payload'
[160, 164) 'channels'
[224, 228) 'ptime'
[288, 292) 'port'
[352, 368) 'ipv4'
[416, 480) 'audio_name'
[512, 576) 'audio_codec'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are*
This addresses an ASAN issue where the request was already deleted
by our callback function.
(gdb) where
#0 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0
#1 0xb69e0aff in __asan_report_store4 () from /usr/lib/i386-linux-gnu/libasan.so.0
#2 0x0804ea64 in subscr_send_paging_request (subscr=subscr@entry=0xb5103cb0)
at gsm_subscriber.c:212
#3 0x0804edac in subscr_get_channel (subscr=subscr@entry=0xb5103cb0, type=type@entry=2,
cbfn=cbfn@entry=0x804969d <subscr_cb>, param=param@entry=0x2342) at gsm_subscriber.c:246
#4 0x080498f7 in main (argc=1, argv=0xbffff804) at channel_test.c:77
Breakpoint 3, subscr_paging_dispatch (hooknum=hooknum@entry=101, event=event@entry=200,
msg=msg@entry=0x1323, data=<optimized out>, data@entry=0x8063900 <s_conn>,
param=<optimized out>, param@entry=0xb5103cb0) at gsm_subscriber.c:126
126 llist_del(&request->entry);
(gdb) b llist_del
(gdb) bt
#0 subscr_paging_dispatch (hooknum=hooknum@entry=101, event=event@entry=200,
msg=msg@entry=0x1323, data=<optimized out>, data@entry=0x8063900 <s_conn>,
param=<optimized out>, param@entry=0xb5103cb0) at gsm_subscriber.c:126
#1 0x0804e8a9 in subscr_paging_cb (hooknum=101, event=200, msg=0x1323,
data=0x8063900 <s_conn>, param=0xb5103cb0) at gsm_subscriber.c:187
#2 0x080497e9 in paging_request (bts=0xb5b03e70, subscriber=subscriber@entry=0xb5103cb0,
type=2, cbfn=cbfn@entry=0x804e881 <subscr_paging_cb>, data=data@entry=0xb5103cb0)
at channel_test.c:51
#3 0x0804ea39 in subscr_send_paging_request (subscr=subscr@entry=0xb5103cb0)
at gsm_subscriber.c:207
#4 0x0804edac in subscr_get_channel (subscr=subscr@entry=0xb5103cb0, type=type@entry=2,
cbfn=cbfn@entry=0x804969d <subscr_cb>, param=param@entry=0x2342) at gsm_subscriber.c:246
#5 0x080498f7 in main (argc=1, argv=0xbffff804) at channel_test.c:77
(gdb) q
In ae1997248c the handwritten tokenizer
was replaced with strtok_r. As part of this change the structural
checking of MGCP parameters was stopped. This means that a code like
"line + 3" might access beyond the first NUL and be possibly behind
the msgb. Manually add size checking again. Manually jumping to the
error label is not possible anymore as it has been removed. The result
is that invalid lines will be skipped. This is matching the general
approach by the IETF RFCs to be permissive in data being received.
This patch adds the voice muxer. You can use this to batch RTP
traffic to reduce bandwidth comsuption. Basically, osmux transforms
RTP flows to a compact batch format, that is later on decompacted
to its original form. Port UDP/1984 is used for the muxer traffic
between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This
feature depends on libosmo-netif, which contains the osmux core
support.
Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using
the vendor-specific extension X-Osmux: on) coming from the BSC-NAT,
so you can selectively enable osmux per BSC from one the bsc-nat.cfg
file, so we have a centralized point to enable/disable osmux.
First thing you need to do is to accept requests to use Osmux,
this can be done from VTY interface of osmo-bsc_nat and
osmo-bsc_mgcp by adding the following line:
mgcp
...
osmux on
osmux batch-factor 4
This just initializes the osmux engine. You still have to specify
what BSC uses osmux from osmo-bsc_nat configuration file:
...
bsc 1
osmux on
bsc 2
...
bsc 3
osmux on
In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does
not have osmux enabled.
Thus, you can selectively enable osmux depending on the BSC, and
we have a centralized point for configuration from the bsc-nat to
enable osmux on demand, as suggested by Holger.
At this moment, this patch contains heavy debug logging for each
RTP packet that can be removed later to save cycles.
The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that
is received to configure an endpoint.
In rtcp_sdes_cname_mangle when skipping over additional zeroes at the
end of a chunk we should not read past the actual message (rtcp_end).
Fixes CID #1206579
I'm not entirely sure if this is the best approach. However,
there are phones that send a RACH request for TCH/F on MO calls, even
though they actually do support TCH/H channels.
When forwarding AMR from RTP towards the MNCC interface, we need to set
the apropriate msg_type. Before this patch it was unitialized,
resulting in improper/unknown msg_types of messages on the MNCC
interface.
AMR frames on the MNCC interface are slightly different as they
include a single-byte payload_length indicator prior to the actual
payload. Commit 3f201ac89952b68d05c0bb6cb41932b9cd898b19 introduced
more special-case handling than required, so I'm trying to simplify
things again.
We now also use msgb_put() more consistently, i.e. always put
before actually using the data, and use the return value of msgb_put()
rather than first making assumptions about the pointer, writing to it
and then calling msgb_put().
This has been pointed out by Jacob and removes two more duplicates
of the struct. For the unused CTRL_CMD_DEFINE_STRING macro there
will be no verify command.
Currently, if a CTRL method does not set the reply, an error is
logged ("cmd->reply has not been set"). It even complains when the
function implementing the command returns CTRL_CMD_HANDLED, where
a reply text is not needed.
This patch changes the logging level from ERROR to NOTICE. The logging
is now only done, when the retry has not been set and the
implementation returns either CTRL_CMD_ERROR or CTRL_CMD_REPLY. So
in these cases the reply field must be set.
This fixes the generation of log messages when doing NAT ctrl command
forwarding.
Ticket: OW#1177
Sponsored-by: On-Waves ehf
This adds a --frame-size option to read payload binary files with a
fixed frame size directly. The file must not contain RTP headers.
In addition '--rate' and '--duration' can be used to configure the
timing.
Sponsored-by: On-Waves ehf
FreeBSD uses POSIX netinet/in.h for representing socket addresses
data types.
[Holger removed the #ifdef and changed the order of includes to
have specific ones first and system includes later]
The code in the BSC/NAT called ipaccess_rcvmsg_base without
checking if the protocol is IPA. This lead the BSC to respond
to SCCP messages with an "ID ACK". From a quick look neither
the code of ipaccess_rcvmsg_base in OpenBSC nor the copy of
libosmo-abis ever checked the protocol header. So this code
has been wrong since initially being created in 2010.
The sender_id is gone so the code that attempted to delete SMS
didn't work anymore. Delete the SMS based on src_addr or the
dest_addr.
Fixes:
======================================================================
ERROR: testSubscriberAddRemove (__main__.TestCtrlNITB)
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/ctrl_test_runner.py", line 379, in testSubscriberAddRemove
r = self.do_set('subscriber-delete-v1', '2620345')
File "tests/ctrl_test_runner.py", line 114, in do_set
return self.recv_msgs()[id]
KeyError: 1002
This branch allows a SMPP user to fully specify the sender id. It
requires a change in schema, database migration code and exposed
some issues in the libdbi and the sqlite3 driver.
This is mostly based on Alexander's migration code. The code
adds transaction handling and some sanity checks and cleanups
to the code. We made the decision to fork the sms_from_result
method and freeze it to that version. This way sms_from_result
can move forward without having to deal with legacy.
That was a bad idea from the very beginning. A visible result of this is a wrong
SMS routing when you change subscriber extensions, while having queued SMS. It's
also a very wrong thing from the code layering perspective.
I think the next logical step should be to remove "receiver" pointer from
the gsm_sms structure into a structure, special for the internal SMS queue.
This is an incompatible database schema change. Store the type of
the address in the database for both the sender and the receiver.
Currently it is possible to use SMPP to store a SMS and the NPI
and TON will be lost on the delivery of the SMS. The schema is
changed to make the delivery always use the right NPI/TON. This
patch is not ready for the master branch as there is no upgrade
path for the HLR yet.
Use memcpy to copy from the OML message into the stack and then
convert the network byte order.
network_listen.c: In function ‘test_rep’:
network_listen.c:145:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
test_rep_len = ntohs(*(uint16_t *) &foh->data[3]);
^
network_listen.c:153:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ferr_list_len = ntohs(*(uint16_t *) &foh->data[7]);
^
network_listen.c:164:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ferr_list_len = ntohs(*(uint16_t *) &foh->data[7]);
^
network_listen.c:130:11: warning: variable ‘test_rep_len’ set but not used [-Wunused-but-set-variable]
uint16_t test_rep_len, ferr_list_len;
sgsn_main.c: In function ‘main’:
sgsn_main.c:345:2: warning: implicit declaration of function ‘gprs_sndcp_vty_init’ [-Wimplicit-function-declaration]
gprs_sndcp_vty_init();
^
sgsn_main.c:354:2: warning: implicit declaration of function ‘sgsn_gtp_init’ [-Wimplicit-function-declaration]
rc = sgsn_gtp_init(&sgsn_inst);
^
CC gprs_sndcp_vty.o
gprs_sndcp_vty.c: In function ‘vty_dump_sne’:
gprs_sndcp_vty.c:46:15: warning: unused variable ‘i’ [-Wunused-variable]
unsigned int i;
CC sgsn_libgtp.o
sgsn_libgtp.c: In function ‘create_pdp_conf’:
sgsn_libgtp.c:262:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
int rc;
^
sgsn_libgtp.c: In function ‘cb_data_ind’:
sgsn_libgtp.c:432:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
int rc;
CC gprs_llc.o
gprs_llc.c: In function ‘t200_expired’:
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_UNASSIGNED’ not handled in switch [-Wswitch]
switch (lle->state) {
^
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_ASSIGNED_ADM’ not handled in switch [-Wswitch]
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_REMOTE_EST’ not handled in switch [-Wswitch]
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_ABM’ not handled in switch [-Wswitch]
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_TIMER_REC’ not handled in switch [-Wswitch]
gprs_llc.c: In function ‘gprs_llc_hdr_rx’:
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_NULL’ not handled in switch [-Wswitch]
switch (gph->cmd) {
^
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_RR’ not handled in switch [-Wswitch]
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_ACK’ not handled in switch [-Wswitch]
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_RNR’ not handled in switch [-Wswitch]
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_SACK’ not handled in switch [-Wswitch]
gprs_llc.c: In function ‘gprs_llc_rcvmsg’:
gprs_llc.c:791:23: warning: unused variable ‘udh’ [-Wunused-variable]
struct bssgp_ud_hdr *udh = (struct bssgp_ud_hdr *) msgb_bssgph(msg);
^
gprs_llc.c: At top level:
gprs_llc.c:311:13: warning: ‘t200_expired’ defined but not used [-Wunused-function]
static void t200_expired(void *data)
^
gprs_llc.c:337:13: warning: ‘t201_expired’ defined but not used [-Wunused-function]
static void t201_expired(void *data)
CC gprs_sndcp.o
gprs_sndcp.c: In function ‘defrag_input’:
gprs_sndcp.c:188:25: warning: variable ‘scomph’ set but not used [-Wunused-but-set-variable]
struct sndcp_comp_hdr *scomph = NULL;
^
gprs_sndcp.c: In function ‘sndcp_llunitdata_ind’:
gprs_sndcp.c:512:11: warning: variable ‘npdu_num’ set but not used [-Wunused-but-set-variable]
uint16_t npdu_num;
^
gprs_sndcp.c: At top level:
gprs_sndcp.c:565:12: warning: ‘sndcp_ll_reset_ind’ defined but not used [-Wunused-function]
static int sndcp_ll_reset_ind(struct gprs_sndcp_entity *se)
^
gprs_sndcp.c:573:12: warning: ‘sndcp_ll_status_ind’ defined but not used [-Wunused-function]
static int sndcp_ll_status_ind()
^
CC gprs_gmm.o
gprs_gmm.c: In function ‘gsm48_tx_gmm_att_ack’:
gprs_gmm.c:350:11: warning: unused variable ‘ptsig’ [-Wunused-variable]
uint8_t *ptsig, *mid;
^
gprs_gmm.c: In function ‘gsm48_rx_gmm_auth_ciph_resp’:
gprs_gmm.c:524:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
int rc;
^
gprs_gmm.c: In function ‘gsm48_rx_gmm_att_req’:
gprs_gmm.c:703:9: warning: implicit declaration of function ‘sgsn_acl_lookup’ [-Wimplicit-function-declaration]
!sgsn_acl_lookup(mi_string))) {
^
gprs_gmm.c:632:40: warning: variable ‘old_ra_info’ set but not used [-Wunused-but-set-variable]
uint8_t *cur = gh->data, *msnc, *mi, *old_ra_info, *ms_ra_acc_cap;
^
gprs_gmm.c: In function ‘gsm48_rx_gmm_ra_upd_req’:
gprs_gmm.c:915:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
int rc;
^
gprs_gmm.c:910:11: warning: variable ‘ms_ra_acc_cap’ set but not used [-Wunused-but-set-variable]
uint8_t *ms_ra_acc_cap;
^
gprs_gmm.c: At top level:
gprs_gmm.c:458:12: warning: ‘gsm48_tx_gmm_auth_ciph_req’ defined but not used [-Wunused-function]
static int gsm48_tx_gmm_auth_ciph_req(struct sgsn_mm_ctx *mm, uint8_t *rand,
^
gprs_gmm.c:501:12: warning: ‘gsm48_tx_gmm_auth_ciph_rej’ defined but not used [-Wunused-function]
static int gsm48_tx_gmm_auth_ciph_rej(struct sgsn_mm_ctx *mm)
^
gprs_gmm.c:1169:13: warning: ‘msgb_put_pdp_addr_ipv4’ defined but not used [-Wunused-function]
static void msgb_put_pdp_addr_ipv4(struct msgb *msg, uint32_t ipaddr)
^
gprs_gmm.c:1180:13: warning: ‘msgb_put_pdp_addr_ppp’ defined but not used [-Wunused-function]
static void msgb_put_pdp_addr_ppp(struct msgb *msg)
Given that the method is only called for a traffic channels the
missing breaks didn't hurt.
Fixes: Coverity CID 1040731, CID 1040732, CID 1040733,
CID 1040734
In case ftell -1 will be returned. Coverity complained that the
pos we pass to fseek might be negative. In case the ftell fails
we are at the last line for sure.
Fixes: Coverity CID 1040721
Coverity complains about checking connection->cfg in
bsc_close_connection() at one place but not at the second.
This patch fixes this by adding a check before accessing cfg when
generating the 'partial message' log message.
Fixes: Coverity CID 1195180
Sponsored-by: On-Waves ehf
The log message lacked a lot of context. A SCCP connection is
created on behalf of a configured BSC. This way we should be
able to always list this information.
The old ipa_msg_recv() implementation didn't support partial receive,
so IPA connections got disconnected when this happened.
This patch adds the handling of the temporary message buffers and uses
ipa_msg_recv_buffered().
It has been successfully tested by jerlbeck with osmo-nitb and
osmo-bsc.
Ticket: OW#768
Sponsored-by: On-Waves ehf
In case the max_power_reduction changes, issue a new Set Radio
Carrier Attributes command. OML 12.21 allows to not include the
ARFCN list and the semantic I picked/understand is that a partial
update is possible.
Fixes: SYS#267
Add the control interface with no hierachy right now and implement
the first command to list IMSI + Context Address of active sessions.
sgsn_cmd_handle could share more code with bsc variant.
Fixes: SYS#264, SYS#265
For GPRS the look-up via bts/trx does not make any sense and would
introduce bad depdencies for the SGSN. Move the look-up code to a
new file and introduce new setup methods.
Sadly there is no proper foreign key relationship on the tables
that related to the Subscriber. This means we can't use a DELETE
with Cascade and need to delete everything by hand. To make things
worse maybe the SMS/Paging code is still using the subscriber
making the operation more dangerous. I had added NULL checks for
sender_id/receiver_id at 30C3 so we should not crash in this
situation.
Fixes: SYS#274
The test has been manually verified. Executing the select for
the subscribers showed:
sqlite> select * from Subscriber;
1|2014-03-23 12:12:46|2014-03-23 12:19:09|2620345||445567|1||0|
This created a subscriber with the right IMSI, MSISDN and has
it authorized.
Fixes: SYS#275
The new definitions are: half rate and AMR
Change of definition name for bad frame, because it applies to all types of
traffic, not only TCH/F.
Increase MNCC interface version to 4. Version 3 is skipped, because it was
used by older version of Linux-Call-Router which is incompatible with the
current version of the MNCC interface.
Send the two strings that caused the read handling to misbehave.
Verify that we handle this correctly by still being able to issue
a VTY command. The CPU load issue could not be verified like this.
The size parameter of msgb_alloc is uint16_t so any length value above
65535 will allocate a msgb with incorrect size.
This patch changes the type of rdlen and rc to ssize_t (the return value
of read) and guards against the read length being larger than
UINT16_MAX.
To reproduce the issue run:
echo -en "\x00\x01\x00\x01\x01" |socat stdin tcp:localhost:2775
The first 4 bytes are the length including the length field. For
length < 4 the subsequent msgb_put(msg, sizeof(uint32_t)) will fail,
resulting in an abort. The code also expects (in smpp_msgb_cmdid()) the
existence of 4 more bytes for the SMPP command ID.
This patch checks that the length received is large enough to hold all
8 bytes in the msgb and drops the connection if that's not the case.
The issue is reproducible with:
echo -e "\x00\x00\x00\x02\x00" |socat stdin tcp:localhost:2775
Read returning -1 is an error here so make sure to print the actual
reason and close the socket. Before this patch we just looped over the
fd with read returning -1 every time.
EINTR is handled to not cause an error and we don't need to check
EAGAIN/EWOULDBLOCK since the callback is only called in case there is
something to read.
To avoid copy&paste issues the check is implemented as a macro and the
log message moved into a separate if.
Make sure that bsc_gsmnet->bsc_data->rf_ctrl is initialized for
NITB. In commit a9fae1ae66 the
conditions for the rf_ctrl was removed but it was still needed
for the NITB.
Fixes regression from:
a9fae1ae66
bsc: rf_ctrl will always be created, remove the NULL checks
When one SMS has been delivered check if a second SMS can be scheduled
to that subscriber. If nothing can be scheduled kick the normal SMS queue
as one slot has become free now. Otherwise send the SMS and create a
pending entry.
It was possible that two SMS would be delivered at the same time
which violates GSM 04.11. We should solely rely on the sms queue
to schedule more SMS to the subscriber.
As can clearly be seen from SMPP Spec v3.4 Chapter 5.2.19,
a SUBMIT-SM with data_coding == 0x08 is UCS2, not with 0x80.
Thanks to ciaby@rhizomatica.org for reporting the bug.
Each RP-DATA should have a unique msg reference. Currently 42 is
used for all of these. Remember the last reference we used and
increment it on the next SMS. Do not track if the reference is
still in use a clash is a lot less likely now. First unless SMPP
is used only one SMS is delivered at a time, second the transaction
space is a lot smaller than the one for the reference.
In file included from bsc_api.c:34:0:
../../include/openbsc/trau_mux.h:62:15: warning: ‘struct decoded_trau_frame’ declared inside parameter list [enabled by default]
const struct decoded_trau_frame *tf);
^
../../include/openbsc/trau_mux.h:62:15: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
../../include/openbsc/trau_mux.h:64:15: warning: ‘struct decoded_trau_frame’ declared inside parameter list [enabled by default]
const struct decoded_trau_frame *tf);
^
../../include/openbsc/trau_mux.h:66:2: warning: ‘struct decoded_trau_frame’ declared inside parameter list [enabled by default]
const unsigned char *data);
^
../../include/openbsc/trau_mux.h:68:2: warning: ‘struct decoded_trau_frame’ declared inside parameter list [enabled by default]
const unsigned char *data);
The interface can be accessed through CTRL and a socket. But currently
it is only available when the socket interface has been configured.
Create the interface all the time but only listen on the socket when
a path has been specified.
For the max power reduction we will need to have a different range
method. It will need to check if the value is even. Make the set,
get and verify methods available through a macro.
With the current multiplication we might end up with 19999 as
time on i386. When we round it ends up as 20000 on i386 and
should work the same on AMD64.
Should fix on AMD64:
mgcp_test.c: In function ‘sendto’:
mgcp_test.c:318:10: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ [-Wformat]
So far, the jitter computation has been based on output timestamps.
This patch uses the input timestamps instead and resets jitter
computation on SSRC changes.
Sponsored-by: On-Waves ehf
Currently, when the SSRC changes within a stream and SSRC fixing is
enabled, the RTP timestamp between the last packet that has been
received with the old SSRC and the first packet of the new SSRC
is always incremented by one packet duration.
This can lead to audio muting (at least with the nanoBTS) when the
wallclock interval between these packets is too large (> 1s).
This patch changes the implementation to base the RTP timestamp offset
on the wallclock interval that has passed between these two packets.
Ticket: OW#466
Sponsored-by: On-Waves ehf
Currently micro-secs and RTP rate get mixed when the transit value is
computed in mgcp_patch_and_count().
This patch changes get_current_ts() to accept the desired rate as
argument and to use it for the time conversion instead of always
converting to microseconds. If microseconds are needed,
get_current_ts(1000) can be used.
The arrival_time is now measured in 1/rtp_end->rate seconds so that
it can be directly compared to RTP timestamps as required by RFC3550
(section 6.4.1, see definition of 'interarrival jitter').
Sponsored-by: On-Waves ehf
Currently the stats (jitter, transit) cannot be checked properly,
since they depend on the wallclock time.
This patch fakes clock_gettime (CLOCK_MONOTONIC) to reflect the
scheduling time of the RTP packets. In addition, the RTP statistical
value are written to stdout.
A RTP test case with a SSRC change along with a reference time delay
has been added.
Sponsored-by: On-Waves ehf
Currently the conn_mode and the output_enabled flags are printed to
stdout.
This patch modifies this to print the output_enabled flags to stderr
instead. The bits in conn_mode are shown as RECV, SEND, and LOOP.
This does not reduce the significance of the test, since there is an
assertion already that verifies the values of the output_enabled
flags with respect to the conn_mode.
Sponsored-by: On-Waves ehf
Incoming DTAP messages from MS are discarded during silent calls,
which leads to the repeated delivery of SMS since the ACKs are not
being processed.
This patch adds some log messages that have been helpful to track
this down.
Sponsored-by: On-Waves ehf
E1 based BTS use TRAU muxer to decode TRAU frames. After changing
channel from one timeslot to another (due to handover or assignment),
the TRAU muxer must be updated. The call reference of the call is
disconnected from the old channel and connected to the new channel.
The filtering architecture already allowed to specify a reject
reason but this has not been used for the access-lists. Extend
the access-list to include a reject reason and extend the test
case to honor it.
Currently, the conn_mode field is reset after it has been checked.
This patch disables this behaviour and only adds a mark (bit) to
detect modifications.
Sponsored-by: On-Waves ehf
This patch changes implementation and the mgcp_connection_mode enum
in a way that net_end.output_enabled (bts_end.output_enabled) flag
always matches the MGCP_CONN_SEND_ONLY (MGCP_CONN_RECV_ONLY) bit of
conn_mode.
Based on this, the conn_mode bits are then used instead of the
output_enabled fields within mgcp_protocol.c.
Sponsored-by: On-Waves ehf
Currently RTP output_enabled is set to 1 on initialisation, which
does not semantically match the initial value of conn_mode
(MGCP_CONN_NONE).
This patch changes this initial value to 0.
Sponsored-by: On-Waves ehf
We don't want every caller to check for ts->tsc == -1 and then
using ts->trx->bts->tsc instead. Rather, introduce a new inline
function to retrieve the correct value.
This patch (hopefully) fixes the new defects reported by coverity.
Addresses:
** CID 1156986: Negative array index read (NEGATIVE_RETURNS)
/tests/gsm0408/gsm0408_test.c: 419 in test_si_range_helpers()
/tests/gsm0408/gsm0408_test.c: 423 in test_si_range_helpers()
/tests/gsm0408/gsm0408_test.c: 427 in test_si_range_helpers()
** CID 1156987: Unchecked return value from library
(CHECKED_RETURN)
/src/libmgcp/mgcp_protocol.c: 1150 in mgcp_keepalive_timer_cb()
** CID 1156988: Unchecked return value from library
(CHECKED_RETURN)
/src/libmgcp/mgcp_protocol.c: 983 in handle_modify_con()
Sponsored-by: On-Waves ehf
The check is removed from gsm48_cc_rx_setup() and gsm48_cc_rx_call_conf().
Receiving a layer 3 message implies that the transaction has a subscriber
connection and a logical channel.
This patch fixes the Coverity issues with CID 115311 and CID 1155312.
So far, a single dummy packet has been sent immediately after the
reception of a MDCX message. There is no dedicated keep alive
mechanism (it just worked because the audio from the MS has always
been forwarded to the NAT until the 'mgcp: Set output_enabled flags
based on the MGCP mode' patch).
This patch adds explicit, timer based keep alive handling that can be
enable per trunk. A VTY command 'rtp keep-alive' command is added for
configuration which can be used to set the interval in seconds, to
send a single packet after the reception of a CRCX/MDCX when RTP data
from the net is expected ('once'), or to disable the feature
completely ('no rtp keep-alive'). In 'send-recv' connections, only
the initial packet is sent if enabled (even when an interval has been
configured). The default is 'once'.
Note that this removes the mgcp_change_cb() from mgcp_main.c.
Sponsored-by: On-Waves ehf
Currently a dummy packet is only sent to the RTP port. This is not
enough if RTCP must also cross the SNAT.
This patch sends an additional dummy packet to the RTCP net
destination if omit_rtcp is not set.
Sponsored-by: On-Waves ehf
Rename the timestamp variable to make in clear, that the input
timestamp is meant. Add a helper variable to illustrate the offset
computation.
Sponsored-by: On-Waves ehf
This patch extends the test_messages test to show the number of dummy
packets that has been passed to sendto(). This way, dummy packets are
even being counted when sendto() itself failes (e.g. due to the fd
being -1).
Sponsored-by: On-Waves ehf
This modifies the test MGCP messages to include M:recvonly (CRCX),
M:sendrecv (MDCX) and M:sendonly (MDCX) outputs the resulting
output_enabled flags and the conn_mode after processing the message.
Sponsored-by: On-Waves ehf
This patch make it possible to have a valid endpoint that drops all
outgoing RTP packets. The number of dropped packets is shown by the
VTY 'show mgcp' command. By default, this feature is disabled. To
enable packet dropping, the corresponding output_enabled field must
be set to 0.
Ticket: OW#1044
Sponsored-by: On-Waves ehf
Currently there are two symmetric code paths which are selected by
the packet destination (NET or BTS).
This patch introduces 3 variables that take the different values
and unifies both code paths into one.
Sponsored-by: On-Waves ehf
This commit adds the implementation of these range formats to the
encoder. In addition, the work-around that tried range 512 first is
removed, so that the selection is primarily based on the max distance
between frequencies.
Ticket: OW#1061
Sponsored-by: On-Waves ehf
Currently the encoding of the chan_list is done by a hard-coded
sequence of macros that closely resembles figure 10.5.16 in
3GPP TS 04.08.
This patch replaces this by an algorithmic solution that can be used
for all range encodings and is based on the property
W(2^i) to W(2^(i+1)-1) are on w1_len-i bits when present
(see section 10.5.2.13 in TS 04.08).
Ticket: OW#1061
Sponsored-by: On-Waves ehf
f0 is currently set to arfcns[0] in range_enc_determine_range(),
while GSM 04.08 requires f0 to be ARFCN 0 in range1024 encoding.
This patch modifies range_enc_determine_range() to force f0 to be 0
if this encoding is used. This way the case distinction in
range_enc_filter_arfcns() is not longer necessary.
Sponsored-by: On-Waves ehf
Currently tests covering features of the GSM 04.08 specification are
spread over the si and gsm0408 subdirs in tests.
This commit merges all tests from 'si' into 'gsm0408' and removes the
'si' test sub-directory.
Sponsored-by: On-Waves ehf
This commit adds test range encoding tests. They check the property
decoding(encoding(L)) = L and optionally dump the results and
encoded sequences to stdout.
There a 2 test modes:
- A list of fixed tests
- A random number based test loop per ARFCN list size (only dumps
the first failing test)
Sponsored-by: On-Waves ehf
The iPhone5 (US) appears to have some issues with the SIs generated,
or the nanoBTS is not sending them correctly.
Add a configurable hack to put all bands into the SI2/SI5 message.
It is enabled by the bts VTY command 'force-combined-si'.
This is a quick change without much reflection and watching for side
effects. I have verfied that a network with ARFCN 134 and neighbors
ARFCN 130 and 512 do not get generate the SI2ter and announce everything
inside the SI2.
This patch is conceptually based on 'si: Add a hack to disable
SI2ter/SI2bis/SI5ter/SI5bis messages' (692daaf2d2).
Ticket: OW#1062
Sponsored-by: On-Waves ehf
Speech codings which are not supported by BTS will be removed from the
bearer capability information element after parsing. This way it is not
required for the MNCC application to consider support of each BTS.
Only GSM full rate is supported by default.
This option is a workarround for a bug found in Nokia InSite BTS firmware
version 3.0.0. There is no RELease CONFirm message for local end release.
Nokia MetroSite with firmware version 4.178.16 is not affected.
TS 04.06 Chapter 5.4.4.4 "Local end release procedure" states that a
confirm must be sent by layer 2 when receiving a local end release
request.
In order to correctly switch a channel (handover or assignment), local
end release is required.
Currently the NET_DST information element (see GSM 24.008) is not
included in generated MM info messages even when the DST field in the
timezone info has been set via the VTY or the control interface.
This patch modifies gsm48_tx_mm_info() to append this information
element if (and only if) a non-zero DST has been configured. The
DST IE is not part of GSM 4.8. Therefore it will only be sent, if the
DST offset is configured to a value != 0.
The DST functionality has been verified with wireshark by Jacob.
Sponsored-by: On-Waves ehf
Currently we only set the SUBSCR on RSL messages. Extend it to
messages that go through MNCC. For call control/bridging it is
difficult to pick the right subscriber. We should support a list
or at least two legs in the imsi filter context.
In case the unpack of a USSD request is failing the channel would
remain open and the phone would not receive a response. Simply
reject the interrogation.
Example interrogation:
0000 1b 7b 1c 0d a1 0b 02 01 01 02 01 0e 30 03 04 01
0010 11 7f 01 00
Sylvain pointed out that in the current crash log the transaction
we try to read the SMS from is actually a transaction for Call
Control. On AMD64 the struct layout is different and that leads to
a crash when the CC transaction is in front of the SMS transaction.
Look at the trans->protocol to fix the crash. The issue got
introduced in 6a3d765bf9 (2010)
when I added the SAPI N Reject handling.
#0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0)
at smpp_openbsc.c:284
284 if (sms->source != SMS_SOURCE_SMPP)
(gdb) bt
#0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0)
at smpp_openbsc.c:284
#1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4,
signal_data=0x7fff33574ea0) at signal.c:105
#2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>,
sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125
#3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000
#4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>)
at bsc_api.c:733
#5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:755
#6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:736
#7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>)
at bsc_rll.c:55
#8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243
#9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133
#10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346
(gdb) frame 3
#3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000
1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0);
(gdb) p trans
$1 = (struct gsm_trans *) 0xedba80
(gdb) p *trans
....
data = 0x1}}, sms = 0x3439323400000003}}}
(gdb) p trans->protocol
$4 = 3 '\003'
Avoid a crash when reading a SMS and a Subscriber could not be resolved.
It is not clear why the read was failing. The sender_id and the receiver_id
was valid for the given sms. I assume that the database has been locked
due external access to it.
The side-effect is that in case of such a failure the sms_queue will start
to deliver starting from subscriber id = 0 again.
#1 0x0000000000428bec in sms_from_result (net=0x156a270, result=0x15eda30) at db.c:1146
#2 0x000000000042a8e0 in db_sms_get_unsent_by_subscr (net=0x156a270,
min_subscr_id=<optimized out>, failed=<optimized out>) at db.c:1255
#3 0x000000000042e900 in take_next_sms (smsq=<optimized out>) at sms_queue.c:193
#4 sms_submit_pending (_data=0x158e300) at sms_queue.c:227
#5 0x00007f3fd30de3bc in osmo_timers_update () at timer.c:243
#6 0x00007f3fd30de69b in osmo_select_main (polling=0) at select.c:133
#7 0x0000000000406fbc in main (argc=9, argv=<optimized out>) at bsc_hack.c:346
(gdb) frame 1
#1 0x0000000000428bec in sms_from_result (net=0x156a270, result=0x15eda30) at db.c:1146
1146 strncpy(sms->src.addr, sms->sender->extension, sizeof(sms->src.addr)-1);
(gdb) p *sms
(gdb) p sms->sender
$1 = (struct gsm_subscriber *) 0x0
(gdb) p sender_id
$2 = <optimized out>
Sylvain pointed out that the RLL and the SMC timeout is the same.
This can lead to have a SMC re-transmission before the first RLL
Establish Request has timed out. Reduce the RLL timeout. GSM 08.58
does not specify a timeout so right now I just reduce it to seven
seconds.
conn->loc_operation is already NULL (e.g. due a five second timeout but
we are still processing a RSL message after we initiated the release
procedure). Do not attempt to authorize a subcriber without knowing the
key_sequence.
This can cause more problems but we will need to test this in the field.
(gdb) bt
#0 gsm0408_authorize (conn=0x19fc2f0, msg=<optimized out>) at gsm_04_08.c:323
#1 gsm0408_authorize (conn=0x19fc2f0, msg=<optimized out>) at gsm_04_08.c:319
#2 0x000000000043a99a in mm_rx_id_resp (conn=0x19fc2f0, msg=<optimized out>)
at gsm_04_08.c:495
#3 gsm0408_rcv_mm (msg=<optimized out>, conn=0x19fc2f0) at gsm_04_08.c:1041
#4 gsm0408_dispatch (conn=0x19fc2f0, msg=<optimized out>) at gsm_04_08.c:3232
(gdb) p *conn
$5 = {entry = {next = 0x1746930, prev = 0x1a14270}, subscr = 0x1745eb0,
expire_timer_stopped = 1 '\001', loc_operation = 0x0, sec_operation = 0x0,
anch_operation = 0x0, silent_call = 0, put_channel = 0, sccp_con = 0x0, in_release = 0,
lchan = 0x7f8c79007218, ho_lchan = 0x0, bts = 0x1719f90, T10 = {node = {
rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0},
timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0, data = 0x0},
secondary_lchan = 0x0}
When modern Smartphones receive "Not in VLR". The baseband firmware
apparently does not try to do an IMSI ATTACH but just remains un-happy
and will not connect to the network anymore.
Let's revert it and see if we can find the real issue about the
sms being invalid. Sylvain has pointed out that we get invoked
from a timer and might not have stopped it properly.
This reverts commit 80ba9b5dd6.
I am not sure why it is crashing so this is a speculative fix based on
something we already did in 3e9b2ec257.
#0 sms_find_pending (smsq=0x2706300, sms=<optimized out>) at sms_queue.c:77
#1 sms_sms_cb (subsys=<optimized out>, signal=4, handler_data=0x26e2270,
signal_data=0x7fffdac256c0) at sms_queue.c:396
#2 0x00007fcdea94394c in osmo_signal_dispatch (subsys=1, signal=4,
signal_data=0x7fffdac256c0) at signal.c:105
#3 0x000000000042acc0 in send_signal (sig_no=<optimized out>, trans=<optimized out>,
sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:124
#4 0x000000000042c8e2 in gsm411_sapi_n_reject (conn=0x2722d30) at gsm_04_11.c:999
#5 0x00000000004085d3 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>)
at bsc_api.c:733
#6 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:755
#7 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:736
#8 0x000000000041f522 in complete_rllr (rllr=<optimized out>, type=<optimized out>)
at bsc_rll.c:55
#9 0x00007fcdea9433bc in osmo_timers_update () at timer.c:243
#10 0x00007fcdea94369b in osmo_select_main (polling=0) at select.c:133
#11 0x0000000000406fbc in main (argc=9, argv=<optimized out>) at bsc_hack.c:346
The legacy functions have a bad/wrong return value for the number
of septets in the string. Change the code to use the new functions
which will fix encoding issues as well.
Location Update Requests time out and get rejected because the
subscriber is not authorized. Authorizing the subscriber through
openBSC or sqlite3 doesn't help the subscriber is still seen and
shown as not authorized
The value is read as uint, this is the wrong type it's a (u)longlong
in libdbi 0.9.0 and later.
Currently, all timestamps are force to SeqNo*d + C which is more than
required by the nanoBTS which seems to be sensitive to alignment
errors only (dTS != k*d, d = ptime * rate = 160).
This patch replaces the force_constant_timing feature by a
force_aligned_timing feature. The timestamp offset will only be
changed (and timestamp errors counted) when the alignment does not
match to the raster based on ptime (default 20ms).
The VTY interface does not change.
Sponsored-by: On-Waves ehf
Currently the counter and output timestamp values are written out for
each packet. This makes it difficult to see in the diffs what has
been changed significantly.
This patch changes this by showing differences for those
values. The absolute input values are also shown now. In addition,
the sequence numbers (the difference for the output value) are
written, too.
Sponsored-by: On-Waves ehf
This adds two test cases:
1. Packet repetition (dSeq=0, dTS=0)
2. Broken seqNo (dSeq=0, dTS=160)
The second had been already present in the test cases, but it was a
mere copy&paste mistake which turned out to be rather helpful. This
patch therefore turns it into a documented test case.
Sponsored-by: On-Waves ehf
Decoding and encoding of FR and EFR TRAU frames are put into seperate
functions. CRC check is done to detect bad EFR TRAU frames.
The test case includes FR and EFR transcoding.
EFR support was tested with Nokia InSite BTS and Siemens BS11.
There is the wrong record field selection being used to extract the
default value. It returns the tuple offset instead of the value.
This patch fixes this.
Sponsored-by: On-Waves ehf
Currently the SDP 'ptime' media attribute is never set in generated
MGCP responses.
This patch optionally includes the 'ptime' attribute if
packet_duration_ms is != 0. This behaviour can be enabled/disabled
by using the VTY command "sdp audio-payload send-ptime" (enabled by
default).
Sponsored-by: On-Waves ehf
This patch parses the 'ptime' and 'maxptime' SDP attributes, and the
SDP rate information and sets up packet_duration_ms accordingly. If
the packet duration is unknown or allows for different values (e.g.
because 'ptime' uses a range or 'maxptime' allows for more than one
frame) the duration is set to 0.
Sponsored-by: On-Waves ehf
Currently the local connection options have been stored as a string.
This patch replaces this string by a struct (that still contains a
string) along with the parsed fields (only the packetization period
at the moment).
It also re-adds the calls to set_local_cx_options() to the
handle_create_con() and handle_modify_con() functions. Except for
the test program this has no side effects, since the LCO values
aren't used yet.
This also adds additional MDCX tests (based on MDCX4) to test the
analysis of different combinations of 'p' and 'ptime' fields.
Sponsored-by: On-Waves ehf
Currently the timestamp offset calculation is done in two different
places.
This patch moves and unifies both code parts into a separate function.
Sponsored-by: On-Waves ehf
This tool provides the following features:
- Output formats: state, C arrays
- Optionally take RTP payload from existing state files
- Generate streams with RTP timestamp jumps and/or delays
- Set/change SSRC or payload type
Requires erlang to be installed.
Example:
Generate 300 packets, set playout time offset to 1s, set
RTP timestamp offset to 8000 (1s), generate another 100
packets, the RTP payload is copied from rtp.state:
./gen_rtp_header.erl --type=98 --file=rtp.state --
0 300 0 --delay=1.0 100 8000
Sponsored-by: On-Waves ehf
This patch adds optional parameters to pass the state file, the
destination address (default 127.0.0.1), the destination port
(default 4000), the source port (default 0). So it is called as
follows:
gst rtp_replay.st -a [FILE [HOST [SOURCEPORT [DESTPORT]]]]
In addition, nonexistant FILEs are no longer created but opened
read-only instead.
Sponsored-by: On-Waves ehf
Andreas highlighted that the doubel assignment is not needed and
wrong. Change the code to assign chan_list[0] before writing the
base frequency to the header. Update the testcase to make the highest
bit set and update the test result.
The IMSI can only be 15 characters in length, our define gives
us a length of 17. This means we have place for two NULs. Use
strncpy and make sure it is null-terminated.
Fixes: Coverity CID 1040707
Since the packet duration is given in ms with the 'ptime' RTP media
attribute and also with the 'p' MGCP local connection option, the
computation is changed to use this value (if present). The
computation assumes, that there are N complete frames in a packet and
takes into account, that the ptime value possibly had been rounded
towards the next ms value (which is never the case with a frame length
of exact 20ms).
Sponsored-by: On-Waves ehf
This forces the output timing to fulfill
dTS = dSegNo * fixedPacketDuration
where dSegNo = seqNo - lastSeqNo.
If timestamp patching is enabled, the output timestamp will be set
to lastTimestamp + dTS. This kind of relative updating is used to
handle seqNo- and timestamp-wraparounds properly.
The updating of timestamp and SSRC has been separated and the patch
field of mgcp_rtp_state has been renamed to patch_ssrc to reflect
it's semantics more closely. The offset fields are now used always
and will change the corresponding header field if they are != 0.
Ticket: OW#1065
Sponsored-by: On-Waves ehf
Currently the output SSRC is always forced to be the same if SSRC
patching is enabled.
This patch modifies this to optionally restrict the number of SSRC
changes that will be corrected.
Note that the configuration only allows for the 'once' mode and 'off'.
Sponsored-by: On-Waves ehf
The ssrc has been used without respect to proper byte ordering in
mgcp_patch_and_count(). This only affected log messages.
This patch introduces a new variable 'ssrc' that takes the value of
the SSRC in proper byte order.
Sponsored-by: On-Waves ehf
This patch adds a packet_duration field to mgcp_rtp_state which
contains the RTP packet's duration in RTP timestamp units or 0, when
the duration is unknown or not fixed.
Sponsored-by: On-Waves ehf
Currently seq_offset and timestamp_offset are updated on each SSRC
change even when SSRC patching is not allowed.
This patch fixes this by changing mgcp_patch_and_count() to only
update these fields when SSRC patching is allowed.
Sponsored-by: On-Waves ehf
Show old and new SSRC. Move logging command upward to show the values
immediately after the change has been detected and before any fixing
attempt is made.
Sponsored-by: On-Waves ehf
This adds datastructures and a VTY frontend to configure the
different type of RTP header patching: SSRC and timestamp.
Note that timestamp patching is not yet implemented.
Sponsored-by: On-Waves ehf
The tsdelta computation and error detection didn't handle the
intialisation phase properly.
This patches fixes this by skipping the output timing validation
when the SSRCs don't match.
Sponsored-by: On-Waves ehf
This patch extends the existing RTP error check test by adding a
check for timestamp errors after SSRC changes and a check for a
segno delta of 2 (with a timestamp delta of 320).
To test SSRC patching too, a corresponding line will be written on
each SSRC change that has been detected in the output stream.
In addition there is now support for selectively enabling/disabling
SSRC and timestamp patching. The RTP test sequence is repeated for
all combinations thereof.
Sponsored-by: On-Waves ehf
So far the SDP part of the CRCX message has been ignored by the MGW.
This patch adds SDP parsing for this case, eventually updating the
net end's payload type and connection parameters.
Sponsored-by: On-Waves ehf
So far the payload type used in RTP streams has been taken from the
trunk configuration in NAT mode.
This patch changes the implementation to use the payload type
announced in the SDP part of MGCP messages and responses. SDP
descriptions more than one m=audio line are not yet supported
properly (always the last one is taken).
Ticket: OW#466
Sponsored-by: On-Waves ehf
The MGCP message isn't always NUL-terminated when arriving at
mgcp_handle_message(). This may lead to undefined results.
This patch ensures that the message text is NUL-terminated by
setting *msg->tail to '\0' in mgcp_handle_message().
Addresses:
<000b> mgcp_protocol.c:642 Unhandled option: 'r'/114 on 0x3
<000b> mgcp_protocol.c:593 Unhandled SDP option: '='/61 on 0x3
<000b> mgcp_protocol.c:871 Unhandled option: '.'/46 on 0x2
Sponsored-by: On-Waves ehf
This patch add the for_each_line macro based on a strline_r()
function (similar to strtok_r()), that is also part of this patch.
This strline_r() function is tolerant with respect to line endings,
it supports CR-only, CRLF, and LF-only and any combinations thereof
(note that a CRLF is always detected as a single line break).
Similar to for_each_non_empty_line (the former for_each_line) where
the 'save' pointer needed to be initialised by a call to strtok_r(),
the new for_each_line macro expects, that the 'save' pointer has been
initialised by a call to strline_r(). Also note, that
for_each_line/strline_r and for_each_non_empty_line/strtok_r may use
the 'save' pointer differently, so calls to them can not be mixed.
Sponsored-by: On-Waves ehf
The implementation of for_each_line is based on strtok() and skips
any sequence of CR and LF. Thus empty lines are never detected. There
exists code which tests for an empty line to detect the beginning of
the SDP part which is dead code currently (the parser works
nevertheless due to other reasons). So the semantics of this macro
have been misunderstood at least once.
This patch renames the macro to reflect the semantics more precisely.
Sponsored-by: On-Waves ehf
The current implementation increments the seqno but does not increment
the RTP timestamp, leading to two identical timestamps following one
after the other.
This patch fixes this by adding the computed tsdelta when the offset
is calulated. In the unlikely case, that a tsdelta hasn't been
computed yet when the SSRC changes, a tsdelta is computed based on
the RTP rate and a RTP packet duration of 20ms (one speech frame per
channel and packet). If the RTP rate is not known, a rate of 8000 is
assumed.
Note that this approach presumes, that the per RTP packet duration
(in samples) is the same for the last two packets of the stream being
replaced (the first one).
Sponsored-by: On-Waves ehf
This patch adds a test case to check, whether RTP timestamps are
generated properly after SSRC changes and whether the error counters
work properly.
Sponsored-by: On-Waves ehf
This patch modifies the patch_and_count() function to check for RTP
timestamp inconsistencies. It basically checks, whether dTS/dSeqNo
remains constant. If this fails, the corresponding counter is
incremented. There are four counter for this: Incoming and outgoing,
each for streams from the BTS and the net.
Note that this approach presumes, that the per RTP packet duration
(in samples) remains the same throughout the entire stream. Changing
the number of speech frames per channel and packet will be detected
as error.
In addition, the VTY command 'show mgcp' is extended by an optional
'stats' to show the counter values, too.
Ticket: OW#964
Sponsored-by: On-Waves ehf
GSM 12.21 specifies that "No elementary procedure shall be
initiated to an object instance which has not yet replied to
a previously initiated elementary procedure with a response,
an ACK or a NACK within a layer 3 time-out. The layer 3
timeout for ACK, NACK and responses shall have a default value
of 10 seconds."
We are using this flag in the BTS to enforce/safe-guard
this situation.
Rename this function to bsc_send_ussd_no_srv() since it's a rather
specialised function and not a generic USSD notification function.
Sponsored-by: On-Waves ehf
The MS do not show the USSD messages yet. This patch modifies the
implementation to insert a CM Service Accept to finish the
establishment of the MM connection according to 3GPP TS 04.10/3.2.1
before the USSD notification is sent.
This fix has been tested with a Blackberry phone that has shown
an ussd_grace_txt after rf_locked has been set to '1'. Without this
patch, that message wasn't shown. The phone has sent a CC Setup
and other messages before processing the channel release message sent
by the BSC, but these messages have not been forwarded to the MSC (as
expected).
Ticket: OW#957
Sponsored-by: On-Waves ehf
These functions are currently located in libmsc/gsm_04_08.c together
with other symbols that (transitively) depend on many external
symbols (and thus libraries) that aren't otherwise needed by e.g.
osmo-bsc.
Since gsm48_tx_mm_serv_ack() will be needed by osmo-bsc, these
functions are moved to avoid the dependency on gsm_04_08.o.
Sponsored-by: On-Waves ehf
The MS do not show the USSD messages yet. This patch modifies the
implementation to insert a CM Service Accept before the ussdNotify
to finish the establishment of the MM connection according to
3GPP TS 04.10/3.2.1.
This fix has been tested with a Blackberry phone that has shown
an ussd_grace_txt after rf_locked has been set to '1'. Without this
patch, that message wasn't shown. The phone has sent a CC Setup
and other messages before processing the channel release message sent
by the BSC, but these messages have not been forwarded to the MSC (as
expected).
Ticket: OW#957
Sponsored-by: On-Waves ehf
This patch replaces the calls to ignoredCheckForEndAndExit by calls
to checkForEndAndExit to test the libosmocore nodes, too. The former
method is removed.
Sponsored-by: On-Waves ehf
Remove ournode_exit_cmd, ournode_end_cmd, and bsc_install_default()
since this functionality is provided by the current libosmocore.
Replace calls to bsc_install_default() by call to
vty_install_default() with the following semantic patch:
@rule1@
expression N;
@@
- bsc_install_default(N);
+ vty_install_default(N);
Ticket: OW#952
Sponsored-by: On-Waves ehf
When the PCU is activating a channel we don't want to tell the
BSC using RSL. Add a flag so we can keep track of who asked for
the activation/release of the channel.
The gbproxy looses NSEI changes on BVC_RESET and then tries to send
later messages to the wrong (not longer existing) destination.
This patch fixes this by updating the peer's nsei field on BVC_RESET.
Ticket: OW#874
Sponsored-by: On-Waves ehf
This checks the behavior of the gbproxy when the BSS peer changes the
NSEI and the NSVCI. It also tests BVC_RESET and other UNITDATA
messages after these changes between BSS and SGSN and vice versa (via
the gbproxy).
Ticket: OW#874
Sponsored-by: On-Waves ehf
This adds the option to delete all BVC peers and/or NS_VC with a
given NSEI with a single command. Static (configured) NS-VC are not
affected. In addition, all connections for this NSEI that can be
deleted by this command can be listed without deleting them by
appending 'dry-run' to the command.
Sponsored-by: On-Waves ehf
Currently such messages lead to a creation of a new peer with the
SGSN's NSEI, which results in echoing the message back to the SGSN.
This patch modifies this by sending a STATUS response (invalid BVCI)
instead back to the SGSN.
Sponsored-by: On-Waves ehf
This adds a test with a UNITDATA SGSN message that is addressed to an
invalid (unknown) BVCI. The test shows, that the message is echoed to
the SGSN.
Sponsored-by: On-Waves ehf
This adds counters that are incremented when errors are detected.
It also modifies the VTY command 'show gbproxy' so that
'show gbproxy stats' shows the counters.
Sponsored-by: On-Waves ehf
Add the unused attribute to peer_free() that isn't used currently.
Change 'RAC' to 'NSEI' in the log message, since the latter has been
examined before the log message is generated.
Sponsored-by: On-Waves ehf
This adds a simulation of the SGSN side of the Gbproxy. The VC is set
up correctly and several combinations of BSSGP messages are sent.
Sponsored-by: On-Waves ehf
Currently in most places in gb_proxy.c a reference to a NS-VC object
is used where the peer is meant instead. The patch changes this by
using the NSEI instead in these cases.
Sponsored-by: On-Waves ehf
This program tests the gbproxy implementation by passing NS messages
to a modified gbproxy that dumps the resulting messages, signals, and
state.
It focusses on testing abnormal situations like port changes.
Ticket: OW#874
Sponsored-by: On-Waves ehf
This adds a per BTS control command 'timezone' which expects a value
of the format '<hours>,<mins>,<dst>' or 'off' to set the value of
bts->tz. It has the same functionality like the existing VTY command
'timezone' in network/bts.
Sponsored-by: On-Waves ehf
Ticket: OW#978
This adds in-place patching of the time information in the
MM INFORMATION message. The timezone in the 'Local time zone' and
the 'Universal time and local time zone' information elements
and the offset in the 'Network Daylight Saving Time' information
element are optionally set.
The new values are determined by the 'timezone' vty command in the
config_net_bts node. That command is extended by an optional
DST offset parameter.
Tests are provided for the vty part and for the plain
bsc_scan_msc_msg() function.
Sponsored-by: On-Waves ehf
Ticket: OW#978
When verification failed and the reply string was not updated, the
message "Someone forgot to fill in the reply." was shown instead
of the default "Value failed verification." message.
This patch changes the default reply handling in ctrl_cmd_handle()
by setting the reply to NULL initially and then checking it at the
end. If it hasn't been set, a generic message is assigned and an
error is logged.
This script is similar to vty_test_runner.py but tests the control
interface instead.
It currently tests some error cases, BTS status queries, and
setting/clearing rf_locked.
This stores the last SET rf_locked control command along with a
timestamp. The 'show network' vty command is extended to show
this information.
Ticket: OW#659
This prevents the application from crashing when there is a half
configured BTS (e.g. by using the command 'bts 1' when there isn't
a BTS 1) and the 'write' command is used.
Send an USSD message to the mobile station requesting a connection
for a call or a SMS when the link to the MSC is down or in the
grace period.
The messages can be set (and this feature activated) by setting
bsc/missing-msc-text resp. msc/bsc-grace-text via the vty.
The generation of both messages has been tested manually.
Ticket: OW#957
In case of the RLSD coming from the MSC we are patching the address
in-situ but for local calls set con = NULL. We then answered the RLSD
with the wrong reference and the MSC kept on trying.
It was possible to cause a crash by enabling and disabling the
MSC connection. The enabling lead to scheduling a connection
and the second call was not stopping the timer.
Assign a static name to a MSC Connection and use it. In case there
are multiple connections we can now more easily identify them.
This is only used for the NAT right now, the BSC could start to
name the various MSC connections too.
Currently the 'mgcp' command fails in the 'config-nat' node, because
it get confused with 'mgcp-through-msc-ipa' which is executed
instead because of the prefix based command selection. Thus the
latter command is renamed by this patch to avoid the common prefix.
The workaround in the test suite is removed.
Add bsc_install_default() and replace all install_default()
This patch adds bsc_install_default() which calls install_default()
and add 'exit' and 'end'. All other calls to install_default() are
replaced by calls to bsc_install_default().
Since 'exit' and 'end' are now added automatically to each node, the
explicit registrations of these commands are removed by this patch,
too.
The related tests succeed now without work-arounds (except for the
'config' node itself which is part of libosmocore).
ournode_exit() duplicates most of bsc_vty_go_parent(). This patch
fixes the inconsistencies of both functions within
bsc_vty_go_parent() and replaces the implementation of
ournode_exit() by a call to it. This makes 'exit' behave exactly
like ^D in all openbsc nodes.
ournode_end() has been changed to walk through the intermediate
nodes until one of the top nodes is reached. This allows for
cleanups to be done on the way.
Note that in config mode if the tree is searched along the nodes
toward the config node and a command is not found this way, a
rollback is done by just replacing the vty's node and index member
variable by the saved old values which might break the whole thing, when
there has been a free() on the way.
These tests check for the availability of 'exit' and 'end' in each
configuration node and for the node specific commands to traverse
the tree.
In addition, using these commands from within inner contexts is
checked. This will detect problems, when an outer command word is
a prefix of an inner command, like with 'mgcp' and
'mgcp-through-msc-ipa'.
Several assertions are disabled due to inconsistencies and missing
commands (see above).
Addresses:
osmo_bsc_sccp.c:280:2: warning: implicit declaration of function ‘gsm0480_send_ussdNotify’ [-Wimplicit-function-declaration]
osmo_bsc_sccp.c:281:2: warning: implicit declaration of function ‘gsm0480_send_releaseComplete’ [-Wimplicit-function-declaration]
It was possible that the wrong NSEI information was sent to the
BTS. This is because patch_nm_tables is not called before sending
the data to the BTS. This will break when two BTS connect more or
less at the same time.
Stop using the arrays directly and instead introduce a method
that will patch the table and return the data and length. This
makes sure that all users patch the table before we send the
data to the BTS.
I bootstrapped a sysmoBTS and I can bring up rsl. The device is
running with a dummy load so I couldn't do more verification.
Change '%s(bsc)#' to '%s(config-bsc)# '. The missing trailing blank
breaks osmopy's VTYInteract.command() because the blank is contained
in the end patterns which are checked to decide whether to leave the
select loop. Thus trying to execute the 'bsc' command there blocks
the test script forever.
Send an USSD message on each MS connection if the connection to
the MSC has been lost.
Add a vty config command 'bsc-msc-loss-txt' in 'config-msc' to set
the notification string and to enable the feature.
Ticket: OW#957
This command returns the current state of the connection to the USSD
side channel provider. It shows whether a provider has been connected
and authorized or not.
Fixes: OW#953
These commits have been deployed by sysmocom and it should qualify
as some form of smoke testing. Let's see how things go from here.
The by IMSI alertion has not been used, the rest should have been
executed by the system.
There's a VTY option by which for every ESME the user can specify if the
E.212 or E.164 number should be used in DELIVER-SM. The ALERT
notifications generate by subscriber LU have so far always contained the
E.212 (IMSI) rather than E.164 (MSISDN) which is a bit inconsistent.
Rather than copying code, we create a new function that implements
ALERTing all ESMEs.
If the MS memory for SMS is exceeded and we get an RP-layer error, we
need to report that back to the (transaction-mode) ESME. Otherwise the
ESME will wait forever after sending a SUBMIT-SM without ever receiving
a response to it.
Thanks to Holger for catching this.
* The post-routing is applied after the first re-writing. To do this
the new number is copied back into the called data structure.
* Add a testcase that goes from 0172 to 0049 and then back to 0049
using the post rule with a table lookup.
* Increase the rewritten rule to five digits (this is the easiest
for the unit test). This will add another 40kb to the runtime size.
* Create a unit test that tests adding and removing the prefix rules.
* Use the regexp match to replace from one package
* It is a trie. The max depth of the trie is the length of the
longest prefix. The lookup is O(lookuped_prefix), but as the prefix
length is limited, the lookup time is constant.
* Each node can hold the entire prefix, has place for the rewrite
rule with up to three digits.
* A trie with 20k entries will take about 3MB ram.
* Filling the trie 100 times takes ~800ms on my i7 laptop
* 10.000.000 lookups take 315ms.. (for the same prefix).
* 93/99 lines are tested, 6/6 functions are tested, 49 of 54 branches
are tested. Only memory allocation failures are not covered
* A late addition is to handle the '+' sign and to increase the number
of chars in the rewrite prefix. The timing/line coverage has not
been updated after this change.
In case we have access to the context verify that the selected
msgb_tlli is either the old_tlli or the tlli in either local or
foreign format. It is wrong to use any other TLLI.
Attempt to solve what f0901f0067 tried to
solve without breaking the case of someone with a foreign TLLI from a
different network.
Lookup with the foreign TLLI converted to a local one in case we did
not find the TLLI and only then create a LLE/LLME on the fly for the
RX path.
During the GPRS Attach procedure we might have a foreign tlli and
in the RX create a LLME on the fly for this tlli. The GMM GPRS
Attach handling code will then assign a new TLLI and keep the
foreign tlli as the llme->old_tlli.
When the GMM is sending the identity request the msgb_tlli will
point to the foreign tlli. The GPRS LLC code will then try to find
that foreign tlli but due the conversion this will not be found.
Instead a new ad-hoc LLE/LLME will be created on the fly for
each message (this means there are duplicate LLE/LLMEs in the
list).
Make the code more strict and remove the tlli_foreign2local change
from the look-up routine. This will make the GPRS LLC code find
the right LLE/LLME and the N(U) will be handled correctly.
This partially reverts:
f0901f0067
Addresses:
<0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly
...
<0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly
Reproducable:
Use pcu_emu (gprs attach) and observe with wireshark.
In case of a failure this method didn't set the pctx->lib back to
NULL. In case of a timeout the callback will be made with pdp=NULL
and this would lead to leaking the PDP context. Check for the case
of having a pctx->lib != pdp and free it.
This resolves:
<000f> gprs_sgsn.c:259 freeing PDP context that still has a libgtp handle attached to it, this shouldn't happen!
The jenkins build node has Python 2.5.X installed and the
assertGreater method is not available. Use assert_ until
we can use newer versions of Python.
Disable the periodic LU using "no periodic location update" VTY
command. In that case set the expire_lu to 0 which will then be
translated to a NULL in the database layer. This leads to a bit of
copy and paste in the db_sync_subscriber method but I don't see
how we could easily use 'datetime(%i, 'unixepoch')' and 'NULL'
at the same time.
Change the query to find expired queries to check for NOT NULL
and the time being in the past. This means if there are still
old subscribers in the database they might not be expired. One
would need to execute a query like "UPATE Subscriber SET expire_lu
= 0 WHERE expire_lu is null". The same applies when disabling the
periodic LU. One would need to update the database by hand.
Manual tests executed/passed:
1.) periodic LU enabled:
* use gst LUTest.st to do a LU
* UPDATE Subscriber SET expire_lu=datetime('now');
* observe the subscriber being expired (it was)
2.) periodic LU disabled:
* use gst LUTest.st to do a LU
* verify that the expire_lu is NULL in the database
We were expiring subscribers during active calls. This is because
the T3212 is stopped under certain conditions but we didn't stop
that timer at all.
Remember if T3212 timer was stopped due something done by NITB and
update the expiration time at the end of the radio connection, as
the phone should restart it when returning to MM Idle.
It is a bit difficult to decide when we should set the flag. E.g.
in a CM Service Request we don't know if we accept the service and
during a LU we already send MM messages before we accept or reject
the subscriber.
The easiest is to set the flag when receiving a paging response
on known subscribers and at the end of the authentication process.
Do not expire a subscriber that has an active connection that is
marked with the flag, e.g. we would still expire a subscriber that
is being paged.
Manual tests executed/passed:
* gst LUTest.st verified that a expiration date was set
* gst SMSTest.st (doing another LU but forcing a timeout on the
SMS sending). Verified that the expire_lu was updated.
Make sure to not ever have issues with this code again, move the
utility code to a new file and create a basic testcase. The method
currently has 100% line and branch coverage. My initial patched
missed the smpp_utils.c file and I re-did the copying (and verifying
the branch coverage)
bsc_api.c:417:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘unsigned int’ [-Wformat]
bsc_api.c: In function ‘handle_ass_fail’:
bsc_api.c:458:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘unsigned int’ [-Wformat]
db.c: In function ‘db_sync_subscriber’:
db.c:785:3: warning: format ‘%i’ expects argument of type ‘int’, but argument 8 has type ‘time_t’ [-Wformat]
osmo_msc.c: In function ‘msc_release_connection’:
osmo_msc.c:145:20: warning: unused variable ‘trans’ [-Wunused-variable]
smpp_smsc.c: In function ‘link_accept_cb’:
smpp_smsc.c:891:24: warning: assignment from incompatible pointer type [enabled by default]
smpp_smsc.c:271:1: warning: ‘esme_by_system_id’ defined but not used [-Wunused-function]
smpp_openbsc.c: In function ‘smpp_openbsc_init’:
smpp_openbsc.c:545:2: warning: implicit declaration of function ‘smpp_vty_init’ [-Wimplicit-function-declaration]
osmo_bsc_ctrl.c: In function ‘verify_bts_loc’:
osmo_bsc_ctrl.c:340:19: warning: variable ‘height’ set but not used [-Wunused-but-set-variable
smpp_mirror.c: In function ‘main’:
smpp_mirror.c:297:2: warning: implicit declaration of function ‘osmo_init_logging’ [-Wimplicit-function-declaration]
This adds a minimalistic ACL by which certain, individual roaming IMSIs
can be authorized to use the SGSN. So you can selectively bypass the
'MCC+MNC == first 5 digits of IMSI' checking for a couple of IMSIs
It appears to me that for NM_OC_BS11 mo was either NULL or the
one mo value from NM_OC_BS11_RACK. The break inside the nested
switch case didn't break from the outer one.
Fixes Coverity: CID 1040728
The esme->acl is treated like it can be NULL in other places
of the code. Assume it can be NULL during this check as well.
Dereference after null check (FORWARD_NULL)
9. var_deref_op: Dereferencing null pointer "esme->acl".
Fixes: Coverity CID 1042374
As Holger pointed out, they contained a GPLv2+ disclaimer rather than
the AGPLv3+ which we use for OpenBSC. This is not an incompaibility,
but was done unintentionally. The code was always mean to be under
AGPLv3+.
Nevertheless, anyone using those two files in a version up to this
commit have the right to use it under GPLv2+ as well. This is not
applicable for any versions after this commit.
A CM service request must be acknowledged also, when encryption is already
enabled.
Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL,
which causes a CM service acknowledge. On initial CM service request, the
security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This
will not lead to an acknowledge, because the cyphering command implies an
acknowlege. An additional CM service request requires an acknowledge, so
I added a new security status: GSM_SECURITY_ALREADY
Coverity pointed out that we use trans->subscr after a NULL check,
it is our believe that every transaction will have a subscriber.
Remove the check and add an assert before we are dispatching things.
Fixes: Coverity CID 1040740, CID 1040739
Coverity pointed out that this code is logically dead. Quickly
judging the code we will forward the RSLD message anyway. Remove
the code for now and next time I work on the NAT/USSD bridge I
will have a look at the flow of the RLSD messages.
Fixes: Coverity CID 1042327
The number = int_number assignment will make the number point to
the stack and as the int_number goes out of scope at the end of
the if statement other code could re-use this stack for other memory.
Fixes: Coverity CID 1042325
Coverity complains about the saveptr used in the strtok_r. This
is not a bug because we pass a string as part of the first call
to strtok_r but it is easier to just initialize it.
Addresses: Coverity CID 1042323
This fixes both a GCC and a Coverity warning:
GCC:
gsm_subscriber.c: In function ‘subscr_expire_callback’:
gsm_subscriber.c:389:2: warning: format ‘%i’ expects argument of type ‘int’, but argument 8 has type ‘long long unsigned int’ [-Wformat]
Coverity:
CID 1040712
This is fixing a GCC and Coverity warning.
GCC:
sgsn_vty.c: At top level:
sgsn_vty.c:308:1: warning: ‘show_ggsn_cmd’ defined but not used [-Wunused-variable]
Coverity: CID 1040727
This is fixing a GCC and Coverity warning:
GCC:
sgsn_vty.c: In function ‘vty_dump_pdp’:
sgsn_vty.c:64:5: warning: ‘i’ may be used uninitialized in this function [-Wmaybe-uninitialized]
sgsn_vty.c:49:15: note: ‘i’ was declared here
Coverity: CID 1040706
The code was written like checking the return value of the
osmo_fd_register but the rc variable was not assigned for the
subsequent calls.
Fixes: Coverity CID 1040741
Original code was inconsistent about lengths and could lead to out
of bounds write. Lengths were also inconsistent with the TS 24.008.
Fixes: Coverity CID 1040714.
The support has been implemented for an old model, we were told that
newer versions would be made incompatible with OpenBSC. Ther are
various warnings in the code and coverity has found some new ones.
Just remove the code as we don't know of anyone using this code.
Coverity is not happy about it but it doesn't appear to be a real
issue as the data will not be NULL on the first call.
Addresses: Coverity CID 1040704
In case the specified trx number is not configured, do not crash
but return NULL from the function. The libosmo-abis library should
close the connection for us then.
Begin with the NAT code. It is not clear yet if we will have one
file with all the tests or will have a sub directory with *.py files.
In the long run the base class will move to the osmo-python-tests
module.
The test scripts warn about missing documentation, untested configs,
check common errors, and stub out testing individual VTY commands.
The scripts have been moved to the another osmocom repository,
python/osmo-python-tests
The features were requested by zecke.
In some situations (like MS reboot without prior DETACH or SGSN reboot
without prior MS detach), the LLC sequence numbers for UI mode could
be different on both sides.
The LLC spec unfortunately doesn't permit us to send something like a
FRMR in this case, but instructs us to silently discard the frame. At
that time the remote LLC entity will re-transmit the frame with the same
seqeunce number over and over again, which we will drop again and again.
The mthod used now will keep track of the last received UI sequence
number. If that number is retransmitted for three times in a row, then
we accept this sequence number and recover from that point on.
system_id is a char array, which makes the NULL check a tautology,
so we should check with strlen if the string is empty or not.
This is fixing the "write" command of VTY that would otherwise
create a config file that can not be parsed.
If an ESME has the dcs_transparent config flag, then the TP-DCS
of MO-SMS is transparently passed to SMPP and not converted to SMPP
specific data_coding values.
This is needed in cases where ESMEs actually care about the exact
TP-DCS, as the conversion from TP-DCS to SMPP data_coding is not
bijective.
There are multiple ways how the TS 03.38 TP-DCS can indicate 8bit or
7bit messages. SMPP has it's own data coding specification, which is
different from TS 03.38.
However, some SMPP ESMEs want to be able to have fine-grained control
over the TP-DCS indicated in the TPDU header. If such values like 0xF6
are used in SMPP, we now transparently pass them on to the GSM side.
The RQNT message might not contain a 'S:' line with the actual tone
to play. Instead of calling the callback with the 0 as tone just leave
early.
Example:
X: 6B9519B88F0
R: D/[0-9#*](N), G/ft, fxr/t38
A channel that fails to send an ACK/NACK/REL within the four second
timeout is now marked as broken. In case the release comes in late
it will be ignored. The lchan should already been freed and for now
we don't want to trust the channel.
In the future we might want to send a "release" for a channel that
got activated ack late and just set the state to none on a channel
that is released acked late.
The late ACK and REL has been tested with two manual tests using the
fakebts. The channels remained blocked even after having received
the ACK message here. The NACK case has not been manually tested.
* This branch make the type sysmobts work.
* Asssume a bsc_gsmnet variable to be defined.
* This allows to use channel configurations not supported by the
nanoBTS.
* Manually tested with the FakeBTS and tested by users.
Assume that there is a bsc_gsmnet and modify the ipaccess-config to
provide this symbol. If a bsc_gsmmnet is not available when linked
the linker will complain and fail.
E.g. give an error like this:
../../src/libbsc/libbsc.a(bts_ipaccess_nanobts.o): In function `ipaccess_sign_link_up':
src/libbsc/bts_ipaccess_nanobts.c:550: undefined reference to `bsc_gsmnet'
Make sure that the bts_ipa_nm_sig_cb is only installed once. In
a nanoBTS + sysmoBTS network the _start method will be called
for each mode leading to the handler being registered twice.
Make sure that there is only one handler registered by unregistering
a previously installed handler. The osmo_signal_unregister_handler
will remove 0 or 1 handlers per invocation and we only add one
handler in this file so it is always balanced.
The nanoBTS code is trying to find a struct gsm_bts based on
the ipaccess_gsmnet and the ipaccess_unit data. The pointer is
not initialized in the case of a sysmoBTS leading to a classic
NULL pointer dereference.
Move the feature init into the _init method. This way we can
re-use the start code of the nanoBTS. This ensures that the
ipaccess_gsmnet pointer is properly initialized and that the
signal handlers are installed.
Extend the status message and send LAC/CI as part of the status
message. It is using TV to allow sending more fields in the feature.
We only need to encode the data and this is why there is no tlv
description yet.
The bsc_nat.h is included by common_vty.c so we may not used
sccp_types.h in the bsc_nat.h header file. Move the callstats
to a new file and include it where it is needed.
Find the Cell Identifier from the Complete Layer3 Information and
store it for future reference. We could begin to verify that the
LAC/CI used really belongs to the BSC.
The name sccp_connection is used in the osmo-sccp code, sccp_connections
was used in the NAT for tracking a sccp_connection. Rename it so it is
obvious that the struct belongs to the nat.
The rename was done with sed:
$ sed -i s,"struct sccp_connections","struct nat_sccp_connection",g \
include/openbsc/*.h src/osmo-bsc_nat/* tests/*/*
Prepend the international number with a '+' and then do the normal
re-writing on it. There are a couple of ways to handle this:
\+([0-9]), \+[0-9][0-9]([0-9]), \+49([0-9])
Add a test case for the international re-write based on an already
internationalized number.
Limit the amount of pending DLCX responses to three times the amount
of available endpoints. Currently all MGCP messages are sent and handled
in sequence.
We want to send a TRAP with the MGCP statistics from the NAT and
the connected BSC. The BSC endpoint can be either released because
of a DLCX from the MGCP CallAgent or the SCCP Connection release on
the A-link.
This is why we need to queue the statistics when the deleting the
endpoint on the BSC. The processing is continued once the response
arrives. This code assumes that the response of the DLCX will be sent
by the remote side. The current amount of outstanding responses can be
seen on the VTY. This assumption is based on the fact that the BSC has
already responded to the CRCX and maybe to the MDCX.
The MGCP RFC is bended to prefix the transaction identifier with "nat-"
to easily detect the response and hand it to the handler. This will
then parse the response and generate the TRAP. The current version is
v1. We assume that the transaction space is big enough and we will
not re-assign the transaction identifier too early.
The sysmobts is now having a SAPI queue with all pending SAPI operations
on the BTS. Add the llist_head to the lchan and make sure it is initialized
by the shared code.
The token was compared with the configured one but only up to a
user supplied length. Compare the token sizes and then use memcmp
for the actual comparison to make sure to compare the right ammount
of characters.
There is no unit-test but there should be one.
It was possible that the tmp was strduped but not freed, e.g. when
the number of commas was not right. It would evenutally be freed at
the time the cmd is freed thanks to the talloc hierachy.
An ESME can now be configured in the VTY to enable osmocom-extensions,
which will add vendor-specific SMPP TLVs for RxLev/RxQual/ARFCN/IMEI and
transmit power to the SMPP DELIVER-SM message type.
As bsc_gsmnet is NULL at the time we call smpp_openbsc_init(),
we later run into segfaults with subscribers that don't have a
subscr->net set.
However, we cannot delay smpp_openbsc_init() until after
bsc_bootstrap_network(), as we then fail to parse the SMPP specific
VTY/config file options...
This patch adds a new VTY command "ip.access rsl-ip A.B.C.D" at the
BTS level. If you set this IP address, the BTS will be instructed to
establish the RSL link to the indiciated IP address, rather than using
the same as for the OML link (default).
Use "ip.access rsl-ip 0" to disable the feature.
Inside the SI1 rest_octets we will need to indicate if the ARFCN
is band 1800 or 1900. If the BTS is either 850 or 1900 we assume
we are running a PCS network, otherwise it is a DCS network.
The band indicator is not documented in GSM 04.08 but it is in the
GSM 05.14 version 6.1.0 Release 1997.
abis_rsl.c:332:23: warning: 'memset' call operates on objects of type 'struct rsl_ie_chan_mode'
while the size is based on a different type 'struct rsl_ie_chan_mode *'
[-Wsizeof-pointer-memaccess]
memset(cm, 0, sizeof(cm));
~~ ^~
abis_rsl.c:332:23: note: did you mean to dereference the argument to 'sizeof' (and multiply it
by the number of elements)?
memset(cm, 0, sizeof(cm));
^~
1 warning generated.
The paging structure is still initialized lazily and we attempt
to traverse it before it is ready. The crash was discovered by
Katerina. Removing the lazy initialization will take a bit of work
as the gsm_data_shared is used by the osmo-bts and the OpenBSC but
paging is different.
Katerina pointed out that some nodes are not fully documented and
proposed some messages. The token/timeout messages were correct, I
have modified the other messages. I removed the full-stop from the
PING/PONG documentation as we are normally not using a full sentence.
when the SMS code was moved into libosmocore, its logging prefix was
changed from 'sms' to 'lsms', which breaks existing config files.
This introduces a deprecated/hidden vty command to make sure those
config files are still parsed OK, and will simply print a warning
message about the config needing some update.
The message was corrupt at several points. They are fixed now and
successfully tested.
A default T3122 timer value of 10 is defined by default now. If set to 0,
the reject message will not be sent. Note that when using existing configs
with T3122 value set to 0.
Exclude a BTS from the RF Lock and allow MO and MT operations on
this BTS. The paging modification has been verified using the FakeBTS
and the handover test. Paging continues to work for the normal case.
The RF lock excluded BTS was not paged at all. Now forward the
paging message to the handler and call a function that will check
if this LAC can be paged right now. Introduce a new paging method
that allows to page on a dedicated bts, refactor the code to use
this method for paging.
When introducing the exclude for the BTS lock the RF stayed up but
all connections were immediately released. Optionally pass the BTS
as second parameter and check the exclude bit.
Tested-with: rf-lock-exclude/RFLockExcludeTest.st
If after release has been sent, the call control layer waits for:
- reception of release complete
- or timeout
- or release of transaction (due to radio link failure)
In this case, an MNCC_REL_CNF is sent to upper layer. The callref must
still exist, so the upper layer can handle this confirm.
If transaction is destroyed, but callref still exists, the
mncc_release_ind function is called. If the upper layer already sent an
MNCC_REL_REQ, the state N19 was entered. In this case it expects an
MNCC_REL_CNF.
For PCS1900 the SI1 does not contain the ARFCN of the serving cell.
This is because the arfcn2band method will return GSM_BAND_1800 and
not GSM_BAND_1900. The academic fix would be to set the ARFCN_PCS bit
but this would require increasing the bitvector sizes from 1024/8 to
(0x8000 + 1024) / 8. This would increase the storage size for each
bitvector by three.
It is not possible to have DCS1800 and PCS1900 in one network so we
can avoid increasing the memory usage and check if the ARFCN resolved
to 1800 and then check if the BTS is a 1900 BTS and then claim that
this is compatible.
The code predates the TLV parser and we were parsing the RLM from the
wrong offset. In general we were using the length of the TLV which
happened to be equal to the T200 indication.
After consulting the RLM cuases not every of them should generate a
BSC_RLLR_IND_ERR_IND as these are forwarded to the MSC as a SAPI reject
right now.
TLV parsing now generates this due a bug in the osmo-bts code:
abis_rsl.c:1605 (bts=0,trx=0,ts=2,ss=0) SAPI=0 <0000> abis_rsl.c:1547 (bts=0,trx=0,ts=2,ss=0) ERROR INDICATION cause=Fraeme not implemented
For short IP failures we want the RF to stay up and wait for
the re-connect but in case the A-link is gone too long it is
good to switch off the RF and wait for commands to enable it
again.
Merge the code from the On-Waves branch. Use the internal RF control
interface to switch the TRXs on/off. This code has the necessary delays
to not crash the nanoBTS. Introduce signals for re-connection of the
BSC on the A-link.
The issue can be reproduced by typing the following 9 or more times.
OpenBSC> subscriber id 2 sms sender id 2 send bla
For some unknown reason the phone sends us a CP-ERROR for a transaction
identifier we have allocated and used but don't remember. Due the way
we use the SMC/SMR we 'establish' the machine and this results in a CP-ACK
being sent out. But the CP-ERROR is not having the content we want for
an establish so we send out a RP-ERROR. This will result in a CP-ERROR
because the phone does not know the transaction...
Avoid the issue by checking the direction of the transaction. If we do
not know the transaction and it is supposed to be allocated by us then
just ignore it and do not create a new transaction.
Make the macros use the cmd->node instead of the data pointer. The
naming of the variable inside the macro already indicates that it
should use the nodes data structure.
Like with all type unsafe callbacks we will need to cast from
void to the dtype. This addresses some compiler warnings.
Make it possible to only include the control_cmd.h to use the
macros defined in this file.
Handle the mr_config request and set the AMR multirate config for
the given MSC. Initialize the mr_config with the AMR5.9 default we
have been using until now.
When we are asked to route calls on a local link and
the link is not available we would crash when trying
to send a packet over a deadline. When we have decided
to move a connection it is guranteed that the current
SCCP connection will vanish, we either migrate to another
MSC or the RSL/subscriber connection will be closed.
Inspect the CC Setup messages and if the dialed number is matching
the regexp of the local MSC the connection will be rerouted. The
original MSC will get a GSM0808 CLEAR REQUEST, a new connection with
a CC Setup message will be opened.
For USSD we remember that it is a supplementary service but this
means we sent no CM Service Reject down to the subscriber. Treat
NAT_CON_TYPE_CM_SERV_REQ and NAT_CON_TYPE_SSA the same and send
a cm service reject.
Do the auth check in bsc_nat_filter_sccp_cr, remove the cause from
the signature again. For the bsc_nat_filter_dt restructure the flow
but leave the auth inside the id response message.
Return 1 when the IMSI has been extracted as indicator for running
the auth check. 1 has not been used before and is safe to be used
as this indicator.
In preparation for another kind of black-list allow the filter code
to decide how the connection should be rejected. Introduce a new struct
that will carry the reject causes for certain operations.
This implements exipiry of subscribers, requires a schema change. A permanent
attachment (time set to 0) is not supported any more and would require some
more work. This code was used at the 29C3.
Set the subscriber expiry timeout to twice the duration of the location
update period and provide functions subscr_expire() and
db_subscriber_expire() to mark subscribers offline that have missed two
location update periods.
This patch increases the DB revision to 3, so the hlr will be
incompatible with prior versions.
We should allow 0 for T3212 as well to disable the location update
period. In that case we will need a way to indicate that in the
database.
libcommon: Default to 30min location update period
libbsc: Limit VTY value for periodic update and disallow the value 0
According to GSM 04.08 Table 10.5.33 "The value 0 is used for infinite
timeout value i.e. periodic updating shall not be used within the cell."
This was the default value until now, but the code that deals with
expiring inactive subscribers in the next commit can't handle that case
so this remains a TODO for now.
The actual command implementation was already for this, but some
bad vty parsing prevented optional range arguments from working
properly.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This file is created in ./configure so we shouldn't remove it with make.
Otherwise ./configure && make clean && make check fails with:
make[3]: *** No rule to make target `atconfig', needed by `check-local'.
Stop.
We parse the load_config, take the ptrdiff_t from start and load_config
and from the previous array as the alignment can differ on different ABIs.
This was found by Daniel when executing the tests on a 64 bit userspace.
This was reported by Kevin when he was testing handover. The problem
is the order of the signal handlers for S_ABISIP_CRCX_ACK. Right now
the handover signal handler is called before the one inside the libmsc
gsm_04_08.c. This means S_HANDOVER_ACK is signalled _before_ there is a
rtp socket created for the channel. The result is that the MDCX will
never be sent and the called will not be properly switched _after_ the
handover detection.
I do not want to play with the order of signal handlers, remove the
CRCX ack handling from the handover_logic.c and force the NITB (and
later the BSC) to check if the lchan is involved with a handover and
do the switching in there. This means right now we do what two signal
handlers did in one.
Reproduced and tested with the FakeBTS Handover test.
Log message:
<0004> abis_rsl.c:1954 (bts=1,trx=0,ts=3,ss=0) IPAC_CRCX_ACK ...
<000c> gsm_04_08.c:1400 no RTP socket for new_lchan
<001a> rtp_proxy.c:533 rtp_socket_create(): success
<001a> rtp_proxy.c:615 rtp_socket_bind(rs=0x48703c8, IP=0.0.0.0): ...
In case of handover (but probably on RACH) we would send a RLL for
SAPI=0 even if this SAPI was never established. After we have released
all SAPI>0 locally check that SAPI=0 is established and if not release
the rf channel directly.
Merge the channel release re-work. The most notable change is that
SAPI > 0 will now be released on the local end and that the release
process should be both more fast and more standard conform. With SMS
spamming/mass sending the nanoBTS is crashing but this does not appear
to originate from any of these changes. I used git rebase to go through
each of the change to see where the nanoBTS is crashing but couldn't
reproduce it. It might be a general overload or something generated by
the modems of the sysmocom modem bank. Merge it before the 29C3 so we
can test this code some more.
T3109 is started when the SACCH is deactivated. It is stopped when
the phones sends the DISC/UA/UM on LAPDm for the main signalling
link. In case of timeout the abnormal release procedure will be
initiated. Make sure to not issue the SACCH Deactivate twice to
avoid confusing the equipment.
This is still not fully spec compliant. In case of a timeout the
abnormal release handling will be started which involves starting
T3111+2. The error handling should be split out of the rf channel
release method, e.g. lchan_release should be called and check if
the channel release was already initiated.
If the CHAN ACTIV is NACKED we set the state backto NONE. This is
problematic as our channel allocator will allocate from the front
or from the back and if the channel is early in the list it might
cause permanent failures. Introduce a BROKEN state and use it when
the channel activation is failing for an unknown reason. Copy the
cause so it can be inspected later.
Deactivate the SACCH and release all SAPIs locally as of GSM 04.08. Add
documentation to the code and explain what will happen as part of the
release process.
* Release all channels with SAPI > 0 with the "local end release"
(as of NOTE 1 of GSM 04.08).
* No need to wait for all SAPIs to be torn down and the normal
REL_IND/REL_CONF will call rsl_handle_release and the channel
should be released.
* Update the documentation
Put the idiom that sets the lchan state to none and respecting the
error state into a shared method. This way the special handling for
the abnormal case is just in one place.
Avoid printing error messages when paging while the BTS is down. In
case a BTS is going down it is best to just let the timers expire
normally. We can not expire them right away as multiple BTS could be
paged and we do not want to interfere with that. There is no need to
stop the queue right now.
If subscriber A is calling B and has sent a CC Setup message we will
allocate the MO and MT transaction and link them together. When the
BTS or the lchan is failing the BSC API will send a clear request,
as part of the clear request all pending transactions will be released.
As part of taking down the transaction, the remote leg will be informed
and will send a MNCC_REL_REQ. This results in a call to trans_free. The
llist_for_each_entry_safe does not handle removing other elements from
the list and we would segfault.
One way to fix this is to move the transaction list into the subscriber
connection. This might require to create the subscriber connection for
MT handling earlier. Otherwise one could have one transaction list inside
the subscriber connection and a global list for MT- transactions.
--disable-smpp would actually not disable SMPP but enable it. Correct
it for all usages of AC_ARG_ENABLE.
Move the unconditional invocation of PKG_CHECK_MODULES before the
conditional one to make it work as the pkg-config m4 macro appears
to expand the first usage differently and searches for the pkg-config
exuable.
Use "$enableval" to see if the feature should be enabled or disabled
and then search for the module afterwards.
This has been reported and analyzed by Tobias Engel. The IMSI Detach
is dispatched as part of the complete layer3 message. I had patched
the code to release the anchor and call msc_release_connection to
release the connection as fast as possible (otherwise the anchor would
trigger in a couple of seconds).
With commit 70ae5d3000 I made this more
generic to release the connection immediately if there are no operations,
no transaction and no silent call. This leads to the subscriber connection
being released twice and eventually causing a segfault. Remove the
msc_release_connection invocation from the IMSI Detach code as the connection
will be taken down by the BSC API.
This has been tested using the FakeBTS and an IMSI Detach message. The
channel is released immediately and the nitb does not crash.
GCC 3.x on PowerPC correctly highlights that the code is fishy.
Re-reading the RFC 3550 shows that we should subtract it and then
we are in the 16bit range. The probation and re-sync code is still
missing.
GCC:
mgcp/mgcp_network.c:200: warning: comparison is always true due to limited range of data type
MGCP is used over UDP and a response might be lost. The MGCP RFC
asks for keeping a list of responses and then using the previous
response to answer a duplicate request. I tried to conserve memory
and just wanted to remember the last transaction identifier and
result-code and re-generate the result from that. This made the
code look bad and this is why the entire response will now be stored.
It sadly increases the memory usage but can not be avoided at this
time.
Remove the msg->l3h pointer for the RQNT callback as strtok has
modified the content of it.
MT-SMS:
Manual test with VTY to phone. Also multiple SMS deliveries on
the same lchan. Manual test with phone to phone.
MO-SMS:
Manual test with phone to phone but only a single SMS at a time,
not testing the special 'CP-ACK' case.
Forced CP timeout using the fakebts SMSTest, not causing a crash.
Rebased, tested and fixed by Holger Freyther. Release the transaction
only once the SMC is asking for the release and set the cb's to NULL
to catch a use after free early.
This has been rebased and fixed by Holger Freyther. The change of
the debug area was split out in a previous commit and the is_mt was
put back into the transaction code.
The transaction is now freed from the RELEASE_REQ sent by the SMC
layer and not inside the error path. When clearing the SMC instance
we also clear the callbacks.
This should and does happen as part of the trans_free/msc_release_connection
code. There is no easy way to determine that the lchan is now 'free' for other
things.. Let the transaction code sort this out. This code just needs to make
sure that transactions are always freed.
This is more a work around and one still needs to implement a
proper dispatch on the opening of the connection. If there is no
operation left, no transaction and no silent call, close down the
channel.
Use the code that is shipped inside the libosmogsm library. Right now
the signature (besides the static) and the implementation is the same.
This makes using the libosmogsm SMC code more easy in the near future.
For the gsm340_gen_oa we are now using a small wrapper to generate the
proper type and numbering plan.
For some reason, libsmpp34 is too smart to zero out the entire structure
to which it is unpacking. This introduces an ugly wrapper macro to
work around. This needs discussion with the libsmpp34 maintainer.
Move to the control command handling out of the main file into
a dedicated module. There are still some calls embedded into the
main code but it will be moved soon.
Use a usec timestamp for the local time. The seconds to usec will
swap over to the lower bits but this appears to be correct. The
CLOCK_MONOTONIC is used to fulfill the RFC 3550 requirement even
if it is a bit slower than the gettimeofday.
Make sure to initialize transit in a way that the first transit
time will be 0. Otherwise the jitter will contain the difference
of the localtime and the remote time.
Calculate the expected packages and packet loss as of RFC 3550.
The values should be clamped but our packet loss counter is 32
bits and not 24 and we should clamp at other values but I am
waiting for some issues first before dealing with that.
This is missing the probation and the dealing with a remote
restart. For the remote restart we will simply write a log
statement as this is unlikely to happen during a call or if
it does happen the call will be taken down by the BSC anyway.
Align the naming inside the mgcp_rtp_state with the naming inside
the 'source' struct of the appendix. Make first_seq_no/base_seq
a uint16_t. This is removing rules for alignments and reduces the
struct from 40 bytes to 36.
Count the received octets. This is encouraged by the MGCP specification.
Use a 32bit counter that is good enough for more than 12 hours of a EFR
call. This limit is good enough for the current configuration.
The RFC 3435 specifies a different formula for calculating the lost
packages. It involves the number of received packages and the delta
of the sequence number.
The previous code didn't work as expected. The trx and dst pointer
are located in an union and in the case of the Abis code the dst
is used to point to the signalling link timeslot and not the TRX.
The is_ipaccess_bts always returned false because the dst was casted
to a trx while it was no trx.
This fix was tested with the nack_test/NACKTest.st of the test repo.
The test cases were failing on 64bit systems because the sizeof
code operated on the pointer size which is 8 and longer than the
size that was intended to be used for comparing it.
the dh_autoreconf application did not honor the sourcedirectory
option back then. Override the target and call autoreconf from
the right directory.
The libdbi development package is called libdbi0-dev. Use this name
for Debian stable but it should work for Ubuntu as well.
It is a bad idea to detach a subscriber. The subscriber will not
be reachable until the next periodic updating cycle. In case we have
too many failed deliveries we will need to reduce the period for the
LU and implement a subscriber purging task.
This is a preparation for the 29C3 and a problem Jolly experience with
his type writer system.
I saw the old copy of the "Appendix J" code too late and I have
discovered some quirks and I am more familar with my implementation.
Most noticable 'w' only needs to be as big as the input arfcn but
requires the 'w' to be initialized. The power_of_2 implementation
differs as well (mine matches the output of wirehsark).
The f0 could be chosen in a better way but right now picking
the lower bound is the easiest. It is not clear if to use
modulo if the range is chosen in the middle. This can be improved
in the future. Right now I have no bit fiddling for range128, 256
and 1024 as I was running out of time.
alpha=0 (the new value) doesn't reduce MS transmission power during GPRS
as much as we did with alpha=10. This is to optimize for coverage and
to keep GPRS working at all cost, and not care about MS battery life
time or uplink interference in surrounding cells.
FIXME: This should be made configurable via the VTY and the normal
default (unless configured otherwise by vty/config file) should be '6'.
In order to keep mobile at PACCH as long as possible the timer T3192 is
set to 1500ms. This reduces the probablity of long lasting assignment
process on CCCH for subsequent downlink TBFs.
Inspect the message and see if it is a paging response,
then try to find the MSC that has paged this subscriber
and select this as the target MSC, also move the MSC to
the back of the list for 'load balancing'.
The lines 461 and 303 were producing unaligned memory access as
the BVCI was not aligned properly. Introduce a tlvp_val16_unal to
read 16bit from the data, use memcpy to the stack to make sure
that it is working in the aligned and unaligned case.
The commands net.<netid>.bsc.<bscid>.* are now forwarded to the
appropriate osmo-bsc. <netid> for now is just 0. <bscid> is not the LAC
anymore (since that could be ambiguous), but instead the number as
configured in bsc-nat.cfg
The first fields are still the location up to the height.
The next field is "operational" if any of the trx are operational,
otherwise "inoperational"
The second to last field contains "locked" if all of the trx are in the
admin state, otherwise "unlocked".
The last field represents the rf policy currently in effect. It is one
of (on|off|grace|unknown).
<tstamp>,<valid>,<lat>,<lon>,<height>,<oper>,<admin>,<policy>
The ip.access nanoBTS has issues if the admin changes are called
too often in too little time. This will lead to a situation where
the site manager will fail to start properly. Remove the TRX code
as the RF Control class does not support setting this per TRX.
nat: Catch up with controlif_setup API change
We now save a control handle reference in the nat
osmo-bsc: Catch up with controlif_setup API change
We now save a control handle reference in the gsm network
bts_hsl_femtocell.c: In function ‘hsl_sign_link_up’:
bts_hsl_femtocell.c:206:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘uint64_t’ [-Wformat]
bts_hsl_femtocell.c:210:2: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘uint64_t’ [-Wformat]
When adding the "omit RTCP" the method started to return with
a proper return statement.
mgcp_network.c: In function ‘send_to’:
mgcp_network.c:233:1: warning: control reaches end of non-void function [-Wreturn-type]
abis_nm.c: In function ‘abis_nm_get_attr’:
abis_nm.c:1380:11: warning: unused variable ‘cur’ [-Wunused-variable]
abis_nm.c: In function ‘ipac_parse_bcch_info’:
abis_nm.c:2588:11: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]
bts_nokia_site.c:1310:6: warning: variable ‘constructed’ set but not used [-Wunused-but-set-variable]
bts_nokia_site.c: At top level:
bts_nokia_site.c:1364:12: warning: ‘dump_elements’ defined but not used [-Wunused-function]
gsm_04_08.c: In function ‘mm_rx_loc_upd_req’:
gsm_04_08.c:521:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
osmo_msc.c: In function ‘msc_ciph_m_compl’:
osmo_msc.c:122:7: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
bts_hsl_femtocell.c: In function ‘hslfemto_bootstrap_om’:
bts_hsl_femtocell.c:101:11: warning: variable ‘cur’ set but not used [-Wunused-but-set-variable]
bts_hsl_femtocell.c: In function ‘hsl_drop_oml’:
bts_hsl_femtocell.c:232:21: warning: variable ‘line’ set but not used [-Wunused-but-set-variable]
handover_logic.c: In function ‘ho_chan_activ_ack’:
handover_logic.c:197:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
gcc does not really know the _NR_OF_ELEMENTS_IN_ENUM approach, add
the _NUM_GSM_BTS_TYPE to the handled cases.
gsm_data.c: In function ‘gsm_set_bts_type’:
gsm_data.c:349:2: warning: enumeration value ‘_NUM_GSM_BTS_TYPE’ not handled in switch [-Wswitch]
We now have a lchan->csd_mode member that determines if RSL should
activate the channel in CSD transparent services or not. The previous
code always assumed CSD is non-transparent.
(This requires libosmocore >= eed26116c96f03c6128fac3dead9054714af6cab)
Some nodes below 'config' didn't have ournode_exit / ournode_end,
and thus were not able to properly perform this function. exit should
always only go back one level, while end drops us back to ENABLE_NODE.
The prompt now represents the nesting level, and there's one consistent
space after the final prompt character (typically #).
This effectively limits the number of BTSs to 256, but I think that's
acceptable for now. Unfortuantely there's no decent way to dynamically
update the valid number range depending on how many BTSs are actually
configured in the system :/
Use the Smalltalk SIP implementation to create a call
and once the call has been established start the replay
using the commoncode. No patching of RTP occurs yet.
Update/Move/Create example configuration files for NiTB, BSC,
MGCP, NAT and the GbProxy. Create a script that starts, generates
the vty reference and terminates the application.
While generally we should log troly unknown RR messages, we can simply
pass along RRLP messages (which aren't unknown!)
In real networks, the RRLP would probably not end up at the MSC, but
well, sometimes we don't care what real/classic networks do.
A crash was obsserved in cb_data_ind() when mm is dereferenced.
This patch adds some safeguards that try to prevent the library handle
back-pointer to the pdp_ctx to be NULL, and print a stack backtrace in
case we are free() ing the sgsn-side pdp_ctx while there's still a
library handle attached.
The Nokia E71 sends a "IMSI Detach" this msc code does not immediately
send the "RR Channel Release", the E71 is impatient and sends a DISC,
the "RELEASE INDICATION" is handled by starting the channel release
procedure. OpenBSC sends a "RR Channel Release" which will never be
answered, during the early release there is no timer and the lchan will
be in "RELEASE REQUESTED" forever.
This commit removes the anchor operation and checks if the channel can
be released immediately. Regarding the channel release handling there
is already a branch that needs to be tested.
We are currently not checking if the BTS actually suports that cipher,
and we particularly don't have any hack for ip.access which apparently
seems to re-use the RSL algorithm identifier for A5/2.
so far, osmo-bts/sysmobts used to be entered as "sysmobts" type in the
configuration file. However, there are some differences in the
protocol/behaviour and we should reflect that by a new BTS plugin (with
lots of code reuse from the nanobts driver).
like in libosmogsm, we separate between header files that are just
reflecting information in the respective specs, and header files that
related to our specific implementation.
Instead of direct function calls to individual functions, we now
generate primitives (osmo_prim) and send them to one
application-provided function "bssgp_prim_cb()"
The ip.access nanoBTS appears to send quite broken NTP timestamps in
the RTCP messages might confuse equipment that uses the sender report
of the BTS. Make it easy to experiment by adding an option to drop RTCP.
In case the connection should not be created/accepted release
the channel by sending a RR Release and de-activating the
SACCH. Phones should deal better with that behavior.
In case the call handling starts on a TCH/H switch to a TCH/F
if fullrate is requested. Add a method that is used to determine
if the mode and current channel are compatible with each other.
control_if.c:521:2: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
osmo_bsc_bssap.c:473:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘unsigned int’ [-Wformat]
mgcp_main.c:162:4: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘unsigned int’ [-Wformatt]
We want to have multiple MSCs but we also have some data
that is only present on a per BSC basis. Right now the
MSC data is not allocated with talloc, so we have some
change in the talloc contexts.
osmo_bsc_main.c: In function ‘main’:
osmo_bsc_main.c:398:2: warning: implicit declaration of function ‘bts_init’ [-Wimplicit-function-declaration]
osmo_bsc_main.c:399:2: warning: implicit declaration of function ‘libosmo_abis_init’ [-Wimplicit-function-declaration]
osmo_bsc_main.c:418:2: warning: implicit declaration of function ‘bsc_bootstrap_network’ [-Wimplicit-function-declaration]
osmo_bsc_api.c: In function ‘bsc_cm_update’:
osmo_bsc_api.c:195:2: warning: ‘return’ with a value, in function returning void [enabled by default]
osmo_bsc_api.c:193:28: warning: unused variable ‘sccp’ [-Wunused-variable]
Instead of building complex manual byte-wise parsers, we simply use two
strtok_r loops: one iterating over all the lines, the next one
iterating over the invididual space-separated elements in the first line.
The benefit is that we now accept \r, \n or \r\n, or any multiple of
them as line ending. This works around incompliant MGCP implementations
like that of Zynetix MSC.
Addition: mgcp_analyze_header returns 0 when all out parameters have
been set.
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
In addition to SI 2 and SI 5, the SI 2ter and 2bis is generated, if
neighbour cells in other bands exist. Also it is indicated in the rest
octets of SI3, that SI 2ter is used. If no neighbour cell in a different
band exists, the SI 2ter and SI 5ter is omitted.
A special case is P-GSM range (channels 1-124). To be compatible with
older phones, SI 2bis and SI 5bis is used. If the BCCH lays inside the
P-GSM band, only neighbour cells of the P-GSM range are included in
SI 2 and SI 5. If neighbour cells exist in the same band (900), but lay
outside the P-GSM range, the SI 2bis and SI 5bis is used to extend the
list of neighbour cells. The extension is also indicated in SI 2 and
SI 5. If the BCCH lays inside the P-GSM range, but no neighbour cell
exists in the same band outside the P-GSM range, the SI 2bis ans SI 5bis
are omitted.
strstr() was used with wrong argument order, causing it to always match,
and causing an invalid response to a variety of different SS and USSD
requests.
This has apparently caused havoc among a number of HTC phones which
issue SS requests without user interaction upon boot, and then trip over
our inappropriate response.
This must have been obsoleted by the move to libosmo-abis.
GCC warning:
bts_ipaccess_nanobts.c: In function ‘ipaccess_drop_oml’:
bts_ipaccess_nanobts.c:509:21: warning: variable ‘line’ set but not used [-Wunused-but-set-variable]
The old BSC code had code to override the payload type, this has
been removed, remove the variable accessing it.
GCC warning:
abis_rsl.c: In function ‘ipa_rtp_pt_for_lchan’:
abis_rsl.c:1590:22: warning: unused variable ‘net’ [-Wunused-variable]
Introduce a SS_CCCH for the paging and the rach load. The paging
code could now start using the signal.
GCC warning:
abis_rsl.c: In function ‘rsl_rx_ccch_load’:
abis_rsl.c:1371:11: warning: variable ‘rach_access_count’ set but not used [-Wunused-but-set-variable]
abis_rsl.c:1370:11: warning: variable ‘rach_busy_count’ set but not used [-Wunused-but-set-variable]
abis_rsl.c:1369:11: warning: variable ‘rach_slot_count’ set but not used [-Wunused-but-set-variable]
attribute get|set <0-255> (.HEX) was never implemented and the
output about the unused attributes clutter the build output, remove
them.
GCC warning:
abis_nm_vty.c: In function ‘oml_attrib_get’:
abis_nm_vty.c:141:25: warning: unused variable ‘oms’ [-Wunused-variable]
abis_nm_vty.c: In function ‘oml_attrib_set’:
abis_nm_vty.c:152:25: warning: unused variable ‘oms’ [-Wunused-variable]
Use LOGP(DNM, LOGL_ERROR, ...); for errors in the
abis_nm_rx_sw_act_req method.
GCC warning:
abis_nm.c: In function ‘abis_nm_rx_sw_act_req’:
abis_nm.c:412:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
Assume nothing special needs to be done for the Nokia
*site hardware.
GCC warning:
gsm_data.c: In function ‘gsm_set_bts_type’:
gsm_data.c:342:2: warning: enumeration value ‘GSM_BTS_TYPE_NOKIA_SITE’ not handled in switch [-Wswitch]
I'm sure I read somewhere that it actually was 0..1024, as I kept
wondering how stupid it was to use 10bit+1. However, that source
was incorrect, as GSM TS 05.05 quite clearly states 0..1023
When we get an assignment command from the MSC, we no longer have to
check statically for certain codecs, as we have a vty-configured list of
codecs that is checked just below.
This allows the use of the existing "call-agent ip A.B.C.D" command in
libmgcp in order to set a default destination address of the call agent.
This is required as a pre-condition for certain call agents (like the
zynetix MSC) that require a RSIP from the BSC to the MSC as the initial
MGCP message.
RR Messages like STATUS, GPRS SUSPEND, HANDOVER COMPLETE/FAIL, ...
should be processed on the BSC side of things, not on the MSC side.
This is among other things required in preparation of intra-BSC
hand-over support in osmo-bsc.
Introduce number rewriting of SMS-SUBMIT. Introduce a new list,
move code around to help with finding a new number, somehow the
number encoding for TP-DA is borked, 03.40 references 04.11 but
the length appears to be strlen(number) without taken the type
field into account.
In case of a reset (loss of the BTS) close down all remaining
RTP Proxy sockets. In case of a lchan_free shout if the rtp
proxy is still open. I would prefer if the proxy code sits inside
the gsm subscriber connection.
gsm_data_shared.h includes e1_input.h of libosmo-abis, add the
LIBOSMOABIS_CFLAGS to Makefile.am, remove AM_LDFLAGS at the same
time as we only build .a archives.
Increase the version number and send the sizeof of the gsm_mncc
and the gsm_data_frame structure. Include the offsets of some
members as well to maybe identify ABI problems.
The reason we go through this is that we want to benefit from
the native ABI and don't want to force packed structs.
In case of a memory allocation failure in rsl_rx_chan_rqd we would
have left the channel in the LCHAN_S_ACT_REQ state. Move the state
change below the allocation.
In case a BTS does not send the RF Channel Release ACK and we are
closing the channel because of an error two timers are running to
set the state back to none.
Make lchan_deact_tmr_cb and rsl_rx_rf_chan_rel_ack behave the same
in regard to changing the state of the lchan. For the other direction
we are save, the error path will set the state to NONE and the timeout
will call lchan_free to set the channel type back to NONE, only then
the lchan may be allocated again.
The channel release procedure requires some more tweaking, some part
was started in the zecke/28c3 branch and needs to be tested/integrated
with the goal of having one common release path.
In case of a failed channel we still want the channel to not be
re-allocated right away but keep it closed/unused for (T3109 + T311).
rsl_rx_rf_chan_rel_ack has a check to not set the channel to S_NONE in
case the channel is in the error state. Add the camp Harald added a timer
to set the channel back to the none state in case the RF Channel Release
is not acked.
This reverts commit fc462dd59e.
show lchan should be capable of showing all allocated lchans,
all of a given bts, a given trx, a given ts. This feature was
broken when I added the ability to show a more simple summary.
Restore the initial behavior by splitting out the for loops
for the bts/trx/ts and check if we have parsed all parameters
and then call and return the subroutine.
Match IMSI and destination address against a set of entries, if it
is matching the header will be modified and no sender report will be
requested. Change the test case to request the sender report and then
verify that this bit is reset to 0.
GSM 04.64 8.4.2 asks to ignore UI frames if the DLCI is not known,
or if the "(V(UR)- 32) <= N(U) < V(UR)". E.g. if we want to have
V(UR) == 511 and this frame is dropped, we would ignore N(U)'s
0 to 510. Calculate the delta.
The code is based on Jonathan Santos's "LLC UI window" fix but the
issue was discovered independly.
The osmo-nitb application sometimes crashes because the BSC API
is doing an assignment underneath which is not handled by the code,
add dumy handlers to not crash, the right thing to do is to change
MNCC to have an assignment that can succeed/fail.
The keyword to look for is MNCC_LCHAN_MODIFY and mncc_sock should
wait for an ack/nack but right now the call just continues.
The UTC offset from the operating system will be used by default to
calculate the NITZ in MM INFO. However, a "timezone" vty command is
added at the BTS level, allowing BTS-specific overrides, e.g. in case
BTSs are distributed accross multiple timezones.
The BSS-side of BSSGP requires quite a number of additional functions
for sending unidirectional messages that a SGSN never sends.
This is a first step into completing the BSSGP implementation and making
it ready to be used from osmo-bts and other BTS-side GPRS
implementations.
Send a hello packet down to the client with the version number
of the MNCC interface. The hello structure might be extended to
include the endianes, size of each structure, etc.
In this iteration I just want to make sure that each VTY command has
online help. Replace "a b" with "a-b" if there is no "a c" with b!=c.
This config should gain some more sanity and consistency, this will
happen in another iteration.
Also make sure to specify seconds in the 'seconds' field. Doing
otherwise is an abuse that non longer works with the new timer infra.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
do_reset was not initialized anywhere anymore, so the reset was never
triggered. It's now fixed and we add an option to skip it in the
config so that when in production, you can restart without config
changes quickly.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
In case a MS (of which we have no MM context) sends us anything but a
GMM ATTACH REQUEST, we need to send it a LLC XID RESET (by means of
issuing LLGMM-RESET.req). Otherwise the phone will expect us to send a
specific unacknowledged sequence number that we don't know.
Thanks to Holger for pointing this bug out to me.
It seems to commonly occur when a MS is doing network re-selection and
(erroneously) sends a RA UPD REQ instead of an ATTACH REQ. The RA UPD
REJ that we sent was never seen by the GMM entity in the MS, as the LLC
entity discarded it due to sequence number mis-match.
Using LLGMM-RESET.req, the GMM can request the LLC of the MS to reset
all its parameters, particularly the sequence numbers. We don't yet do
XID RESET retransmissions, and we don't yet generate a LLGMM-RESET.conf
primitive back to GMM.
Ubuntu 11.10 has changed some linker/compiler flags. Some fixes for this
can be seen here[1]. In general the to be linked libs need to be moved into
the LDADD section of parameters. This is with the old BFD linker (not gold).
This is likely to end in some ping-pong with other versions of the linker.
[1] https://bugs.launchpad.net/ubuntu/+source/nis/+bug/771034
Errors:
/usr/bin/ld.bfd.real: bsc_hack.o: undefined reference to symbol 'osmo_init_ignore_signals'
/usr/bin/ld.bfd.real: note: 'osmo_init_ignore_signals' is defined in DSO /home/ich/install/openbsc/lib/libosmocore.so so try adding it to the linker command line
/home/ich/install/openbsc/lib/libosmocore.so: could not read symbols: Invalid operation
...
../../src/libbsc/libbsc.a(rest_octets.o):/home/ich/source/gsm/openbsc/openbsc/src/libbsc/rest_octets.c:381: more undefined references to `bitvec_set_bit' follow
../../src/libbsc/libbsc.a(rest_octets.o): In function `rest_octets_si13':
/home/ich/source/gsm/openbsc/openbsc/src/libbsc/rest_octets.c:382: undefined reference to `bitvec_set_uint'
/home/ich/source/gsm/openbsc/openbsc/src/libbsc/rest_octets.c:383: undefined reference to `bitvec_set_uint'
/home/ich/source/gsm/openbsc/openbsc/src/libbsc/rest_octets.c:385: undefined reference to `bitvec_set_bit'
/home/ich/source/gsm/openbsc/openbsc/src/libbsc/rest_octets.c:402: undefined reference to `bitvec_set_bit'
/home/ich/source/gsm/openbsc/openbsc/src/libbsc/rest_octets.c:403: undefined reference to `bitvec_set_uint'
gprs_gmm.c:240:2: warning: passing argument 4 of ‘gprs_llc_tx_ui’ discards qualifiers from pointer target type
../../include/openbsc/gprs_llc.h:151:5: note: expected ‘void *’ but argument is of type ‘const struct sgsn_mm_ctx *’
gprs_gmm.c:349:11: warning: unused variable ‘ptsig’
gprs_gmm.c:601:5: warning: too many arguments for format
gprs_gmm.c:987:25: warning: initialization discards qualifiers from pointer target type
gprs_gmm.c:1010:6: warning: ‘rc’ may be used uninitialized in this function
When the BTS reboots it might not want to accept our BTS Attr,
do not leave the bsc_msc_ip/bsc_nitb but simply drop the BTS
connection.
Manually cherry-picked from: 54e6c8b3400b376ed36fe84f28f7930d2d9ff24b
The libosmo-abis merge broke Ericsson RBS support, as it didn't get the
part right where the per-TRX OML sign_link is determined while
transmitting OM2000 messages.
As a result of this fix, we can remove the 'to_trx_oml' parameter to
_abis_nm_sendmsg(), which is a nice cleanup.
In order to have the MNCC application reliably decide on the codec type,
it needs to know if we are running on a TCH/F or TCH/H. Thus, we pass
lchan_mode as a new parameter to the 'struct gsm_mncc'
When gsm48_send_rr_ass_cmd() is being called to send the ASSIGNMENT
COMMAND, we need to use the propwer lchan->ms_power setting, not
some fixed magic "0x3" number.
Without this patch, every MS would transmit at a very high output power
fullowing an assignment command - more than what was set in the config
file with "ms max power"
In case of a nack the secondary_lchan will be NULLed but then the T10
timeout will attempt to release the channel and we will try to release
a NULL pointer.
Daniel witnessed this crash at the camp and added the NULL check at:
28d9ccbca0, it is also the proper fix
given the _NAK handling.
When we got a clear request we did not clear the internal
association between the gsm_subscriber_connection and the SCCP
part. When we got a DTAP message before the CLEAR COMMAND we
will end up in a crash as the ->bts pointer of the connection
has been cleared.
#0 bsc_scan_msc_msg (conn=0xde178, msg=<value optimized out>) at osmo_bsc_filter.c:258
#1 0x000112c8 in bsc_handle_dt1 (conn=0xdebd8, msg=0xd1f58, len=<value optimized out>) at osmo_bsc_bssap.c:507
#2 0x00010208 in msc_outgoing_sccp_data (conn=<value optimized out>, msg=0xdfacc, len=858696) at osmo_bsc_sccp.c:73
#3 0x0003c110 in sccp_system_incoming (msgb=0xd1f58) at sccp.c:1064
Remove the separation of half-rate and full-rate AMR. The used rate
can be found inside the AMR payload. The signalling of what kind of
traffic channel is used can be done with the GSM 08.08 Chosen
Channel IE in the Assignment Complete message.
This way I can use a fixed payload type in the MGCP GateWay but
have a mixed TCH/F and TCH/H config. E.g. use TCH/F FR3 for some
subscribers when connected to MSC A but use AMR5.9 on a TCH/F for
MSC B when all TCH/Hs are gone.
When the CRCX 200 is lost on the way to the CallAgent we will
get another CRCX (retransmission) which was answered with a 400.
Change the code to extract the CallID, Mode and the optional
LocalOptions first. Then check if the endp is allocated with the
same call identifier, in that case return the current session
information.
The SDP file for FreeSWITCH should contain o= (Origin) and the
t= (Timing) for the session. The data of the Origin should be
globally unique but this is not the case yet. We will need to
store the (NTP) time of the creation of the endpoint.
Move the regexp parsing code from the NAT to libcommon as it will
be used by the NAT and BSC code. This also adds the #include <regex.h>
include to gsm_data. This header should be split up.
This is a big patch that ports openBSC over libosmo-abis.
Sorry, the changes that are included here are all dependent
of libosmo-abis, splitting them into smaller pieces would
leave the repository in some intermediate state, which is
not desired.
The main changes are:
- The directory libabis/ has been removed as it now lives in
libosmo-abis.
- new configuration file format for nanoBTS and HSL femto, we
need to define the virtual e1_line and attach it to the OML
link.
- all the existing BTS drivers (nanoBTS, hsl femto, Nokia site,
BS11 and rbs2000) now use the new libosmo-abis framework.
- use r232 input driver available in libosmo-abis for bs11_config.
- use ipa_msg_recv instead of old ipaccess_read_msg function.
- delete definition of gsm_e1_subslot and input_signal_data.
These structures now lives in libosmo-abis.
Most of this patch are deletions of libabis/ which has been
moved to libosmo-abis.
This patch also modifies openBSC to use all the new definitions
available in libosmocore and libosmo-abis. In order to do that,
we have replaced the following:
- DINP, DMI, DMIB and DMUX by their respective DL* correspondences.
- SS_GLOBAL by SS_L_GLOBAL
- SS_INPUT by SS_L_INPUT
- S_GLOBAL_SHUTDOWN by S_L_GLOBAL_SHUTDOWN
- SS_INPUT by SS_L_INPUT
- S_INP_* by S_L_INP_* sub-signals
- E1INP_NODE by L_E1INP_NODE vty node
This patch has been tested with:
- one nanoBTS
- the HSL femto with the examples available under libosmo-abis
- BS11 with both dahdi and misdn drivers.
This patch modifies openBSC code to use msg->dst which stores the
pointer to the signalling link structure instead of the pointer to
the transceiver structure.
This patch prepares the introduction of libosmo-abis.
It is possible that MNCC sends a MNCC_LCHAN_MODIFY and
wants a channel mode that is not possible on the current
lchan, in that case a new channel is assigned. We now crash
as the osmo-nitb is not having an assignment complete handler,
add a NULL check.
The Nokia metrosite BTS seem to keep the channels open indefinitely.
If osmo-nitb is restarted while one of the channel was still active
and tries to activate that channel again the bts would return a
CHANNEL ACTIVATE NACK with "Radio channel already activated". This
accumulated over the restarts so soon enough no more channels were
available.
This patch sends a release request to the bts so the channel
becomes available again.
The function lchan_alloc only considers lchans to be available if both
the type and state are NONE. So change show lchan to list all lchans
that are not considered available.
This will cause the remote end to read 0 bytes, which is interpreted as
if we cleanly closed the socket, making the remote end close their side
of the socket, which would lead to us closing our side of the socket,
so we should never send such a packet.
The timer callback will simply reset the lchan state to NONE in order
to prevent channels getting stuck in 'activation requested' or
'deactivation requested' states.
During the GSM deployment in the CCC Camp, Daniel Willmann
noticed that the LCR and the MNCC were closing the local
connection over unix sockets communication quite so often.
After some debugging, Peter Stuge noticed that openBSC was
closing the connection since write was returning 0.
Then, I suggested that it could be a malformed message with
zero length. By skipping empty messages, Peter confirmed that
the connection between the LCR and the MNCC was not closing
anymore. However, there was no voice in the calls that went
over MNCC.
After some more debugging I found that we were not building
GSM_TCHF_FRAME over MNCC appropriately in the TRAU multiplexer
code, since we forgot to msgb_put() the message.
Scenario: BTS are configured and working, then the BSC stops working
for some reason (crash or administrative stop).
If the BSC comes back to life, LAPD among other things does not know
about the previous existing TEIs. Instead of ignoring these frames,
we notify the driver that we are seeing frames with unknown TEIs, so
it can try to recover, e.g. by resending the SABM message.
Running the entire bts_nokia_site.c through the 'Lindent' script
to match indent/coding style with remainder of project.
There are still lots of other cleanups pending, but this one is
a purely cosmetic one.
DAHDI creates one device node for every E1 timeslot, starting from '1',
and keeps incrementing that number even for additional ports/cards.
Thus, we have to use the e1inp_line number multiplied by 31 as a base.
The byte ordering is a bit odd: The least significant byte is ahead of
the most significant byte, different from everything else in GSM that
seems to be big-endian.
Thanks to Seungju Kim <admin@manateeshome.com> for repoerting the bug.
This fixes a bug introduced more than one year ago in commit
e38bd6caa3:
The RSL_IE_CHAN_IDENT is a TLV, but the GSM48_IE_CHANDESC_2 contained in
it, is a mere TV type IE with fixed length.
The problem specifically has caused problems on Nokia MetroSite BTS,
which apparently read the TSC out of this Layer3 IE.
The MS Radio Access Capability IE can be _very_ long in some recent
high-end mobile phones, way beyond the old 14-byte limit. We increase
our array to 52 bytes, and make sure not to overflow that buffer.
It was possible to set the LAC=0 on a subscriber that just has
done a LU because it did not respond to a paging request.
E.g. when a phone is rebooting, a SMS being delivered, the phone
is doing the LU, sub_ready_for_sm will try to send a SMS (but the
phone is not ready yet and it will timeout), then the paging code will
send us an expiration note and we might set the LAC=0 for this
subscriber.
Ideally we would be able to stop the paging request once the subscriber
is authenticated and then hand this to the SMS layer, right now the
best thing to do is to detect that we will run into this problem and
not send the SMS, not try to set the LAC=0.
When the BSC is refusing to open an outgoing connection the SCCP
connection was leaked. Use the normal free as the socket should
be either closed or disconnected.
Reset the BTS MO State on BTS bootstrap. This way we will always
test the BTS disconnect/reconnect case of the BTS.
Do not reset the administrative state of objects. The BSC might
have set these and wants to maintain them across disconnect/
reconnect. Right now this is true for the TRX state.
We want to compare the file more_magic[0] and more_magic[1]
with the static more_magic array to see where the difference
is.
src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 2
src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 3
* net.location to get/set the geographical location of the network
format is <tstamp>,<lat>,<lon>,<height>
* per trx rf_locked command (net.bts0.trx0.rf_locked)
* network-wide rf_locked command (net.rf_locked)
These commands are installed in controlif_setup. Query them like this:
"rate_ctr.<interval>.<counter group>.<index>.<counter name>" for rate
counters and "counter.<counter name>" for regular counters. <interval>
may be either "abs" for absolute values or one or
"per_{sec,min,hour,day}".
It is possible to query all rate counters in a group (regardless of
index) or all counters in a group and with a certain index if you omit
<counter name> and <index> or just <counter name>.
due to a missing return statement, we ran into the 'reject' case
of bssmap_handle_cipher_mode(). Due to another bug in libosmocore,
the reject message was corrupted (fixed in libosmocore commit
0c83670a595a278b7d1fb7b21b2eacab84d3c031)
GCC 4.6.0 and LD.BFD 2.21 on ARM somehow fail to resolve
the dbi symbols when we have the library in front of the
static libraries, move them to the back.
Without this patch the tlv_def_patch symbol and the
gsm48_construct_ra.
GCC 4.6.0 and LD.BFD 2.21 on ARM somehow fail to resolve
the dbi symbols when we have the library in front of the
static libraries, move them to the back.
The idea that MCC and MNC is enough to classify a subscriber
turns out to be wrong. Certain operatos license a number range
of IMSIs to others. When we see a '^' in the MCC field we treat
it as a regexp. The code now turns the MCC/MNC into a regexp
for the IMSI. It is not using extended POSIX regexp to match
the behavior of the access list.
Separate the code to patch the code and the code to find a
new number based on the old number. This will allow to add
multiple targets for number changing.
Fix make distcheck to uninstall files that were installed
by our custom hook.
This is fixing:
ERROR: files left after uninstall:
./share/doc/openbsc/examples/osmo-bsc_mgcp/mgcp.cfg
./share/doc/openbsc/examples/osmo-nitb/nanobts/openbsc.cfg
./share/doc/openbsc/examples/osmo-nitb/nanobts/openbsc-multitrx.cfg
./share/doc/openbsc/examples/osmo-nitb/bs11/openbsc-1bts-2trx.cfg
./share/doc/openbsc/examples/osmo-nitb/bs11/openbsc.cfg
./share/doc/openbsc/examples/osmo-nitb/bs11/openbsc-1bts-2trx-hopping.cfg
./share/doc/openbsc/examples/osmo-nitb/bs11/openbsc-2bts-2trx.cfg
./share/doc/openbsc/examples/osmo-nitb/rbs2308/openbsc.cfg
This patch fixes a segfault that occured when a ipaccess RSL link gets
closed unexpectedly.
The segfault can be provoked by connecting to the RSL port with ncat and
hitting ^C.
autoconf >=2.68 demands the body of an AC_COMPILE_IFELSE to be wrapped in
an AC_LANG_SOURCE macro, otherwise outputs annoying warnings on the
invocation of `autoreconf -i`. this patch follows that demand.
This should not introduce any functional changes, it just re-arranges
some definitions in the header file, and introduces the ROLE_BSC
define that we enable for the BSC-specific fields.
The daemons set up nanoBTS and HSL femto sockets by default, ie. the
three sockets to support these two drivers are open even if we have
no BTS of that kind.
This patch enables on-demand socket creation, ie. we only enable them
if we have one BTS at least that requires it.
I added two new attributes to the gsm_bts object, they are:
* the start() function includes the code that we need to run to start
the BTS. This new function contains the socket creation in the
particular case of nanoBTS and HSL femto.
* the started boolean, which is used to know if we have already
started the BTS, ie. we have already invoked start().
Note that, I have splitted the bts_model_*_init() function into two
functions, the _init() functions that register the BTS driver
and the _start() functions that start BTS driver on-demand.
While I was at it, I added several changes/cleanups to this patch:
* Group all bts_model_*_init() calls into one function bts_init(),
which is called in the initialization path of osmo-nitb and
osmo-bsc.
* Add openbsc/bss.h that contains the declaration of
bsc_bootstrap_network, bsc_shutdown_net and bts_init.
* Add missing e1inp_init() in osmo-bsc.
* Fix missing declaration of hsl_setup in openbsc/e1_input.h
The error message was missing in case of problems bootstrapping the BTS.
The E1 input driver initialization was displayed in the standard output,
now this error is reported via logs.
With this patch, we don't include e1_input if it's empty
[...]
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
e1_input <----------------- empty, it should not show up.
msc
[...]
Pablo pointed out that my previous commit was rubish. If we have
less than two arguments we want ifname to remain NULL and if we
have a second argument (or more) we want to use that as the interface
name to bind to.
Use the libosmocore code to ignore certain signals by
default (e.g. SIGHUP, SIGPIPE) and use the new code to
create a default stderr logging target and initialize
it properly.
This can be used to throw the data into GNUplot. It collects
the time (from the start of the trace), the buffer data in kbyte
and the number of buffered PDUs. It is assuming that no PDU
is delivered toward the target.
This patch adds several messages that would be displayed if:
* the Ki argument is missing.
* you pass an invalid Ki.
* the database fails to perform the operation (add/delete/update).
Before this patch, no messages were spotted on this errors.
I noticed this while adding Ki to the existing subscribers in the
nanoBTS setup: I introduced a wrong Ki but the VTY command line did
not report any error. A quick look at the database via sqlite
command confirmed that the new authkey information was not added.
Introduce a paging group that a BSC can refer to and is used
during the LAC lookup. This way paging can be flooded through
the network and just filtered at the last element in the core.
The current code tries to find _one_ bsc for a paging message
and then continues. The new code will try to find multiple BSCs
for each LAC. This is done in preparation of having two BSCs
handle the same LAC. This code right now is O(m*n) but it will
be worse once paging groups are landed.
The code to test the function was reduced to just test the lac
lookup code as the other part can not be tested in a standalone
setup anymore.
The code to create the struct gsm_bts is in libcommon right now
and we can not call paging_init from there. Right now it appears
to be the easiest of doing the init internally.
Be able to configure a list of destinations (duplicates allowed)
that will be tried in a round robin fashion. The change is in
the bsc_msc_connection to operate on a list. We achieve the
round robin nature with the same trick used in the paging code
to delete and append the current entry. The nat code was updated
to compile but one can only configure one destination.
For restarting the NAT we can now block it, it will not accept
new connections and for existing connections it will attempt
to drop them over time. A blocked NAT will end up with no BSC
connections left and then can be safely restarted.
In case this is a local USSD connection we will ignore
the clear command and respond with a RLC to any RLSD but
will never forward that to the BSC. This way the external
USSD is fully in charge of the connection.
There are theoretical issues if there are multiple transactions
on the same SCCP Connection but this can not be solved properly
right now.
Keep track of the used transaction identifier and always forward
messages to the USSD provider. E.g. this can be used to have a
dialogue going. Right now it is still possible that the MSC will
close down the connection.
We need to and out the protocol discriminator as call control
might have use transactions. This has only failed for the USSD
filter so far as this must deal with transactions.
With this patch, ipaccess-proxy makes more robust option checking:
$ ./ipaccess-proxy -l 1.1.1.1 -b 2.2.2.2 -e
ERROR: missing mandatory argument for `-e' option
And we return to shell to enforce the user to try again with the
appropriate invocation.
Before this patch, the default getopt_long() error handling was
enabled which displayed this message:
./ipaccess-proxy: option requires an argument -- 'e'
and ipaccess-proxy continued working.
This is generic enough to cover other option that require mandatory
arguments like `--bsc' and `--listen'.
Now ipaccess_idtag_parse() returns -EINVAL instead of -1. We also
check for the return value of this function in every invocation to
skip further processing in case of messages with malformed TLVs.
This idea was suggested by Zecke.
When we have no other MNCC connection but the registeration of the
new fd is failing we should not disable reading from the listen_fd
for ever as the situation might not be permanent.
This patch removes the C99 structure initialization which is not allowed
by the wireshark project (since it has to compile with non-C99 compliant
compilers).
It also adds a new option to enable/disable the dissection of vendor
specific ip.access nanoBTS RSL messages.
Tested with file:
ipaccess-startup-mo_to_mo_call-proxy.pcap
* include/openbsc/ipaccess.h: Reserve a protocol number for control
commands
* input/ipaccess.c: New function ipaccess_prepend_header_ext prepends
the extension header
This patch finishes the new ipaccess_send_*() functions and use them
in the ipaccess-proxy code.
I have also cleanup the definition of the PONG, ID_ACK and ID_REQ
messages (including some minor documentation about them).
I had to rename ipaccess_recvmsg() in ipaccess-proxy to avoid clashing
with the one defined in libabis.
For the USSD module we only want to handle requests that are
legitimate. This is achieved by looking for the CM Service Accept
or the BSSAP CIPHER MODE COMMAND.
This patch extends the make_sock() prototype so you can fully set
the fields priv_nr and data of the bsc_fd structure.
This is the first step to get rid of the internal make_sock()
implementation that ipaccess-proxy uses.
This patch includes a minor cleanup to pass INADDR_ANY instead
of zero, if you do not want to bind the socket to one specific
address.
The VTY code calls the write function for nodes in the order of
registration of the node and not in terms of hierachy of nodes. This
means that the e1_input code is written before the MSC node that
was the child of the network. Make the MSC_NODE a direct descendant
of the CONFIG_NODE and avoid this issue.
In 136f453dd2, I forgot to update
the new header path in the test/bsc-nat files (this happened to
me because I forgot to configured openBSC without --enable-nat).
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
This patch fixes:
CC gb_proxy_main.o
gb_proxy_main.c: In function ‘main’:
gb_proxy_main.c:224: warning: implicit declaration of function ‘logging_vty_add_cmds’
And a similar problem in osmo-bsc_nat.
This was introduced in by myself in patch:
"bsc: change bsc_vty_init to take logging categories as parameter"
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
This change is required to finish the integration of the VTY and
the per-application logging categories that provides:
"vty: integration with logging framework"
in libosmocore.
It has been tested with osmo-nitb. The other just compiled tested.
This is the case of osmo-nitb, since it does not call
osmo_bsc_rf_create().
term1: $ ./osmo-nitb -c ../openbsc.cfg.nanobts
term2: $ telnet localhost 4242
term2: OpenBSC> show network
term1: Segmentation fault
This patch applies to the wireshark/0001-abis_oml.patch.
This patch converts the C99 structure initialization which is not
accepted by the wireshark developers (Harald told me that they need
it to compile with non-gcc compilers which don't always support C99).
I have tested it here with four pcap files that Harald passed to me.
... and in order to do this reasonably well, we have to get rid of
the pre-computed message length field in the OML header. Instead,
we now simply compute it at abis_om2k_sendmsg() time based on the
msgb_l2len().
It seems HSL has fixed most of their obvious issues in the SR1.0.1
release. However, this creates quite an incompatibility of the
protocol, and we have to adapt accordingly
The HSL Femtocell seems to be a poor man implementation of the
ip.access Abis/IP protocol, but cutting corners wherever possible.
We try to workaround those corners wherever possible...
The new structure divides the code into a number of libraries
for the BSC core functionality, MSC core functionality, Abis transport,
TRAU and other bits.
This doesn't introduce any functional code change but simply moves
around files and alters Makefile.am accordingly.
Next step would be to disentangle a lot of the inter-library
dependencies and make the individual bits of code more independent.
Introduce a VTY setting that right now needs to be set to
one. To make updating this setting possible we will now store
the number of endpoints in the bsc connection as well.
On a classic BSC we have 32 channels but one is reserved for
signalling. Make sure that we are not assigning 0x1f as we
assume that this is the signalling channel. This means that
from 32 possible voice channels we are only going to use 30
as we are already not using the 0x0.
Allocate the status for an endpoint dynamically. We will support
BSCs with different amount of multiplexes and need to have this
flexibility in the future. Add the proper null checks to the
current users of this code.
Rename the method as we send everything to the MSC and not just
SCCP. Put alink into the function name. Also use msg->data and
msg->len in hexdump as this is what we are sending to the server.
Recent libosmocore introdues a way how log targets can be configured from
the VTY.
This commit makes the 'log filter (imsi|nsvc|bvc)' compatible with it.
This introducecs the new VTY command "neighbor-list mode manual-si5"
in combination with "si5 neighbor-list (add|del) arfcn <0-1024>",
which allows you to (optionally) have neighbor channel lists that
differ in SI5 and in SI2.
So far, all BTS we have interfaced had one OML link per BTS, independent of the
number of TRX. In Ericsson RBS 2000, there is an OML link for the DXU/IXU,
and one additional OML link for each TRX/TRU.
The previous patch introduces new code for the RBS2000 but didn't
actually activate/call it yet.
After this patch, you can see LAPD being established and OM2000 messages
will fall into abis_nm.c (which of course has no clue about them).
bsc_init.c was a big mess even only for two supported BTS models,
so before adding more BTS types, this needs a cleanup.
All the BTS specific code from bsc_init.c has now moved into
bts_{siemens_bs11,ipaccess_nanobts}.c
This has required that input_event() and nm_state_event() get both
converted to proper libosmocore signals instead of referencing external
symbols.
When we copy a msgb, we need to make sure the msgb_cb->bssgp_cell_id
pointer points to data in the new message, not in the old message.
Thanks to Dieter Spaar for spotting this.
As we only have one NS-VC between gb_proxy and SGSN, we cannot
forward a NS-BLOCK from the BSS to the SGSN, as it would affect
all other BSS's, too.
Thus, we check if we have an unblocked PTP-BVC in the NSVC to the BSS,
and then issue a BVC-BLOCK towards the SGSN.
This should prevent any further PDU's from the SGSN to be sent to
this BSS.
We cannot afford static/global state, as we may have multiple E1
lines, each having its own LAPD instance. Furthermore, we might
even have multiple LAPD instances on the same E1 line (think of
a multi-drop setup).
This also implements dynamic TEI allocation, i.e. no hardcoded
TEI list anymore.
This introduces a new 'e1_input' config node with a command to be
used like:
e1_line 0 driver misdn
This allows us to have different input drivers in the future
When the remote subscriber has not responded yet we could
end up with a crash in the MNCC code. It was enough to dial
the number, then hang up and bsc_hack would end up with a
segfault due the list poisining of linux_list.
The paging response should always have a TMSI or IMSI
and we should be able to find the subscriber using that. If
no IMSI/TMSI is present and we would still accept the LU
we would access the uninitialized memory.
The compiler concludes that if (ts->type == type && ts->line && line
can be false as line is NULL and then we unconditionally access
it, make it happy by adding an extra NULL check.
now it correctly names some of the IEs like DSP/FPGA version,
and also automatically marks the UDP streams as RTP depending on
what it has seen in the RSL CONNECT TRAU message.
This parameter indicates how many of the PCH+AGCH blocks are reserved
for the AGCH and thus not used for the PCH. If we set it to 0,
we basically tell the BTS there is no AGCH - and thus it would be
impossible to send any IMMEDIATE ASSIGNMENTs.
Luckily the BS-11 and the nanoBTS don't seem to care.
So far, OpenBSC simply assumed that all BTS's configured in openbsc.cfg are
neighbors of each other. While this is true for small site installations,
it is definitely not true in most real world cases. We now have the
following new commands at the 'configure bts' level:
'neighbor-list mode (auto|manual)' for selecting the mode
'neighbor-list (add|del) arfcn <0-1024>'
for adding/deleting ARFCN in manual mode
Add a short README mentioning the svn version they apply
to, how to rebase them in the future, and what they do.
The renaming is done to add a hint on in which order to
apply them. The abis_oml patch has been updated to some
value_string changes in epan, all patches now add the new
files to the CMakeLists.txt of epan as well.
Instead of using more numbers from the proto range we will
use the 0xee and then have a mini header with our new proto
id in there. For a start rename the use types to _OLD.
The transaction layer was stopping paging requests that might or
might not have been owned by the transaction. This makes the subscr
code get stuck delivering requests. This code is mostly a band aid
and just makes sure that we will kick the queue if it is needed.
Remember if this channel got opened due a paging response and in
that case when we close it down we will call subscr_put_channel
that will try to page the subscriber again. This highlights the
lack of a good subscriber management in the MSC code.
If one paging request is timing out the others will timeout soon
as well. With the current code the next timeout would expire the
next request in the queue. We will now stop all paging requests
and then issue a next paging request. So for both paging success
and failure we will now stop all the other requests.
This is mostly a workaround, one should count on how many
BTSes we are paging and wait for all failures before we remove
the item from the queue.
Kick the queue in case the paging was timing out. No one is going
to call subscr_put_channel for us so we will do it on the subscriber.
There is also another problem with multiple BTS in the LAC and paging
timeout. We will need to remember how many BTSes we have paged.
If we have a RF failure between the paging response and the auth
success we will not inform the subscriber layer of the failed paging
and instead just 'drop' the SMS. In case we have not completed the
auth and close the channel we will now send an auth failure.
The conn might be released during the loop and then conn->bts
is a null pointer and we end up crashing. Store the gsm_network
in a local variable and access this one.
Improve the debugging possibilities and print the failed attempts
and the sms that was attempted to be delivered. this should help
with debugging the code.
The active channel might or might not be gone when the transaction
has been released. Instead of passing an invalid subscriber conn
we will pass the subscr that is ref-counted and guranteed to be
valid at this point. subscr_put_channel could search the connections
for an active connection if that is ever needed.
In contrast to the previous believe we may not have a conn here
as we are still paging for the sub. Instead of printing the BTS
print the lac where we think the subscriber is located.
Follow trans->conn->lchan to the BTS instead of using the BTS that
is guranteed to be NULL in the codepath we have entered here. The
trans->conn should still be there, and the lchan should be valid as
well as we have reordered the clear statements.
When the new_lchan for handover is failing we should stop the
handover operation. This is fixing a crash that we get a timeout
on the lchan and have no conn set to it. Introduce a flag to
the bsc_clear_handover to not free the lchan. In case the ho_lchan
is failing we do not want to call lchan_release as it would
reset the state.
The trau_mux likes to call cc_tx_to_mncc for each received
frame from the E1 link. Using a signal for each audio frame
is messy as well. The best thing I could think of is to put
this into the BSC to deref the pointer. The other option would
be to include the gsm_data.h in the mncc.h header and have
the method as inline.
Instead of creating the sockets in the RSL code we will do this
in the CRCX_ACK, MDCX_ACK, DLCX_IND signal handler of gsm_04_08.
Introduce a handover signal so we can repatch the RTP sockets in
the gsm_04_08 as well.
In case we get a RA UPD REQ on a new cell (both served by the same
SGSN), the LLC stack should not allocate a ne LLE/LLME, as the latter
would reset the V(u)sent / V(u)recv to zero and make the MS discard
our responses.
Instead, whenever the LLC stack sees a foreign TLLI, it should always
convert it to the local TLLI before doing any lookup for a LLE/LLME.
We create a loop by not setting trans->callref = 0 before calling
trans_free(), as the latter would again send a MNCC_REL_IND up
the stack.
Also: Fix memory leak in case we try to read from mncc_sock
but socket is just gone.
This adds mncc_sock_from_cc() as a handler function for CC messages
to be passed to the MNCC interface. If there is no MNCC socket
registered, we immediately release any CC related messages.
Together with flushing all established CC transaction at MNCC socket
close time, this ensures that all resources are released and no
new resources can be established until the MNCC applicaiton has
re-attached.
The MNCC messages now again get directly handled by the net->mncc_recv()
callback. If the callee wants to put them in a queue, it' his business
to do that.
Using this code we will soon be able to use LCR or other MNCC
applications via a unix domain socket.
The code is not actually used yet after this patch.
The reason for this is quite simple: We want to make sure anyone
running a customized version of OpenBSC to operate a network will
have to release all custom modifiations to the source code.
The SS_LCHAN signals now always include the lchan_sig_data. For
the measurement report it will optionally include the measurement
report as well. Attempt to update all handlers of this signal as well
Check the signal and only continue if it is any of the
signals we want to handle. In the case of measurement
reports we would cast some random code to a lchan.
The release might release the lchan we want to send the response
on. Reorder the code to first send the message and then give up
the security operation which might release the lchan.
According to the specs (GSM 04.08 Table 9.9), the only possibility
if neci=1 and this cause is used is "Originating call and TCH/F is
needed"
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
With the old code it was possible that we first saw SMS that
we have already in the queue. In that case we had free slots
available but have not filled them. With his new loop we try
harder to find SMS we can send, it attempts (and should work)
to detect a loop to break the loop before finding SMS to deliver.
Increase the number of SMS we will try to send at a time and
decrease the failures we handle before going to the next item. With
the default timeout we will attempt to page the subscriber for 60
seconds and we can increase the queue speed by going to the next
item faster.
The sms queue will attempt to send one SMS per subscriber
to fill all the available slots. It will handle the case
where paging has not started, timed out or if there was
any kind of other failure. It is also retransmitting SMS
in case of failures.
The SMSqueue will be responsible of sending to the user. It will
do so in a loop and will also try not to overload the BTS. This
means the throughput of SMS will be limited.
This is providing access to the paging result, the sms,
the transaction. This will allow the SMS queue to do
decisions based on the source of the failure.
The signal_data was inconsistent. Sometimes we passed the transaction
and sometimes we passed the sms. Change it to always pass the sms. The
S_SMS_SMMA is a bit special as it does not involve any SMS.
This is creating 1000 subscribers and 30 SMS each. The SMS
itself is badly formatted (not a valid 7bit encoding) but
it should be enough for a stress test.
If a signal handler accesses the database he will still see
the old lac. Make sure he is seeing the new one. Update the
subscriber from the database in case the query failed or other
things have changed.
Start counting the attempts of each paging request and call
the callback with the PAGING_BUSY type when the paging request
timed out but the subscriber was not paged at all. This can
only happen with a huge paging backlog.
In case the system has so many pending paging
Introduce a method that will remove all subscribers that have a
zero use count. This is useful if someone wants to purge subscribers
from memory or wants to disable the everything in RAM feature.
This is implemented by not freeing the subscriber when the
reference count becomes smaller than zero. We hope that this
will save many database accesses during the congres.
As we do not yet use the HLR from the SGSN, we allow all MS to
attach to our GPRS network. However, if this is running in a public
environment, it could cause service interruption to users of commercial
GPRS networks.
Thus, we now check if the first 5 digits of the IMSI match the MCC/MNC
of the cell that they want to register to. Thus, any subscribers with
SIM cards from real operators will no longer be accepted.
LOGL_ERROR will make this message shpw up in everey default log
config. However, as it seems, this is commonly observed in case
a MS still sends a MS STATUS (in respons to the MM INFO) at the
end of a location area update.
It might be best to actually change the channel release procedure
to make sure we can still pass such 'late' data to the MSC until
the time the Layer2 has been completely released.
If a MS changes RA, the RA will arrive in the new cell using the old
TLLI (masked as foreign TLLI). So we need to look-up the TLLI
in a special way, using the old RA as indicated in the 04.08 GMM
message.
There is still another bug remaining: As we somehow create a new LLC,
the sequence numbers of our responses start from 0 again, which is not
what the MS expects. This needs to be fixed in a follow-up patch.
In the GPRS NS protocol stack, the amount of NS/BSSGP headers like MS RADIO
CAPA INFO can be quite long. In order to fit the full user message and
those headers, we have to enlarge the head/tailroom of the msgb allocations.
On a nanoBTS, this command can be used to manually switch a given 'dynamic
pdch/tch' timeslot from one mode into the other.
There are no safeguards that the timeslot is not in use at the given time.
We send a LU Accept with the TMSI as the MI. According to the
spec the phone should store this new TMSI and send a TMSI
REALLOCATION COMPLETE to us. We will release the LU then and this
should trigger the release procedure.
This was introduced by a recent change to gsm_data.h to include
less header files. We really need to access the RSL information
here so it is fine to include the file.
In commit 39e2eadc99 a bug was introduced
that used the 'trans' after trans_free() had already been called.
This became visible now when the openbsc+lcr combination was calling
an unknown/invalid telephone number in a MO call, resulting in
a segfault.
Currently the nanoBTS bootstrap code requires a high delay
otherwise we are not bringing the device up properly. Changing
the init code turns out harder than it seems like. So this is
a workaround for that to allow a high speed RSL/OML connection
after the bringup.
The line driver can have a default TS delay. It is set to the
current default for the nanoBTS and the BS11. For the ipaccess
case we will set the delay lower for the RSL connection and
inside the ipaccess-config we can set it low right away to
have fast firmware flashing and such.
Instead of sending many messages we will queue the OML
messages and wait for the ACK/NACK before sending the
next message from the queue. We tag the msgb to remember
if we need to wait for an ack or not.
We keep the order of all messages, on ACKs and similiar
occassions we will drown the queue until we reach a message
that needs to be acked and then wait for that ack again.
Possible breakage can appear when we send an OML (e.g.
BS11 specific message) msg which does not need to be acked
through the abis_nm_sendmsg call. The fix will be to use
the _direct version of this method.
Re-Enable as it might have fixed something... who knows.
Conflicts:
openbsc/include/openbsc/abis_nm.h
openbsc/include/openbsc/gsm_data.h
openbsc/src/abis_nm.c
openbsc/src/gsm_data.c
Assume that a NACK is a onetime failure and that on the next
attempt it will work better. If that is not the case we might
even send a reboot to the BTS.
Sometimes the operative change for the NSE is getting nacked,
this might be due that we send it before we get the OPSTART ACK
for this object class. Send it from the CELL availability as
a workaround. This init code needs to be changed to make these
dependencies work more reliable.
Forget about the ho_lchan inside the gsm_subscriber_connection
in case of a handover failure, also clear the gsm_subscriber_connection
pointer before the lchan is passed to the lchan_free routine.
Do not use the NULL context for this allocation. It should hang
off the gsm_subscriber_connection but for now at least make it
the child of the BSC so it is showing up in the talloc report.
Can't declare it in gsm_04_08.h tough ... gsm_cbfn is defined in
gsm_data.h and trying to include that in gsm_04_08 just creates a
huge mess.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The default values are those where the parameters are encoded
as '0' and they're not output in the config file if that case
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When switching the RF off we will always go through the grace
period, add a direct off mode to switch it off directly. Make
the query return a 'g' if we are in the process of switching
things over.
Use the ipaccess_drop_oml and ipaccess_drop_rsl functions
instead of closing the socket and hoping this is picked up
somehow. This just leads to some weird hangs. And gdb was
not really helpful to say where it was coming from.
In the future we should avoid using a gsm_subscriber at all
and pass the imsi/tmsi to the paging function directly. For
now we can use the old model for paging and go through the
gsm_subscriber. This has the benefit of load balancing on
the BTS and such.
Sending this as the RTP_PAYLOAD2 will produce a MDCX NACK
as we send the RTP_PAYLOAD in the CRCX. It does not seem to
be necessary to send anything != 0 for the RTP_PAYLOAD2.
Refactor the closing code of the CC timeout to a new function,
also make sure that the SCCP Connection is forced closed before
we destruct the connection for real.
This will change the LAI of a LU accept message to the LAI
used for the on-air network. It will also detect when to
send a welcome ussd to the subscriber.
Set conn to NULL before starting the release procedure, remove
code to check for a lchan->conn as it can not happen. If there
are any memleaks we will notice them.
Detach the lchan->conn from the channel before detaching.
The timedout could come between lchan_release and the
S_CHALLOC_FREED signal. In the future we might want to
use the gsm0808_clear to stop the RLL timeouts and such.
For SAPI=3 on a TCH it might be nice to use the SACH to submit
the message. The api allows to automatically use the SACH if
a message like this is submitted.
The cipher mode reject will be send in case the BSC is not
able to support the requested cipher. So this reject can be
handled by however attempts to enable ciphering.
For certain messages we will need to call other GSM0808 functions. To
keep the bsc_hack working we will try to send this through the normal
messages first and then fallback to dtap if no handler is registered.
The gsm_04_08.c code is not forced to handle the IPA activation
and channel modify ack anymore. This is done transparently by the
BSC API now.
The implementation of bsc_hack would call subscr_con_free before
the BSC API has had the chance to call gsm0808_clear to try to
release other channels. Fix that by adding a return value.
This is used by the paging code of the osmo_bsc. When we get
a paging response there should be an active subscriber with
the TMSI or IMSI and we can stop paging. There is no need to
allocate a new subscriber.
In case of a inflexible network it is better to hardcode
the rtp payload to a given type. E.g. when using AMR5.9 on
a TCH/F and TCH/H having the same payload is helpful. For
now this will be only used by the osmo-bsc.
Use the offsetof/__builtin_offsetof to determine the
offset of a variable inside a structure instead of going
via a NULL pointer and taking the address.
This fixes:
warning: variably modified ‘dummyhalen_offset’ at file scope
Make sure that the MSC endpoint exists on the NAT, otherwise
we end up trying to free this endpoint when the SCCP connection
is taken down and will corrupt our memory. This issue started
to pop up as we have reduced the number of endpoints to 60
to allow transcoding on them.
Strip IPA protocol header correctly removing extension if present
Returns data length, IPA protocol, extension (or None if not defined for a give protocol) and the data without header
"""
ifnotlen(data):
returnNone,None,None,None
(dlen,proto)=struct.unpack('>HB',data[:3])
ifself.PROTO['OSMO']==protoorself.PROTO['CCM']==proto:# there's extension which we have to unpack
returnstruct.unpack('>HBB',data[:4])+(data[4:],)# length, protocol, extension, data
returndlen,proto,None,data[3:]# length, protocol, _, data
defsplit_combined(self,data):
"""
Split the data which contains multiple concatenated IPA messages into tuple (first, rest) where rest contains remaining messages, first is the single IPA message
echo -e "/*\n\n DO NOT EDIT THIS FILE!\n THIS IS OVERWRITTEN DURING BUILD\n This is an automatic copy of <osmocom/mgcp/mgcp_common.h>\n\n */" > mgcp_common.h
voidmgcp_client_conf_init(structmgcp_client_conf*conf)OSMO_DEPRECATED_OUTSIDE_LIBOSMOMGCPCLIENT("use mgcp_client_conf_alloc() (or even better, switch to the mgcp_client_pool API!)");
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
