Hi Philipp,
I promised you to look at handover_test.c on the new fsm4 branch.
Looking at it now, I immediately ran into FSM events being dropped on the floor because it was in the wrong state. When I initially fix that, the test runs into the MGCP FSM not existing.
So at the end of the day, it is all related to the recently added FSMs and how they interact, and it seems to me that you are more familiar with those than me. In other words, I'm playing the ball back into your corner now:
Look at osmo-bsc branch neels/fsm4, here are the differences to pmaier/fsm4:
- right at the start, I add a patch to properly wrap abis_rsl_sendmsg(). That's just cosmetic, really. It was doing its job well, just I don't trust that implicit linking. It's at the start because I also submitted it to gerrit. 5eaaf6120e21 (I'd link to git.osmocom.org but after 10 minutes the branch still isn't synced there, strange.)
- I add the DMSC logging category to handover_test.c. That enables the FSM's error messages to be logged. This only makes sense as long as that FSM is actually logging on DMSC, which doesn't seem a good fit. 8128a49a6c6ce4ae
- I kick the gscon into the ACTIVE state when a conn is created. That might be taking a shortcut, since I'm not sure how e.g. the conn->user_plane.fi_bts should be populated... c2f90c36c445b2a38
So, e.g. when running './handover_test 1', my code state enabled the logging for them and uncovered the errors:
DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{INIT}: Event HO_START not permitted and then DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{WAIT_CC}: Event HO_START not permitted
These two are fixed, and now I'm stuck at:
DMSC handover_logic.c:333 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: Received Event HO_COMPL DMSC bsc_subscr_conn_fsm.c:710 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: state_chg to WAIT_MDCX_BTS_HO Assert failed fi ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_fsm.c:603
i.e. the handover_test.c is trying to indicate a 'Handover Complete' to the libbsc machinery by calling handover_test.c:send_ho_complete(), and it runs into a wall of the fake conn having conn->user_plane.fi_bts == NULL.
At this point I could start figuring out how to fake the fi_bts, but in fact I assume you're more proficient in that area, so please take over from here.
Thanks!
~N
Hello Neels,
I'm playing the ball back into your corner now:
I managed to fix the unit tests now. I wrapped the MGCP client FSM API functions mgcp_conn_delete() and mgcp_conn_delete(). The delete just does nothing and lets the GSCON FSM think that everything went fine. The modify just dispatches the GSCON_EV_MGW_MDCX_RESP_BTS signal back to the GSCON fsm and tricks it into thinking that all MGCP operations went well.
I hadd to do a little hacking because the reference pointer to the MGCP client FSM is unpopulated, but to me this looks ok. I documented the details of this in the code.
All unit tests now pass fine and I think we are finally there. I have put the current status on pmaier/fsm5. If everything is fine I would squash everything between 4b159cb6f39e7f0516b191575f4420819de3606e and 8f9d6124c5eb6ae11fea7dd5113c15775d8ecc99 into one commit and give it one last TTCN3 test run before I would submit it into review tomorrow.
best regards, Philipp