Using NLM_F_ACK in these functions is confusing because they don't
parse any netlink response.

In fact, NLM_F_ACK is only required internally by rtnl_talk(), which
already adds it when its 'answer' parameter is NULL. Therefore it's
useless to manually set it in functions that don't set 'answer'.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

These are deletion requests. NLM_F_CREATE is confusing for readers and
ignored by kernel.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

No need to be clever here. All IPv6 routes have global scope (kernel
ignores rtm_scope for IPv6 and always reports RT_SCOPE_UNIVERSE when
dumping such routes).
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

From a logical point of view, we have link scope if no gateway is
present, and global scope otherwise. Therefore it makes more sense
to set rtm_scope depending on 'gw' rather than on 'ifindex'.

Currently, callers of iproute_add() and iproute_del() either set
'ifindex' or 'gw', but never both. So even if confusing, the current
code results in right scope selection. However one can't figure this
out without analysing every caller.

We should set rtm_scope based on the presence of the gateway instead.
Given the current code base, that doesn't change the end result, but
that better maches the scope concept. Also, that's the way iproute2
does its selection.

Furthermore, it'd be perfectly valid to have both 'iface' and 'gw' set.
In that case, scope should be RT_SCOPE_UNIVERSE instead of
RT_SCOPE_LINK. Basing scope selection on 'gw' makes this case work
correctly.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

Rework iproute_del() to have the same parameters as iproute_add().
This will allow callers to specify more precisely the route they want
to delete.

Callers will later be converted to make use of these parameters to
ensure that the removed route precisely matches the one that was
originaly inserted.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

Let callers set a gateway and a priority to IPv6 routes. This is
necessary for implementing the RADIUS Framed-IPv6-Route attribute.

Also let ip6route_del() configure .rtm_protocol. This is already
implemented in ip6route_add(), so we need to add the ip6route_del()
counterpart. Otherwise, we couldn't delete routes that were added using
a non-zero protocol.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

Let an optional route priority (aka metric) be defined in RADIUS
Framed-Route attributes.
The priority is an integer placed at the end of the route string. This
is backward compatible with the previous format and also conforms with
the recommended format defined by RFC 2865 (although we don't allow
multiple metrics).

Framed-Route format is:
<network> [<gateway> [<priority>]]

For example, 'Framed-Route = "192.0.2.0/24 203.0.113.1 8"' will let
the following route be installed (assuming 203.0.113.1 is routed
through eth0):
$ ip route show
[...]
192.0.2.0/24 via 203.0.113.1 dev eth0 metric 8

It's possible to use the unspecified gateway (0.0.0.0) if one wants to
set a priority without specifying a gateway address.

Finally, route deletion now also takes the priority into account, in
order to avoid removing a different route accidentally.
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>

This is done using radius attribute NAS-Port-Id. The new format of this attribute is NAS-Port-Id=[ns/][name].
Namespaces must be created malually by "ip netns add ..." command

ipoe,pppoe,vlan_mon: deleted conditions to simultaneous start ipoe and pppoe on same interfaces (started by vlan_mon)

Before this time accel-ppp always worked in "ip unnumbered" mode.
This option may turn this mode off (default is on)

Signed-off-by: NDmitry Kozlov <xeb@mail.ru>

Signed-off-by: NDmitry Kozlov <xeb@mail.ru>

ipoe: implemented client address, router address and mask to be passed via radius