1. 02 Feb, 2007 22 commits
  2. 01 Feb, 2007 2 commits
  3. 31 Jan, 2007 12 commits
  4. 30 Jan, 2007 4 commits
    • Vlad Yasevich's avatar
      [SCTP]: Force update of the rto when processing HB-ACK · e533ca16
      Vlad Yasevich authored
      When processing a HEARTBEAT-ACK it's possible that the transport rto
      timers will not be updated because a prior T3-RTX processing would
      have cleared the rto_pending flag on the transport.  However, if
      we received a valid HEARTBEAT-ACK, we want to force update the
      rto variables, so re-set the rto_pending flag before calling
      sctp_transport_update_rto().
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e533ca16
    • Li Yewang's avatar
      [IPV6]: fix BUG of ndisc_send_redirect() · 29556526
      Li Yewang authored
        When I tested IPv6 redirect function about kernel 2.6.19.1, and found
      that the kernel can send redirect packets whose target address is global
      address, and the target is not the actual endpoint of communication.
      
        But the criteria conform to RFC2461, the target address defines as
      following:
      
        Target Address An IP address that is a better first hop to use for
                       he ICMP Destination Address.  When the target is
                       the actual endpoint of communication, i.e., the
                       destination is a neighbor, the Target Address field
                       MUST contain the same value as the ICMP Destination
                       Address field.  Otherwise the target is a better
                       first-hop router and the Target Address MUST be the
                       router's link-local address so that hosts can
                       uniquely identify routers.
      
      According to this definition, when a router redirect to a host, the
      target address either the better first-hop router's link-local address
      or the same as the ICMP destination address field. But the function of
      ndisc_send_redirect() in net/ipv6/ndisc.c, does not check the target
      address correctly.
      
      There is another definition about receive Redirect message in RFC2461:
      
      8.1.  Validation of Redirect Messages
      
         A host MUST silently discard any received Redirect message that does
         not satisfy all of the following validity checks:
         ......
         - The ICMP Target Address is either a link-local address (when
           redirected to a router) or the same as the ICMP Destination
           Address (when redirected to the on-link destination).
         ......
      
      And the receive redirect function of ndisc_redirect_rcv() implemented
      this definition, checks the target address correctly.
          if (ipv6_addr_equal(dest, target)) {
              on_link = 1;
          } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
              ND_PRINTK2(KERN_WARNING
                     "ICMPv6 Redirect: target address is not link-local.\n");
              return;
          }
      
      So, I think the send redirect function must check the target address
      also.
      Signed-off-by: default avatarLi Yewang <lyw@nanjing-fnst.com>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29556526
    • Neil Horman's avatar
      [IPV6]: Fix up some CONFIG typos · fa03ef38
      Neil Horman authored
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa03ef38
    • Patrick McHardy's avatar
      [NETFILTER]: SIP conntrack: fix out of bounds memory access · adcb4711
      Patrick McHardy authored
      When checking for an @-sign in skp_epaddr_len, make sure not to
      run over the packet boundaries.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      adcb4711