char: don't silently skip tn3270 protocol init when TLS is enabled

Even if common tn3270 implementations do not support TLS, it is trivial to have them proxied over a proxy like stunnel which adds TLS at the sockets layer. We should thus not silently skip tn3270 protocol initialization when TLS is enabled.

Signed-off-by Daniel P. Berrange <[email protected]>

---
 chardev/char-socket.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

chardev/char-socket.c +0 -0

index 53eda8ef00..6013972f72 100644

Quoted 15 lines · On Thu, 21 Dec 2017 10:54:33 +0000 "Daniel P. Berrange" <[email protected]>…

Even if common tn3270 implementations do not support TLS, it is trivial to have them proxied over a proxy like stunnel which adds TLS at the sockets layer. We should thus not silently skip tn3270 protocol initialization when TLS is enabled.

Signed-off-by Daniel P. Berrange <[email protected]>

---
 chardev/char-socket.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

chardev/char-socket.c +0 -0

index 53eda8ef00..6013972f72 100644

chardev/char-socket.c static void tcp_chr_tls_handshake(QIOTask *task, · line 629

Quoted 9 lines

chardev/char-socket.c +1 -2

@@ -623,8 +623,7 @@ static void tcp_chr_tls_handshake(QIOTask *task,
     if (qio_task_propagate_error(task, NULL)) {
         tcp_chr_disconnect(chr);
     } else {
-        /* tn3270 does not support TLS yet */
-        if (s->do_telnetopt && !s->is_tn3270) {
+        if (s->do_telnetopt) {
             tcp_chr_telnet_init(chr);
         } else {
             tcp_chr_connect(chr);

With this patch applied, attaching an additional 3270 tty still works for me as before.

I have no idea how to try this out with TLS, though. Would you be able to run a sanity check? (The instructions in
https://wiki.qemu.org/Features/3270 work fine with a tcg s390x guest.)

Quoted 31 lines · Cornelia Huck

Quoted 15 lines · On Thu, 21 Dec 2017 10:54:33 +0000 "Daniel P. Berrange" <[email protected]>…

Even if common tn3270 implementations do not support TLS, it is trivial to have them proxied over a proxy like stunnel which adds TLS at the sockets layer. We should thus not silently skip tn3270 protocol initialization when TLS is enabled.

Signed-off-by Daniel P. Berrange <[email protected]>

---
 chardev/char-socket.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

chardev/char-socket.c +0 -0

index 53eda8ef00..6013972f72 100644

chardev/char-socket.c static void tcp_chr_tls_handshake(QIOTask *task, · line 629

Quoted 9 lines

chardev/char-socket.c +1 -2

@@ -623,8 +623,7 @@ static void tcp_chr_tls_handshake(QIOTask *task,
     if (qio_task_propagate_error(task, NULL)) {
         tcp_chr_disconnect(chr);
     } else {
-        /* tn3270 does not support TLS yet */
-        if (s->do_telnetopt && !s->is_tn3270) {
+        if (s->do_telnetopt) {
             tcp_chr_telnet_init(chr);
         } else {
             tcp_chr_connect(chr);  

With this patch applied, attaching an additional 3270 tty still works for me as before.

Quoted 3 lines

I have no idea how to try this out with TLS, though. Would you be able to run a sanity check? (The instructions in
https://wiki.qemu.org/Features/3270 work fine with a tcg s390x guest.)

NB, the x3270 emulator that's described in that page would not do TLS in the manner than it's provided by QEMU. x3270 wants to start in plain text mode, and then use STARTTLS command to negotiate use of TLS afterwards.

The QEMU chardev code doesn't work that way - it immediately activates TLS when started, with no optional negotiation.

We could potentially add support for STARTTLS telent/tn3270 negotiation, but that would be a separate mode from the TLS support we currently have in QEMU chardevs.

I'm guessing the original author who added this check I'm removing was mixing these two modes of operating, and hence mistakenly added this check to stop 3270 init.