Hello folks, I have a strange behavior when the a MS send a Location Update, it is often rejected.
I think the the problem is the "Rx GSUP LU Result without LU in progress" (see log further).
It's weird because in the point of view of the HLR it seems OK :
- message 0x04 Update Location Request followed by 0x10 Insert Subscriber Data Request - message 0x12 Insert Subscriber Data Result followed by 0x06 Update Location Result
Is anyone experiencing the same problem?
I will investigate in the code to see if I found something with the state machines or timers, if I found more detail, I will post them.
Have a nice day, Antony
Here is a extract of the logs of osmo-msc :
20180423132534278 DBSSAP <0010> a_iface_bssap.c:268 Rx BSSMAP COMPLETE L3 INFO (conn_id=4) 20180423132534278 DVLR <000e> vlr.c:388 New subscr, TMSI: 0xb35bd0aa 20180423132534278 DMSC <0006> a_iface_bssap.c:351 User has been accepted by MSC. 20180423132534748 DVLR <000e> gsm_04_08.c:3729 SUBSCR(MSISDN:1) VLR: update for IMSI=206012225318490 (MSISDN=1, used=2) 20180423132534748 DVLR <000e> vlr.c:769 SUBSCR(MSISDN:1) Rx GSUP LU Result without LU in progress 20180423132539279 DMM <0002> subscr_conn.c:110 Subscr_Conn(LU:3009138858)[0x1387410]{SUBSCR_CONN_S_AUTH_CIPH}: Close event, cause: CONGESTION 20180423132539279 DMM <0002> gsm_04_08.c:217 Subscriber IMSI:206012225318490: LOCATION UPDATING REJECT 20180423132539279 DMM <0002> vlr_lu_fsm.c:728 Subscr_Conn(LU:3009138858)[0x1387410]{SUBSCR_CONN_S_RELEASING}: Event SUBSCR_CONN_E_CN_CLOSE not permitted 20180423132539279 DBSSAP <0010> a_iface.c:419 (subscr IMSI:206012225318490, conn_id 4) Tx BSSMAP CLEAR COMMAND to BSC 20180423132539281 DBSSAP <0010> a_iface_bssap.c:241 (subscr IMSI:206012225318490, conn_id 4) Rx BSSMAP CLEAR COMPLETE, releasing SCCP connection
Hi Antony,
thanks for reporting!
I haven't seen the behavior you describe.
The VLR wants to first send a GSUP Update Location Request to the HLR before it receives a reply to it. From the short logs that you sent it's hard to figure out whether that was the case, or if not, why.
Does this happen only sporadically or do you have a sure-shot way to reproduce the failure?
If you have an account on osmocom.org, I can enable permissions for you to create an issue, to attach all logs and a network trace.
~N
Side Note:\
On Mon, Apr 23, 2018 at 11:42:26PM +0200, Neels Hofmeyr wrote:
If you have an account on osmocom.org, I can enable permissions for you to create an issue, to attach all logs and a network trace.
I think issue creation / reporting is public, i.e. works after self-registration of an user account. Only editing wiki pages requires an explicit permission, as we had too many problems with wiki spam.
Hello, I will do a more in deep analysis of the behavior, gather all logs and traces and post them back :-) It is happening really often in my setup when I get out my phone from my osmo gsm network and put it back just after.
On Mon, Apr 23, 2018 at 11:42 PM, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Hi Antony,
thanks for reporting!
I haven't seen the behavior you describe.
The VLR wants to first send a GSUP Update Location Request to the HLR before it receives a reply to it. From the short logs that you sent it's hard to figure out whether that was the case, or if not, why.
Does this happen only sporadically or do you have a sure-shot way to reproduce the failure?
If you have an account on osmocom.org, I can enable permissions for you to create an issue, to attach all logs and a network trace.
~N
-
Antony Lemmens -
Harald Welte -
Neels Hofmeyr