Skip to content
  • Thomas Graf's avatar
    sctp: Enforce retransmission limit during shutdown · f8d96052
    Thomas Graf authored
    
    
    When initiating a graceful shutdown while having data chunks
    on the retransmission queue with a peer which is in zero
    window mode the shutdown is never completed because the
    retransmission error count is reset periodically by the
    following two rules:
    
     - Do not timeout association while doing zero window probe.
     - Reset overall error count when a heartbeat request has
       been acknowledged.
    
    The graceful shutdown will wait for all outstanding TSN to
    be acknowledged before sending the SHUTDOWN request. This
    never happens due to the peer's zero window not acknowledging
    the continuously retransmitted data chunks. Although the
    error counter is incremented for each failed retransmission,
    the receiving of the SACK announcing the zero window clears
    the error count again immediately. Also heartbeat requests
    continue to be sent periodically. The peer acknowledges these
    requests causing the error counter to be reset as well.
    
    This patch changes behaviour to only reset the overall error
    counter for the above rules while not in shutdown. After
    reaching the maximum number of retransmission attempts, the
    T5 shutdown guard timer is scheduled to give the receiver
    some additional time to recover. The timer is stopped as soon
    as the receiver acknowledges any data.
    
    The issue can be easily reproduced by establishing a sctp
    association over the loopback device, constantly queueing
    data at the sender while not reading any at the receiver.
    Wait for the window to reach zero, then initiate a shutdown
    by killing both processes simultaneously. The association
    will never be freed and the chunks on the retransmission
    queue will be retransmitted indefinitely.
    
    Signed-off-by: default avatarThomas Graf <tgraf@infradead.org>
    Acked-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    f8d96052