1. 03 Mar, 2014 17 commits
  2. 02 Mar, 2014 1 commit
    • Veaceslav Falico's avatar
      bonding: send arp requests even if there's no route to them · 28572760
      Veaceslav Falico authored
      Currently we're only sending arp requests if we have a route to the target
      (and, thus, can find out the source ip address).
      
      There are some use cases, however, where we don't want/need to set an ip
      address (or set up a specific route) for bonding to use arp monitoring *for
      traffic generation*. We can easily send arp probes (arp requests with src
      ip == 0) to generate arp broadcast responses from the target ip and use
      them for determining if the target is up.
      
      This, obviously, won't work with arp validation - because we don't have the
      ip address set and, thus, will filter out the responses. So in that case -
      print a warning.
      
      CC: François CACHEREUL <f.cachereul@alphalink.fr>
      CC: Zhenjie Chen <zhchen@redhat.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28572760
  3. 28 Feb, 2014 19 commits
  4. 27 Feb, 2014 3 commits
    • Bjørn Mork's avatar
      ipv6: addrconf: silence sparse endianness warnings · bc861959
      Bjørn Mork authored
      Avoid the following sparse __CHECK_ENDIAN__ warnings:
      
       include/net/addrconf.h:318:25: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:318:70: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:330:25: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:330:70: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:347:25: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:348:26: warning: restricted __be64 degrades to integer
       include/net/addrconf.h:349:18: warning: restricted __be64 degrades to integer
      
      The warnings are false but they make it harder to spot real
      bugs.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc861959
    • Duan Jiong's avatar
      neigh: directly goto out after setting nud_state to NUD_FAILED · 5e2c21dc
      Duan Jiong authored
      Because those following if conditions will not be matched.
      Signed-off-by: default avatarDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e2c21dc
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next · 8e1f40ec
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      This is the rework of the IPsec virtual tunnel interface
      for ipv4 to support inter address family tunneling and
      namespace crossing. The only change to the last RFC version
      is a compile fix for an odd configuration where CONFIG_XFRM
      is set but CONFIG_INET is not set.
      
      1) Add and use a IPsec protocol multiplexer.
      
      2) Add xfrm_tunnel_skb_cb to the skb common buffer
         to store a receive callback there.
      
      3) Make vti work with i_key set by not including the i_key
         when comupting the hash for the tunnel lookup in case of
         vti tunnels.
      
      4) Update ip_vti to use it's own receive hook.
      
      5) Remove xfrm_tunnel_notifier, this is replaced by the IPsec
         protocol multiplexer.
      
      6) We need to be protocol family indepenent, so use the on xfrm_lookup
         returned dst_entry instead of the ipv4 rtable in vti_tunnel_xmit().
      
      7) Add support for inter address family tunneling.
      
      8) Check if the tunnel endpoints of the xfrm state and the vti interface
         are matching and return an error otherwise.
      
      8) Enable namespace crossing tor vti devices.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e1f40ec