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...
We have to copy the sin_addr.s_addr, rather than the entire sin_addr. The
latter results in the destination interpreting it as an IPv6 address, as
the only differentiator between IPv4 and IPv6 is the size of the payload
of this IE.
* 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.
We assume that the lchan_free will initiate the release and
that when we handle the RLL release indication or the release
request as part of the shutdown sequence.
The current channel release has a couple of issues we will
need to fix in a set of upcoming commits.
The issues include:
1.) sending release twice
2.) reassigning the channel inbetween the relase..
This is of course not the correct way of dealing with it, but for
now it should make the Ericsson Mobile Plafrom based phones happy
(they insist to do a suspend/resume cycle before pdp ctx act)
GRE has the strange notion of keepalive messages being encapsulated IPv4
packets adressed back to the sender. Since we actually really only care
about frame relay, this is a bit strange. However, we'll do some sanity
checks and send it back through our GRE socket...
Holger Hans Peter Freyther
Harald Welte