Bug #5773
openOsmoGGSN sends Direct Tunnel packets to the wrong IP address
90%
Description
When GTP-U Direct Tunnel is used, GGSN shall send all data packets to the RNC.
But sometimes when data packets are queued right after the Echo Request message from the SGSN, data packets are sent to the SGSN instead of RNC, causing SGSN to crash.
Attached is a pcap of the bug.
Packet no. 1-6 are correctly sent to the RNC at 10.27.30.100
But after packet no. 18 Echo response subsequent GTP-U packets are wrongly sent to the SGSN at 10.27.30.99 and SGSN reports Error indication.
Files
Related issues
Updated by manatails over 1 year ago
I found that st_pmm_idle_on_enter() from osmo-sgsn is resetting the GTP-U address.
Is it necessary when the RNC is in Direct Tunnel mode? I am not sure what the correct behavior is. Disabling st_pmm_idle_on_enter seems to fix the problem for me.
Updated by pespin 1 day ago
Hi manatails , I didn't see this ticket before. I'm currently improving a bit the Direct Tunnel support in osmo-sgsn and osmo-ggsn since it's not conformant to specs (TS 29.060, missing "Direct Tunnel Flags").
I just submitted a bunch of patches to SGSN_Tests which allows us testing a lot more stuff for 3G (Iu). We can probably try to reproduce your bug there.
Updated by pespin 1 day ago
- Assignee set to pespin
manatails what I'm seeing in the pcap is osmo-sgsn updating osmo-ggsn because probably the 3G UE went to PMM IDLE state (released Iu context), hence SGSN drops the Direct Tunnel and tells the GGSN to point the GTPU to the SGSN itself.
This way the SGSN can know when there's new incoming MT data and can page the UE so that it gets a new Iu ctx.
So the UpdatePDPCtx you see in frame_nr=10-11 are telling the GGSN to send data to the SGSN. And the GGSN does so in frame_nr=19-20.
The problem is that we probably don't have a proper path to forward data in the SGSN yet for non-DirectTunnel, we need to improve that, hence why it probably answers with Error Indication.
Some logging during that scenario plus a backtrace would be welcome. Otherwise we can also write a TTCN-3 test to reproduce the issue.
Updated by pespin about 6 hours ago
- Status changed from New to Feedback
- Assignee changed from pespin to manatails
- % Done changed from 0 to 90
I submitted several fixes to gerrit, and I think this ticket should be fixed by:
https://gerrit.osmocom.org/c/osmo-sgsn/+/37644
I wasn't unable to trigger a crash though.
See test TC_pmm_idle_rx_mt_data, submitted to gerrit here: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/37646
Note that the current status of osmo-sgsn still is unable to forward MT traffic being sent to it while the UE is paged + direct tunnel is re-established.
