SCTP interval reporting prints an uninitialized retransmit value
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c
- Domain
- networking
Research direction
Reproduce the issue with iperf3 -s and iperf3 -c localhost --sctp -V -t 5, then inspect iperf_stats_callback and the SCTP reporting branch where temp.interval_retrans is left unset. Determine the intended SCTP retransmit and header values, and verify that interval output no longer contains uninitialized data while preserving correct reporting.
Written by the indexing model from the issue text.
Description
Hi, when I run iperf3 -s in one window and iperf3 -c localhost --sctp -V -t 5 in another, I get the following:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.08 GBytes 9.24 Gbits/sec 140615631915280 96.1 KBytes
[ 5] 1.00-2.00 sec 1.09 GBytes 9.32 Gbits/sec 140615631915280 96.1 KBytes
[ 5] 2.00-3.00 sec 1.06 GBytes 9.10 Gbits/sec 140615631915280 96.1 KBytes
[ 5] 3.00-4.00 sec 1.13 GBytes 9.70 Gbits/sec 140615631915280 96.1 KBytes
[ 5] 4.00-5.00 sec 1.17 GBytes 10.1 Gbits/sec 0 104 KBytes
The 140615631915280 is clearly incorrect here. This apparently happens because temp.interval_retrans (in iperf_stats_callback) is not initialized, and the sctp branch never sets it.
Zeroing temp.interval_retrans fixes the issue*, though I'd consider something like memset(&temp, 0, sizeof(temp)) to make it more robust.
*) It fixes the uninitialized memory, but it will always report 0, which is not exactly correct. Also, the table header seems to be missing some values? I did not look into that further, though.
- Dominant language
- C
- Stars
- 8.9k
- Forks
- 1.5k
- Avg merge
- 5d 11h
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from esnet/iperf
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
esnet/iperf#2101 · 2 comments ·
Maintainers usually reply within 2 days
-
Cannot use more than 128 parallel streamsPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
esnet/iperf#2079 · 3 comments ·
Maintainers usually reply within 2 days
-
Build failure on platforms without `<stdatomic.h>` due to use of non-standard `u_int64_t`Possibly taken @lgoettgens claimed this 114 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
esnet/iperf#2060 · 1 comment ·
Maintainers usually reply within 2 days
-
JSON output (-J) emits two top-level "error" keys on server-relayed errorsPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
esnet/iperf#2051 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
esnet/iperf#2076 · 4 comments ·
Maintainers usually reply within 2 days
Similar issues
-
XPM values line with more than one space between numbers raises ValueErrorPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
python-pillow/Pillow#10429 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 9 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
containers/bubblewrap#826 ·
Maintainers usually reply within 1 day