Attention is currently required from: fixeria.
laforge has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38210?usp=email )
Change subject: s1gw: make number of eNBs configurable via module params
......................................................................
Patch Set 2: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38210?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Ia80b9118e66a5d6721b89d3ba068227d30dcc01f
Gerrit-Change-Number: 38210
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:35:02 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Attention is currently required from: fixeria.
laforge has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38209?usp=email )
Change subject: s1gw: f_init_pfcp(): use 'PFCPEM' as the prefix
......................................................................
Patch Set 2: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38209?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Ia5413313cffb265f83ea0850e31dfb35274c28ba
Gerrit-Change-Number: 38209
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:34:06 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Attention is currently required from: fixeria.
laforge has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email )
Change subject: library: add generic Mutex API for parallel components
......................................................................
Patch Set 2: Code-Review+1
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/ad03cca5_3a93… :
PS2, Line 14: and there
: is no way for the PFCPEM to correlate which session belongs to which eNB.
> In theory, the S1GW could include a tuple of `{MME-UE-S1AP-ID, ENB-UE-S1AP-ID, e-RAB-ID}`, which would uniquely identify each PFCP session, even at the establishment phase.
I guess even only either MME-UE or ENB-UE side for S1AP-ID would be s ufficient in combination with the e-RAB-ID.
> I was considering this at the beginning and the question I had is **what kind of IE**? I could not find suitable PFCP IEs for that and I was not sure if adding Osmocom specific IEs to simplify the job for the testsuite is worth it.
Would have been worth raising the question at the time, IMHO.
> > If we cannot find a good PFCP IE to include such identity information in, 3GPP TS 29.244 Section 5.9 states we may add vendor-specific IEs anywhere and any implementation not understanding them shall just ignore them: [...]
>
> While I agree that it would also be useful for debugging, I've already put a significant effort into getting this implemented, debugged, and finally working. I hope we can get this merged for now and consider adding Osmocom specific IEs as a further improvement?
It's a bit of a double-edged sword. The mere fact that somebody has worked [far] on a given topic [without prior discussion] by itself doesn't make it the right thing to do, nor does it say we must merge it.
But yes, in this specific instance we can go ahead, the mutex approach is small/self-contained enough that it shouldn't be too hard to remove it later on, if needed.
> IMSI is not easily accessible for the S1GW, since it's usually part of the inner NAS PDUs. Digging into NAS in the S1GW (and likely having to keep some context around) sounds like an overkill to me. Some S1AP PDUs, like the `INITIAL CONTEXT SETUP` carry masked IMEISV (not IMSI), which is optional and unlikely can be considered a unique identifier, since it's the serial number part that is being masked.
Indeed, the IMSI is of course not available on S1. I was probably thinking in terms of Iu. Definitely we *should* not dig into NAS or higher protocol layers. On the other hand, as you probably know we will sadly have to do that anyway soon (in s1gw) in order to get per-subscriber statistics.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032
Gerrit-Change-Number: 38206
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:32:56 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Attention is currently required from: fixeria.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38208?usp=email )
Change subject: library: as_pfcp_ignore(): log SeqNr of received PDUs
......................................................................
Patch Set 2:
(1 comment)
File library/PFCP_Emulation.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38208/comment/0df3329c_dd38… :
PS2, Line 398: log("Ignoring PFCP PDU (SeqNr := ", pdu.sequence_number, ")");
> You can always get very detailed logging by enabling `TTCN_MATCHING`. […]
Yeah yeah, but then we end up every week during weekly meeting looking at Junit output from jenkins with totally meaningless error reports.
This way at least you now quickly more or less which point in test it fails without needing to dig into pcaps, ttcn3 log files, etc.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38208?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I803ff46def4ae0182310bc01e753fe0c05112836
Gerrit-Change-Number: 38208
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:26:37 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: fixeria.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207?usp=email )
Change subject: library/PFCP_Emulation: a better PDU routing concept
......................................................................
Patch Set 2:
(1 comment)
File hnbgw/HNBGW_Tests.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207/comment/642b934f_f20e… :
PS2, Line 1967: f_PFCPEM_subscribe_seid(c_SEID0);
> (lines 1963..1967)?
yes.
> I don't expect to receive any PFCP PDUs at that moment at all.
Yes, that's the point. You don't expect, but then if IUT misbehaves and sends one, you won't see it in the test since it will be discarded by the emulation :)
Anyway, just mentioning since it can be quickly fixed, feel free to merge as is and modify later if you want.
It also saves a few lines in each test.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I25802471519fa297ad4cb2b056adaa6748b00af2
Gerrit-Change-Number: 38207
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:25:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: fixeria, laforge.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email )
Change subject: library: add generic Mutex API for parallel components
......................................................................
Patch Set 2:
(1 comment)
File library/Mutex.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/47ac92a8_0632… :
PS2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */
> But why would you want to lock the Mutex twice? Is this a normal scenario?
Sure reentrant mutexes are a thing :) This is usually only needed in more complex scenarios than what we aim here though.
This can be used for instance to implement semaphores, which eg. allow up to N-concurrent users where N can be defined.
> Can you explain your idea a bit more?
Yes, you have 1 port which has LOCK and UNLOCK operations.
alt {
[lock_count == 0] pt.get_call(LOCK) -> sender {
lock_sender = sender;
lock_count++;
pt.send_response(sender, LOCK);
}
[lock_count > 0] pt.get_call(LOCK) -> sender {
if (lock_count > 0) {
if(and sender != lock_sender) {
error();
} else {
/* Make the component wait until mutex is unlocked: */
lock_queue := lock_queue & { sender };
return;
}
lock_sender = sender;
lock_count++;
pt.send_response(sender, LOCK);
}
[lock_count == 0] pt.get_call(UNLOCK) -> sender {
errror();
}
[lock_count > 0] pt.get_call(UNLOCK) -> sender {
if (sender != lock_sender)
error();
lock_count--;
pt.send_response(sender, UNLOCK);
if (lock_count == 0) {
if (lengthof(lock_queue) > 0)
sender := lock_queue[0]
//TODO: HERE pop lock_queue[0] from queue
/* Tell first component waiting in the queue that it finally acquired the lock: */
pt.send_response(sender, LOCK);
lock_count++;
}
}
}
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032
Gerrit-Change-Number: 38206
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:21:59 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: pespin.
fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38208?usp=email )
Change subject: library: as_pfcp_ignore(): log SeqNr of received PDUs
......................................................................
Patch Set 2:
(1 comment)
File library/PFCP_Emulation.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38208/comment/32f6168a_1afa… :
PS2, Line 398: log("Ignoring PFCP PDU (SeqNr := ", pdu.sequence_number, ")");
> I'd say printing pfcp_expect *and* seq number may be more informative.
You can always get very detailed logging by enabling `TTCN_MATCHING`. Not only this will tell the matching outcome, but also point out to the exact parts of the template that did not match. This is much more powerful than just logging a template, IMO.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38208?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I803ff46def4ae0182310bc01e753fe0c05112836
Gerrit-Change-Number: 38208
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:20:05 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: pespin.
fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207?usp=email )
Change subject: library/PFCP_Emulation: a better PDU routing concept
......................................................................
Patch Set 2:
(1 comment)
File hnbgw/HNBGW_Tests.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207/comment/d848879d_2ced… :
PS2, Line 1967: f_PFCPEM_subscribe_seid(c_SEID0);
> Otherwise there may be race conditions in between the 2 where you lose messages.
I don't see how can we loose messages here, if you mean the session related PFCP PDUs specifically. I am subscribing for `SEID=0` before triggering the IUT to initiate session establishment (`BSSAP.send(tx)` down below) and unsubscribing right after the establishment request is received.
I guess you meant the moment after we called `f_PFCPEM_unsubscribe_bcast()`, but before `f_PFCPEM_subscribe_seid()` completes (lines 1963..1967)? If so, then I don't expect to receive any PFCP PDUs at that moment at all. The only message that we expect to be broadcasted here is the `PFCP_Assoc_Setup_Req` above, anything else should be subscribed by SEID explicitly.
I could have cheated a bit by calling `f_PFCPEM_subscribe_bcast()` at the top and calling `f_PFCPEM_unsubscribe_bcast()` at the very bottom. This would work just fine here, since this particular TC was written without parallelism in mind, and so far purely relied on the PFCPEM broadcasting all messages [to a single ConnHdlr in the list]. But I decided to do it properly here, since at some point we may want to scale this test scenario too.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38207?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I25802471519fa297ad4cb2b056adaa6748b00af2
Gerrit-Change-Number: 38207
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 14:16:39 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>