1. 11 Jan, 2016 1 commit
  2. 01 Nov, 2015 2 commits
  3. 18 Oct, 2015 1 commit
  4. 08 Oct, 2015 10 commits
  5. 30 Sep, 2015 1 commit
  6. 29 Sep, 2015 1 commit
  7. 25 Sep, 2015 1 commit
  8. 17 Sep, 2015 7 commits
  9. 13 Aug, 2015 1 commit
  10. 12 Jun, 2015 2 commits
  11. 27 May, 2015 2 commits
    • Florian Westphal's avatar
      ip_fragment: don't forward defragmented DF packet · d6b915e2
      Florian Westphal authored
      
      
      We currently always send fragments without DF bit set.
      
      Thus, given following setup:
      
      mtu1500 - mtu1500:1400 - mtu1400:1280 - mtu1280
         A           R1              R2         B
      
      Where R1 and R2 run linux with netfilter defragmentation/conntrack
      enabled, then if Host A sent a fragmented packet _with_ DF set to B, R1
      will respond with icmp too big error if one of these fragments exceeded
      1400 bytes.
      
      However, if R1 receives fragment sizes 1200 and 100, it would
      forward the reassembled packet without refragmenting, i.e.
      R2 will send an icmp error in response to a packet that was never sent,
      citing mtu that the original sender never exceeded.
      
      The other minor issue is that a refragmentation on R1 will conceal the
      MTU of R2-B since refragmentation does not set DF bit on the fragments.
      
      This modifies ip_fragment so that we track largest fragment size seen
      both for DF and non-DF packets, and set frag_max_size to the largest
      value.
      
      If the DF fragment size is larger or equal to the non-df one, we will
      consider the packet a path mtu probe:
      We set DF bit on the reassembled skb and also tag it with a new IPCB flag
      to force refragmentation even if skb fits outdev mtu.
      
      We will also set DF bit on each fragment in this case.
      
      Joint work with Hannes Frederic Sowa.
      Reported-by: default avatarJesse Gross <jesse@nicira.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6b915e2
    • Florian Westphal's avatar
      net: ipv4: avoid repeated calls to ip_skb_dst_mtu helper · c5501eb3
      Florian Westphal authored
      
      
      ip_skb_dst_mtu is small inline helper, but its called in several places.
      
      before: 17061      44       0   17105    42d1 net/ipv4/ip_output.o
      after:  16805      44       0   16849    41d1 net/ipv4/ip_output.o
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5501eb3
  12. 24 May, 2015 1 commit
  13. 18 May, 2015 1 commit
  14. 13 May, 2015 1 commit
  15. 07 Apr, 2015 2 commits
    • Sheng Yong's avatar
      net: remove extra newlines · 8bc0034c
      Sheng Yong authored
      
      Signed-off-by: default avatarSheng Yong <shengyong1@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8bc0034c
    • David Miller's avatar
      netfilter: Pass socket pointer down through okfn(). · 7026b1dd
      David Miller authored
      
      
      On the output paths in particular, we have to sometimes deal with two
      socket contexts.  First, and usually skb->sk, is the local socket that
      generated the frame.
      
      And second, is potentially the socket used to control a tunneling
      socket, such as one the encapsulates using UDP.
      
      We do not want to disassociate skb->sk when encapsulating in order
      to fix this, because that would break socket memory accounting.
      
      The most extreme case where this can cause huge problems is an
      AF_PACKET socket transmitting over a vxlan device.  We hit code
      paths doing checks that assume they are dealing with an ipv4
      socket, but are actually operating upon the AF_PACKET one.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7026b1dd
  16. 03 Apr, 2015 2 commits
  17. 25 Mar, 2015 1 commit
  18. 22 Mar, 2015 1 commit
  19. 02 Mar, 2015 1 commit
    • Michal Kubeček's avatar
      udp: only allow UFO for packets from SOCK_DGRAM sockets · acf8dd0a
      Michal Kubeček authored
      
      
      If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a
      UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to
      CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer
      checksum is to be computed on segmentation. However, in this case,
      skb->csum_start and skb->csum_offset are never set as raw socket
      transmit path bypasses udp_send_skb() where they are usually set. As a
      result, driver may access invalid memory when trying to calculate the
      checksum and store the result (as observed in virtio_net driver).
      
      Moreover, the very idea of modifying the userspace provided UDP header
      is IMHO against raw socket semantics (I wasn't able to find a document
      clearly stating this or the opposite, though). And while allowing
      CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit
      too intrusive change just to handle a corner case like this. Therefore
      disallowing UFO for packets from SOCK_DGRAM seems to be the best option.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acf8dd0a
  20. 03 Feb, 2015 1 commit