All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadim Kochan <vadim4j@gmail.com>
To: Phil Sutter <phil@nwl.cc>, Vadim Kochan <vadim4j@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	netdev@vger.kernel.org
Subject: Re: ss filter problem
Date: Tue, 29 Mar 2016 23:05:19 +0300	[thread overview]
Message-ID: <20160329200519.GA15515@angus-think.lan> (raw)
In-Reply-To: <20160329193242.GA28502@orbyte.nwl.cc>

Hi Phil,

On Tue, Mar 29, 2016 at 09:32:42PM +0200, Phil Sutter wrote:
> Hi,
> 
> I am trying to fix a bug in ss filter code, but feel quite lost right
> now. The issue is this:
> 
> | ss -nl -f inet '( sport = :22 )'
> 
> prints not only listening sockets (as requested by -l flag), but
> established ones as well (reproduce by opening ssh connection to
> 127.0.0.1 before calling above).
> 
> In contrast, the following both don't show the established sockets:
> 
> | ss -nl '( sport = :22 )'
> | ss -nl -f inet
> 
> My investigation led me to see that current_filter.states is altered
> after ssfilter_parse() returns, and using gdb with a watchpoint I was
> able to identify parse_hostcond() to be the bad guy: In line 1560, it
> calls filter_af_set() after checking for fam != AF_UNSPEC (which is the
> case, since fam = preferred_family and the latter is changed to AF_INET
> when parsing '-f inet' parameter).

Yes, after removing of fam != AF_UNSPEC body - it works, because
it does not overwrite specified states (-l) from command line, but I
can't say what it may affect else, I will try to investigate it better.

> 
> This whole jumping back and forth confuses me quite effectively. Since
> you did some fixes in the past already, are you possibly able to point
> out where/how this tiny mess has to be fixed?
> 
> I guess in an ideal world we would translate '-l' to 'state listen', '-f
> inet' to 'src inet:*' and pass everything ANDed together to
> ssfilter_parse(). Or maybe that would make things even worse. ;)
> 
> Cheers, Phil

I thought I fixed & tested well ss filter, but seems it would be good to
have good automation testing.

Regards,
Vadim Kochan

  reply	other threads:[~2016-03-29 20:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 19:32 ss filter problem Phil Sutter
2016-03-29 20:05 ` Vadim Kochan [this message]
2016-04-13 20:07 ` [iproute PATCH 0/2] Minor ss filter fix and review Phil Sutter
2016-04-13 20:07   ` [iproute PATCH 1/2] ss: Drop silly assignment Phil Sutter
2016-04-13 20:07   ` [iproute PATCH 2/2] ss: Fix accidental state filter override Phil Sutter
2016-04-19 14:57   ` [iproute PATCH 0/2] Minor ss filter fix and review Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160329200519.GA15515@angus-think.lan \
    --to=vadim4j@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=phil@nwl.cc \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.