Project

General

Profile

Actions

Bug #4000

closed

Unknown PDP context after Iu-Release (and updated gtp-u endpoints) -> Hard-dropping PDP context

Added by efistokl almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/14/2019
Due date:
% Done:

0%

Spec Reference:
Tags:
3G

Description

The bug seems to be triggered when the Iu-Release is performed, the GTP-U endpoints are updated (with Update PDP Context Request), and when the GTP-U packet arrives from GGSN to SGSN, then PDP context for given TEID is not found and then it is hard-dropped because of the error in gtp.c:

May 07 15:16:17 Core osmo-sgsn[4054]: <0023> gtp.c:2378 Packet from 10.0.1.123:2123, length: 55 content: 32 13 00 2f 00 00 00 01 98 1d 00 00 01 80 10 00 00 00 01 7f 0b 56 70 83 85 00 04 0a 00 01 7b 85 00 04 c0 a8 0e 10 87 00 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Missing information field
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> sgsn_libgtp.c:644 libgtp cb_conf(type=18, cause=-1, pdp=0x7f6447263060, cbp=0xc0eae0)
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> sgsn_libgtp.c:648 libgtp EOF (type=18, pdp=0x7f6447263060, cbp=0xc0eae0)
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> gtp.c:2800 Packet from 192.168.14.16:2152, length: 60 content: 30 ff 00 34 00 00 00 09 45 00 00 34 0a 29 00 00 f4 06 dc 57 45 ad 90 95 0a 00 00 01 01 bb ce 32 f1 00 89 77 34 68 f8 fa 80 11 0e 24 24 bd 00 00 01 01 08 0a c3 05 ef 21 00 05 39 a2 : Unknown PDP context, GTPv1
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> sgsn_libgtp.c:669 PDP(248010132392306:5): Context 0x7f6447263060 was deleted
May 07 15:16:17 Core osmo-sgsn[4054]: <000e> gprs_sgsn.c:740 PDP(248010132392306/0) Hard-dropping PDP ctx due to GGSN recovery
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> pdp.c:255 Begin pdp_tiddel tid = 5603293231010842
May 07 15:16:17 Core osmo-sgsn[4054]: <0023> pdp.c:262 End pdp_tiddel: PDP found

The relevant PCAP and logs are attached.
10.0.2.52 - Femtocell
10.0.2.51 - SGSN
10.0.1.123 or 192.168.14.16 - GGSN

I use a filthy hack which is to comment out the call to mmctx_change_gtpu_endpoints_to_sgsn function in sgsn.

Btw, possibly bug in the gtp library...


Files

pdp-drop.pcap pdp-drop.pcap 26 KB efistokl, 05/14/2019 11:10 AM
sgsn-logs-pdp-drop.txt sgsn-logs-pdp-drop.txt 6.58 KB efistokl, 05/14/2019 11:11 AM
Actions #1

Updated by efistokl almost 5 years ago

efistokl wrote:

The bug seems to be triggered when the Iu-Release is performed, the GTP-U endpoints are updated (with Update PDP Context Request), and when the GTP-U packet arrives from GGSN to SGSN, then PDP context for given TEID is not found and then it is hard-dropped because of the error in gtp.c:
The relevant PCAP and logs are attached.

Do we need more information about the bug (extended traces/logs/...)? Has anyone faced such a behavior this before?

Actions #2

Updated by laforge almost 5 years ago

I think we first have to ensure that the basics are working, i.e.
OsmoSGSN sends IuRelease at the right point in time and properly closes
the SCCP connections before we dig any further on what happens
after the release.

It's great to get all those (very useful!) bug reports from you, but
unfortunately it doesn't increase our capacity in terms of developer
time/contributions. Ideally, the next step after having reproducible
bugs is to create TTCN-3 testcases for them, and finally the actual
required changes to OsmoSGSN.

Particularly looking at this with my sysmocom hat: We have various
support contracts for users of the 2G stack, but we don't have any
single customer who contributes financially to maintenance and/or
bugfixiong on the 3G side.

It's OK if you're not too much familiar with the code yet to take on
implementing those additional steps. Please keep filing bug reports.
I'm just afraid there won't be all that much bugfixing happen due to the
aforementioned reasons.

Actions #3

Updated by efistokl almost 5 years ago

laforge wrote:

I think we first have to ensure that the basics are working, i.e.
OsmoSGSN sends IuRelease at the right point in time and properly closes
the SCCP connections before we dig any further on what happens
after the release.

In short: absolutely agreed.

A bit longer:
With all the hacks I've come up so far I have the 3G PS working perfectly for my
iPhone 6S, Honor, and Huawei phones (not sure which models, need to look at
them).
But the Samsung J7 phone behaves weirdly on the network (on both
Osmo-SGSN and the proprietary one). When connected to some other cellular
provider (checked with Telia or Elisa (Finland)) it works fine. It means that
the proprietary software we use also misbehaves... -> and it means that I cannot
trust the traces with the proprietary one anymore and have to rely on 3GPP specs
and TTCN-3 testing.

I'm just afraid there won't be all that much bugfixing happen due to the
aforementioned reasons.

Yeah, I don't expect them to be fixed, just filing bug reports so the bug is at
least known.

Actions #4

Updated by efistokl over 4 years ago

The issue wasn't related to the core network. It was the misconfiguration of our femtocell. And we observed the problem only with Samsung phones (which is now resolved). The issue can be closed.

Actions #5

Updated by laforge over 4 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)