1375 [main] DEBUG org.apache.sshd.client.SshClient - close(SshClient[d6da883])[Immediately] closed
org.apache.sshd.common.SshException: DefaultOpenFuture[ChannelShell[id=0, recipient=-1]-ClientSessionImpl[karaf@localhost/127.0.0.1:8101]]: Failed (IllegalArgumentException) to execute: Invalid UINT32 value: -1
at org.apache.sshd.common.future.AbstractSshFuture.lambda$verifyResult$1(AbstractSshFuture.java:132)
at org.apache.sshd.common.future.AbstractSshFuture.formatExceptionMessage(AbstractSshFuture.java:190)
at org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:131)
at org.apache.sshd.client.future.DefaultOpenFuture.verify(DefaultOpenFuture.java:39)
at org.apache.sshd.client.future.DefaultOpenFuture.verify(DefaultOpenFuture.java:32)
at org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at org.apache.karaf.client.Main.main(Main.java:281)
Caused by: java.lang.IllegalArgumentException: Invalid UINT32 value: -1
at org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
at org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
at org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
at org.apache.sshd.common.util.buffer.BufferUtils.validateUint32Value(BufferUtils.java:703)
at org.apache.sshd.common.util.buffer.Buffer.putUInt(Buffer.java:726)
at org.apache.sshd.client.channel.PtyCapableChannelSession.lambda$doOpenPty$0(PtyCapableChannelSession.java:265)
at java.base/java.util.HashMap.forEach(HashMap.java:1337)
at org.apache.sshd.client.channel.PtyCapableChannelSession.doOpenPty(PtyCapableChannelSession.java:263)
at org.apache.sshd.client.channel.ChannelShell.doOpen(ChannelShell.java:45)
at org.apache.sshd.client.channel.AbstractClientChannel.handleOpenSuccess(AbstractClientChannel.java:366)
at org.apache.sshd.common.session.helpers.AbstractConnectionService.channelOpenConfirmation(AbstractConnectionService.java:545)
at org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:456)
at org.apache.sshd.common.session.helpers.CurrentService.process(CurrentService.java:109)
at org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:594)
at org.apache.sshd.common.session.helpers.AbstractSession.lambda$handleMessage$0(AbstractSession.java:525)
at org.apache.sshd.common.util.threads.ThreadUtils.runAsInternal(ThreadUtils.java:66)
at org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:524)
at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1644)
at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:485)
at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
at org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:371)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:344)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:339)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
at java.base/sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:127)
at java.base/sun.nio.ch.Invoker$2.run(Invoker.java:219)
at java.base/sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
The failing check was introduced in https://issues.apache.org/jira/browse/SSHD-1244 .
From quick glance I have not found anything fishy in SSHD itself, but Karaf's client is initializing the input in
client/src/main/java/org/apache/karaf/client/Main.java:267: channel.setPtyModes(modes);
can you look at modes here with a debugger?
Alternatively, we really need to know the PtyMode key which has that -1 associated and then track down where it is set.
And we'll need a Karaf bug, I think because JLine reports -1 for characters it does not find: https://github.com/jline/jline3/blob/92a63e1494d7e24a9f36cf639257b181080a535f/terminal/src/main/java/org/jline/terminal/Attributes.java#L292 and karaf is not filtering those.
Now we need to figure out which attributes are missing and why – because perhaps this can be solved with setting TERM via https://github.com/jline/jline3/wiki/Terminals – I don't really know, though.
Upstream issue: https://issues.apache.org/jira/browse/KARAF-7607
Upstream (partial?) fix: https://github.com/apache/karaf/pull/1680
We still need to try to work this around with TERM.
Hopefully the unavailable control char is not one of the three mentioned here: https://github.com/apache/karaf/pull/1680/commits/96128a63c7c71f613b88ca05017c7e7e75b86d85
Thank you Robert to take care of this issue.
I've just tested your karaf PR and obtained the following messge now:
Logging in as karaf
Required control character VDSUSP is not available
Ah, so it is 
gthouenon can you try without the second patch in the PR, please?
Good news!
Without your second patch, karaf-client works perfectly!
Thanks for testing 
Unfortunately it seems we are not getting a new Karaf for a couple of weeks. I am loathe to downgrade, but it seems the best short-term option to get this unblocked.
Q: which release train is the most pressing? Cl SR1? Su SR2?
From TPCE side, no pressing at all for any of these releases. From ODL release schedule, it seems Su SR2 is rather urgent if we don't want make the delay worse...
But, may be the best solution would be to find a workaround on TPCE side to avoid a karaf downgrade which will entail to restart all the release process...
Since this karaf feature is only used to perform some TPCE functional test, I can see if we can do thing in another way. Let me have a look to it today...
you meant Su SR3 or I'm missing something ?
Yes of course, this is Su SR3.
In TransportPCE, we have overcomed this issue by switching on lighty build as the runtime for all TransportPCE functional tests on the gate instead of karaf. By this way, this issue is no longer blocking for Su-SR3 nor Cl-SR1.