GPRS branch status update

[Harald Welte]

Hi Sylvain,

On Mon, Nov 16, 2009 at 10:16:53AM +0100, Sylvain Munaut wrote:
 
> > I've applied a series of fixes and extensions to the GPRS branch, and
> > would like to invited interested nanoBTS users to give it another try.
> 
> I gave it a go and got to the ACTIVATE PDP CONTEXT with few hacks :
> 
>  - Changed gsm48_gmm_authorize to make identity requests if it doesn't
> have everything it needs, and call
>    it from gsm48_rx_gmm_att_req instead of making identity requests directly.

ok, that makes sense, and I believe this is the same as what we're doing in the 
non-GPRS mobility management case (location update procedure).  Feel free to
send a patch.

>  - Remove the NM_ATT_IPACC_RLC_CFG_3 attr since my nanoBTS doesn't have EDGE

There is some way how to inquire the capabilities of the nanoBTS through
ip.access specific 12.21 extensions.  I must have seen it in their wireshark
dissector but don't remember the details. As I'm not using EDGE at the moment
anyway (we're not indicating it in the SI either), I think it is safe to simply
remove RLC_CFG_3 completely for the time being.  I am currently travelling and
don't have the latest git version, so if you don't mind simply send a patch -
this way I cannot easily forget about it.

>  - (and of course, set correct IPs in nanobts_attr_nsvc0 & ipac_gprs_send)

yes, if you or anyone wants to remove those hardcoded parts and rather replace
it with the BSC's IP address (e.g. getsockname on the OML connection), that
would be great.

> The main problem I have currently is that both phones I use (android
> magic & iPhone 1G), seem to ignore most of the packets that are sent
> back.

that's strange. I suppose that means that those packets are somehow broken and
ignored by either the BTS or the MS.

Have you checked in wireshark how it looks like?  If you decode UDP port 23000
packets as NSIP protocol, you will get a full decode of ns, bssgp llc and 04.08

Things to check is if the NSVCI/BVCI/TLLI of the response we send matches the
TLLI of the request.  Also interesting to see if the dissector detects some
broken messages or if the data we send generally makes sense or not.

> So for example, after a GMM ATTACH REQUEST a IDENTITY REQUEST is sent
> back, and for the first one, the phone answers, then a second IDENTITY
> REQUEST is sent (need both IMSI & IMEI and the phone did the initial
> attach request by TMSI ...) and there it's just ignored, no answer.

that's strange.  I have so far tested wit Motorola EZX phones such as the A780,
and that has worked.  I didn't have time to test with any other phone and thus
flavor of GPRS stack.

> Same thing with RA LOCATION UPDATE, if I send REJECT with
> cause=implicit detach, it just retries the RA UPDATE instead of going
> to ATTACH REQUEST. And the list goes on, the ACTIVATE PDP CONTEXT
> ACCEPT has to be sent 4-5 times before the phone accept it.

ok, we're doing this wrong anyway.  My assumption that we need to reject a RA
update until we have seen an ATTACH request apparently was wrong.  I still
think it's illogical,  but it seems we have to accept a RA UPDATE even if the
phone is not ATTACHed and mark it implicitly as ATTACHed at that point.

So feel free to play with the code and tell me what works for you[r phone]

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)