Switch it to be v2. Reject the case where the client sends and addrvec, though;
that should only happen for clients that did_bind, and they should only connect to
v2 if they have a v2 bound addr.
Signed-off-by: Sage Weil <sage@redhat.com>
We could have a fault on a server-side of a non-lossy connectoin where
there is a fault and we have outgoing data queued. Since we are a server,
we cannot connect; we should just go into standby and wait for the other
end to reconnect, or for someone to mark us down.
This fixes a failure reproduced by Messenger/MessengerTest.SyntheticInjectTest/0
where it would assert(!policy.server) in the connect code.
Signed-off-by: Sage Weil <sage@redhat.com>
If of relying on the peer to tell us what address we are connecting from,
look at how our local socket is bound, and use that address.
This removes the possibility for error because we will infer our address
locally and that will be the one place it is decide; the server will just
use our value. As things were previously, we had to make the local and
remote inference match, which was fragile.
This does take away the client's ability to discover if it is traversing
NAT to reach the server and learning its public/external address. I
don't think anybody has ever tested this, so it probably didn't even work,
and I've never heard it come up as a requirement.
Signed-off-by: Sage Weil <sage@redhat.com>
If we don't know our address yet, send the peer a 0.0.0.0 or :: address with an empty
port and a populated nonce. That way the peer can infer our final addr the same way
we do from learned_addr.
Signed-off-by: Sage Weil <sage@redhat.com>
If we are a client and didn't bind, then we should not fill in the port for our
address. The one the peer sent us is just the random port our outgoing connection
happened to land on!
Signed-off-by: Sage Weil <sage@redhat.com>
If we parse something out of mon_host or are given an addr by a user,
we should succeed as long as our target_addr is one of the destination's
addrs.
Signed-off-by: Sage Weil <sage@redhat.com>
If we have a connection race, and we lose, we may end up with outgoing
messages *and* be in ACCEPTING_SESSION. If we then fault, we want to
leave connect_seq at 0 to avoid triggering a reset.
Signed-off-by: Sage Weil <sage@redhat.com>
The session_key is unique for each time we newly authenticate with the
mon--e.g., for each client instantiation. This is not ideal for
encryption, since we don't want to encrypt all connections with the same
key.
Signed-off-by: Sage Weil <sage@redhat.com>
