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