Bug 435110 - fix up remaining sctp MIB problems
Summary: fix up remaining sctp MIB problems
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 5.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Martin Jenner
Depends On:
Blocks: 368731
TreeView+ depends on / blocked
Reported: 2008-02-27 12:52 UTC by Neil Horman
Modified: 2010-03-14 21:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 20:17:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
additionl patch to fix header/data argreement (1.40 KB, patch)
2008-03-13 20:30 UTC, Neil Horman
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:0225 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.3 kernel security and bug fix update 2009-01-20 16:06:24 UTC

Description Neil Horman 2008-02-27 12:52:29 UTC
Description of problem:

the sctp assoc array appears to be missinga few remaining pieces of data.  This
is to track them and fix them up
Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Neil Horman 2008-02-27 14:35:48 UTC
> Neil Horman wrote:
> >On Mon, Feb 25, 2008 at 04:16:15PM +0100, Jan Safranek wrote:
> >>I'm testing 2.6.18-81.el5.bz277111 kernel and I am a bit confused,
> >>mainly because missing documentation. At first, the header and content
> >>of /proc/net/sctp/assocs does not match. Header shows, that there are
> >>some parameters after remote addresses (HBINT INS OUTS MAXRT T1X T2X
> >>RTXC), but in the body I can see no parameter after last remote address.
> >>I can only guess the order of values of these parameters in the file body.
> >>
> >Thats odd, I tested this and was able to see all the appropriate values in
> >there.  Are you using an official build, or your own kernel?
> My own, created from cvs co -r private-nhorman-bz277111-branch && make
> test-srpm && brew build --scratch. With one SCTP association (over
> loopback), cat /proc/net/sctp/assoc shows:
> ffff810003026000 ffff810003662080 0   7   4  777     1    63488        0
>       0  9287 54979 12345    30000    10    10   10    0    0        0
>  * <-> *
> ffff81000303c000 ffff810003663a00 0   10  4  3861    2    63488        0
>       0  9200 12345 54979    30000    10    10   10    0    0        0
>  * <-> *
> -> header does not match the content.
Crap, I think I see the problem.  I have a ton of other stuff to do at the
moment, but I'll get to fixing this in short order.  Basically the new values
are in there, they're just in there before the LADDRS <-> RADDRS stuff.  The
order is off, but the content is there.  You should be able to make that switch
in net-snmmp until I get to fixing it.

> >>>sctpAssocRemAddrRtx is the same as  sctpAssocRtxChunks
> >>I thought that sctp chunks are sent only to one remote address and
> >>resent to another one only if the previous addr. times out. -> each
> >>RemAddr can have different value of this counter. Or do we always send
> >>all chunks to all remote addresses? And isn't it possible that the
> >>remote host can add/remove addresses dynamically?
> >>
> >
> >Hmm, you're right about that. For some reason it didn't register with me
> >that
> >this is a per-remote-address table and the numbers wouldn't be in
> >aggregate.
> Are you going to fix it? I would be very interested in /proc file format
> then (implementation can wait at the moment, RHEL 5.3 is far away).
I'd like to, but I don't have it on my schedule yet.  Like you say, 5.3 is still
a bit distant

Comment 2 Neil Horman 2008-03-13 20:30:56 UTC
Created attachment 297982 [details]
additionl patch to fix header/data argreement

Hey, can you test out this patch please?  It should fix the data in
/proc/net/sctp/assoc so the layout agrees with the header.  Thanks!

Comment 3 Neil Horman 2008-03-13 20:32:45 UTC
oh, if it wasnt clear previously, my patch in comment #2 should apply on top of
my previous patch, not instead of :)

Comment 4 Jan Safranek 2008-03-17 10:15:31 UTC
the header now matches file body, thanks. It would be nice if there would be
some separator between last remote address and HBINT value (just to prevent
possible parse bugs when parsing the line from backward...). But that's just a
"Christmas wish", not a requirement.

