This fixes the following dpkg-shlibdeps warning:
Change-Id: Iea00c209652e8070a59942504bef660db0999e86
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bsc-nat/usr/bin/osmo-bsc_nat was not linked against libosmoabis.so.6 (it uses none of the library's symbols)
This fixes the following dpkg-shlibdeps warning:
Change-Id: I31af5fb8b52ef1fd5effb139d9cdea1ebe9a41b4
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bsc/usr/bin/osmo-bsc_nat was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
We output a hexdump for each sccp message we receive, but not when
sending.
Also log the hexdump of sccp messages when sending.
Change-Id: Ibfe52a0b7dbca4c569c603a008d73d0d99d1c345
We already log the message type of sccp messages we receive, but
for transmitting the log output is missing.
Also log the message type for tramsitted sccp messages.
Change-Id: I6736f15ddc03e5f70c3504abffbae6cbf766c9d7
A FSM doesn't need "FSM" in its name, as it is obvious that it is a
FSM. Also, having two that are called RESET is confusing, so let's
try to come up with better names.
Also, after Change-Id I9ef59432f43a3cdb94e4cbb0c44ac3f9b2aac0f2 in
libosmocore, we now enforce that no FSM identifiers contain spaces
or other illegal characters.
Change-Id: I1b44d26cebc4a47094d7b8b3983e5737b88bf003
The library code for rate counter initialization, which is called
from the descendants of bsc_network_alloc() might already want to
log something (particularly after Change-Id
Ifc6ac824f5dae9a848bb4a5d067c64a69eb40b56 in libosmocore), so the
logging framework must be initialized before.
Change-Id: I1e893c97e023e63489fe8c46539b5e507d3cec8f
unsigned long can be 32 bits on some arch/OS, while "current" field is
always 64 bit because it's a uint64_t.
Change-Id: Ibad1e4f09cf912cb654dbe3687a3f2182e2060f5
Related: OW#3893
Program terminated with signal SIGSEGV, Segmentation fault.
0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342
(gdb) bt
0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342
1 0x0805ab80 in lchan_release (lchan=0x0, sacch_deact=sacch_deact@entry=0, mode=mode@entry=RSL_REL_LOCAL_END)
at chan_alloc.c:410
2 0x0805c1dd in handle_ass_fail (msg=0x94142b8, conn=0x9251048) at bsc_api.c:459
3 dispatch_dtap (msg=0x94142b8, link_id=0 '\000', conn=0x9251048) at bsc_api.c:598
4 gsm0408_rcvmsg (msg=msg@entry=0x94142b8, link_id=0 '\000') at bsc_api.c:658
5 0x08058ca2 in abis_rsl_rx_rll (msg=0x94142b8) at abis_rsl.c:1686
6 abis_rsl_rcvmsg (msg=0x94142b8) at abis_rsl.c:2097
7 0xb7e8cf9a in handle_ts1_read (bfd=0x94e8e08) at input/ipaccess.c:271
8 ipaccess_fd_cb (bfd=0x94e8e08, what=1) at input/ipaccess.c:386
9 0xb7ee8434 in osmo_select_main (polling=polling@entry=0) at select.c:158
10 0x0804bd7c in main (argc=6, argv=0xbfc27144) at osmo_bsc_main.c:272
(gdb) print lchan
$2 = (const struct gsm_lchan *) 0x0
Possible scenario in which this crash can appear:
1- gsm0808_assign_req() calls handle_new_assignment() which sends an CHAN
ACTIVATE msg and arms T10 timer.
2- ACTIVATE ACK is received (handle_chan_ack), which calls
gsm48_send_rr_ass_cmd() which sends an ASSIGNMENT CMD, and doesn't
disable/modify T10 timer.
3- T10 timeout is triggered (assignment_t10_timeout()), which sets
conn->secondary_lchan = NULL
4- Immediately after, the ASSIGNMENT FAILURE message (which might have been
already queued) is processed in handle_ass_fail, and then the crash occurs.
This race condition is not an issue for handle_ass_compl() path because there's
this check there which would trigger most probably if secondary_lchan is NULL:
"if (conn->secondary_lchan != msg->lchan)"
Change-Id: I3798b36c628f75d4e8bc7b0996c27d695d53fbb1
Previously if we ran out of space while adding EARFCN, we simply return
which might result in malformed SI2q. Fix it by proper rollback of
entire EARFCN. While at it, let's be paranoid and introduce extra checks
against integer overflow in budget calculations.
Change-Id: I4b2aa3825e9affb6dfeadecdf24dd1a43a92b7b7
Related: OS#2357
Expose OML link uptime available via vts's "sh bts 0" command with the
new "bts.0.oml-uptime" ctrl command. To avoid code duplication, move
uptime computation into separate function and use it for both.
Change-Id: Iec405aa949d6a38a9c8e64cd7ee4b49fd416835d
Related: OS#2486
* fix insert routine to keep the list sorted by UARFCN
* fix rest octets generator to properly account for offset
* adjust test results accordingly
Change-Id: I443c5c5f937b490578354f3c8a0c5b92629f2794
Related: OS#2357
OML link state is available via vty ("sh bts 0" command) and
ctrl ("oml-connection-state" RO variable).
When showing OML link state, take into consideration RSL link state as
well: if OML is up but RSL is missing show it as degraded.
That's implemented via BTS model-specific functions (currently Sysmo- and
Nano- BTS only)
Change-Id: I5952fc59e4d82e0aa627ad91d20f964d9559a4c4
Related: OS#2486
* expand comments, fix typos
* constify parameter
* move try-add-adjust routine into separate function to facilitate
further modifications
* remove excessive checks and unnecessary return values
* move (UARFCN, Scrambling Code) tuple uniqueness check into separate
function and use it early
Change-Id: Ia72f848dec40723510ca56868e08081804227d47
Related: OS#2357
Currently, OSMO_ASSERT() is defined such that it ends in a semicolon, hence an
added ';' is redundant. However, the usual way this kind of macro should be
defined is
#define OSMO_ASSERT(x) do { ... } while(0)
so that the compiler requires a trailing semicolon.
To prepare for such a change possibly coming up in libosmocore, add ';' to all
OSMO_ASSERT() users.
Change-Id: If6dce81faee9177737a6e1b572a871aaf7e37138
In masurement reports sent by the MS, this can then be used to correlate
if a given measurement report was in response to a BCCH/neighbor list
received on BCCH (SI2xxx) or on dowlink SACCH (SI5xxx).
Closes: OS#2525
Change-Id: I1cd0dc51026dcd0e508e63eea4e333e6b184787a
Save the time when OML link to BTS was established and show it in
vty. That's useful when troubleshooting issues like periodic/sporadic
BTS restart.
Related: SYS#3889
Change-Id: I9e4e8504afe8ca467b68d41826f61654e24d9600
Previously we've used function so debug print always pointed to the same
place which is not very useful. Wrap it with macro so proper
file:line is printed. Also, make sure that we always change state only
through this wrapper and log only when the state has changed.
Change-Id: I21789f8021290965b61a54a2b23177ccbbfe8321
According to 3GPP TS 44.018 §1.8 the "network shall never enable PBCCH
and PCCCH".
Change-Id: I319e71a4b0c682361529e9c21377398a826b934b
Related: OS#2400
* log administrative state transitions
* log what's caused it
* while at it, mark boolean variable as such
Change-Id: I3e25a19fac4d0b4886d825c9876771b1f66efe58
Related: SYS#3864
These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-bsc.
Empty out contrib: remove things that are either obviously unrelated to
osmo-bsc, or seem old and/or esoteric.
osmoappdesc.py: drop nitb_e1_configs (and some ws)
Change-Id: Ib20064f35e623d99c7d59496a3156e84b8a0d07a
smpp_mirror is maintained in osmo-msc.git, so let's remove it
(and the associated libsmpp34 build requirement).
Change-Id: Ia7b242cc52cf261b1a5dd3c287da2868e1a2b9a8
This is the OsmoBSC project. Disabling the build of the BSC would be
somewhat odd, so let's remove the option.
Also, OsmoBSC depends on libosmo-sccp now, so we must unconditionally
depend on it. As a result, we can remove the --enable-nat option,
as this was only to avoid a mandatory libosmo-sccp requirement in
historical times.
Change-Id: Icfee8a904d33b7c13ab8d185d64fb5c2337d8640
Rewire build and includes to libosmo-legacy-mgcp.
Drop osmo-bsc_mgcp and related python tests, now found in osmo-mgw.git.
libosmo-legacy-mgcp is installed from osmo-mgw, hence add the dependency to
jenkins.sh (so far using the pre_release branch).
Change-Id: Ic99d681759edce11564da62500c2aac5cf5fffe2
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
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
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
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
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
Harald Welte
Philipp Maier
Pau Espin
Max
Neels Hofmeyr
Keith Whyte