This is more a work around and one still needs to implement a
proper dispatch on the opening of the connection. If there is no
operation left, no transaction and no silent call, close down the
channel.
Use the code that is shipped inside the libosmogsm library. Right now
the signature (besides the static) and the implementation is the same.
This makes using the libosmogsm SMC code more easy in the near future.
For the gsm340_gen_oa we are now using a small wrapper to generate the
proper type and numbering plan.
For some reason, libsmpp34 is too smart to zero out the entire structure
to which it is unpacking. This introduces an ugly wrapper macro to
work around. This needs discussion with the libsmpp34 maintainer.
Move to the control command handling out of the main file into
a dedicated module. There are still some calls embedded into the
main code but it will be moved soon.
Use a usec timestamp for the local time. The seconds to usec will
swap over to the lower bits but this appears to be correct. The
CLOCK_MONOTONIC is used to fulfill the RFC 3550 requirement even
if it is a bit slower than the gettimeofday.
Make sure to initialize transit in a way that the first transit
time will be 0. Otherwise the jitter will contain the difference
of the localtime and the remote time.
Calculate the expected packages and packet loss as of RFC 3550.
The values should be clamped but our packet loss counter is 32
bits and not 24 and we should clamp at other values but I am
waiting for some issues first before dealing with that.
This is missing the probation and the dealing with a remote
restart. For the remote restart we will simply write a log
statement as this is unlikely to happen during a call or if
it does happen the call will be taken down by the BSC anyway.
Align the naming inside the mgcp_rtp_state with the naming inside
the 'source' struct of the appendix. Make first_seq_no/base_seq
a uint16_t. This is removing rules for alignments and reduces the
struct from 40 bytes to 36.
Count the received octets. This is encouraged by the MGCP specification.
Use a 32bit counter that is good enough for more than 12 hours of a EFR
call. This limit is good enough for the current configuration.
The RFC 3435 specifies a different formula for calculating the lost
packages. It involves the number of received packages and the delta
of the sequence number.
The previous code didn't work as expected. The trx and dst pointer
are located in an union and in the case of the Abis code the dst
is used to point to the signalling link timeslot and not the TRX.
The is_ipaccess_bts always returned false because the dst was casted
to a trx while it was no trx.
This fix was tested with the nack_test/NACKTest.st of the test repo.
The test cases were failing on 64bit systems because the sizeof
code operated on the pointer size which is 8 and longer than the
size that was intended to be used for comparing it.
It is a bad idea to detach a subscriber. The subscriber will not
be reachable until the next periodic updating cycle. In case we have
too many failed deliveries we will need to reduce the period for the
LU and implement a subscriber purging task.
This is a preparation for the 29C3 and a problem Jolly experience with
his type writer system.
I saw the old copy of the "Appendix J" code too late and I have
discovered some quirks and I am more familar with my implementation.
Most noticable 'w' only needs to be as big as the input arfcn but
requires the 'w' to be initialized. The power_of_2 implementation
differs as well (mine matches the output of wirehsark).
The f0 could be chosen in a better way but right now picking
the lower bound is the easiest. It is not clear if to use
modulo if the range is chosen in the middle. This can be improved
in the future. Right now I have no bit fiddling for range128, 256
and 1024 as I was running out of time.
alpha=0 (the new value) doesn't reduce MS transmission power during GPRS
as much as we did with alpha=10. This is to optimize for coverage and
to keep GPRS working at all cost, and not care about MS battery life
time or uplink interference in surrounding cells.
FIXME: This should be made configurable via the VTY and the normal
default (unless configured otherwise by vty/config file) should be '6'.
In order to keep mobile at PACCH as long as possible the timer T3192 is
set to 1500ms. This reduces the probablity of long lasting assignment
process on CCCH for subsequent downlink TBFs.
Inspect the message and see if it is a paging response,
then try to find the MSC that has paged this subscriber
and select this as the target MSC, also move the MSC to
the back of the list for 'load balancing'.
The lines 461 and 303 were producing unaligned memory access as
the BVCI was not aligned properly. Introduce a tlvp_val16_unal to
read 16bit from the data, use memcpy to the stack to make sure
that it is working in the aligned and unaligned case.
The commands net.<netid>.bsc.<bscid>.* are now forwarded to the
appropriate osmo-bsc. <netid> for now is just 0. <bscid> is not the LAC
anymore (since that could be ambiguous), but instead the number as
configured in bsc-nat.cfg
The first fields are still the location up to the height.
The next field is "operational" if any of the trx are operational,
otherwise "inoperational"
The second to last field contains "locked" if all of the trx are in the
admin state, otherwise "unlocked".
The last field represents the rf policy currently in effect. It is one
of (on|off|grace|unknown).
<tstamp>,<valid>,<lat>,<lon>,<height>,<oper>,<admin>,<policy>
The ip.access nanoBTS has issues if the admin changes are called
too often in too little time. This will lead to a situation where
the site manager will fail to start properly. Remove the TRX code
as the RF Control class does not support setting this per TRX.
nat: Catch up with controlif_setup API change
We now save a control handle reference in the nat
osmo-bsc: Catch up with controlif_setup API change
We now save a control handle reference in the gsm network
bts_hsl_femtocell.c: In function ‘hsl_sign_link_up’:
bts_hsl_femtocell.c:206:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘uint64_t’ [-Wformat]
bts_hsl_femtocell.c:210:2: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘uint64_t’ [-Wformat]
When adding the "omit RTCP" the method started to return with
a proper return statement.
mgcp_network.c: In function ‘send_to’:
mgcp_network.c:233:1: warning: control reaches end of non-void function [-Wreturn-type]
abis_nm.c: In function ‘abis_nm_get_attr’:
abis_nm.c:1380:11: warning: unused variable ‘cur’ [-Wunused-variable]
abis_nm.c: In function ‘ipac_parse_bcch_info’:
abis_nm.c:2588:11: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]
bts_nokia_site.c:1310:6: warning: variable ‘constructed’ set but not used [-Wunused-but-set-variable]
bts_nokia_site.c: At top level:
bts_nokia_site.c:1364:12: warning: ‘dump_elements’ defined but not used [-Wunused-function]
gsm_04_08.c: In function ‘mm_rx_loc_upd_req’:
gsm_04_08.c:521:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
osmo_msc.c: In function ‘msc_ciph_m_compl’:
osmo_msc.c:122:7: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
bts_hsl_femtocell.c: In function ‘hslfemto_bootstrap_om’:
bts_hsl_femtocell.c:101:11: warning: variable ‘cur’ set but not used [-Wunused-but-set-variable]
bts_hsl_femtocell.c: In function ‘hsl_drop_oml’:
bts_hsl_femtocell.c:232:21: warning: variable ‘line’ set but not used [-Wunused-but-set-variable]
handover_logic.c: In function ‘ho_chan_activ_ack’:
handover_logic.c:197:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
gcc does not really know the _NR_OF_ELEMENTS_IN_ENUM approach, add
the _NUM_GSM_BTS_TYPE to the handled cases.
gsm_data.c: In function ‘gsm_set_bts_type’:
gsm_data.c:349:2: warning: enumeration value ‘_NUM_GSM_BTS_TYPE’ not handled in switch [-Wswitch]
We now have a lchan->csd_mode member that determines if RSL should
activate the channel in CSD transparent services or not. The previous
code always assumed CSD is non-transparent.
(This requires libosmocore >= eed26116c96f03c6128fac3dead9054714af6cab)
Some nodes below 'config' didn't have ournode_exit / ournode_end,
and thus were not able to properly perform this function. exit should
always only go back one level, while end drops us back to ENABLE_NODE.
The prompt now represents the nesting level, and there's one consistent
space after the final prompt character (typically #).
This effectively limits the number of BTSs to 256, but I think that's
acceptable for now. Unfortuantely there's no decent way to dynamically
update the valid number range depending on how many BTSs are actually
configured in the system :/
Use the Smalltalk SIP implementation to create a call
and once the call has been established start the replay
using the commoncode. No patching of RTP occurs yet.
Update/Move/Create example configuration files for NiTB, BSC,
MGCP, NAT and the GbProxy. Create a script that starts, generates
the vty reference and terminates the application.
While generally we should log troly unknown RR messages, we can simply
pass along RRLP messages (which aren't unknown!)
In real networks, the RRLP would probably not end up at the MSC, but
well, sometimes we don't care what real/classic networks do.
A crash was obsserved in cb_data_ind() when mm is dereferenced.
This patch adds some safeguards that try to prevent the library handle
back-pointer to the pdp_ctx to be NULL, and print a stack backtrace in
case we are free() ing the sgsn-side pdp_ctx while there's still a
library handle attached.
The Nokia E71 sends a "IMSI Detach" this msc code does not immediately
send the "RR Channel Release", the E71 is impatient and sends a DISC,
the "RELEASE INDICATION" is handled by starting the channel release
procedure. OpenBSC sends a "RR Channel Release" which will never be
answered, during the early release there is no timer and the lchan will
be in "RELEASE REQUESTED" forever.
This commit removes the anchor operation and checks if the channel can
be released immediately. Regarding the channel release handling there
is already a branch that needs to be tested.
We are currently not checking if the BTS actually suports that cipher,
and we particularly don't have any hack for ip.access which apparently
seems to re-use the RSL algorithm identifier for A5/2.
so far, osmo-bts/sysmobts used to be entered as "sysmobts" type in the
configuration file. However, there are some differences in the
protocol/behaviour and we should reflect that by a new BTS plugin (with
lots of code reuse from the nanobts driver).
like in libosmogsm, we separate between header files that are just
reflecting information in the respective specs, and header files that
related to our specific implementation.
Instead of direct function calls to individual functions, we now
generate primitives (osmo_prim) and send them to one
application-provided function "bssgp_prim_cb()"
The ip.access nanoBTS appears to send quite broken NTP timestamps in
the RTCP messages might confuse equipment that uses the sender report
of the BTS. Make it easy to experiment by adding an option to drop RTCP.
In case the connection should not be created/accepted release
the channel by sending a RR Release and de-activating the
SACCH. Phones should deal better with that behavior.
In case the call handling starts on a TCH/H switch to a TCH/F
if fullrate is requested. Add a method that is used to determine
if the mode and current channel are compatible with each other.
control_if.c:521:2: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
osmo_bsc_bssap.c:473:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘unsigned int’ [-Wformat]
mgcp_main.c:162:4: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘unsigned int’ [-Wformatt]
We want to have multiple MSCs but we also have some data
that is only present on a per BSC basis. Right now the
MSC data is not allocated with talloc, so we have some
change in the talloc contexts.
osmo_bsc_main.c: In function ‘main’:
osmo_bsc_main.c:398:2: warning: implicit declaration of function ‘bts_init’ [-Wimplicit-function-declaration]
osmo_bsc_main.c:399:2: warning: implicit declaration of function ‘libosmo_abis_init’ [-Wimplicit-function-declaration]
osmo_bsc_main.c:418:2: warning: implicit declaration of function ‘bsc_bootstrap_network’ [-Wimplicit-function-declaration]
osmo_bsc_api.c: In function ‘bsc_cm_update’:
osmo_bsc_api.c:195:2: warning: ‘return’ with a value, in function returning void [enabled by default]
osmo_bsc_api.c:193:28: warning: unused variable ‘sccp’ [-Wunused-variable]
Instead of building complex manual byte-wise parsers, we simply use two
strtok_r loops: one iterating over all the lines, the next one
iterating over the invididual space-separated elements in the first line.
The benefit is that we now accept \r, \n or \r\n, or any multiple of
them as line ending. This works around incompliant MGCP implementations
like that of Zynetix MSC.
Addition: mgcp_analyze_header returns 0 when all out parameters have
been set.
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
In addition to SI 2 and SI 5, the SI 2ter and 2bis is generated, if
neighbour cells in other bands exist. Also it is indicated in the rest
octets of SI3, that SI 2ter is used. If no neighbour cell in a different
band exists, the SI 2ter and SI 5ter is omitted.
A special case is P-GSM range (channels 1-124). To be compatible with
older phones, SI 2bis and SI 5bis is used. If the BCCH lays inside the
P-GSM band, only neighbour cells of the P-GSM range are included in
SI 2 and SI 5. If neighbour cells exist in the same band (900), but lay
outside the P-GSM range, the SI 2bis and SI 5bis is used to extend the
list of neighbour cells. The extension is also indicated in SI 2 and
SI 5. If the BCCH lays inside the P-GSM range, but no neighbour cell
exists in the same band outside the P-GSM range, the SI 2bis ans SI 5bis
are omitted.
strstr() was used with wrong argument order, causing it to always match,
and causing an invalid response to a variety of different SS and USSD
requests.
This has apparently caused havoc among a number of HTC phones which
issue SS requests without user interaction upon boot, and then trip over
our inappropriate response.