1. 08 3月, 2019 3 次提交
  2. 12 2月, 2019 1 次提交
  3. 06 2月, 2019 2 次提交
  4. 03 2月, 2019 3 次提交
  5. 28 1月, 2019 1 次提交
  6. 27 1月, 2019 1 次提交
  7. 25 1月, 2019 1 次提交
  8. 23 1月, 2019 1 次提交
  9. 22 1月, 2019 2 次提交
  10. 21 1月, 2019 2 次提交
  11. 19 1月, 2019 3 次提交
  12. 20 12月, 2018 7 次提交
    • G
      ipoe: stricter route deletion · 2910add2
      Guillaume Nault 提交于
      Rework the conditionals to make __ipoe_session_activate() and
      ipoe_session_finished() follow the same logic:
        * Drop the second '!serv->opt_ifcfg' test in __ipoe_session_activate(),
          which is is already checked by the parent conditional.
        * Invert the order of the tests in ipoe_session_finished(), so that
          it uses the same conditions as __ipoe_session_activate().
      Finally, set the 'src' parameter in iproute_del(), so that we can be
      sure that the deleted route matches the one added by
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      iputils: remove unnecessary NLM_F_ACK · 46f5f9c1
      Guillaume Nault 提交于
      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>
    • G
      iputils: remove NLM_F_CREATE flag from ip6{route,addr}_del() · 412e908e
      Guillaume Nault 提交于
      These are deletion requests. NLM_F_CREATE is confusing for readers and
      ignored by kernel.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      iputils: always set scope to RT_SCOPE_UNIVERSE in ip6route_{add,del}() · 525fe7ee
      Guillaume Nault 提交于
      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>
    • G
      iputils: set scope depending on gateway in iproute_{add,del}() · 55bcbfff
      Guillaume Nault 提交于
      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
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      radius: specify gateway in iproute_del() · 6355bfd7
      Guillaume Nault 提交于
      Be more specific about which route we want to remove. By not specifying
      the gateway we could remove a different route than the one we
      originally inserted.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      iputils: add 'src' and 'gw' parameters to iproute_del() · 6f6f7f2e
      Guillaume Nault 提交于
      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>
  13. 08 12月, 2018 4 次提交
    • G
      iprange: rework range parsing using u_parse_*() functions · 7951559f
      Guillaume Nault 提交于
      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
      The diff is a bit ugly, but the implementation should be much clearer.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      utils: add IPv4 string parsing helpers · 093bacca
      Guillaume Nault 提交于
      Define the IPv4 counterparts of u_ip6str() and u_parse_ip6cidr().
      Also add the special u_parse_ip4range() which will be useful for
      parsing the [client-ip-range] section of accel-ppp.conf.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      utils: rework u_parse_ip4addr() · 0f2f775d
      Guillaume Nault 提交于
      Redefine u_parse_ip4addr() to match the behaviour of other u_parse_*()
        * 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
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      utils: fix typo in description of u_parse_endstr() · 7bbe2a6d
      Guillaume Nault 提交于
      u_parse_endstr() used to be u_parse_eos() in my internal repository.
      I forgot to update the documentation when I renamed it.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
  14. 06 12月, 2018 1 次提交
  15. 04 12月, 2018 3 次提交
    • G
      radius: implement Framed-IPv6-Route attribute · 2e66e6a9
      Guillaume Nault 提交于
      Framed-IPv6-Route is the IPv6 counterpart of Framed-Route. It's only
      used for defining routes to be added locally by accel-ppp. Routes that
      should be announced to the peer using Router Advertisements should be
      defined in the Route-IPv6-Information attribute (but that's currently
      not implemented).
      Framed-IPv6-Route format is:
      <network in CIDR notation> [<gateway IPv6 address> [<route metric>]]
      The gateway address and the route metric are optionals, but the metric
      can only be set if a gateway address is given. One can use the
      unspecified address '::' to define a route with no gateway and a
      non-default route metric.
      When no gateway address is defined, the session's network interface is
      used directly.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      utils: add string parsing helpers · 68475cd0
      Guillaume Nault 提交于
      Define parsers for IPv6 addresses and CIDR notations, unsigned
      integers, separators (variable number of space characters) and end of
      strings (variable number of spaces followed by '\0').
      All of these functions work on constant string and return the number
      bytes parsed. If the input string doesn't have the expected format,
      these functions return 0 (no forward progress).
      Also implement a convenient wrapper around inet_ntop() that can be used
      easily in printf-like functions.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
    • G
      libnetlink: add gateway and priority parameters to ip6route_*() · 896b7ae6
      Guillaume Nault 提交于
      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>
  16. 03 12月, 2018 2 次提交
  17. 02 12月, 2018 1 次提交
  18. 01 12月, 2018 1 次提交
  19. 27 11月, 2018 1 次提交
    • G
      ppp: use random LCP (and NCP) identifiers · 707e1547
      Guillaume Nault 提交于
      In DSL setups, it's common to have an intermediate equipment,
      potentially managed by a different operator, between the two PPP
      endpoints. In such setups, the client establishes a PPPoE or L2TP
      session with the intermediate equipment. They perform LCP negotiation
      and eventually get to the authentication phase. Based on the client's
      username, the intermediate equipment then establishes another L2TP
      session with the final PPP endpoint (accel-ppp). At this point, the
      intermediate equipment forwards any PPP frame received on one side to
      the other side, so that it becomes transparent to PPP frames.
      Then accel-ppp starts an LCP negotiation again, performs
      authentication, negotiates NCPs and finally forwards IP packets to and
      from the client.
      +--------+                        +--------------+                    +-----------+
      | Client |------------------------| Intermediate |--------------------| accel-ppp |
      |        |                        | equipment    |                    |           |
      +--------+                        +--------------+                    +-----------+
                <-- First hop PPPoE  -->                <--  Second hop  -->
      	      or L2TP session                         L2TP session
                <----------------- End to end PPP session ----------------->
      Therefore, from the client point of view, two LCP negotiations occur.
      LCP re-negotiation is explicitly handled by RFC 1661 and even
      non-conforming PPP clients generally cope with this situation well
      enough (as long as LCP re-negotiation occurs before the authentication
      phase completes).
      However, accel-ppp always starts its LCP negotiation with an identifier
      set to 1. If the previous LCP negotiation also used identifier 1, then
      some clients (at least MikroTik products) consider that the
      Configure-Request sent by accel-ppp is part of the previous LCP
      negotiation and refuse to return to link establishment phase as
      mandated by section 3.4 of RFC 1661.
      We can easily work around this problem by using random identifiers.
      This maximises the chances that accel-ppp picks a different identifier
      than the intermediate equipment and avoids falling into the MikroTik
      problem. In case of bad luck and the chosen identifier is the same as
      the one used for the original LCP negotiation, then PPP establishment
      fails and the client tries to reconnect until the intermediate
      equipment and accel-ppp pick up different numbers. So the connection
      eventually succeeds.
      The identifier is set in ppp_fsm_init(), so it also affects NCPs.
      Therefore, IPCP and IPv6CP now also use random identifiers.
      We need to define 'id' and 'recv_id' in struct ppp_fsm_t as uint8_t,
      otherwise they could be chosen larger than 255 and comparing their
      value with the 8-bits values found in received packets would fail (this
      was generally not a problem when id was initially set to 1 and wouldn't
      grow much).
      Also, let's seed random() at startup, so that we don't end up with the
      same sequences across restarts. This also benefits other users of
      random(), like LCP magic numbers.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>