OpenAFS Master Repository branch, master, updated. openafs-devel-1_5_76-4529-g05217c2

[Gerrit Code Review]

The following commit has been merged in the master branch:
commit 05217c29179100b69a32562202b302ae60b4b36c
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Oct 1 14:54:15 2013 -0500

    rx: Ignore responses to nonexistent challenges
    
    Consider the following situation:
    
     - A client sends a data packet to a server, using a security class
       that requires a challenge
     - The server responds with a challenge
     - The server is restarted
     - The client responds to the challenge with a response
    
    In that situation, the server will process the response, but since the
    server was restarted, it has no knowledge of the challenge that was
    sent. This generally means that we error the connection, since the
    given response is not valid. For rxkad with modern endpoints, this
    results in an RXKADPACKETSHORT error, since we interpret the response
    as an 'old' response, but it's actually a 'v2' response, so we
    interpret the fields in the response as garbage.
    
    This means that the client gets a connection error when the client did
    nothing wrong, and there's no way for the client to distinguish this
    from a real connection error.
    
    One way to solve this would be to send a Challenge packet to the
    client immediately when we detect that this situation has occurred.
    However, if we do that, then we never see a data packet with a
    checksum, so we fall back to using "old" challenges and responses. And
    in general, that would cause the server side to never see a data
    packet during the connection negotiation, which is unusual and I am
    concerned there may be other niggles of odd behavior that may occur in
    that scenario.
    
    So instead, to fix this, make the server ignore responses in this
    situation (that is, if we haven't sent out any challenges yet).
    Clients will eventually resend the data packet, and we will go through
    negotiating the connection security like normal. This should never
    cause any new problems, since dropping a challenge packet must be
    handled anyway (sometimes packets just get dropped). And a client will
    never hang on sending the same response over and over again; clients
    only ever send a Response in response to a Challenge packet.
    
    Change-Id: Id3fae425addb2ac8ab60965213b3ebca2e64ba5d
    Reviewed-on: http://gerrit.openafs.org/10315
    Reviewed-by: Daria Brashear <shadow@your-file-system.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

 src/rx/rx.c      |   11 +++++++++++
 src/rx/rx_conn.h |    1 +
 2 files changed, 12 insertions(+), 0 deletions(-)

-- 
OpenAFS Master Repository