lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 26 Nov 2018 20:02:54 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     "Nambiar, Amritha" <amritha.nambiar@...el.com>
Cc:     David Ahern <dsahern@...il.com>, netdev@...r.kernel.org,
        jakub.kicinski@...ronome.com, sridhar.samudrala@...el.com,
        jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us
Subject: Re: [iproute2-next PATCH v4] tc: flower: Classify packets based
 port ranges

On Mon, 26 Nov 2018 17:56:10 -0800
"Nambiar, Amritha" <amritha.nambiar@...el.com> wrote:

> On 11/26/2018 4:43 PM, David Ahern wrote:
> > On 11/26/18 5:23 PM, Nambiar, Amritha wrote:  
> >>> Can tc flower use something similar to ip ru with single port or port
> >>> range handled like this?
> >>>
> >>>     },{
> >>>         "priority": 32764,
> >>>         "src": "172.16.1.0",
> >>>         "srclen": 24,
> >>>         "ipproto": "tcp",
> >>>         "sport": 1100,
> >>>         "table": "main"
> >>>     },{
> >>>         "priority": 32765,
> >>>         "src": "172.16.1.0",
> >>>         "srclen": 24,
> >>>         "ipproto": "tcp",
> >>>         "sport_start": 1000,
> >>>         "sport_end": 1010,
> >>>         "table": "main"
> >>>     },{
> >>>
> >>>  
> >>
> >> Does it have to be separate fields "sport_start" and "sport_end"?
> >> Removing the space and 'range' keyword will make the output format
> >> consistent with the input format and print as "sport <number>" for
> >> single port and "sport <start>-<end>" for range.
> >> Example:
> >>
> >> ... flower ip_proto tcp src_port 12 skip_hw action will print as:
> >>   ip_proto tcp
> >>   src_port 12
> >>   skip_hw
> >>   not_in_hw
> >>         action
> >>
> >> ... flower ip_proto tcp src_port 100-200 skip_hw action :
> >>   ip_proto tcp
> >>   src_port 100-200
> >>   skip_hw
> >>   not_in_hw
> >>         action  
> > 
> > non-json output needs to match what the user gives on the command line.
> > 
> > My comment was about consistency with json output when possible. I am
> > not a json expert by any means. Other commands have a single key value
> > pair, so I suspect the json here needs to follow suit (ie., not
> > "src_port": "1000-1010" but separate start and end entries).
> >   
> I'm not quite familiar with json. Maybe, Jiri can give feedback here.

JSON support strings and numeric and objects.
The more common JSON way of expressing this would be either as object for sport

{
       "priority": 32765,
       "src": "172.16.1.0",
        "srclen": 24,
       "ipproto": "tcp",
	"sport" : {
		"start" : 1000,
		"end" : 1010
	},
	"table: "main"
}

or as an array:
{
       "priority": 32765,
       "src": "172.16.1.0",
        "srclen": 24,
       "ipproto": "tcp",
	"sport" : [ 1000, 1010 ],
	"table: "main"
}

My point is don't build some semantic meaning directly into the tag part of the syntax.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