"J.P." writes: > At the end of the day, I still question the soundness of resorting to a > protocol exchange to prove that the underlying transport is functioning > properly. However, if no one complains in the next week or two, I'll > close this with the release of 5.6.1. This "delayed check" method has reportedly been failing for some users. It apparently "hangs" at some point while redialing and displays a negative countdown in the mode line segment. If my suspicions are correct, this is somewhat of a known issue related to the sending of a "stateless" pre-connection-registration message, namely a PING, which is pretty nonstandard for clients. One possible solution that springs to mind involves reusing the last session's local state to perform the initial "$hello" of the so-called "connection registration" sequence. It would interpret any response as indicative of a healthy connection and stash it in order to first initialize the session properly before processing the stashed response manually at the juncture where its request (the "$hello" thing) would normally be emitted. This solution is appealing in that it would preserve the program's basic design and contracts. However, its fatal flaw would be performing connection registration in the old session's buffer. Doing this hampers modularity by making it difficult if not impossible for modules to meaningfully influence the process. In any case, the second of the attached patches (the one labeled "POC") demos this approach. For now, I think our best option is to forgo emitting _any_ pre- registration protocol and to instead accept the "open\n" event from the process sentinel as sufficient evidence our messages are getting through. Of course, not seeing a single response means this reconnect method may still fail with some proxies, which is something I guess we'll just have to live with. Anyway, the first of the attached patches (the one labeled "5.6.1") hopefully does this in a competent way. Those affected by this bug are encouraged to give it a try. In the end, the fact remains that anything short of fully integrating the reconnect logic into session setup and the connection-registration dialog will always be a hack and prone to failure. Unfortunately, such a comprehensive overhaul would mean reworking the way ERC initializes sessions and would break way too much user code. But it's something perhaps worth revisiting on a major version release. Thanks.