1. 24 3月, 2015 2 次提交
    • H
      ipv6: generation of stable privacy addresses for link-local and autoconf · 622c81d5
      Hannes Frederic Sowa 提交于
      This patch implements the stable privacy address generation for
      link-local and autoconf addresses as specified in RFC7217.
      
        RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
      
      is the RID (random identifier). As the hash function F we chose one
      round of sha1. Prefix will be either the link-local prefix or the
      router advertised one. As Net_Iface we use the MAC address of the
      device. DAD_Counter and secret_key are implemented as specified.
      
      We don't use Network_ID, as it couples the code too closely to other
      subsystems. It is specified as optional in the RFC.
      
      As Net_Iface we only use the MAC address: we simply have no stable
      identifier in the kernel we could possibly use: because this code might
      run very early, we cannot depend on names, as they might be changed by
      user space early on during the boot process.
      
      A new address generation mode is introduced,
      IN6_ADDR_GEN_MODE_STABLE_PRIVACY. With iproute2 one can switch back to
      none or eui64 address configuration mode although the stable_secret is
      already set.
      
      We refuse writes to ipv6/conf/all/stable_secret but only allow
      ipv6/conf/default/stable_secret and the interface specific file to be
      written to. The default stable_secret is used as the parameter for the
      namespace, the interface specific can overwrite the secret, e.g. when
      switching a network configuration from one system to another while
      inheriting the secret.
      
      Cc: Erik Kline <ek@google.com>
      Cc: Fernando Gont <fgont@si6networks.com>
      Cc: Lorenzo Colitti <lorenzo@google.com>
      Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      622c81d5
    • H
      ipv6: introduce secret_stable to ipv6_devconf · 3d1bec99
      Hannes Frederic Sowa 提交于
      This patch implements the procfs logic for the stable_address knob:
      The secret is formatted as an ipv6 address and will be stored per
      interface and per namespace. We track initialized flag and return EIO
      errors until the secret is set.
      
      We don't inherit the secret to newly created namespaces.
      
      Cc: Erik Kline <ek@google.com>
      Cc: Fernando Gont <fgont@si6networks.com>
      Cc: Lorenzo Colitti <lorenzo@google.com>
      Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d1bec99
  2. 19 3月, 2015 1 次提交
  3. 28 2月, 2015 1 次提交
    • M
      multicast: Extend ip address command to enable multicast group join/leave on · 93a714d6
      Madhu Challa 提交于
      Joining multicast group on ethernet level via "ip maddr" command would
      not work if we have an Ethernet switch that does igmp snooping since
      the switch would not replicate multicast packets on ports that did not
      have IGMP reports for the multicast addresses.
      
      Linux vxlan interfaces created via "ip link add vxlan" have the group option
      that enables then to do the required join.
      
      By extending ip address command with option "autojoin" we can get similar
      functionality for openvswitch vxlan interfaces as well as other tunneling
      mechanisms that need to receive multicast traffic. The kernel code is
      structured similar to how the vxlan driver does a group join / leave.
      
      example:
      ip address add 224.1.1.10/24 dev eth5 autojoin
      ip address del 224.1.1.10/24 dev eth5
      Signed-off-by: NMadhu Challa <challa@noironetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93a714d6
  4. 24 2月, 2015 1 次提交
    • M
      ipv6: addrconf: validate new MTU before applying it · 77751427
      Marcelo Leitner 提交于
      Currently we don't check if the new MTU is valid or not and this allows
      one to configure a smaller than minimum allowed by RFCs or even bigger
      than interface own MTU, which is a problem as it may lead to packet
      drops.
      
      If you have a daemon like NetworkManager running, this may be exploited
      by remote attackers by forging RA packets with an invalid MTU, possibly
      leading to a DoS. (NetworkManager currently only validates for values
      too small, but not for too big ones.)
      
      The fix is just to make sure the new value is valid. That is, between
      IPV6_MIN_MTU and interface's MTU.
      
      Note that similar check is already performed at
      ndisc_router_discovery(), for when kernel itself parses the RA.
      Signed-off-by: NMarcelo Ricardo Leitner <mleitner@redhat.com>
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77751427
  5. 07 2月, 2015 1 次提交
  6. 06 2月, 2015 1 次提交
    • E
      net: ipv6: allow explicitly choosing optimistic addresses · c58da4c6
      Erik Kline 提交于
      RFC 4429 ("Optimistic DAD") states that optimistic addresses
      should be treated as deprecated addresses.  From section 2.1:
      
         Unless noted otherwise, components of the IPv6 protocol stack
         should treat addresses in the Optimistic state equivalently to
         those in the Deprecated state, indicating that the address is
         available for use but should not be used if another suitable
         address is available.
      
      Optimistic addresses are indeed avoided when other addresses are
      available (i.e. at source address selection time), but they have
      not heretofore been available for things like explicit bind() and
      sendmsg() with struct in6_pktinfo, etc.
      
      This change makes optimistic addresses treated more like
      deprecated addresses than tentative ones.
      Signed-off-by: NErik Kline <ek@google.com>
      Acked-by: NLorenzo Colitti <lorenzo@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c58da4c6
  7. 31 1月, 2015 1 次提交
  8. 26 1月, 2015 1 次提交
  9. 19 1月, 2015 1 次提交
  10. 18 1月, 2015 1 次提交
    • J
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg 提交于
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      
      This makes the very common pattern of
      
        if (genlmsg_end(...) < 0) { ... }
      
      be a whole bunch of dead code. Many places also simply do
      
        return nlmsg_end(...);
      
      and the caller is expected to deal with it.
      
      This also commonly (at least for me) causes errors, because it is very
      common to write
      
        if (my_function(...))
          /* error condition */
      
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      053c095a
  11. 27 11月, 2014 1 次提交
    • Z
      ipv6: Remove unnecessary test · 73cf0e92
      zhuyj 提交于
      The "init_net" test in function addrconf_exit_net is introduced
      in commit 44a6bd29 [Create ipv6 devconf-s for namespaces] to avoid freeing
      init_net. In commit c900a800 [ipv6: fix bad free of addrconf_init_net],
      function addrconf_init_net will allocate memory for every net regardless of
      init_net. In this case, it is unnecessary to make "init_net" test.
      
      CC: Hong Zhiguo <honkiko@gmail.com>
      CC: Octavian Purdila <opurdila@ixiacom.com>
      CC: Pavel Emelyanov <xemul@openvz.org>
      CC: Cong Wang <cwang@twopensource.com>
      Suggested-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NZhu Yanjun <Yanjun.Zhu@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73cf0e92
  12. 24 11月, 2014 1 次提交
  13. 12 11月, 2014 1 次提交
    • J
      net: Convert LIMIT_NETDEBUG to net_dbg_ratelimited · ba7a46f1
      Joe Perches 提交于
      Use the more common dynamic_debug capable net_dbg_ratelimited
      and remove the LIMIT_NETDEBUG macro.
      
      All messages are still ratelimited.
      
      Some KERN_<LEVEL> uses are changed to KERN_DEBUG.
      
      This may have some negative impact on messages that were
      emitted at KERN_INFO that are not not enabled at all unless
      DEBUG is defined or dynamic_debug is enabled.  Even so,
      these messages are now _not_ emitted by default.
      
      This also eliminates the use of the net_msg_warn sysctl
      "/proc/sys/net/core/warnings".  For backward compatibility,
      the sysctl is not removed, but it has no function.  The extern
      declaration of net_msg_warn is removed from sock.h and made
      static in net/core/sysctl_net_core.c
      
      Miscellanea:
      
      o Update the sysctl documentation
      o Remove the embedded uses of pr_fmt
      o Coalesce format fragments
      o Realign arguments
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba7a46f1
  14. 30 10月, 2014 2 次提交
    • E
      net: ipv6: Add a sysctl to make optimistic addresses useful candidates · 7fd2561e
      Erik Kline 提交于
      Add a sysctl that causes an interface's optimistic addresses
      to be considered equivalent to other non-deprecated addresses
      for source address selection purposes.  Preferred addresses
      will still take precedence over optimistic addresses, subject
      to other ranking in the source address selection algorithm.
      
      This is useful where different interfaces are connected to
      different networks from different ISPs (e.g., a cell network
      and a home wifi network).
      
      The current behaviour complies with RFC 3484/6724, and it
      makes sense if the host has only one interface, or has
      multiple interfaces on the same network (same or cooperating
      administrative domain(s), but not in the multiple distinct
      networks case.
      
      For example, if a mobile device has an IPv6 address on an LTE
      network and then connects to IPv6-enabled wifi, while the wifi
      IPv6 address is undergoing DAD, IPv6 connections will try use
      the wifi default route with the LTE IPv6 address, and will get
      stuck until they time out.
      
      Also, because optimistic nodes can receive frames, issue
      an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
      flag appropriately set).  A second RTM_NEWADDR is sent if DAD
      completes (the address flags have changed), otherwise an
      RTM_DELADDR is sent.
      
      Also: add an entry in ip-sysctl.txt for optimistic_dad.
      Signed-off-by: NErik Kline <ek@google.com>
      Acked-by: NLorenzo Colitti <lorenzo@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fd2561e
    • L
      ipv6: notify userspace when we added or changed an ipv6 token · b2ed64a9
      Lubomir Rintel 提交于
      NetworkManager might want to know that it changed when the router advertisement
      arrives.
      Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2ed64a9
  15. 28 10月, 2014 1 次提交
  16. 01 10月, 2014 1 次提交
    • H
      ipv6: remove rt6i_genid · 705f1c86
      Hannes Frederic Sowa 提交于
      Eric Dumazet noticed that all no-nonexthop or no-gateway routes which
      are already marked DST_HOST (e.g. input routes routes) will always be
      invalidated during sk_dst_check. Thus per-socket dst caching absolutely
      had no effect and early demuxing had no effect.
      
      Thus this patch removes rt6i_genid: fn_sernum already gets modified during
      add operations, so we only must ensure we mutate fn_sernum during ipv6
      address remove operations. This is a fairly cost extensive operations,
      but address removal should not happen that often. Also our mtu update
      functions do the same and we heard no complains so far. xfrm policy
      changes also cause a call into fib6_flush_trees. Also plug a hole in
      rt6_info (no cacheline changes).
      
      I verified via tracing that this change has effect.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: YOSHIFUJI Hideaki <hideaki@yoshifuji.org>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Martin Lau <kafai@fb.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      705f1c86
  17. 14 9月, 2014 2 次提交
  18. 13 9月, 2014 1 次提交
  19. 06 9月, 2014 3 次提交
  20. 25 8月, 2014 1 次提交
    • I
      ipv6: White-space cleansing : Line Layouts · 67ba4152
      Ian Morris 提交于
      This patch makes no changes to the logic of the code but simply addresses
      coding style issues as detected by checkpatch.
      
      Both objdump and diff -w show no differences.
      
      A number of items are addressed in this patch:
      * Multiple spaces converted to tabs
      * Spaces before tabs removed.
      * Spaces in pointer typing cleansed (char *)foo etc.
      * Remove space after sizeof
      * Ensure spacing around comparators such as if statements.
      Signed-off-by: NIan Morris <ipm@chirality.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67ba4152
  21. 30 7月, 2014 1 次提交
  22. 12 7月, 2014 1 次提交
    • J
      ipv6: addrconf: implement address generation modes · bc91b0f0
      Jiri Pirko 提交于
      This patch introduces a possibility for userspace to set various (so far
      two) modes of generating addresses. This is useful for example for
      NetworkManager because it can set the mode to NONE and take care of link
      local addresses itself. That allow it to have the interface up,
      monitoring carrier but still don't have any addresses on it.
      
      One more use-case by Dan Williams:
      <quote>
      WWAN devices often have their LL address provided by the firmware of the
      device, which sometimes refuses to respond to incorrect LL addresses
      when doing DHCPv6 or IPv6 ND.  The kernel cannot generate the correct LL
      address for two reasons:
      
      1) WWAN pseudo-ethernet interfaces often construct a fake MAC address,
      or read a meaningless MAC address from the firmware.  Thus the EUI64 and
      the IPv6LL address the kernel assigns will be wrong.  The real LL
      address is often retrieved from the firmware with AT or proprietary
      commands.
      
      2) WWAN PPP interfaces receive their LL address from IPV6CP, not from
      kernel assignments.  Only after IPV6CP has completed do we know the LL
      address of the PPP interface and its peer.  But the kernel has already
      assigned an incorrect LL address to the interface.
      
      So being able to suppress the kernel LL address generation and assign
      the one retrieved from the firmware is less complicated and more robust.
      </quote>
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc91b0f0
  23. 02 7月, 2014 1 次提交
    • B
      ipv6: Allow accepting RA from local IP addresses. · d9333196
      Ben Greear 提交于
      This can be used in virtual networking applications, and
      may have other uses as well.  The option is disabled by
      default.
      
      A specific use case is setting up virtual routers, bridges, and
      hosts on a single OS without the use of network namespaces or
      virtual machines.  With proper use of ip rules, routing tables,
      veth interface pairs and/or other virtual interfaces,
      and applications that can bind to interfaces and/or IP addresses,
      it is possibly to create one or more virtual routers with multiple
      hosts attached.  The host interfaces can act as IPv6 systems,
      with radvd running on the ports in the virtual routers.  With the
      option provided in this patch enabled, those hosts can now properly
      obtain IPv6 addresses from the radvd.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9333196
  24. 08 5月, 2014 1 次提交
    • W
      net: clean up snmp stats code · 698365fa
      WANG Cong 提交于
      commit 8f0ea0fe (snmp: reduce percpu needs by 50%)
      reduced snmp array size to 1, so technically it doesn't have to be
      an array any more. What's more, after the following commit:
      
      	commit 933393f5
      	Date:   Thu Dec 22 11:58:51 2011 -0600
      
      	    percpu: Remove irqsafe_cpu_xxx variants
      
      	    We simply say that regular this_cpu use must be safe regardless of
      	    preemption and interrupt state.  That has no material change for x86
      	    and s390 implementations of this_cpu operations.  However, arches that
      	    do not provide their own implementation for this_cpu operations will
      	    now get code generated that disables interrupts instead of preemption.
      
      probably no arch wants to have SNMP_ARRAY_SZ == 2. At least after
      almost 3 years, no one complains.
      
      So, just convert the array to a single pointer and remove snmp_mib_init()
      and snmp_mib_free() as well.
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      698365fa
  25. 06 5月, 2014 1 次提交
  26. 23 4月, 2014 1 次提交
  27. 29 3月, 2014 1 次提交
    • H
      ipv6: move DAD and addrconf_verify processing to workqueue · c15b1cca
      Hannes Frederic Sowa 提交于
      addrconf_join_solict and addrconf_join_anycast may cause actions which
      need rtnl locked, especially on first address creation.
      
      A new DAD state is introduced which defers processing of the initial
      DAD processing into a workqueue.
      
      To get rtnl lock we need to push the code paths which depend on those
      calls up to workqueues, specifically addrconf_verify and the DAD
      processing.
      
      (v2)
      addrconf_dad_failure needs to be queued up to the workqueue, too. This
      patch introduces a new DAD state and stop the DAD processing in the
      workqueue (this is because of the possible ipv6_del_addr processing
      which removes the solicited multicast address from the device).
      
      addrconf_verify_lock is removed, too. After the transition it is not
      needed any more.
      
      As we are not processing in bottom half anymore we need to be a bit more
      careful about disabling bottom half out when we lock spin_locks which are also
      used in bh.
      
      Relevant backtrace:
      [  541.030090] RTNL: assertion failed at net/core/dev.c (4496)
      [  541.031143] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O 3.10.33-1-amd64-vyatta #1
      [  541.031145] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  541.031146]  ffffffff8148a9f0 000000000000002f ffffffff813c98c1 ffff88007c4451f8
      [  541.031148]  0000000000000000 0000000000000000 ffffffff813d3540 ffff88007fc03d18
      [  541.031150]  0000880000000006 ffff88007c445000 ffffffffa0194160 0000000000000000
      [  541.031152] Call Trace:
      [  541.031153]  <IRQ>  [<ffffffff8148a9f0>] ? dump_stack+0xd/0x17
      [  541.031180]  [<ffffffff813c98c1>] ? __dev_set_promiscuity+0x101/0x180
      [  541.031183]  [<ffffffff813d3540>] ? __hw_addr_create_ex+0x60/0xc0
      [  541.031185]  [<ffffffff813cfe1a>] ? __dev_set_rx_mode+0xaa/0xc0
      [  541.031189]  [<ffffffff813d3a81>] ? __dev_mc_add+0x61/0x90
      [  541.031198]  [<ffffffffa01dcf9c>] ? igmp6_group_added+0xfc/0x1a0 [ipv6]
      [  541.031208]  [<ffffffff8111237b>] ? kmem_cache_alloc+0xcb/0xd0
      [  541.031212]  [<ffffffffa01ddcd7>] ? ipv6_dev_mc_inc+0x267/0x300 [ipv6]
      [  541.031216]  [<ffffffffa01c2fae>] ? addrconf_join_solict+0x2e/0x40 [ipv6]
      [  541.031219]  [<ffffffffa01ba2e9>] ? ipv6_dev_ac_inc+0x159/0x1f0 [ipv6]
      [  541.031223]  [<ffffffffa01c0772>] ? addrconf_join_anycast+0x92/0xa0 [ipv6]
      [  541.031226]  [<ffffffffa01c311e>] ? __ipv6_ifa_notify+0x11e/0x1e0 [ipv6]
      [  541.031229]  [<ffffffffa01c3213>] ? ipv6_ifa_notify+0x33/0x50 [ipv6]
      [  541.031233]  [<ffffffffa01c36c8>] ? addrconf_dad_completed+0x28/0x100 [ipv6]
      [  541.031241]  [<ffffffff81075c1d>] ? task_cputime+0x2d/0x50
      [  541.031244]  [<ffffffffa01c38d6>] ? addrconf_dad_timer+0x136/0x150 [ipv6]
      [  541.031247]  [<ffffffffa01c37a0>] ? addrconf_dad_completed+0x100/0x100 [ipv6]
      [  541.031255]  [<ffffffff8105313a>] ? call_timer_fn.isra.22+0x2a/0x90
      [  541.031258]  [<ffffffffa01c37a0>] ? addrconf_dad_completed+0x100/0x100 [ipv6]
      
      Hunks and backtrace stolen from a patch by Stephen Hemminger.
      Reported-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15b1cca
  28. 14 3月, 2014 1 次提交
  29. 18 2月, 2014 1 次提交
    • N
      gre: add link local route when local addr is any · 08b44656
      Nicolas Dichtel 提交于
      This bug was reported by Steinar H. Gunderson and was introduced by commit
      f7cb8886 ("sit/gre6: don't try to add the same route two times").
      
      root@morgental:~# ip tunnel add foo mode gre remote 1.2.3.4 ttl 64
      root@morgental:~# ip link set foo up mtu 1468
      root@morgental:~# ip -6 route show dev foo
      fe80::/64  proto kernel  metric 256
      
      but after the above commit, no such route shows up.
      
      There is no link local route because dev->dev_addr is 0 (because local ipv4
      address is 0), hence no link local address is configured.
      
      In this scenario, the link local address is added manually: 'ip -6 addr add
      fe80::1 dev foo' and because prefix is /128, no link local route is added by the
      kernel.
      
      Even if the right things to do is to add the link local address with a /64
      prefix, we need to restore the previous behavior to avoid breaking userpace.
      Reported-by: NSteinar H. Gunderson <sesse@samfundet.no>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08b44656
  30. 25 1月, 2014 1 次提交
  31. 20 1月, 2014 1 次提交
  32. 18 1月, 2014 1 次提交
  33. 16 1月, 2014 2 次提交
    • T
      ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE · 5b84efec
      Thomas Haller 提交于
      Refactor the deletion/update of prefix routes when removing an
      address. Now also consider IFA_F_NOPREFIXROUTE and if there is an address
      present with this flag, to not cleanup the route. Instead, assume
      that userspace is taking care of this route.
      
      Also perform the same cleanup, when userspace changes an existing address
      to add NOPREFIXROUTE (to an address that didn't have this flag). This is
      done because when the address was added, a prefix route was created for it.
      Since the user now wants to handle this route by himself, we cleanup this
      route.
      
      This cleanup of the route is not totally robust. There is no guarantee,
      that the route we are about to delete was really the one added by the
      kernel. This behavior does not change by the patch, and in practice it
      should work just fine.
      Signed-off-by: NThomas Haller <thaller@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b84efec
    • T
      ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes · 761aac73
      Thomas Haller 提交于
      When adding/modifying an IPv6 address, the userspace application needs
      a way to suppress adding a prefix route. This is for example relevant
      together with IFA_F_MANAGERTEMPADDR, where userspace creates autoconf
      generated addresses, but depending on on-link, no route for the
      prefix should be added.
      Signed-off-by: NThomas Haller <thaller@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      761aac73
  34. 15 1月, 2014 1 次提交