We see GTP-U originating from ports other than 2152 in the field. When
osmo-upf forwards these, we want to forward from our GTP-U port 2152,
since that is the only port osmo-upf has bound for GTP-U (for echo).
According to 3GPP TS 29.060, the *destination* port for GTP-U shall be
2152 -- but the source port is apparently allowed to be different.
Before this patch, we would forward GTP-U like this:
3.3.3.3:33333 -> (3.3.3.4:2152 UPF 2.2.2.2:33333) -> 1.1.1.1:2152
^^^^^
Instead we want to always send from UDP source port 2152:
3.3.3.3:33333 -> (3.3.3.4:2152 UPF 2.2.2.2:2152) -> 1.1.1.1:2152
^^^^
This hasn't shown up before because so far all GTP-U peers we saw
consistently used source port 2152.
Related: SYS#6773
Change-Id: Idaf43f1c2b915846b50a8b97305f0229e34ad539
When handing out a chain_id, make sure it is not in use yet.
So far picking a chain_id was of PoC grade quality. As osmo-upf is
approaching production grade, make this waterproof.
So far with inefficient iteration of all sessions; faster lookup follows
in I36a75ec4698cd83558185c1f202400eb53ae8ff6.
Related: OS#5900
Change-Id: I139b46de0bd15185a7a06109d55f7c759755ec81
Verify that skipping used IDs works for:
- PFCP UP-SEID
- GTP local TEID
- chain_id for nft rulesets -- so far expected to fail,
fix follows in I139b46de0bd15185a7a06109d55f7c759755ec81.
Related: OS#5900
Change-Id: I36acff15f22d23ade4d281c2af3eb117dfc10359
Neels Hofmeyr