1. 11 7月, 2007 3 次提交
    • M
      [IPV6]: Remove unneeded pointer idev from addrconf_cleanup(). · dffe4f04
      Micah Gruber 提交于
      This trivial patch removes the unneeded pointer idev returned from
      __in6_dev_get(), which is never used. The check for NULL can be simply
      done by if (__in6_dev_get(dev) == NULL).
      Signed-off-by: NMicah Gruber <micah.gruber@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dffe4f04
    • M
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA 提交于
      This patch makes MIPv6 loadable module named "mip6".
      
      Here is a modprobe.conf(5) example to load it automatically
      when user application uses XFRM state for MIPv6:
      
      alias xfrm-type-10-43 mip6
      alias xfrm-type-10-60 mip6
      
      Some MIPv6 feature is not included by this modular, however,
      it should not be affected to other features like either IPsec
      or IPv6 with and without the patch.
      We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
      separately for future work.
      
      Loadable features:
      * MH receiving check (to send ICMP error back)
      * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
      * XFRM policy/state database handling for RO
      
      These are NOT covered as loadable:
      * Home Address flags and its rule on source address selection
      * XFRM sub policy (depends on its own kernel option)
      * XFRM functions to receive RO as IPv6 extension header
      * MH sending/receiving through raw socket if user application
        opens it (since raw socket allows to do so)
      * RH2 sending as ancillary data
      * RH2 operation with setsockopt(2)
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59fbb3a6
    • J
      bonding / ipv6: no addrconf for slaves separately from master · c2edacf8
      Jay Vosburgh 提交于
      	At present, when a device is enslaved to bonding, if ipv6 is
      active then addrconf will be initated on the slave (because it is closed
      then opened during the enslavement processing).  This causes DAD and RS
      packets to be sent from the slave.  These packets in turn can confuse
      switches that perform ipv6 snooping, causing them to incorrectly update
      their forwarding tables (if, e.g., the slave being added is an inactve
      backup that won't be used right away) and direct traffic away from the
      active slave to a backup slave (where the incoming packets will be
      dropped).
      
      	This patch alters the behavior so that addrconf will only run on
      the master device itself.  I believe this is logically correct, as it
      prevents slaves from having an IPv6 identity independent from the
      master.  This is consistent with the IPv4 behavior for bonding.
      
      	This is accomplished by (a) having bonding set IFF_SLAVE sooner
      in the enslavement processing than currently occurs (before open, not
      after), and (b) having ipv6 addrconf ignore UP and CHANGE events on
      slave devices.
      
      	The eql driver also uses the IFF_SLAVE flag.  I inspected eql,
      and I believe this change is reasonable for its usage of IFF_SLAVE, but
      I did not test it.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c2edacf8
  2. 15 6月, 2007 1 次提交
    • H
      [IPV6] addrconf: Fix IPv6 on tuntap tunnels · 74235a25
      Herbert Xu 提交于
      The recent patch that added ipv6_hwtype is broken on tuntap tunnels.
      Indeed, it's broken on any device that does not pass the ipv6_hwtype
      test.
      
      The reason is that the original test only applies to autoconfiguration,
      not IPv6 support.  IPv6 support is allowed on any device.  In fact,
      even with the ipv6_hwtype patch applied you can still add IPv6 addresses
      to any interface that doesn't pass thw ipv6_hwtype test provided that
      they have a sufficiently large MTU.  This is a serious problem because
      come deregistration time these devices won't be cleaned up properly.
      
      I've gone back and looked at the rationale for the patch.  It appears
      that the real problem is that we were creating IPv6 devices even if the
      MTU was too small.  So here's a patch which fixes that and reverts the
      ipv6_hwtype stuff.
      
      Thanks to Kanru Chen for reporting this issue.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74235a25
  3. 08 6月, 2007 1 次提交
  4. 25 5月, 2007 1 次提交
  5. 11 5月, 2007 1 次提交
  6. 04 5月, 2007 1 次提交
  7. 29 4月, 2007 1 次提交
  8. 26 4月, 2007 8 次提交
  9. 25 4月, 2007 1 次提交
  10. 28 3月, 2007 1 次提交
  11. 23 3月, 2007 1 次提交
  12. 08 3月, 2007 1 次提交
  13. 01 3月, 2007 1 次提交
  14. 27 2月, 2007 3 次提交
  15. 15 2月, 2007 3 次提交
  16. 13 2月, 2007 1 次提交
  17. 11 2月, 2007 1 次提交
  18. 09 2月, 2007 1 次提交
    • P
      [NETLINK]: Don't BUG on undersized allocations · 26932566
      Patrick McHardy 提交于
      Currently netlink users BUG when the allocated skb for an event
      notification is undersized. While this is certainly a kernel bug,
      its not critical and crashing the kernel is too drastic, especially
      when considering that these errors have appeared multiple times in
      the past and it BUGs even if no listeners are present.
      
      This patch replaces BUG by WARN_ON and changes the notification
      functions to inform potential listeners of undersized allocations
      using a unique error code (EMSGSIZE).
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26932566
  19. 31 1月, 2007 1 次提交
  20. 24 1月, 2007 1 次提交
  21. 05 1月, 2007 1 次提交
  22. 11 12月, 2006 1 次提交
  23. 03 12月, 2006 5 次提交