accel-ppp.git/accel-pppd/iprange.c, branch stable

iprange: rework range parsing using u_parse_*() functions

2018-12-08T04:51:37+00:00

Now that we have primitives for parsing IPv4 ranges, let's use them to simplify parse_iprange(). Try u_parse_ip4cidr() first. In case of failure, try u_parse_ip4range(). If any of them succeeds, verify that there aren't spurious data following the range definition. If everything is valid, either load the range or disable the module (if the range is 0.0.0.0/0). The diff is a bit ugly, but the implementation should be much clearer. Signed-off-by: Guillaume Nault

utils: rework u_parse_ip4addr()

2018-12-08T04:51:34+00:00

Redefine u_parse_ip4addr() to match the behaviour of other u_parse_*() functions: * Drop the err_msg parameter. * Return the number of bytes parsed instead of an error number. * Remove support for fancy IPv4 address notations. There is currently only one user of u_parse_ip4addr() (in iprange.c). Dropping the fancy IPv4 address representations is probably not going to harm anyone (quite the opposite as many users don't realise that leading 0 means octal and that plain integers can be considered IPv4 addresses). Signed-off-by: Guillaume Nault

iprange: warn before disabling module due to /0 network with non-null IP

2016-05-11T11:45:56+00:00

Using a /0 prefix on an IP different from 0.0.0.0 is valid, but might be a configuration mistake. Log warning message in this case so that user can easily troubleshoot it. Signed-off-by: Guillaume Nault

iprange: replace UINT32_MAX by INADDR_BROADCAST

2016-05-11T11:45:54+00:00

This is equivalent, but INADDR_BROADCAST is more descriptive. Signed-off-by: Guillaume Nault

iprange: don't warn about empty iprange config if no modules depend on it

2016-05-11T10:26:02+00:00

Move warning messages to PPTP and L2TP modules. No other module actually uses iprange, so it's perfectly valid to disable it, or at least to not configure any range, when PPTP and L2TP aren't used. Signed-off-by: Guillaume Nault

iprange: implement config reload

2016-05-11T10:26:00+00:00

Protect conf_disable and client_ranges with a mutex. Instead of directly setting conf_disable, load_ranges() now returns a disable flag. The caller is in charge of propagating its value in conf_disable. Signed-off-by: Guillaume Nault

iprange: rework ip range parsing functions

2016-05-11T10:25:13+00:00

The previous parsing functions had a few problems: * They did accept negative numbers in addresses (e.g. 192.0.2.-5). * They relied on C undefined behaviour for detecting /0 prefix length: "mask = htonl(~((1 << (32 - m)) - 1)" was wrong for m = 0, because that resulted in a left shift of 32 bits, on a 32 bit wide value (the right operand of a bitwise shift operator must be strictly smaller than the width of the promoted left operand). * They misinterpreted /32 prefixes as disable requests. In fact, due to the undefined behaviour described above, /0 and /32 prefix lengths were represented in the same way by parse1(), that is, with an iprange_t structure where ->begin == ->end. Therefore load_ranges() had no way to distinguish between them and did disable the module in both cases. This patch fixes these issues and brings the following improvements: * It uses getaddrinfo() to parse IP addresses, so it accept (almost) all IPv4 representations and is more easily extensible to IPv6 in the future. * It warns when the IP address used in CIDR notation is not the first address in the range (e.g. the first address of 192.0.2.1/24 is 192.0.2.0, not 192.0.2.1). * It doesn't _exit() on parsing failures, thus making the functions usable in an EV_CONFIG_RELOAD handler. While there, the unfinished tunnel_ranges code, which was already commented, has been removed. Signed-off-by: Guillaume Nault

remove trailing whitespaces

2014-11-22T05:56:40+00:00

iprange: accept network with null mask (which actually disables iprange module)

2012-07-07T12:14:54+00:00

rewrited initialization procedure (fix gcc-4.6 builds)

2011-05-30T07:24:27+00:00