Hello Sylvain,
On Mon, 2 Nov 2009 01:05:20 +0100, "Sylvain Munaut" 246tnt@gmail.com wrote:
I found out the problem.
In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is incorect. It uses msg->len but at that point it already did a msgb_push to add space for the header so msg->len is already too big. You need to save the size of msg->len before the msgb_push and then use that when encoding the PDU TLV length.
Thanks for the info, I tried it here but it did not help for the "GMM ATTACH REQUEST", the nanoBTS still reboots when it receives the data of the "GPRS IDENTITY REQUEST" which is sent afterwards. I finally found the reason for this behaviour (at least I hope it is the reason), I had to specify the correct BVCI parameter for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If I use "925" instead of "0" it works. The phone sends an "GMM IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" because it does not yet receive an accept.
BTW, do you sometimes hangout in #openbsc ?
No, usually not (its a bit difficult for me to do my work and look at what is happing on IRC).
Best regards, Dieter
I finally found the reason for this behaviour (at least I hope it is the reason), I had to specify the correct BVCI parameter for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If I use "925" instead of "0" it works.
Ah yes, I had to do that too. I fixed that first and forgot about it because it didn't fix the reboot but apparently both fix are needed for things to work.
The phone sends an "GMM IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" because it does not yet receive an accept.
After rebooting the phone fully I was able to convince it it wasn't attached (both my iPhone and my android had the same behavior of thinking they were still attached after switching from their 'home' network EDGE to OpenBSC GPRS, even with different mnc/mcc ... And they didn't seem to care about the RA REJECT with "implicit detach" cause)
Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in the CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set in openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from where yet. So currently you need to set 1/1 in your openbsc.cfg as well.
Sylvain
On Tue, Nov 03, 2009 at 07:03:15AM +0000, 246tnt@gmail.com wrote:
Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in the CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set in openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from where yet.
it's the NM_ATT_IPACC_CGI in nanobts_attr_bts[]: three bytes bcd-encoded mcc/mnc, two bytes lac and two bytes cell id. two-byte values as u_int16_t in network byte order.
Hi Dieter and Sylvain,
On Mon, Nov 02, 2009 at 11:35:00AM +0000, Dieter Spaar wrote:
Thanks for the info, I tried it here but it did not help for the "GMM ATTACH REQUEST", the nanoBTS still reboots when it receives the data of the "GPRS IDENTITY REQUEST" which is sent afterwards. I finally found the reason for this behaviour (at least I hope it is the reason), I had to specify the correct BVCI parameter for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If I use "925" instead of "0" it works. The phone sends an "GMM IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" because it does not yet receive an accept.
I'll soon add the nsvci and bvci values to the config file. Those values are then used by both the OML attributes and the BSSGP/NS protocol code, which should address this problem 'the right way'.
BTW, do you sometimes hangout in #openbsc ?
No, usually not (its a bit difficult for me to do my work and look at what is happing on IRC).
yes, getting Dieter at least on an instant messenger (not even talking about IRC) is really hard ;)
-
246tnt＠gmail.com -
Dieter Spaar -
Harald Welte