* gsm_04_08_utils.c will directly send the message...
* gsm_04_08.c will use the DTAP API, add a new method to pull
in the data from the transaction...
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>
Ultimately, we'll need to store both the last used tuple by a
subscriber and a list of known tuples (for unknown Ki). What's
currently implemented for AuthTuples is the former behavior, so
reflect that.
The second use case will be added as a separate table with separate
accessors later on.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
We now have a function that generates BSSGP PS and CS paging request.
It is called from the libgtp code when we receive a GTP packet from
the GGSN for a MM context that is in SUSPEND state. We then issue
a PS paging request to the Cell with the BVCI where the last RA update
was being performed.
TODO: We still don't enqueue the GTP packet (and transmit it on paging
complete), and we don't rate-limit the paging requests, i.e. every GTP packet
will trigger another paging request.
We probably also need some kind of logic that marks the phone as UNREGISTERED
if it doesn't respond to paging requests for some time.
The paging message should not be called directly and the GSM Subscriber
can handle multiple requests at the same time... Now a subscr_put_channel
should be called after the message sending. But it is not very clear when
this can be called. The current code works by luck that the SAPI=0 will
be released...
The MT-SMS was tested via the VTY interface and a N900.
We will tell the BTS where we are listening, but the ACK
will return the original settings... this should make it
possible to intercept the GPRS stream..
As we don't support compressed SMS, we have to properly reject it.
In the existing code, we segfaulted at some later point since the error
handling was incomplete.
This was triggered by some obscure STK SIM card that insisted on sending a
compressed SMS after registering to the OpenBSC network.
Some phones (notably a Ericsson Mobile Platform based E-TEN M800)
insist on sending PDP CTX DEACT messages for contexts that have already
been deactivated. The spec doesn't really say what we should do in
this case. But since there is no "reject", we simply acknowledge it.
This is a good interim solution for messages not handled by us,
right now this would include the NVRAM attributes that I do not
feel like caching right now.
Holger Hans Peter Freyther
Sylvain Munaut
Harald Welte