netdev - Re: [iproute2-next PATCH v4] tc: flower: Classify packets based port ranges

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] [day] [month] [year] [list]

Message-ID: <730a79de-1b43-9ba8-4b9b-df26b4875651@intel.com>
Date:   Tue, 27 Nov 2018 13:47:55 -0800
From:   "Nambiar, Amritha" <amritha.nambiar@...el.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
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 11/26/2018 8:02 PM, Stephen Hemminger wrote:
> 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.
> 

Okay. Will fix this in v6. I'll keep the default (non-json) output
format similar to the input format, and for the json output, I'll use
the object for sport as in the first example above.