Following up on a pub conversation from a couple weeks ago: The client apparently assumes that (in the absence of state protection) sending a SEQUENCE over a new tcp connection to the server automatically associates the new tcp connection with both the forechannel and backchannel of the session. The server currently assumes that the new tcp connection should be associated only with the forechannel. RFC 5661 sides with the forechannel-only convention: - 2.6.10.6.2: "If the client wants to use additional connections for the backchannel, then it needs to call BIND_CONN_TO_SESSION on each connection it wants to use with the session." - 2.10.13.1.2: "If the connection that was lost was the last one associated with the backchannel, and the client wants to retain the backchannel and/or prevent revocation of recallable state, the client needs to reconnect, and if it does, it MUST associate the connection to the session and backchannel via BIND_CONN_TO_SESSION." - 18.34.3: "If, when the client ID was created, the client opted for SP4_NONE state protection, the client is not required to use BIND_CONN_TO_SESSION to associate the connection with the session, unless the client wishes to associate the connection with the backchannel." That means that currently if the client attempts to reconnect (e.g. to resend a timed-out rpc), it will see SEQ4_STATUS_CB_PATH_DOWN_SESSION set on future SEQUENCE replies. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
