1. 16 12月, 2015 1 次提交
  2. 01 12月, 2015 1 次提交
  3. 02 11月, 2015 2 次提交
  4. 19 10月, 2015 1 次提交
  5. 08 10月, 2015 10 次提交
  6. 30 9月, 2015 2 次提交
  7. 26 9月, 2015 1 次提交
  8. 18 9月, 2015 7 次提交
  9. 14 8月, 2015 1 次提交
  10. 13 6月, 2015 1 次提交
  11. 12 6月, 2015 1 次提交
  12. 28 5月, 2015 2 次提交
    • F
      ip_fragment: don't forward defragmented DF packet · d6b915e2
      Florian Westphal 提交于
      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: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6b915e2
    • F
      net: ipv4: avoid repeated calls to ip_skb_dst_mtu helper · c5501eb3
      Florian Westphal 提交于
      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: NFlorian Westphal <fw@strlen.de>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5501eb3
  13. 25 5月, 2015 1 次提交
  14. 19 5月, 2015 1 次提交
  15. 14 5月, 2015 1 次提交
  16. 08 4月, 2015 2 次提交
    • S
      net: remove extra newlines · 8bc0034c
      Sheng Yong 提交于
      Signed-off-by: NSheng Yong <shengyong1@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8bc0034c
    • D
      netfilter: Pass socket pointer down through okfn(). · 7026b1dd
      David Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      7026b1dd
  17. 04 4月, 2015 2 次提交
  18. 26 3月, 2015 1 次提交
  19. 23 3月, 2015 1 次提交
  20. 03 3月, 2015 1 次提交
    • M
      udp: only allow UFO for packets from SOCK_DGRAM sockets · acf8dd0a
      Michal Kubeček 提交于
      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: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acf8dd0a