netfilter buglog - Aug 2013 - [Bug 838] New: ipset add foo syslog fails for bitmap:port

https://bugzilla.netfilter.org/show_bug.cgi?id=838

           Summary: ipset add foo syslog fails for bitmap:port
           Product: ipset
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: default
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: quentin at armitage.org.uk
   Estimated Hours: 0.0


Created attachment 409
  --> https://bugzilla.netfilter.org/attachment.cgi?id=409
Patch to allow UDP service names to be specified for bitmap:port

The following commands produce the error message below:
# ipset create foo bitmap:port range 500-999
# ipset add fred syslog
ipset v6.19: Syntax error: 'syslog' is invalid as number
Syntax error: cannot parse 'syslog' as a tcp port

The problem is that syslog is only defined as a UDP service in /etc/services,
and not as a TCP service.

I could think of two options for how to resolve this:
1. Try TCP first, and if that fails try UDP, but then presumably that would
mean also trying SCTP and UDPLITE for completeness.
2. Allow a protocol to be specified.

1. has disadvantages in that it doesn't appear to fit within the existing
code
structure, and also if at some time in the future a service name had different
port numbers for different protocols it wouldn't work.

2. seems to work but it is perhaps slightly strange to specify a protocol for a
bitmap:port which is protocol neutral; however I could see no other way to
allow it to work, since there needs to be some indication not to use the
default of TCP.

I have produced a patch along the lines of option 2 which appears to work, and
have added comments to the help and man page stating that specification of the
protocol does not effect the bitmap:port. It allows the protocol to be
specified for the create/add/del/test commands for a bitmap:port.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=838

Jozsef Kadlecsik <kadlec at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kadlec at netfilter.org

--- Comment #1 from Jozsef Kadlecsik <kadlec at netfilter.org> 2013-08-07
23:54:54 CEST ---
Your patch does not prevent entering other protocols besides TCP and UDP.
That's confusing. because the kernel part handles nothing else. I think a
new
function is required which calls ipset_parse_proto_port and then verifies the
protocol.

Also, I think it's unnecessary to add the IPSET_OPT_PROTO flag: this is a
userspace issue and there's no need to send the parsed protocol to the
kernel.

Otherwise solution 2 is OK for me.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=838

--- Comment #2 from Quentin Armitage <quentin at armitage.org.uk>
2013-08-07 23:59:51 CEST ---
Would you like me to rework the patch along the lines you indicate, or is that
something you would prefer to do?

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=838

Quentin Armitage <quentin at armitage.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #409 is|0                           |1
           obsolete|                            |

--- Comment #3 from Quentin Armitage <quentin at armitage.org.uk>
2013-08-09 13:42:16 CEST ---
Created attachment 411
  --> https://bugzilla.netfilter.org/attachment.cgi?id=411
Updated patch to allow UDP service names to be specified for bitmap:port

I have added the function ipset_parse_tcp_udp_port in line with your
suggestion. I don't think the function name I have chosen is a good choice
since there is already a function ipset_parse_tcpudp_port, and the new name is
just confusing with the other name. However I couldn't think of a better
name
that matched the existing function name scheme, so you may want to change the
name I have used.

Without IPSET_OPT_PROTO I am getting the following error messages:

# ipset add foo udp:syslog
ipset v6.19: There are not allowed options (26) but can't resolve them.
It's a
bug, please report the problem.

# ipset del foo udp:syslog
ipset v6.19: There are not allowed options (26) but option list is NULL.
It's a
bug, please report the problem.

# ipset test foo udp:syslog
ipset v6.19: There are not allowed options (26) but option list is NULL.
It's a
bug, please report the problem.

I have removed IPSET_OPT_PROTO from create though, since that isn't
required.

I couldn't see a way of getting it to work without IPSET_OPT_PROTO being
specified, so in order to stop the protocol option being passed to the kernel,
I have added:
ipset_data_flags_unset(data, IPSET_FLAG(IPSET_OPT_PROTO));
in the new function ipset_parse_tcp_udp_port.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=838

Jozsef Kadlecsik <kadlec at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Jozsef Kadlecsik <kadlec at netfilter.org> 2013-08-17
21:35:03 CEST ---
I have committed your patch with minimal changes, thanks.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.