Currently every SAPI release indication will trigger the channel. It
was possible that we had SAPI=3 and SAPI=0 allocated and we tried to
release the channel by sending a RF Channel Release, the BTS answered
with a RF Channel Release ACK but also sent the SAPI Release Indication
which triggered a channel release here. So it was possible that we
would have released a newly allocated channel because of the SAPI
release of the old connection.
This code now works by releasing all SAPIs from highest to lowest,
then sending a SACH Deactivate and finally releasing the channel. This
approach is in use on the on-waves/bsc-master.
Also, we now re-start the network listen test after it has finished,
so if you run a test from ipaccess-find, the test will get re-started
and re-started all the time.
* We should create the transaction for SMS, CC on the CM Service Request
but for now we will use a band aid and create a dummy operarion to wait
five seconds for the transaction to be opened.
The transaction should not know on which lchan we are operating
as this can change due handover. Add untested code to share the
subscriber connection of the new and old lchan and move the pointer
in case of success/failure. Also on a clear command we will free
any resources allocated...
This code is not tested and needs to be debugged, but it should
have the right structure. I am going to fix a potential memleak
in the next commit.
A channel will be released in case of
* Errors via the clear_request callback...
* no more transactions and operations are going on.
This means that if we do something without a transaction
the channel might be closed down right away. The bug fix
will be to create a transaction/operation.
This is a big change to the way we use the subscriber
connection. From now on it is is dynamically allocated
and we will slowly move from a 1:1 lchan to conn to
having more than one lchan per connection.
This is the first commit, the subscr_con* methods will
move to gsm_data once the use_count is removed from the
connection, the freeing of the connection will also change.
The Channel Activate might be sent to a different TRX than the
Immediate Assignment. So we need to make sure that the channel
is activated before we send the immediate assignment for the RACH.
Another reason for that is according to GSM 08.58 we should take
the frame number from the activate and use it for the starting
time inside the immediate assignment message. We obviously do not
do this yet.
The code assumes that the BTS will either respond with a CHAN ACK
or a CHAN NACK if not the lchan will remain in the request state.
Also, make sure the bit ordering in the pre-computed MA is correct,
as well as the cell channel description of the target cell being
present in the HO CMD.
We now compute the Cell Channel Description for SI 1 by bit-wise
OR of the ARFCN bitmask of each timeslot on all the TRX of the BTS.
Also, support generating a GSM 04.08 Channel Description IE for
the hopping case (with HSN/MAIO instead of ARFCN).
What's still missing now: Sending the 04.08 Mobile Allocation IE
Allow to set the TOS field via the VTY interface. The
SO_PRIORITY was not used as it has no effect on the
packets being sent (in contrast to the documentation).
When submitting a DTAP message, the BSC API will attempt to
establish the RLL layer and then send the message or send an
SAPI n REJECT. This will be used by the SMS code.
This will take care of the auth/check/enable cipher sequence
and call a callback function when done.
Currently the negotiated Kc is saved but not re-used, so
there is an authentication each time ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When we issue a RF Channel Release in case of a failure we receive
RLL release indications after the channel was tearn down and we
issue another RF Channel Release as a result. The channel allocator
might have already allocated this channel and we release the channel
again with another MS on it.
Make rsl_rf_chan_release take an error argument and make it set
a new state in case of an error and change the RF Channel Release
ack to not set the state back to none in case of an error but wait
for a timeout that is a bit higher than T3111.
I tested this with removing the battery during a phonecall and
waiting for the channel failure. With this test we only send the
release once.
BSSGP stores a pointer to the Cell Identifier IE in msgb->cb, which
is later used by the GMM layer to identify the cell that has sent a
given message.
This now also means that the gsm_04_08_gprs.c code is free of any
legacy references to msg->trx or struct gsm_bts.
We now expect the highest level (actual SGSN GMM code) to know
all identifiers for every element in the protocol stack, i.e.
TLLI, SAPI, BVCI and NSEI. The layer-inetrnal state is looked
up based on those identifiers.
The reason for this is to ensure only the highest level state
needs to be persistent, while everything else can be regenerated
dynamically (e.g. in a SGSN restart)
In the old code
l3h = BSSGP, l4h = LLC, cb[gmmh] = 04.08
Now, this has been changed to
cb[bssgph] = BSSGP, cb[llch] = LLC, l3h = 04.08
This way, GSM general 04.08 and GPRS 04.08 code can expect a
GSM 04.08 header at msgb->l3h
According to TS 08.16, the BSSGP layer needs to specify NSEI and BVCI when
executing the NS UNITDATA REQUEST primitive of the underlying NS layer.
Rather than passing around a pointer to the 'struct gprs_nsvc', we now
have NSEI and BVCI as members of 'struct obsc_msgb_cb' and set them
when BSSGP hands a message down to NS.
NS then does a lookup of the 'gprs_nsvc' based on the NSEI parameter.
The explicit 'tlli, gmmh' members of struct msgb are gone from
current libosmocore and have been replaced by the more generic
'control buffer' mechanism.
Be able to tune the RACH settings of the BTS via the vty interface,
by default they are initialized to -1 which means we will use the
content of the static array (BTS default) and can be changed via
the VTY interface. I have verified the setting on the nanoBTS with
wireshark and I have tested writing the config file.
For GSM V1 FR, the payload type is fixed to 3 in the RFC.
But for the other codecs, the payload type is dynamically assigned
between 96 and 127. Here, we use a static mapping internal to OpenBSC.
This patch is needed to make a rather old 139 unit (with sw version
120a002_v149b42d0) work with something else than FR codec. I also tested
this patch on a newer 139 (with sw version 120a352_v267b22d0) to make
sure it didn't add a regression. More testing with newer EDGE units
should be done by whoever has some of theses.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The current code was overly complex. It tried to iterate over
the list in a round robin and we had to keep track of the last
element, see if we remove that one, check if the list becomes
empty... This can all replaced by treating the double linked
list as a queue. We take the item at the front, do something
on it and then and then put it back to the list at the end.
Holger Hans Peter Freyther
Harald Welte
Sylvain Munaut