1. 02 Jun, 2009 1 commit
  2. 01 Jun, 2009 3 commits
  3. 30 May, 2009 4 commits
  4. 29 May, 2009 5 commits
  5. 27 May, 2009 8 commits
  6. 26 May, 2009 4 commits
  7. 25 May, 2009 3 commits
    • Pablo Neira Ayuso's avatar
      netfilter: nf_ct_dccp: add missing DCCP protocol changes in event cache · b38b1f61
      Pablo Neira Ayuso authored
      This patch adds the missing protocol state-change event reporting
      for DCCP.
      
      $ sudo conntrack -E
          [NEW] dccp     33 240 src=192.168.0.2 dst=192.168.1.2 sport=57040 dport=5001 [UNREPLIED] src=192.168.1.2 dst=192.168.1.100 sport=5001 dport=57040
      
      With this patch:
      
      $ sudo conntrack -E
          [NEW] dccp     33 240 REQUEST src=192.168.0.2 dst=192.168.1.2 sport=57040 dport=5001 [UNREPLIED] src=192.168.1.2 dst=192.168.1.100 sport=5001 dport=57040
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      b38b1f61
    • Jozsef Kadlecsik's avatar
      netfilter: nf_ct_tcp: fix accepting invalid RST segments · bfcaa502
      Jozsef Kadlecsik authored
      Robert L Mathews discovered that some clients send evil TCP RST segments,
      which are accepted by netfilter conntrack but discarded by the
      destination. Thus the conntrack entry is destroyed but the destination
      retransmits data until timeout.
      
      The same technique, i.e. sending properly crafted RST segments, can easily
      be used to bypass connlimit/connbytes based restrictions (the sample
      script written by Robert can be found in the netfilter mailing list
      archives).
      
      The patch below adds a new flag and new field to struct ip_ct_tcp_state so
      that checking RST segments can be made more strict and thus TCP conntrack
      can catch the invalid ones: the RST segment is accepted only if its
      sequence number higher than or equal to the highest ack we seen from the
      other direction. (The last_ack field cannot be reused because it is used
      to catch resent packets.)
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      bfcaa502
    • Lennert Buytenhek's avatar
      gianfar: fix BUG under load after introduction of skb recycling · 4e2fd555
      Lennert Buytenhek authored
      Since commit 0fd56bb5 ("gianfar:
      Add support for skb recycling"), gianfar puts skbuffs that are in
      the rx ring back onto the recycle list as-is in case there was a
      receive error, but this breaks the following invariant: that all
      skbuffs on the recycle list have skb->data = skb->head + NET_SKB_PAD.
      
      The RXBUF_ALIGNMENT realignment done in gfar_new_skb() will be done
      twice on skbuffs recycled in this way, causing there not to be enough
      room in the skb anymore to receive a full packet, eventually leading
      to an skb_over_panic from gfar_clean_rx_ring() -> skb_put().
      
      Resetting the skb->data pointer to skb->head + NET_SKB_PAD before
      putting the skb back onto the recycle list restores the mentioned
      invariant, and should fix this issue.
      Reported-by: default avatarMichael Guntsche <mike@it-loops.com>
      Tested-by: default avatarMichael Guntsche <mike@it-loops.com>
      Signed-off-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e2fd555
  8. 22 May, 2009 1 commit
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: usb: fix device reset on autosuspend while not yet idle · e069c0cf
      Inaky Perez-Gonzalez authored
      When the i2400m is connected to a network, the host interface (USB)
      cannot be suspended. For that to happen, the device has to have
      negotiated with the basestation to put the link on IDLE state.
      
      If the host tries to put the device in standby while it is connected
      but not idle, the device resets, as the driver should not do that.
      
      To avoid triggering that, when the USB susbsytem requires the driver
      to autosuspend the device, the driver checks if the device is not yet
      idle. If it is not, the request is rejected (will be retried again
      later on after the autosuspend timeout). At some point the device will
      enter idle and the request will succeed (unless of course, there is
      network traffic, but at that point, there is no idle neither in the
      link or the host interface).
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      e069c0cf
  9. 21 May, 2009 8 commits
  10. 20 May, 2009 3 commits