Mailing List Archive

High-bit strip?
So, does Conserver strip bit 7? My terminal server is set to pass chars
raw, but line-drawing chars come out as "MMMM" etc. on a Linux console.

Also, is there any info on how keycodes are passed on?
Re: High-bit strip? [ In reply to ]
Yep, by default it does. You can change it by using the --enable-8bit
configure option with 7.0.0 or editing conserver/cons.h in pre-7.0.0
versions (option CPARITY - set to 0). If that doesn't do it for you,
let me know ("conserver -V" should tell you your current policy with
recent versions).

Bryan

On Thu, Feb 22, 2001 at 01:45:16PM -0800, Aaron Burt wrote:
> So, does Conserver strip bit 7? My terminal server is set to pass chars
> raw, but line-drawing chars come out as "MMMM" etc. on a Linux console.
>
> Also, is there any info on how keycodes are passed on?
>
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
Re: Re: High-bit strip? [ In reply to ]
On Fri, 23 Feb 2001, Bryan Stansell wrote:
> On Thu, Feb 22, 2001 at 01:45:16PM -0800, Aaron Burt wrote:
>> So, does Conserver strip bit 7? My terminal server is set to pass
>> chars raw, but line-drawing chars come out as "MMMM" etc. on a Linux
>> console.
>
> Yep, by default it does. You can change it by using the --enable-8bit
> configure option with 7.0.0 or editing conserver/cons.h in pre-7.0.0
> versions (option CPARITY - set to 0). If that doesn't do it for you,
> let me know ("conserver -V" should tell you your current policy with
> recent versions).

Well, it still draws MMMM with TERM=linux but things look great with
TERM=vt220 or xterm. I tried a stock 6.1.7 client connecting to a 8-bit
7.0.0 server, too. Worked fine.

>> Also, is there any info on how keycodes are passed on?

To amplify, it'd be nice to understand the mechanism well enough to ensure
Fn keys and suchlike are sent properly, and perhaps even to remap <BREAK>
to something like, say, SysRQ (for Linux kernel hackers, y'see).
Also, no matter what the terminal-type is set to in the inittab for getty
on the machine being controlled, backspace and delete don't work when
logging in. Though ^H does. Arrow keys move the cursor but seem to
invisibly mess up the username/password.

And yes, I'm trynta look at the source, too.
Re: Re: High-bit strip? [ In reply to ]
On Fri, Feb 23, 2001 at 12:32:37PM -0800, Aaron Burt wrote:
> > Yep, by default it does. You can change it by using the --enable-8bit
> > configure option with 7.0.0 or editing conserver/cons.h in pre-7.0.0
> > versions (option CPARITY - set to 0). If that doesn't do it for you,
> > let me know ("conserver -V" should tell you your current policy with
> > recent versions).
>
> Well, it still draws MMMM with TERM=linux but things look great with
> TERM=vt220 or xterm. I tried a stock 6.1.7 client connecting to a 8-bit
> 7.0.0 server, too. Worked fine.

Hmmm...I have a RAID array that uses line drawing characters and they
pass through just fine (7 or 8 bit compilation setting). Are you
logging the data to a file? Does the data in the file look correct?
In my logfile it looks like there's a "start line drawing" sequence
(ctrl-n), then a bunch of normal characters (m,q,j, etc) and a "stop
line drawing" sequence (ctrl-o) (an echo of ctrl-n,mqqqqj,ctrl-o makes
line characters appear, actually, so that's probably it). Do things
like that being logged? Since all of that are 7-bit characters, it
should "just work" through conserver.

Whatever conserver gets on the console is logged without change (except
for possibly stripping the high bit) to the logfile.

> >> Also, is there any info on how keycodes are passed on?
>
> To amplify, it'd be nice to understand the mechanism well enough to ensure
> Fn keys and suchlike are sent properly, and perhaps even to remap <BREAK>
> to something like, say, SysRQ (for Linux kernel hackers, y'see).
> Also, no matter what the terminal-type is set to in the inittab for getty
> on the machine being controlled, backspace and delete don't work when
> logging in. Though ^H does. Arrow keys move the cursor but seem to
> invisibly mess up the username/password.

Oops..forgot to address this question. Conserver and the console
client do no translation of characters (in either direction)...it's
just a "semi-stupid" conduit between your keyboard and the serial port
(well, console - could be a command being run instead of a serial port,
ya know). I say semi-stupid because you have all the escape sequences
to replay logs, send a break, etc. I'd suggest logging into a console
that you're having trouble with, run 'cat -tv' and then hit the
backspace and return keys. Do you get a '^H' as output or some long
sequence of escape characters (which some things like to send)? It's
one way of finding out what, exactly, your keyboard is sending and what
the terminal driver is seeing and having to cope with. That should,
hopefully, help you determine what you need to do to get it to pass the
right data.

> And yes, I'm trynta look at the source, too.

Good luck! I hope some of what I've said helps. Yell if I made things
less clear or anything.

Bryan