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.
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.
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
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.
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);
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.
If QoS is only three bytes it does not include the allocation/
retention policy. Otherwise it does. Copy it depending on that.
We should have a macro for the clamping to reduce code duplication.
The insanity does come from the MAP data and this seems to be
the easiest in terms of complexity. It is an array of bytes that
is transported from MAPProxy to the SGSN and then simply forwarded.
The case of more than three bytes is neither unit nor manually
tested so far.
sgsn_create_pdp_ctx should use the subscribed QoS. When selecting
the PDP context we inject the QoS to be used into the TLV structure
and use it during the request. Assume a "qos-Subscribed" structure
only with three bytes and prepend the Allocation/Retention policy
to the request.
The MSISDN should be present for "security" reasons in the first
activation of a PDP context. Take the encoded MSISDN, store it for
future use and then put it into the PDP activation request.
The MM Context contains a field for a decoded MSISDN already. As
we need to forward the data to the GGSN I want to avoid having to
store TON and NPI in another place. Simply store the data in the
encoded form.
QoS is a mess. In MAP there is qos-Subscribed which is then extended
using ext-QoS-Subscribed, ext2-QoS-Subscribed, ext3-QoS-Subscribed
and maybe even ext4-QoS-Subscribed by now. The MAP ASN1 files defined
how these need to be "linearized". Instead of copying this I have
decided to include the two semantics with/without the Allocation/Retention
policy using the size of the data.
It is a bit arbitary to decide which one is the global
and which one is the local one. We might change it around.
I don't think we want to introduce it based on BTS.
For the BSC we will have the gsm48_hdr and don't need to
find data within SCCP. For legacy reasons we need to
initialize con_type, imsi, reject causes early on and
need to do the same in the filter method.
This means we need to require a talloc context and
simply operate on the list. I had considered creating
a structure to hold the list head but I didn't find
any other members so omitted it for now.
Move the filter methods to the filter module. This is
still only usable for the NAT and the _dt/_cr filter
routines need to move back to the bsc_nat in the long
run.
For customer requirements we want to be able to do
filtering on the BSC as well. The same messages need
to be scanned and the same access-lists will be looked
at. In the future we might even split traffic based
on the IMSI. Begin with moving the code to a new top
level directory and then renaming and removing the
nat dependency.
ENDPOINT_NUMBER takes the difference of two pointers. On 64bit
builds the difference is a long and the compiler then complains
about the usage of abs. We will never have thousands of endpoints
so silence the warning by casting the ENDPOINT_NUMBER to int.
mgcp_vty.c:1381:34: warning: absolute value function 'abs' given an argument of type 'long' but has parameter of
type 'int' which may cause truncation of value [-Wabsolute-value]
rtp_port = rtp_calculate_port(ENDPOINT_NUMBER(endp),
^
../../include/openbsc/mgcp_internal.h:206:31: note: expanded from macro 'ENDPOINT_NUMBER'
#define ENDPOINT_NUMBER(endp) abs(endp - endp->tcfg->endpoints)
^
mgcp_vty.c:1381:34: note: use function 'labs' instead
The idea of "subscriber_get_channel" was that different
requests would be coordinated. At the same time we have
seen that the "queue" can get stuck at both 31C3 and the
rhizomatica installations.
Voice calls and SMS do not need coordination. We should
be able to send SMS on a voice channel and switch the MS
from a SDCCH to a TCH in case we establish a voice call.
The SMS code itself needs to coordinate to obey the limit
of one SMS per direction but this should be enforced in
the sms layer and not on the subscriber.
Modify the code to have a simple paging coordination. The
subscriber code will schedule the paging and register who
would like to know about success/failure.
This allowed to greatly simplify the paging response
handling for the transaction code (and in fact we could
move the transaction list into the subscriber structure
now). The code gained to support to cancel the notification
of a request (but not the paging itself yet).
TODO: Cancel paging request in case no one cares about it
anymore.
In case the default TCH/F codec is "EFR" and we do an early
assignment from SDCCH to a TCH we would assign the TCH/H
codec. This is because the lchan_type will be neither a
TCH/H nor a TCH/F.
At the same time the _gsm48_lchan_modify code to check for
half vs. full-rate is the other way around. Align both.
It is full-rate if it is not a TCH_H. This will have some
other complications down the way (early assignment on
cells with only TCH/H). So the mode should not depend on
the _current_ channel but the kind of channel we want.
In test_rtp_seq_state an assignment is accidently done within an
assertion.
This commit changes that into a comparison as it was intended.
Fixes: Coverity CID 1295457, 1295458
Sponsored-by: On-Waves ehf
Currently the src_codec const variable is set to &src_end->codec
before src_end is checked against NULL. Since the assigment is just
an address operation and the memory where it points to is only
accessed after the NULL check, this does not harm technically.
Nevertheless this is potential source for errors if that code is
changed.
This commit moves the definition below the NULL check. This does not
comply with the coding style, but it cannot be split into definition
and a later assignment due to the const qualifier.
Sponsored-by: On-Waves ehf
We might have compiled transcoding into the MGW but
we don't want to enable it for a given user. Add a new
switch that should allow that.
I had manually tested the allow-transcoding/no allow
VTY interface for the primary interface and a new trunk
using show running-config.
It is unlikely that GSM, gsm and GsM refer to different codecs.
The mera mvts does send the audio codecs in lower case even if
RFC 3551 has them in upper case (but copy and paste is sometimes
too hard).
Currently the handling of the buffers is not done consistently. Some
code assumes that the whole buffer may be used to store the string
while at other places, the last buffer byte is left untouched in the
assumption that it contains a terminating NUL-character. The latter
is the correct behaviour.
This commit changes to code to not touch the last byte in the buffers
and to rely on the last byte being NUL. So the maximum IMSI/IMEI
length is GSM_IMSI_LENGTH-1/GSM_IMEI_LENGTH-1.
For information: We assume that we allocate the structure with
talloc_zero. This means we have NULed the entire imsi array and then
only write sizeof - 1 characters to it. So the last byte remains NUL.
Fixes: Coverity CID 1206568, 1206567
Sponsored-by: On-Waves ehf
Currently some VTY command do neither check the length of the source
string before calling strncpy nor ensure NUL-termination afterwards.
This can to destination string buffers whose contents are not
NUL-teminated.
This commit adds checks and corresponding warnings to the VTY
commands 'subscriber TYPE ID name .NAME" and "subscriber TYPE ID
extension EXTENSION".
Fixes: Coverity CID 1206570, 1206569
Sponsored-by: On-Waves ehf
When handling an incoming GSUP cancellation request, the cancel_type
if effectively ignored, such that is always handled as
GPRS_GSUP_CANCEL_TYPE_UPDATE and never as WITHDRAW.
This commit fixes the expression used to set the variable
is_update_procedure.
Fixes: Coverity CID 1267739
Sponsored-by: On-Waves ehf
Currently the inner loop in show_bsc_mgcp iterates of the timeslot
interval [0, 31]. Timeslot 0 is not valid, which causes
mgcp_timeslot_to_endpoint to generate a corresponding warning and to
return an invalid endp value. That value causes an out-of-bound
read access, possibly hitting unallocated memory.
This patch fixes the loop range by starting with timeslot 1.
Note that this does not prevent mgcp_timeslot_to_endpoint from
returning an invalid endpoint index when called with arguments not
within its domain.
Addresses:
<000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0
[...]
vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256
max = 1
con = 0xb4a004f0
i = 0
j = 0
[...]
==15700== ERROR: AddressSanitizer: heap-use-after-free on address
0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c
Sponsored-by: On-Waves ehf
I omitted the check as this was already done by the verify
function for this command. Please Coverity and do the check
again even if it is not necessary. I begin to doubt the
usage of a "dedicated" verify method as well.
Silences: Coverity CID 1293150
On DT messages we directly write into the tracked SCCP
connection. This means "imsi" will always be NULL at
this check. Change the code to use con->imsi
Fixes: Coverity CID 1293151
We want to have a program add entries to the allow list
this can be done using:
$ bsc_control.py -d localhost -p 4250 -s net.0.add.allow.access-list.NAME "^IMSI$"
bsc_stat_reject is treating -1 as parsing failure but for the
global barring. Change it to another return value so it is
not counted as parsing failure.
We had issues with odd behavior on the nanoBTS which lead
to the introduction of the "broken" state. On busy multi
BTS cells (e.g. rhizomatica) with wifi backhaul the timeout
we set to wait for a RF Channe Release ACK is sometimes too
little and channels are marked broken that look to be okay
(besides the still to be determined delay).
In case of a sysmoBTS we now know that we can change the
state of a broken channel back to normal in case we do
receive the right response.
Manually verified using the Smalltalk BTS code
PackageLoader fileInPackage: 'FakeBTS'
bts := FakeBTS.BTS new.
bts btsId: '1903/0/0'.
bts connect: 'localhost'.
bts waitForBTSReady.
test := FakeBTS.OpenBSCTest new.
test bts: bts.
test requireAnyChannel
... wait for NITB output
<0004> abis_rsl.c:223 (bts=0,trx=0,ts=0,ss=0) Timeout during deactivation! Marked as broken.
... process pending messages
stdin next
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=0,ss=0) CHAN REL ACK for broken channel. Releasing it.
So the channel went from broken to unallocated.
Change the paging strategy based on on if a LAC override
is in place or not. In case we had changed the LAC we need
to page on all the BTS. Change the "grace" handling to
iterate over the BTS and filter out all non matching ones
LAC in case no LAC handling is active.
Manually verified all four cases with a single BTS:
* No LAC handling and grace period
* LAC handling and grace period
* No LAC handling and not lock
* LAC handling and lock.
Related: SYS#1398
For MT we can't page per lac as we don't know which BTS was
the original one. Split the grace period and normal mode into
two methods so we can bloat both of them later.
We need to use different LAC/CI towards the core network.
It is a bit problematic as LAC/CI is a per BTS attribute
so this feature only works if a BSC manages everything in
the same LAC.
Related: SYS#1398
The write_queue is designed to have a maximum amount of pending
messages and will refuse to take new messages when it has been
reached. The caller can decide if it wants to flush the queue
and add the message again, create a log. But in all cases the
ownership of the msgb has not been transferred. Fix the potential
memory leak in the failure situation.
When reading from RTP socket, the first read() may fail right after
connecting to remote socket. Subsequent read() will work as it should.
If the remote socket does not open fast enough, the transmitted RTP
payload can cause an ICMP (connection refused) packet reply. This causes
the read to fail with errno=111. In all other error cases, the errno is
logged at debug level. In all error cases, reading is not disabled.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Fix typo, stop reading in all cases but ECONNREFUSED]
If a bad TRAU frame is received, it is forwarded to MNCC application
as GSM_BAD_FRAME. The application can now handle the GAP of missing
audio. (e.g. by extrapolation)
If TRAU frames are forwarded via RTP, bad frames are dropped, but frame
counter and timestamp of RTP sender state is incremented.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Merge without testcase, fix typo]
In case:
* No message_payload and a 0 sm_length was used
* esm_class indicates UDH being present
* 7bit encoding was requested
The code would execute:
ud_len = *sms_msg + 1;
Which is a NULL pointer dereference and would lead
to a crash of the NITB. Enforce the limits of the
sm_length parameter and reject the messae otherwise.
Fixes: Coverity CID 1042373
I used strdup in case the data would not be valid from after
the call to getopt and this creates a potential leak if a user
is specifying multiple configuration files. If I depend on the
fact that the string is a pointer into the argv[] array I can
kill the strdup and fix the unlikely leak.
Fixes: Coverity CID 1206578
Holger Hans Peter Freyther
Daniel Willmann
Neels Hofmeyr
Harald Welte