On Wednesday 2011-05-18 14:49, Lutz Jaenicke wrote:
>
>this modification lead to a subtle failure I don't know how to cure yet.
>
>> + {.name = "dport", .id = O_DEST_PORT, .type = XTTYPE_PORTRC_NE,
>> + .flags = XTOPT_INVERT | XTOPT_PUT, XTOPT_POINTER(s, dpts)},
>> + XTOPT_TABLEEND,
>> };
>
>The port parsing now performed indirectly via xtables_getportbyname() and
>then hence getaddrinfo().
>At least for uClibc (did not test glibc), getaddrinfo() will complain
>when a port is specified by number but no socket type of address family
>is set:
>...
> /*
> * Can't specify a numerical socket unless a protocol
> * family was given.
> */
> if (hints->ai_socktype == 0 && hints->ai_protocol == 0)
> return EAI_SERVICE;
>...
That's one of these totally useless comments. I know from the
condition that it disallows them, but it fails to say _why_, and what
makes numerical specs different from name-based ones - in particular
they should ask themselves, why should getaddrinfo special-case it
when getportbyfoo does not?
>The straight forward solution would be to add a respective ai_protocol
>information (we actually know that it is IPPROTO_UDP). I am currently
>however not deep enough into the new parser structure to know where to
>add this information to the function calls and or data structures.
The approach would be to encode the family in xt_option_entry somehow.
Possilibites are a new XTTYPE_UDPPORT (suboptimal because all protos
would need to be specified), or seemingly better, a flag that would
interpret the .max field as a family instead (similar to how
XTTYPE_TOSMASK uses it). Me ponders.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
