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_2ced1... : 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.