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>
According to the GPRS NS spec the maximum framesize
is 1600 octets for FrameRelay, it can be bigger if
configured to be so. Make it 2048 octets to have some
space available...
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.
Using the code of this commit, it was possible to provision GPRS
services and access a website from a G1 phone (Qualcomm MSM7k baseband chipset)
using a nanoBTS, Osmo-SGSN and OpenGGSN.
There is still no fragment re-assembly in the uplink path yet,
despite the (untested) code present in the gprs_sndcp.c file
This only works for packets that are small enough to not need
fragmentation at the SNDCP layer (dns queries, ntp and the like).
It requires libgtp built from OpenGGSN dc3744fda045f9fca83de6881176987335a309a8
or later. Plain 0.90 will NOT work.
Using this version, I could see bi-directional traffic from various
phones going all the way through BTS, OsmoSGSN, OpenGGSN and being routed
to and from the real internet. Time to celebrate...
* separate the LLME and LLE state in the LLC layer
* introduce gprs_llgmm_assign() function for LLGMM-ASSIGN.req primitive
* change QoS profile to match 'real' SGSN
* Update the new TLLI when assigning a P-TMSI
The result now is that the LLC layer is notified of TLLI changes, which in turn
means it doesn't allocate a new LLE structure every TLLI change, which again
in turn means that the UI frame sequence number does not reset to zero.
As a result, MS should no longer ignore frames based on wrong UI sequence number.
When we send a downlink unit-data request via BSSGP, there is a lot
of information that needs to be copied from the mm context, such as
the IMSI, DRX parametes, MS radio access parameters, ...
This is a quite strange layering violation, since we now need to pass
a pointer to the MM ctx from GMM through LLC into BSSGP :(
Our state transitions and timers now reflect 04.08 for GMM much
better than before. Also, we allocate a new P-TMSI on every ATTACH
and RA UPDATE, as some phones seem to get confused if they don't
get a P-TMSI.
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.
Change gprs_nsvc_reset to return void instead of a int
as the gb_proxy.c currently ignores the reutnr value anyway.
Change the caller inside gprs_ns to return the newly allocated
nsvc instead of the return of gprs_nsvc_reset.
Almost all parameters about the SGSNs NS-VC can be specified in the NS
protocol node. All that needs to remain in the gbproxy config node
is "nsip sgsn nsei XXX".
* store LLC SAPI as part of PDP ctx
* store NSEI + BVCI as part of MM ctx
* export gsm48_tx_gsm_act_pdp_acc() and call it from sgsn_libgtp.c
* create and use gsm48_tx_gsm_act_pdp_rej for error cases
* print SAPI as part of VTY show pdp
Sylvain Munaut
Holger Hans Peter Freyther
Harald Welte