Bug #5773
open
OsmoGGSN sends Direct Tunnel packets to the wrong IP address
Added by manatails over 1 year ago.
Updated about 19 hours ago.
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
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.
- Related to Bug #6512: osmo-ggsn: Missing support for Direct Tunnel Flags logic added
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.
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.
- Status changed from New to Feedback
- Assignee changed from pespin to manatails
- % Done changed from 0 to 90
Also available in: Atom
PDF
