Bug 1375215 - ss incorrectly represents cwnd
Summary: ss incorrectly represents cwnd
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iproute
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Davide Caratti
QA Contact: Jaroslav Aster
Ioanna Gkioka
Depends On:
Blocks: 1393481
TreeView+ depends on / blocked
Reported: 2016-09-12 13:37 UTC by suresh kumar
Modified: 2020-09-10 09:47 UTC (History)
9 users (show)

Fixed In Version: iproute-3.10.0-75.el7
Doc Type: Bug Fix
Doc Text:
*ss* now displays correctly cwnd Previously, the *ss* utility displayed Transmission Control Protocol congestion window (TCP cwnd) values from the kernel, performing a cast from unsigned to signed 32-bit integer. As a consequence, some values can overflow and be interpreted as a negative value. With this update, the *ss* code has been fixed, and the utility no longer displays negative cwnd values.
Clone Of:
Last Closed: 2017-08-01 21:32:13 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2171 0 normal SHIPPED_LIVE iproute bug fix and enhancement update 2017-08-01 18:40:13 UTC

Description suresh kumar 2016-09-12 13:37:40 UTC
Description of problem:
tcp->snd_cwd is a u32, but ss treats it like a signed int.  This results in negative bandwidth calculations.


202:            is_cwnd_limited:1;/* forward progress limited by snd_cwnd? */
232:    u32     snd_cwnd;       /* Sending congestion window            */ 
233:    u32     snd_cwnd_cnt;   /* Linear increase counter              */
234:    u32     snd_cwnd_clamp; /* Do not allow snd_cwnd to grow above this */
235:    u32     snd_cwnd_used;
236:    u32     snd_cwnd_stamp;

>>> Probably need to change this %d to a %u, and deal with the casting to double below. <<<<


1270         if (s.cwnd != 2)
1271             printf(" cwnd:%d", s.cwnd);

1416         if (info->tcpi_snd_cwnd != 2)
1417             printf(" cwnd:%d", info->tcpi_snd_cwnd);

1431         if (rtt > 0 && info->tcpi_snd_mss && info->tcpi_snd_cwnd) {
1432             printf(" send %sbps",
1433                    sprint_bw(b1, (double) info->tcpi_snd_cwnd *
1434                      (double) info->tcpi_snd_mss * 8000000.
1435                      / rtt));

Sample data (DCTCP):

[root@tesla02 ~]# /usr/lpp/mmfs/bin/mmdsh -F host.list 'ss -e -t -o -i | grep -A 1 gpfs | grep -A 1 | grep alpha' | grep -v tesla02 | sort | column -t
tesla11:  ts  sack  ecn  ecnseen  dctcp  wscale:1,1  rto:11  rtt:0.144/0.047  ato:40  mss:1448  cwnd:1187830594  dctcp:(ce_state:0,alpha:15,ab_ecn:0,ab_tot:0)      send  95554372228.4Mbps   lastrcv:2    unacked:10          retrans:0/21231546  reordering:40       rcv_rtt:11.375    rcv_space:262236
tesla12:  ts  sack  ecn  ecnseen  dctcp  wscale:1,1  rto:11  rtt:0.109/0.028  ato:40  mss:1448  cwnd:-679123792  dctcp:(ce_state:0,alpha:15,ab_ecn:0,ab_tot:0)      send  384274597709.5Mbps  lastrcv:1    unacked:13          retrans:0/11495136  sacked:2            reordering:38     rcv_rtt:12.375    rcv_space:262236
tesla13:  ts  sack  ecn  ecnseen  dctcp  wscale:1,1  rto:11  rtt:0.095/0.035  ato:40  mss:1448  cwnd:28          dctcp:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 3 Davide Caratti 2016-09-22 08:51:34 UTC
Maybe Hangbin already had this in his queue http://marc.info/?l=linux-netdev&m=147453365410663&w=2

Comment 10 errata-xmlrpc 2017-08-01 21:32:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.