Bug #6253
closedttcn3-hnbgw-test crashes on TC_second_rab_assignment
100%
Description
Since https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34973 was merged, osmo-hnbgw crashes during ttcn3-hnbgw-test.
This patch fixes it:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/34974
I suggest we merge this to master, and tag a new version from master (so the fix is in latest as well, and latest doesn't crash in the testsuite).
Other commits on master are about removing asserts that got hit due to wrong assumptions, increasing a timer default value and a doc fix.
Related issues
Updated by neels 6 months ago
I think we are moving too fast in rolling a backport release for this issue.
The situation is this:- customer reports pcap with two RAB Assignments -- it's the first time we see this anywhere.
- to understand the report, i wrote a ttcn3 test to model that situation.
- the particular customer is apt with compiling code, so i provide a patch for testing the particular situation.
- ever since, the customer has no more duplicated RAB Assignments, suddenly everything is as it usually was, so we have not seen a report of the patch working as intended.
- but now, these two patches are on gerrit and were merged -- maybe a bit quick but ok, shouldn't be harmful.
- because our 'latest' test suite is not independent from 'master', the new test obviously fails 'latest'.
I think this causal chain is not one that warrants a release, it feels too quick. I think we should just wait a little for the patch to settle, because whatever we release will have to be maintained "forever".
Personally, I would just accept that 'latest' fails on the new test.
If there are sentiments against that, maybe we should then disable the new test in the 'latest' test suite?
But whatever it is, let's try to stay low on the effort spent on this rather small corner case.
Does that sound acceptable?
Updated by laforge 5 months ago
On Mon, Nov 13, 2023 at 10:43:45PM +0000, neels wrote:
- ever since, the customer has no more duplicated RAB Assignments, suddenly everything is as it usually was, so we have not seen a report of the patch working as intended.
Additional RAB assignment can very well relate to very specific usage patterns (either in terms of whihc
specific UE, or which specific services are used by the user). Could be related to multiple voice calls active concurrently, or video calls, or whatever. So it's not unlikely that you'd see those only in very specific situations.
Personally, I would just accept that 'latest' fails on the new test.
fine with me until we [decide to] backport.
Updated by osmith 5 months ago
- Assignee changed from neels to osmith
- % Done changed from 0 to 90
Personally, I would just accept that 'latest' fails on the new test.
The problem is, that not only the test fails, but osmo-hnbgw crashes and then all following tests fail as well. It is towards the end of the list of tests, but all tests run again with pfcp, and all of them are failing.
If there are sentiments against that, maybe we should then disable the new test in the 'latest' test suite?
This patch disables the test for latest:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/35012
EDIT: see the graph here: https://jenkins.osmocom.org/jenkins/job/ttcn3-hnbgw-test-latest/
Updated by neels 5 months ago
Additional RAB assignment can very well relate to very specific usage patterns (either in terms of whihc
(In this particular case, it was modifying an existing RAB ID rather than adding a new RAB ID,
only listing SDU subflows and no transportLayerInformation (ip:port), so I guessed it would seen regularly)
