[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected

[Frank Heimes]

Thanks for having a look at this SRU.

The general compile of the socat code works after just having commit
5ebf36038f39 "Under certain circumstances, options of the first address
were applied to the second address" applied.

However, the build also triggers a huge amount of tests, and one, test
case 385 'TERMIOS_PH_ALL', is related to this modification and starts to
fail.

(Btw. this is roughly like the case you mentioned that "affected users of 20.04 may rely on the current behaviour".)
Hence a fix is needed to make the 'TERMIOS_PH_ALL' test case work again.
And I think this is also reasonable for other (non-test) cases.

This was meanwhile upstream fixed "as part of" 9de26f1d0528 "minor
corrections, not affecting binaries" (not a great commit msg).

The commit 9de26f1d0528 covers different aspects, that are not well documented in the commit description.
For this case the modification (as part of 9de26f1d0528) in Makefile.in (and obviously in CHANGES). are not needed.
And even the hunks in test.sh:
@@ -183,7 +183,7 @@
and
@@ -13020,7 +13020,7 @@
are not relevant for the 'TERMIOS_PH_ALL' test case.
Only the hunks:
@@ -13057,8 +13057,10 @@
and
@@ -13066,6 +13068,7 @@
(Whereas hunk '@@ -13066,6 +13068,7 @@' is again not absolutely required for a fixed test.)

So yes, the patch could be minimized, for example to cover only:
@@ -13057,8 +13057,10 @@
and
@@ -13066,6 +13068,7 @@

Well, I thought about this, but from other work (esp. in the kernel
area) I've learned (and I generally agree with that) that it is better
to stick to entire upstream commits/patches (if possible) for the reason
of future maintainability.

I think this can be helpful if further patches (due to other bugs are
needed) and will reduce risk as well, since the patch is like upstream,
means tested like this and incl. like this in never versions.

However, if you insist of having this patch minimized; I can do that of
course.

I think it's close to a philosophical question what is best to do in case "users of 20.04 relying on the current behaviour".
I personally believe that since the behavior is wrong, that it needs to be corrected.
Please notice that the behavior is correct in all releases newer than focal - means if not fixing this now with an upgrade, things will break at least after a dist-upgrade.

Working around this in mkvterm might make the situation (imho) not a lot
better (or even worse) and would introduce modification at another place
(and would be for focal only, and mkvterm code in never releases might
diverge).

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2056485

Title:
  Behaviour of socat in Ubuntu 20.04 unexpected

Status in The Ubuntu-power-systems project:
  In Progress
Status in socat package in Ubuntu:
  Fix Released
Status in socat source package in Focal:
  Incomplete

Bug description:
  SRU Justification:

  [ Impact ]

   * IBM Novalink provides a tool called mkvterm.
     Mkvterm takes an lpar id argument and creates a vty-server device on
     device nodes /dev/hvcs*.
     HVCS is a device driver for the IBM Hypervisor Virtual Console Server
     (hvcs). Mkvterm then uses socat to connect.

   * But socat is not behaving as expected.
     When escape=0x1d is passed, you have to hit enter for socat to close
     (expected behavior is Ctrl-] closing the connection).

   * In addition, Ctrl-C closes the connection.
     When using the up and down arrows, junk is printed.
     Password is also visible!

   * This is caused by the fact that under certain circumstances,
     options of the first address are applied to the second address.

  [ Fix ]

   * 5ebf36038f39 5ebf36038f3960798e769bff5646e755a91a1119
     "Under certain circumstances, options of the first address were applied to the second address"

   * 9de26f1d0528 9de26f1d05284257cd9bbb6eb6662089ab7a0680
     "minor corrections, not affecting binaries"

  [ Test Plan ]

   * There was a special test case introduced for this change
     it's test #385.
     If this succeeds, the reported issue is solved.

   * Initially this test case failed, because it required another commit
     on top: 9de26f1d0528
   
   * To verify the overall end-2-end case, the fixes from LP#056373 are required
     as well, but can be taken from the PPA test build that was done there.

   * Then configure a vty-server and try to connect with socat:
     /usr/bin/socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs[minor num]

   * With an unpatched version one will see that the password is
  visible.

   * In addition, the up and down arrows do not work and junk is outputted.
     In addition, Ctrl-] does not close the vterm.

   * Ctrl-C closes the vterm, and it should not.

   * With a patched version the password will not be visible,
     Ctrl+] and Ctrl+C behave as expected.

  [ Where problems could occur ]

   * The code modification is limited to a single line in if
     and is pretty traceable, and it's on top limited to terminos.

   * If the changed condition of IF was done wrong, the expected
     behavior can change (again) and unforeseen things may happen.

   * The rest of the code changes are text in CHANGES and
     a new test case, introduced especially for this bug.

   * Nevertheless, issues can also occur in the (additional)
     test code (which happened and got fixed by adding 9de26f1d0528).

  [ Other Info ]
   
   * Even the code states that this bug is limited to v1.7.3.3.

   * Nevertheless, the code of the socat versions of jammy, mantic
     and noble were checked, and they all have the fix included.
     (However the code in noble's version changed a bit).

   * So only focal is affected.
  __________

  ---Problem Description---
  Novalink provides a tool called mkvterm. Mkvterm takes an lpar id argument and creates a vty-server device on device nodes /dev/hvcs*. HVCS is a device driver for the IBM Hypervisor Virtual Console Server (hvcs). Mkvterm then uses socat to connect.

  Socat is not behaving as expected. When escape=0x1d is passed, you
  have to hit enter for socat to close (expected behavior is Ctrl-]
  closing the connection). In addition, Ctrl-C closes the connection.
  When using the up and down arrows, junk is printed. Password is also
  visible.

  The follow commit fixes the above issues, please add:
  https://repo.or.cz/socat.git/commit/5ebf36038f39

  ---uname output---
  Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux

  ---Steps to Reproduce---
   Fixes to other issues required to reproduce. Mentioned in other bugs.

  Configure a vty-server and try to connect with socat:

  /usr/bin/socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs[minor num]

  Add You will see that the password is visible. In addition, the up and
  down arrows do not work, junk is outputted. In addition, Ctrl-] does
  not close the vterm. Ctrl-C closes the vterm, and it should not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056485/+subscriptions