11:42 <@ijchain> <rmax_> rkeene: [tls::import] appears to switch a socket that was in -blocking 0 mode before to -blocking 1.
11:44 <@ijchain> <rmax_> ... it also sets -translation to {lf lf}
11:45 <@ijchain> <rmax_> Haven't compared it with the old version yet, but -blocking 1 would explain the behaviour I am seeing.
11:47 <@ijchain> <rmax_> it also enforces -encoding binary
11:52 <@ijchain> <rmax_> Indeed, if I hack [fconfigure $sock -blocking 0 -buffering none -encoding utf-8] (copied from tkchat) into jabberlib immediately after tls::import/tls::handshake, the hang is gone.
11:53 <@ijchain> <rmax_> rkeene: I think this is a regression from the old tls package.
11:54 <@ijchain> <rmax_> [tls::import] should probably not change any [chan configure] options.
11:56 <@ijchain> <rmax_> OK, so old tls already changed -translation to lf.
11:57 <@ijchain> <rmax_> But it does retain blocking state and encoding.

This is rmax. :)

I wonder why putting the to be imported socket in blocking mode was added at first place, but unfortunately the checkin comment doesn't tell it:

https://tcltls.rkeene.org/ci/7df7a8696e009447?sbs=1

Could it be that you added this for debugging reasons and forgot to remove it before committing?

BTW, the proposed fix only preserves the state of -translation, but -encoding and -eofchar need to be preserved as well, because setting "-translation binary" implicitly also changes these two options.

This was corrected in commit [1d757f7e2d47db20].