Bug #5528
closedosmo-pcap-client test failure in TC_multi_capture
100%
Description
The last two jenkins executions of TC_multi_capture failed:
https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-pcap-client-test/356/console
----- OPCAP_CLIENT_Tests.TC_multi_capture ------ Tue Apr 12 11:40:59 UTC 2022 NOTE: unable to use dumpcap due to missing capabilities or suid bit Waiting for packet dumper to start... 0 MTC@2e6e239d24fe: External command `../ttcn3-tcpdump-start.sh OPCAP_CLIENT_Tests.TC_multi_capture' was executed successfully (exit status: 0). MTC@2e6e239d24fe: Test case TC_multi_capture started. MTC@2e6e239d24fe: Waiting for client-0 connection... MTC@2e6e239d24fe: Connection from "172.18.31.20":34413 MTC@2e6e239d24fe: Warning: Re-starting timer g_Tguard, which is already active (running or expired). MTC@2e6e239d24fe: Waiting for client-1 connection... MTC@2e6e239d24fe: Connection from "172.18.31.20":43313 MTC@2e6e239d24fe: setverdict(pass): none -> pass MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(pass): pass -> pass, component reason not changed MTC@2e6e239d24fe: setverdict(fail): pass -> fail reason: "global guard timeout", new component reason: "global guard timeout" MTC@2e6e239d24fe: Setting final verdict of the test case. MTC@2e6e239d24fe: Local verdict of MTC: fail reason: "global guard timeout" MTC@2e6e239d24fe: No PTCs were created. MTC@2e6e239d24fe: Test case TC_multi_capture finished. Verdict: fail reason: global guard timeout MTC@2e6e239d24fe: Starting external command `../ttcn3-tcpdump-stop.sh OPCAP_CLIENT_Tests.TC_multi_capture fail'. Tue Apr 12 11:41:31 UTC 2022 -e ------ OPCAP_CLIENT_Tests.TC_multi_capture fail ------
I cannot reproduce this locally, even in multiple test executions.
Files
Updated by laforge about 2 years ago
We have a global 30s guard timer and we are sending 10 packets + expecting them to be captured. There's no sleep in between, so it should complete relativel fast, basically only bounded by the time it takes for the messges to arrive.
In the pcap file we can see the test runs for ~30s, and there is 7 packets in the first ~10s, and for all of them we see- the generated IP packet to be sniffed
- the client sending it to port 5000
- the client sending it to port 5001
So from the pcap file OPCAP_CLIENT_Tests.TC_multi_capture.pcap.gz, things look generally ok.
Updated by laforge about 2 years ago
ok, so after some debugging I found the culprit: We're trying to send a 0-byte long UDP packet as test traffic, and the kernel refuses that.
The reason for this is that we use f_rnd_octstring(f_rnd_int(1400)) whre f_rnd_int() of course can return 0, making f_rnd_octstring() return O''.
Updated by laforge about 2 years ago
- % Done changed from 0 to 90
should be fixed in https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27763
Updated by laforge about 2 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Applied in changeset core-testing-infra:osmo-ttcn3-hacks|67881aef23a3567aa5cb70364b388041011efbc7.
