1. 17 12月, 2014 2 次提交
  2. 13 11月, 2014 1 次提交
  3. 06 11月, 2014 1 次提交
    • T
      net: Move fou_build_header into fou.c and refactor · 63487bab
      Tom Herbert 提交于
      Move fou_build_header out of ip_tunnel.c and into fou.c splitting
      it up into fou_build_header, gue_build_header, and fou_build_udp.
      This allows for other users for TX of FOU or GUE. Change ip_tunnel_encap
      to call fou_build_header or gue_build_header based on the tunnel
      encapsulation type. Similarly, added fou_encap_hlen and gue_encap_hlen
      functions which are called by ip_encap_hlen. New net/fou.h has
      prototypes and defines for this.
      
      Added NET_FOU_IP_TUNNELS configuration. When this is set, IP tunnels
      can use FOU/GUE and fou module is also selected.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63487bab
  4. 04 10月, 2014 2 次提交
  5. 26 9月, 2014 1 次提交
  6. 23 9月, 2014 1 次提交
  7. 20 9月, 2014 1 次提交
  8. 31 7月, 2014 1 次提交
  9. 16 7月, 2014 1 次提交
    • T
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen 提交于
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      
      Coccinelle patch:
      
      @@
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      @@
      
      (
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      |
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      |
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      )
      
      v9: move comments here from the wrong commit
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c835a677
  10. 09 7月, 2014 1 次提交
    • D
      ip_tunnel: fix ip_tunnel_lookup · e0056593
      Dmitry Popov 提交于
      This patch fixes 3 similar bugs where incoming packets might be routed into
      wrong non-wildcard tunnels:
      
      1) Consider the following setup:
          ip address add 1.1.1.1/24 dev eth0
          ip address add 1.1.1.2/24 dev eth0
          ip tunnel add ipip1 remote 2.2.2.2 local 1.1.1.1 mode ipip dev eth0
          ip link set ipip1 up
      
      Incoming ipip packets from 2.2.2.2 were routed into ipip1 even if it has dst =
      1.1.1.2. Moreover even if there was wildcard tunnel like
         ip tunnel add ipip0 remote 2.2.2.2 local any mode ipip dev eth0
      but it was created before explicit one (with local 1.1.1.1), incoming ipip
      packets with src = 2.2.2.2 and dst = 1.1.1.2 were still routed into ipip1.
      
      Same issue existed with all tunnels that use ip_tunnel_lookup (gre, vti)
      
      2)  ip address add 1.1.1.1/24 dev eth0
          ip tunnel add ipip1 remote 2.2.146.85 local 1.1.1.1 mode ipip dev eth0
          ip link set ipip1 up
      
      Incoming ipip packets with dst = 1.1.1.1 were routed into ipip1, no matter what
      src address is. Any remote ip address which has ip_tunnel_hash = 0 raised this
      issue, 2.2.146.85 is just an example, there are more than 4 million of them.
      And again, wildcard tunnel like
         ip tunnel add ipip0 remote any local 1.1.1.1 mode ipip dev eth0
      wouldn't be ever matched if it was created before explicit tunnel like above.
      
      Gre & vti tunnels had the same issue.
      
      3)  ip address add 1.1.1.1/24 dev eth0
          ip tunnel add gre1 remote 2.2.146.84 local 1.1.1.1 key 1 mode gre dev eth0
          ip link set gre1 up
      
      Any incoming gre packet with key = 1 were routed into gre1, no matter what
      src/dst addresses are. Any remote ip address which has ip_tunnel_hash = 0 raised
      the issue, 2.2.146.84 is just an example, there are more than 4 million of them.
      Wildcard tunnel like
         ip tunnel add gre2 remote any local any key 1 mode gre dev eth0
      wouldn't be ever matched if it was created before explicit tunnel like above.
      
      All this stuff happened because while looking for a wildcard tunnel we didn't
      check that matched tunnel is a wildcard one. Fixed.
      Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0056593
  11. 26 6月, 2014 1 次提交
    • E
      ipv4: fix dst race in sk_dst_get() · f8864972
      Eric Dumazet 提交于
      When IP route cache had been removed in linux-3.6, we broke assumption
      that dst entries were all freed after rcu grace period. DST_NOCACHE
      dst were supposed to be freed from dst_release(). But it appears
      we want to keep such dst around, either in UDP sockets or tunnels.
      
      In sk_dst_get() we need to make sure dst refcount is not 0
      before incrementing it, or else we might end up freeing a dst
      twice.
      
      DST_NOCACHE set on a dst does not mean this dst can not be attached
      to a socket or a tunnel.
      
      Then, before actual freeing, we need to observe a rcu grace period
      to make sure all other cpus can catch the fact the dst is no longer
      usable.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDormando <dormando@rydia.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8864972
  12. 11 6月, 2014 2 次提交
    • D
      ip_tunnel: fix i_key matching in ip_tunnel_find · 5ce54af1
      Dmitry Popov 提交于
      Some tunnels (though only vti as for now) can use i_key just for internal use:
      for example vti uses it for fwmark'ing incoming packets. So raw i_key value
      shouldn't be treated as a distinguisher for them. ip_tunnel_key_match exists for
      cases when we want to compare two ip_tunnel_parms' i_keys.
      
      Example bug:
      ip link add type vti ikey 1 local 1.0.0.1 remote 2.0.0.2
      ip link add type vti ikey 2 local 1.0.0.1 remote 2.0.0.2
      spawned two tunnels, although it doesn't make sense.
      Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ce54af1
    • D
      ip_vti: Fix 'ip tunnel add' with 'key' parameters · 7c8e6b9c
      Dmitry Popov 提交于
      ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
      translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
      TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key)
      making us unable to create vti tunnels with [io]key via ip tunnel.
      
      We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because
      vti_tunnels with same local/remote addresses but different ikeys will be treated
      as different then. So, imo the best option here is to move p->i_flags & *_KEY
      check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
      field for ip_tunnel_parm in the future.
      Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c8e6b9c
  13. 06 6月, 2014 1 次提交
  14. 21 5月, 2014 1 次提交
  15. 17 5月, 2014 2 次提交
    • T
      ipv4: ip_tunnels: disable cache for nbma gre tunnels · 22fb22ea
      Timo Teräs 提交于
      The connected check fails to check for ip_gre nbma mode tunnels
      properly. ip_gre creates temporary tnl_params with daddr specified
      to pass-in the actual target on per-packet basis from neighbor
      layer. Detect these tunnels by inspecting the actual tunnel
      configuration.
      
      Minimal test case:
       ip route add 192.168.1.1/32 via 10.0.0.1
       ip route add 192.168.1.2/32 via 10.0.0.2
       ip tunnel add nbma0 mode gre key 1 tos c0
       ip addr add 172.17.0.0/16 dev nbma0
       ip link set nbma0 up
       ip neigh add 172.17.0.1 lladdr 192.168.1.1 dev nbma0
       ip neigh add 172.17.0.2 lladdr 192.168.1.2 dev nbma0
       ping 172.17.0.1
       ping 172.17.0.2
      
      The second ping should be going to 192.168.1.2 and head 10.0.0.2;
      but cached gre tunnel level route is used and it's actually going
      to 192.168.1.1 via 10.0.0.1.
      
      The lladdr's need to go to separate dst for the bug to trigger.
      Test case uses separate route entries, but this can also happen
      when the route entry is same: if there is a nexthop exception or
      the GRE tunnel is IPsec'ed in which case the dst points to xfrm
      bundle unique to the gre lladdr.
      
      Fixes: 7d442fab ("ipv4: Cache dst in tunnels")
      Signed-off-by: NTimo Teräs <timo.teras@iki.fi>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22fb22ea
    • D
      ip_tunnel: don't add tunnel twice · ee30ef4d
      Duan Jiong 提交于
      When using command "ip tunnel add" to add a tunnel, the tunnel will be added twice,
      through ip_tunnel_create() and ip_tunnel_update().
      
      Because the second is unnecessary, so we can just break after adding tunnel
      through ip_tunnel_create().
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee30ef4d
  16. 16 5月, 2014 1 次提交
  17. 06 5月, 2014 1 次提交
  18. 17 4月, 2014 1 次提交
  19. 16 4月, 2014 1 次提交
  20. 27 3月, 2014 1 次提交
  21. 25 2月, 2014 1 次提交
    • S
      ip_tunnel: Make vti work with i_key set · 6d608f06
      Steffen Klassert 提交于
      Vti uses the o_key to mark packets that were transmitted or received
      by a vti interface. Unfortunately we can't apply different marks
      to in and outbound packets with only one key availabe. Vti interfaces
      typically use wildcard selectors for vti IPsec policies. On forwarding,
      the same output policy will match for both directions. This generates
      a loop between the IPsec gateways until the ttl of the packet is
      exceeded.
      
      The gre i_key/o_key are usually there to find the right gre tunnel
      during a lookup. When vti uses the i_key to mark packets, the tunnel
      lookup does not work any more because vti does not use the gre keys
      as a hash key for the lookup.
      
      This patch workarounds this my not including the i_key when comupting
      the hash for the tunnel lookup in case of vti tunnels.
      
      With this we have separate keys available for the transmitting and
      receiving side of the vti interface.
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      6d608f06
  22. 21 2月, 2014 1 次提交
  23. 20 2月, 2014 1 次提交
  24. 17 2月, 2014 1 次提交
  25. 15 2月, 2014 1 次提交
  26. 04 2月, 2014 1 次提交
  27. 28 1月, 2014 1 次提交
  28. 24 1月, 2014 1 次提交
  29. 22 1月, 2014 1 次提交
  30. 19 1月, 2014 1 次提交
  31. 18 1月, 2014 1 次提交
    • E
      ipv4: fix a dst leak in tunnels · 6c7e7610
      Eric Dumazet 提交于
      This patch :
      
      1) Remove a dst leak if DST_NOCACHE was set on dst
         Fix this by holding a reference only if dst really cached.
      
      2) Remove a lockdep warning in __tunnel_dst_set()
          This was reported by Cong Wang.
      
      3) Remove usage of a spinlock where xchg() is enough
      
      4) Remove some spurious inline keywords.
         Let compiler decide for us.
      
      Fixes: 7d442fab ("ipv4: Cache dst in tunnels")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Cong Wang <cwang@twopensource.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c7e7610
  32. 10 1月, 2014 1 次提交
  33. 05 1月, 2014 1 次提交
  34. 04 1月, 2014 2 次提交
  35. 14 11月, 2013 1 次提交
    • A
      core/dev: do not ignore dmac in dev_forward_skb() · 81b9eab5
      Alexei Starovoitov 提交于
      commit 06a23fe3
      ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
      and refactoring 64261f23
      ("dev: move skb_scrub_packet() after eth_type_trans()")
      
      are forcing pkt_type to be PACKET_HOST when skb traverses veth.
      
      which means that ip forwarding will kick in inside netns
      even if skb->eth->h_dest != dev->dev_addr
      
      Fix order of eth_type_trans() and skb_scrub_packet() in dev_forward_skb()
      and in ip_tunnel_rcv()
      
      Fixes: 06a23fe3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
      CC: Isaku Yamahata <yamahatanetdev@gmail.com>
      CC: Maciej Zenczykowski <zenczykowski@gmail.com>
      CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81b9eab5