Bug #2274

C12 problem on leaf.dragonflybsd.org

Added by robin.carey1 almost 3 years ago. Updated over 2 years ago.

Status:RejectedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Dear DragonFlyBSD bugs,

I reported this problem just recently, and then mistakenly believed an O/S
upgrade on
leaf.dragonflybsd.org had solved the problem. Unfortunately, that was not
the case (I
had changed the code during testing/debugging and had forgot that I had
changed
the code, which led to me believing the problem had been solved).

The problem is with C12 (C12G22r2) operation on leaf.dragonflybsd.org; the
source
code can be downloaded from:

http://www.leopard.uk.com/C12

The problem manifests as a termios(4)/Terminal problem, e.g.

Local echo is not switched off (there are probably other problems
aswell).

Since C12G22r2 works fine on OpenBSD-4.7/i386 and
FreeBSD-9.0/i386, I conclude the problem is with
DragonFlyBSD.

--
Sincerely,

Robin Carey BSc

History

#1 Updated by alexh over 2 years ago

Would be nice if you could narrow it down to a particular call, etc not working as expected.

Cheers,
Alex

#2 Updated by robin.carey1 over 2 years ago

Dear Alex & DFlyBSD-bugs,

With regard to Issue-2274:

It would appear C12 works OK on leaf.dragonflybsd.org, except Local-Echo is
switched on all the time (when it should be switched off).

In the C12 source-code, Local-Echo is switched off during the method:

Terminal::RawInput() -- in the file Terminal.h

The Terminal::RawInput() method is only called in:

Terminal::GetNextInputChar() -- in the file Terminal.h

The Terminal::GetNextInputChar method is only called from 2 places:

Key.h ; class Key ; method Key::WriteKey()

and

Passwd.h ; class Passwd ; method Passwd::Password().

As I said before, C12G22r2 works fine on both FreeBSD-9.0/i386 and
OpenBSD-4.7/i386.

Also, as I said before the C12 source-code can be downloaded from:

http://www.leopard.uk.com/C12

There might be more problems than the one outlined above ....

If there are any other problems, it would probably make sense to resolve
this problem, before finding out if there are any others.

On 24 February 2012 20:41, Alex Hornung via Redmine <
> wrote:

>
> Issue #2274 has been updated by Alex Hornung.
>
>
> Would be nice if you could narrow it down to a particular call, etc not
> working as expected.
>
> Cheers,
> Alex
> ----------------------------------------
> Bug #2274: C12 problem on leaf.dragonflybsd.org
> http://bugs.dragonflybsd.org/issues/2274
>
> Author: Robin Carey
> Status: New
> Priority: Normal
> Assignee:
> Category:
> Target version:
>
>
> Dear DragonFlyBSD bugs,
>
> I reported this problem just recently, and then mistakenly believed an O/S
> upgrade on
> leaf.dragonflybsd.org had solved the problem. Unfortunately, that was not
> the case (I
> had changed the code during testing/debugging and had forgot that I had
> changed
> the code, which led to me believing the problem had been solved).
>
> The problem is with C12 (C12G22r2) operation on leaf.dragonflybsd.org; the
> source
> code can be downloaded from:
>
> http://www.leopard.uk.com/C12
>
> The problem manifests as a termios(4)/Terminal problem, e.g.
>
> Local echo is not switched off (there are probably other problems
> aswell).
>
>
> Since C12G22r2 works fine on OpenBSD-4.7/i386 and
> FreeBSD-9.0/i386, I conclude the problem is with
> DragonFlyBSD.
>
> --
> Sincerely,
>
> Robin Carey BSc
>
>
> --
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
> http://bugs.dragonflybsd.org/my/account
>

--
Sincerely,

Robin Carey BSc

#3 Updated by alexh over 2 years ago

  • Priority changed from Normal to Low

I've added some very simple "instrumentation", printing a dot "." when it calls tcsetattr to disable local echo, and a dash "-" when it restores the local echo. The outcome is:

Encrypt public-key (y/n) ? .-.-.-.-.-y.-
Choose password: /root/caesarion/public-key: .-.-y.-.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-y.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-n.-.-.-m.-.-o.-.-o.-.-.-o.-.-o.-.-o.-.-.-.-.-.-.-.-.-.-.-.

As you can see, this looks more like a problem with the code. It keeps toggling between one and the other, and every time you press a button, it restores the old settings first, before taking the input, it seems.

Disabling local echo itself definitely works just fine, because it's used in e.g. tcplay.

In any case I'll look a bit further into this.

Cheers,
Alex

#4 Updated by alexh over 2 years ago

  • Status changed from New to Rejected

It's quite surprising that it works anywhere, I think. You are enabling local echo while the character is buffered (i.e. select has returned what you wanted), then disabling it again before it's read. It doesn't strike me as a good idea that should work anywhere.

Changing your GetNextInputChar as follows (note that #if 0), makes it work just fine and is in line with good UNIX programming:

int GetNextInputChar (void) const {
int retVal;

#if 1
RawInput();

do {
fd_set readfs;
FD_ZERO(&readfs);
FD_SET (fileno(stdin), &readfs);
struct timeval timeout = { 2, 0 };

#if 0
RawInput (); // A ^Z can reset the terminal/termios(4)
// setting, so we set it to the desired
// configuration just before any I/O
// operating (including select(2)).
//
#endif
retVal = select ((fileno(stdin) + 1), &readfs, NULL, NULL, &timeout);
#if 0
Restore (); // Restore termios(4) ASAP after RawInput().
#endif
ASSERT (retVal != -1);
} while (retVal <= 0);
#endif

#if 0
RawInput (); // A ^Z can reset the terminal/termios(4)
// setting, so we set it to the desired
// configuration just before any I/O
// operating (including select(2)).
//
#endif
const int key = fgetc (stdin);
Restore (); // Restore termios(4) ASAP after RawInput().
ASSERT (!ferror (stdin));
ASSERT (!feof (stdin));

return key;
}

#5 Updated by alexh over 2 years ago

Forgot to mention it in my last message:
using the TIOCSETA ioctl on a pty device (i.e. tcsetattr) causes a flush. This happens on most BSDs, and there is no guarantee that I'm aware of that it shouldn't happen. If you rely on it not happening, you are relying on undefined behaviour.

Cheers,
Alex

Also available in: Atom PDF