> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of > Viktor Dukhovni > Sent: Friday, February 08, 2019 13:00 > > > On Feb 8, 2019, at 12:55 PM, Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> > wrote: > > > > For IPv4: Create your socket, bind it to the local interface you want to > use (specifying a port of 0 if you want an ephemeral port assigned as in the > usual case), then connect to the peer. You'll probably want to enable > SO_REUSEADDR on the socket before calling bind. > > For the record, one should *not* use SO_REUSEADDR for client sockets used in > outbound connections. Not usually, but in the specific case of testing connections bound to specific local addresses - an artificial use case - it will either avoid having to wait for the 2MSL timer to expire (if you bind to a specific local port) or exhausing the ephemeral port space (if you use a stack-assigned ephemeral port) if you're making a lot of short-lived connections. Obviously bypassing TIME_WAIT this way introduces precisely the problem that TIME_WAIT exists to prevent: picking up data from a previous connection. However, modern stacks with randomized ISNs make the failure mode for that situation more palatable (more likely to produce an error state rather than silently accepting the stale data), and applications that implement their own session and/or presentation layers on top of the TCP bytestream will typically do a good job of 1) ensuring there isn't any stale data, and 2) detecting it if there is. TLS provides such a layer. I recognize that the use of SO_REUSEADDR on the active-open (client) side is controversial, but this particular use case shouldn't appear in a production environment anyway. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
