1. 14 11月, 2008 10 次提交
  2. 04 11月, 2008 1 次提交
  3. 03 11月, 2008 3 次提交
  4. 02 11月, 2008 4 次提交
  5. 01 11月, 2008 1 次提交
    • A
      key: fix setkey(8) policy set breakage · 920da692
      Alexey Dobriyan 提交于
      Steps to reproduce:
      
      	#/usr/sbin/setkey -f
      	flush;
      	spdflush;
      
      	add 192.168.0.42 192.168.0.1 ah 24500 -A hmac-md5 "1234567890123456";
      	add 192.168.0.42 192.168.0.1 esp 24501 -E 3des-cbc "123456789012123456789012";
      
      	spdadd 192.168.0.42 192.168.0.1 any -P out ipsec
      		esp/transport//require
      		ah/transport//require;
      
      setkey: invalid keymsg length
      
      Policy dump will bail out with the same message after that.
      
      -recv(4, "\2\16\0\0\32\0\3\0\0\0\0\0\37\r\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208
      +recv(4, "\2\16\0\0\36\0\3\0\0\0\0\0H\t\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      920da692
  6. 31 10月, 2008 3 次提交
  7. 30 10月, 2008 3 次提交
  8. 29 10月, 2008 4 次提交
  9. 28 10月, 2008 2 次提交
  10. 27 10月, 2008 3 次提交
  11. 24 10月, 2008 1 次提交
    • I
      tcp: Restore ordering of TCP options for the sake of inter-operability · fd6149d3
      Ilpo Järvinen 提交于
      This is not our bug! Sadly some devices cannot cope with the change
      of TCP option ordering which was a result of the recent rewrite of
      the option code (not that there was some particular reason steming
      from the rewrite for the reordering) though any ordering of TCP
      options is perfectly legal. Thus we restore the original ordering
      to allow interoperability with/through such broken devices and add
      some warning about this trap. Since the reordering just happened
      without any particular reason, this change shouldn't cost us
      anything.
      
      There are already couple of known failure reports (within close
      proximity of the last release), so the problem might be more
      wide-spread than a single device. And other reports which may
      be due to the same problem though the symptoms were less obvious.
      Analysis of one of the case revealed (with very high probability)
      that sack capability cannot be negotiated as the first option
      (SYN never got a response).
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Reported-by: NAldo Maggi <sentiniate@tiscali.it>
      Tested-by: NAldo Maggi <sentiniate@tiscali.it>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd6149d3
  12. 23 10月, 2008 5 次提交
    • A
      [PATCH] assorted path_lookup() -> kern_path() conversions · 421748ec
      Al Viro 提交于
      more nameidata eviction
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      421748ec
    • H
      net: Fix disjunct computation of netdev features · b63365a2
      Herbert Xu 提交于
      My change
      
          commit e2a6b852
          net: Enable TSO if supported by at least one device
      
      didn't do what was intended because the netdev_compute_features
      function was designed for conjunctions.  So what happened was that
      it would simply take the TSO status of the last constituent device.
      
      This patch extends it to support both conjunctions and disjunctions
      under the new name of netdev_increment_features.
      
      It also adds a new function netdev_fix_features which does the
      sanity checking that usually occurs upon registration.  This ensures
      that the computation doesn't result in an illegal combination
      since this checking is absent when the change is initiated via
      ethtool.
      
      The two users of netdev_compute_features have been converted.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b63365a2
    • W
      sctp: Fix to handle SHUTDOWN in SHUTDOWN_RECEIVED state · 2e3f92da
      Wei Yongjun 提交于
      Once an endpoint has reached the SHUTDOWN-RECEIVED state,
      it MUST NOT send a SHUTDOWN in response to a ULP request.
      The Cumulative TSN Ack of the received SHUTDOWN chunk
      MUST be processed.
      
      This patch fix to process Cumulative TSN Ack of the received
      SHUTDOWN chunk in SHUTDOWN_RECEIVED state.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e3f92da
    • W
      sctp: Fix to handle SHUTDOWN in SHUTDOWN-PENDING state · cf896d51
      Wei Yongjun 提交于
      If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should enter
      the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack field of
      the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk can
      acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be sent.
      
      But now endpoint just silently discarded the SHUTDOWN chunk.
      
      SHUTDOWN received in SHUTDOWN-PENDING state can happend when the last
      SACK is lost by network, or the SHUTDOWN chunk can acknowledge all of
      the received DATA chunks. The packet sequence(SACK lost) is like this:
      
      Endpoint A                       Endpoint B       ULP
      (ESTABLISHED)                    (ESTABLISHED)
      
                     <-----------      DATA
                                                   <--- shutdown
                                       Enter SHUTDOWN-PENDING state
        SACK         ----lost---->
      
        SHUTDOWN(*1) ------------>
      
                     <-----------      SHUTDOWN-ACK
      
       (*1) silently discarded now.
      
      This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as the same
      as ESTABLISHED state.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf896d51
    • W
      sctp: Add check for the TSN field of the SHUTDOWN chunk · df10eec4
      Wei Yongjun 提交于
      If SHUTDOWN chunk is received Cumulative TSN Ack beyond the max tsn currently
      send, SHUTDOWN chunk be accepted and the association will be broken. New data
      is send, but after received SACK it will be drop because TSN in SACK is less
      than the Cumulative TSN, data will be retrans again and again even if correct
      SACK is received.
      
      The packet sequence is like this:
      
      Endpoint A                       Endpoint B       ULP
      (ESTABLISHED)                    (ESTABLISHED)
      
                     <-----------      DATA (TSN=x-1)
      
                     <-----------      DATA (TSN=x)
      
        SHUTDOWN     ----------->      (Now Cumulative TSN=x+1000)
        (TSN=x+1000)
                     <-----------      DATA (TSN=x+1)
      
        SACK         ----------->      drop the SACK
        (TSN=x+1)
                     <-----------      DATA (TSN=x+1)(retrans)
      
      This patch fix this problem by terminating the association and respond to
      the sender with an ABORT.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df10eec4