Hi,

please open a ticket in redmine with: * information about osmocom versions used (and commit hash if you are not running a release). * Explanation about what you see * Expected behavior (if possible linked to some spec section) * pcap trace of what you see

IIRC it's good behavior to drop the connections when you receive an Error Indication with the reset counter incremented.

Hi!

Thanks for your feedback. Seems like a bug indeed. Could you please make a ticket via https://osmocom.org/projects/openggsn/issues/new (registration sould be quick and easy if you don't have one yet).

Would be great if you could share more details in the ticket as well:

- your configs

- how to trigger this error indication reliably

- any spec. reference for proper behavior

- whatever else you think is relevant

11.11.18 07:00, Pierre Kim пишет:

After some debugging I found that the intermittent data loss was caused by the GSN not properly reacting to Error Indication packets.

From GGSN:

<0002> ggsn.c:809 PDP(450091417013617:5): Packet received on APN(internet): forwarding to tun apn0 <000d> gtp.c:2681 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 40 8e 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> pdp.c:255 Begin pdp_tiddel tid = 5716310714190054 <000d> pdp.c:262 End pdp_tiddel: PDP found

When the GGSN receives an error indication, isnt' it supposed to acknowlege the SGSN and attempt to reinitialize the connection? In my case the GGSN simply deleted the PDP context locally and both SGSN and GGSN gets flooded by unknown PDP context error, while the phone keeps trying to transmit data.

Tested on lastest git version and lastest release version: osmo-sgsn 1.3.0, osmo-ggsn 1.2.1

Regards,

Pierre