9 Nov
2018
9 Nov
'18
6:11 a.m.
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
13 Nov
13 Nov
3:49 p.m.
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
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
14 Nov
14 Nov
2:05 p.m.
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
2:19 p.m.
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
8:24 p.m.
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
19 Nov
19 Nov
9:02 a.m.
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
2:33 p.m.
On Mon, Nov 19, 2018 at 05:02:22PM +0900, Pierre Kim wrote:
I've updated the redmine issue with the relevant
packet capture.
https://osmocom.org/issues/3696
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
1994
days inactive
2004
days old
6 comments
3 participants
participants (3)
-
Neels Hofmeyr -
Pau Espin Pedrol -
Pierre Kim