1. 03 12月, 2006 7 次提交
  2. 03 8月, 2006 1 次提交
    • W
      [TCP]: SNMPv2 tcpAttemptFails counter error · 3687b1dc
      Wei Yongjun 提交于
      Refer to RFC2012, tcpAttemptFails is defined as following:
        tcpAttemptFails OBJECT-TYPE
            SYNTAX      Counter32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
                    "The number of times TCP connections have made a direct
                    transition to the CLOSED state from either the SYN-SENT
                    state or the SYN-RCVD state, plus the number of times TCP
                    connections have made a direct transition to the LISTEN
                    state from the SYN-RCVD state."
            ::= { tcp 7 }
      
      When I lookup into RFC793, I found that the state change should occured
      under following condition:
        1. SYN-SENT -> CLOSED
           a) Received ACK,RST segment when SYN-SENT state.
      
        2. SYN-RCVD -> CLOSED
           b) Received SYN segment when SYN-RCVD state(came from LISTEN).
           c) Received RST segment when SYN-RCVD state(came from SYN-SENT).
           d) Received SYN segment when SYN-RCVD state(came from SYN-SENT).
      
        3. SYN-RCVD -> LISTEN
           e) Received RST segment when SYN-RCVD state(came from LISTEN).
      
      In my test, those direct state transition can not be counted to
      tcpAttemptFails.
      Signed-off-by: NWei Yongjun <yjwei@nanjing-fnst.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3687b1dc
  3. 09 7月, 2006 1 次提交
  4. 01 7月, 2006 1 次提交
  5. 30 6月, 2006 1 次提交
    • H
      [NET]: Added GSO header verification · 576a30eb
      Herbert Xu 提交于
      When GSO packets come from an untrusted source (e.g., a Xen guest domain),
      we need to verify the header integrity before passing it to the hardware.
      
      Since the first step in GSO is to verify the header, we can reuse that
      code by adding a new bit to gso_type: SKB_GSO_DODGY.  Packets with this
      bit set can only be fed directly to devices with the corresponding bit
      NETIF_F_GSO_ROBUST.  If the device doesn't have that bit, then the skb
      is fed to the GSO engine which will allow the packet to be sent to the
      hardware if it passes the header check.
      
      This patch changes the sg flag to a full features flag.  The same method
      can be used to implement TSO ECN support.  We simply have to mark packets
      with CWR set with SKB_GSO_ECN so that only hardware with a corresponding
      NETIF_F_TSO_ECN can accept them.  The GSO engine can either fully segment
      the packet, or segment the first MTU and pass the rest to the hardware for
      further segmentation.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      576a30eb
  6. 23 6月, 2006 2 次提交
    • H
      [NET]: Add software TSOv4 · f4c50d99
      Herbert Xu 提交于
      This patch adds the GSO implementation for IPv4 TCP.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4c50d99
    • H
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu 提交于
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
      going to scale if we add any more segmentation methods (e.g., DCCP).  So
      let's merge them.
      
      They were used to tell the protocol of a packet.  This function has been
      subsumed by the new gso_type field.  This is essentially a set of netdev
      feature bits (shifted by 16 bits) that are required to process a specific
      skb.  As such it's easy to tell whether a given device can process a GSO
      skb: you just have to and the gso_type field and the netdev's features
      field.
      
      I've made gso_type a conjunction.  The idea is that you have a base type
      (e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
      For example, if we add a hardware TSO type that supports ECN, they would
      declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
      have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
      packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
      to be emulated in software.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7967168c
  7. 18 6月, 2006 5 次提交
  8. 26 4月, 2006 1 次提交
  9. 31 3月, 2006 1 次提交
  10. 21 3月, 2006 3 次提交
  11. 04 1月, 2006 4 次提交
  12. 16 11月, 2005 1 次提交
  13. 11 11月, 2005 6 次提交
  14. 09 10月, 2005 1 次提交
  15. 02 9月, 2005 1 次提交
  16. 30 8月, 2005 4 次提交
    • A
      [NET]: Fix sparse warnings · 20380731
      Arnaldo Carvalho de Melo 提交于
      Of this type, mostly:
      
      CHECK   net/ipv6/netfilter.c
      net/ipv6/netfilter.c:96:12: warning: symbol 'ipv6_netfilter_init' was not declared. Should it be static?
      net/ipv6/netfilter.c:101:6: warning: symbol 'ipv6_netfilter_fini' was not declared. Should it be static?
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20380731
    • A
      [INET_DIAG]: Move the tcp_diag interface to the proper place · 17b085ea
      Arnaldo Carvalho de Melo 提交于
      With this the previous setup is back, i.e. tcp_diag can be built as a module,
      as dccp_diag and both share the infrastructure available in inet_diag.
      
      If one selects CONFIG_INET_DIAG as module CONFIG_INET_TCP_DIAG will also be
      built as a module, as will CONFIG_INET_DCCP_DIAG, if CONFIG_IP_DCCP was
      selected static or as a module, if CONFIG_INET_DIAG is y, being statically
      linked CONFIG_INET_TCP_DIAG will follow suit and CONFIG_INET_DCCP_DIAG will be
      built in the same manner as CONFIG_IP_DCCP.
      
      Now to aim at UDP, converting it to use inet_hashinfo, so that we can use
      iproute2 for UDP sockets as well.
      
      Ah, just to show an example of this new infrastructure working for DCCP :-)
      
      [root@qemu ~]# ./ss -dane
      State      Recv-Q Send-Q Local Address:Port  Peer Address:Port
      LISTEN     0      0                  *:5001             *:*     ino:942 sk:cfd503a0
      ESTAB      0      0          127.0.0.1:5001     127.0.0.1:32770 ino:943 sk:cfd50a60
      ESTAB      0      0          127.0.0.1:32770    127.0.0.1:5001  ino:947 sk:cfd50700
      TIME-WAIT  0      0          127.0.0.1:32769    127.0.0.1:5001  timer:(timewait,3.430ms,0) ino:0 sk:cf209620
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17b085ea
    • A
      [TCPDIAG]: Just rename everything to inet_diag · 73c1f4a0
      Arnaldo Carvalho de Melo 提交于
      Next changeset will rename tcp_diag.[ch] to inet_diag.[ch].
      
      I'm taking this longer route so as to easy review, making clear the changes
      made all along the way.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73c1f4a0
    • A
      [ICSK]: Move TCP congestion avoidance members to icsk · 6687e988
      Arnaldo Carvalho de Melo 提交于
      This changeset basically moves tcp_sk()->{ca_ops,ca_state,etc} to inet_csk(),
      minimal renaming/moving done in this changeset to ease review.
      
      Most of it is just changes of struct tcp_sock * to struct sock * parameters.
      
      With this we move to a state closer to two interesting goals:
      
      1. Generalisation of net/ipv4/tcp_diag.c, becoming inet_diag.c, being used
         for any INET transport protocol that has struct inet_hashinfo and are
         derived from struct inet_connection_sock. Keeps the userspace API, that will
         just not display DCCP sockets, while newer versions of tools can support
         DCCP.
      
      2. INET generic transport pluggable Congestion Avoidance infrastructure, using
         the current TCP CA infrastructure with DCCP.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6687e988