If I send some data to the server with
# sctp_darn -H localhost -P 2600 -h localhost -p 2500 -s
sctp_darn ready to send...
localhost:2600-localhost:2500> text

and now try to show listening sctp sockets with 'netstat -lS' I can see it there:
Proto Recv-Q Send-Q Local Address              Foreign Address            State
sctp       0      0 localhost.localdomain:2500 localhost.localdomain:2600 LISTEN

Only the sockets with no 'Foreign Address' are not shown with '-l'.
Not sure how to explain it, maybe sctp has more LISTEN "states" ?

yes, I noticed that established connections are listed in more places, I have no idea why.

but then `-a` is able to list them, so it doesn't look like they are completely hidden, maybe some kernel people could explain that

Well, the expected result
sctp                0.0.0.0:2500                                    LISTEN
is displayed when netstat is run with -a.
In the code, it is managed this way:

static int sctp_info(void)
{
    if(flag_all)
	sctp_info_eps();
    return sctp_info_assocs();
}

So if you don't provide -a, only associations are listed (they come from /proc/net/sctp/assocs file), but when you provide it, also endpoints are listed (coming from /proc/net/sctp/eps file).
It seems rather like intended behavior for me so I'd consider it NOTABUG.

But please note, due to fixing https://bugzilla.redhat.com/show_bug.cgi?id=1063906 sctp will NOT be listed when running 'netstat -nl -A inet,inet6', so you must specify -S to list them. With 'netstat -nl' they should be still listed.

(In reply to jkoncick from comment #3)
> Well, the expected result
> sctp                0.0.0.0:2500                                    LISTEN
> is displayed when netstat is run with -a.
> In the code, it is managed this way:
> 
> static int sctp_info(void)
> {
>     if(flag_all)
> 	sctp_info_eps();
>     return sctp_info_assocs();
> }
> 
> So if you don't provide -a, only associations are listed (they come from
> /proc/net/sctp/assocs file), but when you provide it, also endpoints are
> listed (coming from /proc/net/sctp/eps file).
> It seems rather like intended behavior for me so I'd consider it NOTABUG.

That's rather counter intuitive. I'd assume that any socket that is able to serve connections from the net is "open" or LISTENING. /proc/net/sctp/* looks more like an implementation detail.
 
> But please note, due to fixing
> https://bugzilla.redhat.com/show_bug.cgi?id=1063906 sctp will NOT be listed
> when running 'netstat -nl -A inet,inet6', so you must specify -S to list
> them. With 'netstat -nl' they should be still listed.

I don't see -S documented anywhere, not in --help or in man page.

Also, since sctp uses ipv4 or ipv6 as the transport, it is reasonable to expect that its sockets will be printed when using -A inet,inet6.

The point is, I want to be able to print all listening network sockets without grepping netstat output. If there is another way to exclude UNIX sockets using netstat options I'm all open for suggestions.

(In reply to Hubert Kario from comment #4)
> I don't see -S documented anywhere, not in --help or in man page.

bug #1064756

(In reply to Hubert Kario from comment #4)
> (In reply to jkoncick from comment #3)
> > But please note, due to fixing
> > bug #1063906 sctp will NOT be listed
> > when running 'netstat -nl -A inet,inet6', so you must specify -S to list
> > them. With 'netstat -nl' they should be still listed.
> 
> Also, since sctp uses ipv4 or ipv6 as the transport, it is reasonable to
> expect that its sockets will be printed when using -A inet,inet6.

Jaromir, do you think it'd be possible to fix bug #1063906 in a way that
'netstat -n -A inet' would still try to list sctp sockets and wouldn't fail if there's no sctp module loaded ?
It should however still fail when user explicitly requests -S/--sctp.

Created attachment 863188 [details]
Patch - Do not abort and print 'no support for protocol...' if user does not explicitly specifies it

> Jaromir, do you think it'd be possible to fix bug #1063906 in a way that
> 'netstat -n -A inet' would still try to list sctp sockets and wouldn't fail if > there's no sctp module loaded ?
> It should however still fail when user explicitly requests -S/--sctp.
Here I made a patch to fix this. Now, when user does not specify any protocol (tcp, udp, sctp...) and netstat uses default set of them, it does not abort and print error message when some of the default protocols is not supported.

Hubert, if you have no more notes, I'm closing this as NOTABUG. The use of -a parameter seems rather intentional and better not to change it. On the other hand, you're right with "any socket that is able to serve connections from the net is "open" or LISTENING". You might ask upstream about this.

To me it looks more like an oversight, both -a and -l are special cases.
Anyway, shouldn't it be rather cond nak: upstream than NOTABUG?

Ok, let's keep it condnack and opened. Moving to 7.1, as it is too late for 7.0.

Hmmm... -l should list listening sockets. Not familiar mit SCTP, can you consider an "endpoint" a listening socket?

Yes, I would.

If an endpoint exists and the firewall accepts packets you can make a connection and exchange data with the server. That to me is a definition of a "listening" socket.

Ok, then this can be solved by simply printing endpoints without need of -a parameter.
In net-tools-sctp-statistics.patch I found this change:

From:

static int sctp_info(void) {
  int  res;
  res = sctp_info_epts();
  if(res)  return  res;
  return  sctp_info_assocs();
}

To:

static int sctp_info(void)
{
    if(flag_all)
	sctp_info_eps();
    return sctp_info_assocs();
}

This change was introduced with bug 826676 fix.
In upstream version it actually prints the endpoints even without -a option.
So I suggest reverting the sctp_info function to be upstream-like.

Fixed it in Fedora rawhide: net-tools-2.0-0.22.20131119git.fc21
The change can be pushed into rhel-7 too.

The fix mentioned in comment #14:
http://pkgs.fedoraproject.org/cgit/net-tools.git/commit/?h=f21&id=0ccb3b8f4e8bdc13f5b21fa4465a7dfe335e255a

current upstream version of the function:
static int sctp_info(void)
{
  int res = sctp_info_eps();
  return res ? res : sctp_info_assocs();
}

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.

https://access.redhat.com/errata/RHBA-2017:1873