I see packets of 1520 bytes in the generated pcap running under the
docker setup. This happens when a lot of IPA concurrent clients send
messages and end up in the same TCP packet due to naggle algorithm.
Change-Id: I362371508ba83acc48376b6ed012a97a59d4b31b
This test allows initial testing of a session creation through the S2b
interface (emulating an ePDG).
A follow-up test will be added to test the APCO IE (feature which
open5gs-smfd still doesn't support).
Change-Id: I38e469edf0e00feca5a648035b64645e2c905937
So far we were only testing s5/s8 interface, but we'll want to test s2b
soon.
This commit is a mixture of refactorings and code improvements as a step
towards testing S2b interface.
Change-Id: I22b3e18d02ca828e2ea43bde2e0a602db236cf50
Strongswan already has this information during first IKE_AUTH message,
see 3GPP TS 24.302 7.2.2.1.
Change-Id: I42e4dc4bbcef969aae5867dbb103f8a5db157c89
A recent commit added records to separate 2 binary octets into known
fields, but 2 fields filling 1 byte were actually written swapped. Fix
it now.
Fixes: 7b7a1e8ed1
Change-Id: I884bddb0e1e5f1cfc5615c11d6c7d602d0df9224
Should fix the following log message:
NS_Emulation.ttcnpp:784 Timeout operation on timer Tns_alive failed: The timer is not started.
Change-Id: If1fae965659f73fde2508b0e9158099025fa65f2
Should fix the following log message:
BSSGP_Emulation.ttcnpp:1118 Timeout operation on timer g_T1 failed: The timer is not started.
Change-Id: Id7d1b76a6bc1fc2f0f4896c59673c01293b526e9
Those interfaces reuse messages from other Diameter RFCs, but changing
the contents of the messages, eg some Mandatory fields like
Service-Context-Id which are mandatory in RFC5006, doesn't even appear
in Gx CCR in TS 29.212.
Keeping them well separated helps in avoiding confusion on users fo the
messages.
Change-Id: Ibe0d5f263813d5083e020c942283f214983162b4
The previous conditions "isvalue()" were wrong. Passing an array of
templates to isvalue() returns false, which is unexpected here.
Change-Id: Iaad47b1ec7e2a7477fa554df9caeb866ffa594eb
The previous PDP-Type IE should have been a PDP-Address from the
start, since having only PDP-Type with no address is only a specific
case (dynamic addressing).
This becomes clear by looking at other similar protocols like:
* MAP: APN-Configuration IE has servedPartyIP-IP{v4,v6}-Address IEs
* Diameter S6b, 3GPP TS 29.272 7.3.35 APN-Configuration contains
Served-Party-IP-Address AVPs
* Diameter SWx, 3GPP TS 29.273 APN-Configuration.
* GTPv1C Ts 29.060 7.7.29 PDP Context containing PDP Address.
Since PDP-Type on its own really makes no sense, being it a special case
of PDP-Address, let's keep the IE by renaming it (keeping old name too
for API backward compat) and extend it to support lengths > 2 bytes.
Old implementation of libosmogsm gsup actually ignored lengths > 2
bytes, so we are safe acting against older implementations here, both
on the sending and receiving side on the wire.
Change-Id: I3e92368fff61694bcef6a48320595b59ae8f54ca
Related: OS#6091
Related: libosmocore.git Change-Id I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
Related: osmo-gsm-manuals.git Change-Id I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
The CEIA interface is an interface between osmo-epdg and
strongswan.
It is used by the osmo-epdg to synchronize state.
Related: OS#6091
Related: libosmocore.git Change-Id I6f7c20340c99f94b1326a8a7dc99c86cf6a0dbc3
Change-Id: I3da4f731597eee3736a9aab513f5257a78e8d8eb
Since recently GTP2 Emulation got improved routing, and it should simply
match by the already registered imsi.
Change-Id: I410242d6597db10b97edf72b92e749db28520c39
I'm finally not using it for now, but since it takes a while to write,
leave it there for some lucky future user.
Change-Id: Ibf4b98e19ff13f23c552f50ca91832f0d317bbbf
NAS Token is derived from kasme and NAS ul_count as specified in 3GPP TS
33.401 A.9, and its LSB 16 bits passed to the network when mapping the GUTI to
RAI+PTMSI+PTIMSI_SIG.
Take the chance to move guti2rai_ptmsi() up to before the place it is
used.
Change-Id: I5e6003a2fe3e74cc93cfe4a288e6c114aa288d0b
A recent commit in GTPv2_Emulation improved the routing of incoming
messages from network towards clients.
After that change, the GTPv2_Emulation properly matches the originating
component of the procedure and forwards the reply to it.
Hence, TC_tx_echo() needs to be adapter to expect the reply on its
CLIENT port.
TEID0 is now left for incoming initiating messages which have no seqnr
match.
Change-Id: I1764fdf81192597e393d79d34cb8f221aa79bbd9
Fixes: 1d2cc67036
First try forwarding to component transmitting the originating request,
since this is the most fine-grained match.
Finally, if no specific match was found and if messages belongs to
TEID0, send it over that port as a fallback.
Fixes: 1d2cc67036
Change-Id: Ie96d65085fb352489150183415dbd6cc8237a47c
The TEID field is optional, based on t_Bit. Hence, we also want to
match by type if there's no TEID.
Change-Id: I65044b8758046704e22f9057f34ce5fdbb7aabfe
It is sometimes needed to reset them to zero as per spec, like when
moving GERAN/UTRAN->EUTRAN.
This will be used by a follow-up patch.
Change-Id: I61d7b919aba8f58a020c18ae9b9bba4108d59010
Fix the issue that MSC rejects call termination, because talker can't
be identified as originator of the call.
Fixes: OS#6325
Change-Id: I0381e25e15624e6b7577910c95700a355ed3f811
Old osmo-msc versions do not include the Source Name IE in SMS related
GSUP messages, unless it's set explicitly in the config file ('hlr' /
'ipa-name'). Recent osmo-msc versions (see the related osmo-msc patch)
do include this IE even if it's not set explicitly ('unnamed-MSC').
Because of this, some testcases in ttcn3-msc-test are currently
failing for osmo-msc master, but still passing for the -latest.
Let's set the 'ipa-name' explicitly in osmo-msc.cfg, and expect the
Source Name IE to be present in SMS related receive templates.
Change-Id: Ic24d3082fe3dce08e43e8f3ecb6d6132503c55c6
Related: docker-playground.git I7757aae1d01b679f530b5c0a6c95b224cb9f204f
Related: osmo-msc.git I7bacd001b81326c32bc262c7d0c0491ded822fa8
Related: OS#6135
We do expect it in receive templates for SMS, so let's also
indluce it in the send templates.
Change-Id: I6468d8606eb85c811d86e4a1407ee60c8a36fbea
Related: OS#6135
The previous logic was wrong, since it was increasing the rx_count at
the time where the msg is received and before checking it. Instead, it
should be increased after having validated and accepted it.
This fixes the case where rx_count will have to be reset (to zero) when
doing mobility GERAN->EUTRAN.
Change-Id: I712d95f7784a6a9855fe36300b0ebfcd4c6ef377
Pau Espin
Vadim Yanitskiy
Andreas Eversberg