16 Jun, 2015

1 commit

  • Previously, there was no clear distinction between the inet protocols
    that used struct tcp_info to report information and those that didn't.
    This change adds a specific size attribute to the inet_diag_handler
    struct which defines these interfaces. This will make dispatching
    sock_diag get_info requests identical for all inet protocols in a
    following patch.

    Tested: ss -au
    Tested: ss -at
    Signed-off-by: Craig Gallek
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Craig Gallek
     

11 Mar, 2015

1 commit


12 Jan, 2012

1 commit


17 Dec, 2011

1 commit

  • I've made a mistake when fixing the sock_/inet_diag aliases :(

    1. The sock_diag layer should request the family-based alias,
    not just the IPPROTO_IP one;
    2. The inet_diag layer should request for AF_INET+protocol alias,
    not just the protocol one.

    Thus fix this.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     

10 Dec, 2011

2 commits


07 Dec, 2011

2 commits

  • Sorry, but the vger didn't let this message go to the list. Re-sending it with
    less spam-filter-prone subject.

    When dumping the AF_INET/AF_INET6 sockets user will also specify the protocol,
    so prepare the protocol diag handlers to work with IPPROTO_ constants.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     
  • The ultimate goal is to get the sock_diag module, that works in
    family+protocol terms. Currently this is suitable to do on the
    inet_diag basis, so rename parts of the code. It will be moved
    to sock_diag.c later.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     

18 Dec, 2008

1 commit

  • And thus when we try to use 'ss -danemi' on these sockets that have no
    ccid blocks (data collected using systemtap after I fixed the problem):

    dccp_diag_get_info sk=0xffff8801220a3100, dp->dccps_hc_rx_ccid=0x0000000000000000, dp->dccps_hc_tx_ccid=0x0000000000000000

    We get an OOPS:

    mica.ghostprotocols.net login: BUG: unable to handle kernel NULL pointer
    dereferenc0
    IP: [] dccp_diag_get_info+0x82/0xc0 [dccp_diag]
    PGD 12106f067 PUD 122488067 PMD 0
    Oops: 0000 [#1] PREEMPT

    Fix is trivial, and 'ss -d' is working again:

    [root@mica ~]# ss -danemi
    State Recv-Q Send-Q Local Address:Port Peer Address:Port
    LISTEN 0 0 *:5001 *:*
    ino:7288 sk:220a3100ffff8801
    mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
    [root@mica ~]#

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

08 Dec, 2008

1 commit

  • This removes the use of the sysctl and the minisock variable for the Send Ack
    Vector feature, as it now is handled fully dynamically via feature negotiation
    (i.e. when CCID-2 is enabled, Ack Vectors are automatically enabled as per
    RFC 4341, 4.).

    Using a sysctl in parallel to this implementation would open the door to
    crashes, since much of the code relies on tests of the boolean minisock /
    sysctl variable. Thus, this patch replaces all tests of type

    if (dccp_msk(sk)->dccpms_send_ack_vector)
    /* ... */
    with
    if (dp->dccps_hc_rx_ackvec != NULL)
    /* ... */

    The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
    negotiation concluded that Ack Vectors are to be used on the half-connection.
    Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
    so that the test is a valid one.

    The activation handler for Ack Vectors is called as soon as the feature
    negotiation has concluded at the
    * server when the Ack marking the transition RESPOND => OPEN arrives;
    * client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.

    Adding the sequence number of the Response packet to the Ack Vector has been
    removed, since
    (a) connection establishment implies that the Response has been received;
    (b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
    this entry will always be ignored;
    (c) it can not be used for anything useful - to detect loss for instance, only
    packets received after the loss can serve as pseudo-dupacks.

    There was a FIXME to change the error code when dccp_ackvec_add() fails.
    I removed this after finding out that:
    * the check whether ackno < ISN is already made earlier,
    * this Response is likely the 1st packet with an Ackno that the client gets,
    * so when dccp_ackvec_add() fails, the reason is likely not a packet error.

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     

20 Nov, 2008

1 commit


22 Oct, 2007

1 commit


01 Jul, 2006

1 commit


21 Mar, 2006

1 commit

  • This will later be included in struct dccp_request_sock so that we can
    have per connection feature negotiation state while in the 3way
    handshake, when we clone the DCCP_ROLE_LISTEN socket (in
    dccp_create_openreq_child) we'll just copy this state from
    dreq_minisock to dccps_minisock.

    Also the feature negotiation and option parsing code will mostly touch
    dccps_minisock, which will simplify some stuff.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

04 Jan, 2006

1 commit

  • As DCCP needs to be called in the same spots.

    Now we have a member in inet_sock (is_icsk), set at sock creation time from
    struct inet_protosw->flags (if INET_PROTOSW_ICSK is set, like for TCP and
    DCCP) to see if a struct sock instance is a inet_connection_sock for places
    like the ones in ip_sockglue.c (v4 and v6) where we previously were looking if
    sk_type was SOCK_STREAM, that is insufficient because we now use the same code
    for DCCP, that has sk_type SOCK_DCCP.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

30 Aug, 2005

4 commits

  • And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
    information that is specific to them.

    For now reusing struct tcp_info, later I'll try to figure out a better
    solution, for now its really nice to get this kind of info:

    [root@qemu ~]# ./ss -danemi
    State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
    LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
    mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
    ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
    mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377

    This, for instance, shows that we're not congestion controlling ACKs,
    as the above output is in the ttcp receiving host, and ttcp is a one
    way app, i.e. the received never calls sendmsg, so
    ccid_hc_tx_send_packet is never called, so the TX half connection
    stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
    stays with the value set in ccid3_hc_tx_init, 4us, as show above in
    milliseconds (0.004ms), upcoming patches will fix this.

    rcv_rtt seems sane tho, matching ping results :-)

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • Next changeset will introduce net/ipv4/tcp_diag.c, moving the code that was put
    transitioanlly in inet_diag.c.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    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: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • Next changeset will rename tcp_diag to inet_diag and move the tcp_diag code out
    of it and into a new tcp_diag.c, similar to the net/dccp/diag.c introduced in
    this changeset, completing the transition to a generic inet_diag
    infrastructure.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo