Inspect the message and see if it is a paging response,
then try to find the MSC that has paged this subscriber
and select this as the target MSC, also move the MSC to
the back of the list for 'load balancing'.
The lines 461 and 303 were producing unaligned memory access as
the BVCI was not aligned properly. Introduce a tlvp_val16_unal to
read 16bit from the data, use memcpy to the stack to make sure
that it is working in the aligned and unaligned case.
The commands net.<netid>.bsc.<bscid>.* are now forwarded to the
appropriate osmo-bsc. <netid> for now is just 0. <bscid> is not the LAC
anymore (since that could be ambiguous), but instead the number as
configured in bsc-nat.cfg
The first fields are still the location up to the height.
The next field is "operational" if any of the trx are operational,
otherwise "inoperational"
The second to last field contains "locked" if all of the trx are in the
admin state, otherwise "unlocked".
The last field represents the rf policy currently in effect. It is one
of (on|off|grace|unknown).
<tstamp>,<valid>,<lat>,<lon>,<height>,<oper>,<admin>,<policy>
The ip.access nanoBTS has issues if the admin changes are called
too often in too little time. This will lead to a situation where
the site manager will fail to start properly. Remove the TRX code
as the RF Control class does not support setting this per TRX.
nat: Catch up with controlif_setup API change
We now save a control handle reference in the nat
osmo-bsc: Catch up with controlif_setup API change
We now save a control handle reference in the gsm network
bts_hsl_femtocell.c: In function ‘hsl_sign_link_up’:
bts_hsl_femtocell.c:206:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘uint64_t’ [-Wformat]
bts_hsl_femtocell.c:210:2: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘uint64_t’ [-Wformat]
When adding the "omit RTCP" the method started to return with
a proper return statement.
mgcp_network.c: In function ‘send_to’:
mgcp_network.c:233:1: warning: control reaches end of non-void function [-Wreturn-type]
abis_nm.c: In function ‘abis_nm_get_attr’:
abis_nm.c:1380:11: warning: unused variable ‘cur’ [-Wunused-variable]
abis_nm.c: In function ‘ipac_parse_bcch_info’:
abis_nm.c:2588:11: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]
bts_nokia_site.c:1310:6: warning: variable ‘constructed’ set but not used [-Wunused-but-set-variable]
bts_nokia_site.c: At top level:
bts_nokia_site.c:1364:12: warning: ‘dump_elements’ defined but not used [-Wunused-function]
gsm_04_08.c: In function ‘mm_rx_loc_upd_req’:
gsm_04_08.c:521:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
osmo_msc.c: In function ‘msc_ciph_m_compl’:
osmo_msc.c:122:7: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
bts_hsl_femtocell.c: In function ‘hslfemto_bootstrap_om’:
bts_hsl_femtocell.c:101:11: warning: variable ‘cur’ set but not used [-Wunused-but-set-variable]
bts_hsl_femtocell.c: In function ‘hsl_drop_oml’:
bts_hsl_femtocell.c:232:21: warning: variable ‘line’ set but not used [-Wunused-but-set-variable]
handover_logic.c: In function ‘ho_chan_activ_ack’:
handover_logic.c:197:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
gcc does not really know the _NR_OF_ELEMENTS_IN_ENUM approach, add
the _NUM_GSM_BTS_TYPE to the handled cases.
gsm_data.c: In function ‘gsm_set_bts_type’:
gsm_data.c:349:2: warning: enumeration value ‘_NUM_GSM_BTS_TYPE’ not handled in switch [-Wswitch]
We now have a lchan->csd_mode member that determines if RSL should
activate the channel in CSD transparent services or not. The previous
code always assumed CSD is non-transparent.
(This requires libosmocore >= eed26116c96f03c6128fac3dead9054714af6cab)
Some nodes below 'config' didn't have ournode_exit / ournode_end,
and thus were not able to properly perform this function. exit should
always only go back one level, while end drops us back to ENABLE_NODE.
The prompt now represents the nesting level, and there's one consistent
space after the final prompt character (typically #).
This effectively limits the number of BTSs to 256, but I think that's
acceptable for now. Unfortuantely there's no decent way to dynamically
update the valid number range depending on how many BTSs are actually
configured in the system :/
Use the Smalltalk SIP implementation to create a call
and once the call has been established start the replay
using the commoncode. No patching of RTP occurs yet.
Update/Move/Create example configuration files for NiTB, BSC,
MGCP, NAT and the GbProxy. Create a script that starts, generates
the vty reference and terminates the application.
While generally we should log troly unknown RR messages, we can simply
pass along RRLP messages (which aren't unknown!)
In real networks, the RRLP would probably not end up at the MSC, but
well, sometimes we don't care what real/classic networks do.
A crash was obsserved in cb_data_ind() when mm is dereferenced.
This patch adds some safeguards that try to prevent the library handle
back-pointer to the pdp_ctx to be NULL, and print a stack backtrace in
case we are free() ing the sgsn-side pdp_ctx while there's still a
library handle attached.
The Nokia E71 sends a "IMSI Detach" this msc code does not immediately
send the "RR Channel Release", the E71 is impatient and sends a DISC,
the "RELEASE INDICATION" is handled by starting the channel release
procedure. OpenBSC sends a "RR Channel Release" which will never be
answered, during the early release there is no timer and the lchan will
be in "RELEASE REQUESTED" forever.
This commit removes the anchor operation and checks if the channel can
be released immediately. Regarding the channel release handling there
is already a branch that needs to be tested.
We are currently not checking if the BTS actually suports that cipher,
and we particularly don't have any hack for ip.access which apparently
seems to re-use the RSL algorithm identifier for A5/2.
so far, osmo-bts/sysmobts used to be entered as "sysmobts" type in the
configuration file. However, there are some differences in the
protocol/behaviour and we should reflect that by a new BTS plugin (with
lots of code reuse from the nanobts driver).
like in libosmogsm, we separate between header files that are just
reflecting information in the respective specs, and header files that
related to our specific implementation.
Instead of direct function calls to individual functions, we now
generate primitives (osmo_prim) and send them to one
application-provided function "bssgp_prim_cb()"
Holger Hans Peter Freyther
Harald Welte