Hello, I've set up a mini 3G RAN with yesterday's git repo.
The phone works fine and successfully creates a PDP context, but data only works for a few minutes before it stops.
Logs from SGSN and GGSN are as follows.
Any help will be appreciated.
From SGSN:
<000e> sgsn_libgtp.c:175 PDP(450091417013617/0) Create PDP Context <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6) <0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6)<0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 95 content: 32 ff 00 57 00 00 00 05 11 b4 00 00 45 00 00 53 ad fc 40 00 38 06 7b 5c 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c a6 c2 6b 46 39 80 18 01 fc 05 54 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 15 03 03 00 1a 6e ec c9 35 4b a9 48 c5 23 b0 fa 35 a5 d6 e7 e5 5b 95 f0 38 45 0a cf c8 97 d1 : Unknown PDP context, GTPv1 <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 64 content: 32 ff 00 38 00 00 00 05 11 b5 00 00 45 00 00 34 ad fd 40 00 38 06 7b 7a 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c c5 c2 6b 46 39 80 11 01 fc dd ce 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 : Unknown PDP context, GTPv1
GGSN
<0002> ggsn.c:735 PDP(450091417013617:5): Successful PDP Context Creation: APN=internet(internet), TEIC=1, IPv4=192.168.100.2, IPv6=none <000d> gtp.c:2761 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b4 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Received Error Indication <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context <000d> gtp.c:2755 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b5 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Unknown PDP context <000d> gtp.c:2117 Packet from 192.168.27.49:2123, length: 52 content: 32 12 00 2c 00 00 00 01 4c 0a 00 00 0e 13 10 00 00 00 05 14 05 85 00 04 c0 a8 1b 31 85 00 04 c0 a8 1b 2a 87 00 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Unknown PDP context: 1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 00 00 00 45 00 00 3c 6f 51 40 00 40 06 08 fb c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff ce 3c 00 00 02 04 05 b4 04 02 08 0a ff ff c7 58 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 01 00 00 45 00 00 3c 6f 52 40 00 40 06 08 fa c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cd 42 00 00 02 04 05 b4 04 02 08 0a ff ff c8 52 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 02 00 00 45 00 00 3c 6f 53 40 00 40 06 08 f9 c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cb 4d 00 00 02 04 05 b4 04 02 08 0a ff ff ca 47 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1
Hi,
usually it's better if you open a redmine ticket with more information: - releases you are using of each related component - pcap trace taken while the issue appear
On Fri, Nov 09, 2018 at 02:11:02PM +0900, Pierre Kim wrote:
The phone works fine and successfully creates a PDP context, but data only works for a few minutes before it stops.
If you go to flight mode and back, does data continue? If you wait two minutes and try again, does it work again?
I have often seen odd data unreliabilities on 3G, AFAIK it's still an issue which hasn't been resolved yet. I think at some point we had (or still have) an error in a flag indicating whether we're re-using an auth key or using a new one, not sure if that's resolved yet. If it's not that, it should be some obscure protocol corner case that we need to find and fix, once identified it should be quick to solve. The issue I created back in the days was https://osmocom.org/issues/1977 -- not sure if it applies to your situation. That report is notoriously under-informative... Apologies for my past self. It would be excellent if someone familiar with the inner workings of the SGSN could investigate and pinpoint what is going wrong sporadically on 3G.
Also recently there was http://lists.osmocom.org/pipermail/openbsc/2018-November/012362.html Oh wait, that was you, as well!
BTW, technically the right ML for PS issues would be osmocom-net-gprs (but I personally don't mind it being discussed here).
~N
If you go to flight mode and back, does data continue? If you wait two minutes and try again, does it work again?
Switching to flight mode itself doesn't help, I guess I have to wait two minutes until the SGSN finds out about the missing PDP context and tries to reopen the connection.
Also recently there was http://lists.osmocom.org/pipermail/openbsc/2018-November/012362.html Oh wait, that was you, as well!
Yeah thats me, I ended up creating two separate threads because one got held in the moderation queue for a few days. Sorry for that.
One interesting thing that I discovered is that if I just patch the GGSN to ignore all Error Indication packets(not deleting the PDP context), data works surprisingly well. Still there are some quirks but it becomes very reliable. That makes me wonder if those Error Indications are even needed in the first place. One could look into the cause of Error Indication from the SGSN.
Regards, Pierre
On Wed, Nov 14, 2018 at 10:19:03PM +0900, Pierre Kim wrote:
One interesting thing that I discovered is that if I just patch the GGSN to ignore all Error Indication packets(not deleting the PDP context), data works surprisingly well.
I think this is worth investigating indeed. Have we got a redmine issue on it yet? I guess those would be two: a) find out the source of SGSN errors and b) be more tolerant of errors in the GGSN.
Possibly b) becomes obsolete when a) is resolved, or maybe b) is even harmful when errors should have implied the end of a PDP context.
For a), it would be super interesting to get a pcap / log snippets of the actual error indications attached to the redmine issue.
~N
I think this is worth investigating indeed. Have we got a redmine issue on it yet? I guess those would be two: a) find out the source of SGSN errors and b) be more tolerant of errors in the GGSN.
Possibly b) becomes obsolete when a) is resolved, or maybe b) is even harmful when errors should have implied the end of a PDP context.
For a), it would be super interesting to get a pcap / log snippets of the actual error indications attached to the redmine issue.
I've updated the redmine issue with the relevant packet capture.
https://osmocom.org/issues/3696
Regards,
Pierre
On Mon, Nov 19, 2018 at 05:02:22PM +0900, Pierre Kim wrote:
I've updated the redmine issue with the relevant packet capture.
Thanks! I hope it will get picked up by someone sooner or later. And of course, if you figure out more details, keep in touch...
~N
-
Neels Hofmeyr -
Pau Espin Pedrol -
Pierre Kim