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.
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!)");
We want to avoid creating too many external build-time dependencies
like this one to autoconf-archive. This directory provides a local
copy of required m4 rules.
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.
