1. 04 8月, 2015 1 次提交
  2. 30 7月, 2015 2 次提交
  3. 29 7月, 2015 2 次提交
    • E
      arp: filter NOARP neighbours for SIOCGARP · 11c91ef9
      Eric Dumazet 提交于
      When arp is off on a device, and ioctl(SIOCGARP) is queried,
      a buggy answer is given with MAC address of the device, instead
      of the mac address of the destination/gateway.
      
      We filter out NUD_NOARP neighbours for /proc/net/arp,
      we must do the same for SIOCGARP ioctl.
      
      Tested:
      
      lpaa23:~# ./arp 10.246.7.190
      MAC=00:01:e8:22:cb:1d      // correct answer
      
      lpaa23:~# ip link set dev eth0 arp off
      lpaa23:~# cat /proc/net/arp   # check arp table is now 'empty'
      IP address       HW type     Flags       HW address    Mask     Device
      lpaa23:~# ./arp 10.246.7.190
      MAC=00:1a:11:c3:0d:7f   // buggy answer before patch (this is eth0 mac)
      
      After patch :
      
      lpaa23:~# ip link set dev eth0 arp off
      lpaa23:~# ./arp 10.246.7.190
      ioctl(SIOCGARP) failed: No such device or address
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NVytautas Valancius <valas@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11c91ef9
    • D
      net/ipv4: suppress NETDEV_UP notification on address lifetime update · 865b8042
      David Ward 提交于
      This notification causes the FIB to be updated, which is not needed
      because the address already exists, and more importantly it may undo
      intentional changes that were made to the FIB after the address was
      originally added. (As a point of comparison, when an address becomes
      deprecated because its preferred lifetime expired, a notification on
      this chain is not generated.)
      
      The motivation for this commit is fixing an incompatibility between
      DHCP clients which set and update the address lifetime according to
      the lease, and a commercial VPN client which replaces kernel routes
      in a way that outbound traffic is sent only through the tunnel (and
      disconnects if any further route changes are detected via netlink).
      Signed-off-by: NDavid Ward <david.ward@ll.mit.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      865b8042
  4. 28 7月, 2015 1 次提交
  5. 27 7月, 2015 8 次提交
  6. 25 7月, 2015 2 次提交
    • J
      ipv4: consider TOS in fib_select_default · 2392debc
      Julian Anastasov 提交于
      fib_select_default considers alternative routes only when
      res->fi is for the first alias in res->fa_head. In the
      common case this can happen only when the initial lookup
      matches the first alias with highest TOS value. This
      prevents the alternative routes to require specific TOS.
      
      This patch solves the problem as follows:
      
      - routes that require specific TOS should be returned by
      fib_select_default only when TOS matches, as already done
      in fib_table_lookup. This rule implies that depending on the
      TOS we can have many different lists of alternative gateways
      and we have to keep the last used gateway (fa_default) in first
      alias for the TOS instead of using single tb_default value.
      
      - as the aliases are ordered by many keys (TOS desc,
      fib_priority asc), we restrict the possible results to
      routes with matching TOS and lowest metric (fib_priority)
      and routes that match any TOS, again with lowest metric.
      
      For example, packet with TOS 8 can not use gw3 (not lowest
      metric), gw4 (different TOS) and gw6 (not lowest metric),
      all other gateways can be used:
      
      tos 8 via gw1 metric 2 <--- res->fa_head and res->fi
      tos 8 via gw2 metric 2
      tos 8 via gw3 metric 3
      tos 4 via gw4
      tos 0 via gw5
      tos 0 via gw6 metric 1
      Reported-by: NHagen Paul Pfeifer <hagen@jauu.net>
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2392debc
    • J
      ipv4: fib_select_default should match the prefix · 18a912e9
      Julian Anastasov 提交于
      fib_trie starting from 4.1 can link fib aliases from
      different prefixes in same list. Make sure the alternative
      gateways are in same table and for same prefix (0) by
      checking tb_id and fa_slen.
      
      Fixes: 79e5ad2c ("fib_trie: Remove leaf_info")
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18a912e9
  7. 23 7月, 2015 1 次提交
  8. 22 7月, 2015 11 次提交
  9. 16 7月, 2015 6 次提交
  10. 12 7月, 2015 1 次提交
    • F
      Revert "ipv4: use skb coalescing in defragmentation" · 14fe22e3
      Florian Westphal 提交于
      This reverts commit 3cc49492.
      
      There is nothing wrong with coalescing during defragmentation, it
      reduces truesize overhead and simplifies things for the receiving
      socket (no fraglist walk needed).
      
      However, it also destroys geometry of the original fragments.
      While that doesn't cause any breakage (we make sure to not exceed largest
      original size) ip_do_fragment contains a 'fastpath' that takes advantage
      of a present frag list and results in fragments that (in most cases)
      match what was received.
      
      In case its needed the coalescing could be done later, when we're sure
      the skb is not forwarded.  But discussion during NFWS resulted in
      'lets just remove this for now'.
      
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14fe22e3
  11. 11 7月, 2015 1 次提交
    • P
      net: inet_diag: always export IPV6_V6ONLY sockopt for listening sockets · 8220ea23
      Phil Sutter 提交于
      Reconsidering my commit 20462155 "net: inet_diag: export IPV6_V6ONLY
      sockopt", I am not happy with the limitations it causes for socket
      analysing code in userspace. Exporting the value only if it is set makes
      it hard for userspace to decide whether the option is not set or the
      kernel does not support exporting the option at all.
      
      >From an auditor's perspective, the interesting question for listening
      AF_INET6 sockets is: "Does it NOT have IPV6_V6ONLY set?" Because it is
      the unexpected case. This patch allows to answer this question reliably.
      Signed-off-by: NPhil Sutter <phil@nwl.cc>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8220ea23
  12. 10 7月, 2015 4 次提交