Still, I need these values separately for each remote address (* denotes missing
- assoc. id

- sctpAssocRemAddrHBActive (boolean; heartbeat check is activated
or not on this remote addr.), it's always true in RHEL 5.3 and upstream kernel.

* sctpAssocRemAddrRTO (integer, current T3-rtx timer) - probably can be computed
 from /proc/sys/net/sctp/rto_initial and sctpAssocRemAddrRtx, but it would be
nice to have it separately, just in case the RTO computation changes in kernel.

*? sctpAssocRemAddrMaxPathRtx (integer, max. number of DATA chunks
retransmissions allowed to a remote IP address before it is considered inactive)
- ABI breaker for RHEL 5.3, value of asociation's MAXRT can be used instead.

* sctpAssocRemAddrRtx (integer, nr. of DATA chunks retransmissions to this
specific IP address)

- sctpAssocRemAddrStartTime - can be computed by net-snmp with some difficulties
(ugly lookups in tables indexed by ip-address etc... but that's my problem).

Comment 5 Neil Horman 2008-03-17 11:15:03 UTC
yes, I'm aware of those and am getting to them.  Thanks!

Comment 6 Neil Horman 2008-03-17 14:25:06 UTC
pushed the formattting fix upstream.  I'll post all the

Comment 7 Neil Horman 2008-03-17 14:25:40 UTC
sorry, finger check.  Meant to say I'll post this and the rest of the fix
internally during the 5.3 devel cycle

Comment 8 Neil Horman 2008-04-30 14:46:30 UTC
I've sent a patch upstream for review.

Comment 9 Neil Horman 2008-05-12 01:42:40 UTC
patch has been accepted to vlad, and DaveM's tree, I'll backport shortly.

Comment 10 RHEL Product and Program Management 2008-06-06 16:05:02 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 12 Jan Safranek 2008-07-01 14:16:41 UTC
Looking at the kernel-2_6_18-92_el5_bz435110 branch in CVS, the data for
sctpAssocRemAddrTable (in /proc/net/sctp/remaddr) look OK. I only don't
understand the START column - it's always zero, even if the association is
established state. Anyway, as usual, I can poll the remaddr periodically and
reconstruct the start time manually in net-snmp (with ~15-30 sec precision).

What troubles me more, some values disappeared from /proc/net/sctp/assocs. There
is list of values I need. I think the previous version of kernel *had* the
values there... where did they go?

sctpAssocHeartBeatInterval - The current heartbeat interval (I am not sure, is
it HBKT column?)

sctpAssocInStreams - nr. of Inbound Streams according to the negotiation at
association start up. 
sctpAssocOutStreams - nr. of Outbound Streams according to the negotiation at
association start up. 

sctpAssocMaxRetr - The maximum number of data retransmissions in the association

sctpAssocT1expireds - This object reflects the number of times the T1 timer
expires without having received the acknowledgement.

sctpAssocT2expireds - Every DATA chunk that was included in the SCTP packet
that triggered the T3-rtx timer must be added to the value of
this counter (this can be probably reconstructed from /proc/net/sctp/remaddr by
counting values in REM_ADDR_RTX).

Comment 13 Neil Horman 2008-07-10 17:11:00 UTC
The START column is always zero because we don't record start times yet, but we
wanted a placeholer there so we didn't have to change the file format later.

As for the remainging values, they're still there from what I can see, is
net-snmp not parsing the file properly?

Comment 14 Jan Safranek 2008-07-15 12:29:10 UTC
I've checked out today your kernel-2_6_18-92_el5_bz435110 branch and if I open
one associations, each end with two addresses, I can see in /proc/net/sctp/:

ffff810003fc6000 ffff810003f1ba00 0   10  4  2314    2   116488        0       0
 9716 12345 12346  * <-> * 
ffff810003038000 ffff810003f1a080 0   7   4  2569    1    63488   141089       0
 9729 12346 12345  * <-> * 

ffff81000767cc00 ffff810003f1ba00 0   10  57   12345     0  9716 

ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START  2 1 3000 5 0 0  2 1 1000 5 0 0  1 1 1000 5 0 0  1 1 1000 5 0 0

And I cannot see values I want in comment #12. You can check the kernel at

Comment 15 Neil Horman 2008-07-15 12:59:38 UTC
Dangit!  The patch didn't include the association updates.  I'll  open a bug for
it and pull them back in.  For now just grab the patch from upstream and build
your own kernel.

Comment 16 Neil Horman 2008-07-15 15:05:12 UTC
scratch my last comment, I did the stats you were looking for as part of bz
277111.  Just looks like Don hasn't incorporated this into the kernel yet.  You
can get the patch from that bug and include it manually.

Comment 17 Don Zickus 2008-07-23 18:54:48 UTC
in kernel-2.6.18-99.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 19 Ryan Lerch 2008-11-06 06:38:36 UTC
This bug has been marked for inclusion in the Red Hat Enterprise Linux 5.3
Release Notes.

To aid in the development of relevant and accurate release notes, please fill
out the "Release Notes" field above with the following 4 pieces of information:

Cause:   What actions or circumstances cause this bug to present.

Consequence:  What happens when the bug presents.

Fix:   What was done to fix the bug.

Result:  What now happens when the actions or circumstances above occur. (NB:
this is not the same as 'the bug doesn't present anymore')

Comment 23 errata-xmlrpc 2009-01-20 20:17:43 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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