Synchronet Classic Shell causes menu loop with response "unrecognised command" on a legacy Wyse 520-ES dumb terminal

When loading main menu (and some sub menus) - Wyse 520-ES terminal causes a menu re-load with the response from the BBS of "unrecognised command".

Suggestion from DigitalMan:

for example, try removing the @-code stuff to start with @INCLUDE's and @HOT's or, try one at a time. Just keep removing stuff until the problem goes away. And then we'll have some clue what the cause is. If it's the @HOT codes, then it is mouse related.

Issue seems to be with head.msg, in particular this sequence shown in unix vi:

^An^Al^A<80>^An

Removing the ^Al fixes the issue.

Reference to the text string above is at the beginning of head.msg

Only other occurrences of "Unrecognised command" is after exiting [L]list/View messages or /A change your avatar, which results in one screen redraw followed by the the "Unrecognised command" message. Pressing a key (such as enter) redraws the menu just fine after this.

changed the description

Ctrl-AL is a "clear screen" code. If this causes a problem, I would expect any "clear screen" to cause the problem (e.g. the @cls@ or @clear@ codes or any ANSI files that have screen clearing sequences in them).

If the terminal is sending a character to the server in response to a clear-screen ANSI sequence, then I would suspect something is wrong with the terminal. Is the user's setting in ANSI terminal mode or not? If not, then the clear-screen code is a Ctrl-L (ASCII FF character). When in ANSI terminal mode, the clear-screen sequence is ESC[2J. Neither of these sequences should cause a terminal to respond, but knowing which it is could provide a clue.

I'll do some more testing and let you know the results.

So with ANSI off, no issue (SBBS says in dumb mode) with ANSI on I get the problem. Also I'm also getting screen clears ok with that ^AL removed so not sure what else is doing a screen clear. Also just logged into a SBBS 3.13 system with ANSI and that seems ok (although it doesnt have the head.msg text).

I've also tried a cating a text file containing "ESC[2JHow are you?" and that seems to display ok (screen clears) with no odd keyboard inputs afterwards.

Does a ^AL only send ESC[2J when in ANSI mode in SBBS?

what personality mode do you have that terminal set to? one of the manuals i find for this device shows it has these:

Personalities:
ANSI: DEC VT420, VT320, VT100, VT52, Wyse WY-85;
ASCII: Wyse WY-60, PCTerm (both Wyse and DEC); UNIX Console

i'm wondering if, for example, you might have it in ANSI DEC VT420 mode or perhaps the ANSI Wyse WY-85 mode... or are you testing only with the ANSI VT100?

General Settings:

VT400 Mode, 7-bit controls DECSCL = VT400 Multinational Mode User-Defined Keys Unlocked User Features Unlocked Numeric Keypad Normal Cursor Keys No Newline PC International VT420 ID When Available Update

The above settings I've tried a few option changes, but they don't seem to make any difference to the looping issue. If you spot something wrong, or spot something that might be worth experimenting with I will be happy to try.

Here's the actual code (this gets executed by a ^AL sequence):

void sbbs_t::clearscreen(long term)
{
	clear_hotspots();
	if(term&ANSI)
		putcom("\x1b[2J\x1b[H");	/* clear screen, home cursor */
	else if(term&PETSCII)
		outcom(PETSCII_CLEAR);
	else
		outcom(FF);
	row=0;
	column=0;
	lncntr=0;
}

So the sequence sent for ANSI users is "ESC[2JESC[H".

Hi DM, thanks for the code snippet - I've modified my file to include ESC[2JESC[HHow are you? and that doesnt invoke a input from the terminal as far as I can see either.... I'm going to try a few more experiments and see if I can trigger a response.

I just wish I had an old serial capture device so I could see what was being sent back to SBBS that caused the "unrecognised command".

There isn't a mode I can put SBBS in to see what input is causing that "unrecognised command" is there?

You could add log output to your command shell to log the command key that it doesn't like. Or you could use a TCP/IP trace tool.

Hi will investigate a trace tool. Re log output, is there a link you could share on how to set that up (I'm assuming its an SBBS feature)?

Modify your command shell (e.g. exec/default.src) to log the unrecognized/unsupported command key value (in hexadecimal):

print "\r\n\1c\1hUnrecognized command."
int k
copy_char k
sprintf str "Unsupported command: %02X" k
print_local "%s"

Then recompile with baja (baja default). Then when logged in and using that command shell, entering/sending an unsupported command key will log that message (with the hex value of the key) to your server-side log.

Ah, the char is 11 (0x11) which is control-Q - XON.

I also note that the XOFF char control-S doesn't return "Unrecognized commmand".

Perhaps my terminal is doing this:

• Main Menu (or other sub menu - e.g. T) is drawn
• Terminal requests XOFF - control-S which is ignored (not the end of the world - buffer is big enough)
• Terminal requests XON - control-Q which is picked up as an Unrecognized command
• SBBS reload's main menu (or other sub menu - e.g. T)
• Problem loops

Thoughts?

Just tried adding:

cmdkey ^Q end_cmd

to default.src and although I don't get an "Unrecognised command" I still get a redraw of the main menu in a loop....

Ummmm....

It sounds like your terminal is trying to perform "software flow control". Can you disable that? Synchronet hasn't supported XOFF/XON flow control since the modem days.

It might actually be the size of the display file (menu) that is triggering this, not the content, after all. It seems odd that an ESC[2J or ESC[H would trigger an XOFF or XON from the terminal. But it does kind of make sense that a certain number of characters in the receive buffer to the terminal might cause it to want to pause the sender (using XOFF).

I was just thinking that too - will do some more tests now.

I still think that adding a bypass for Control-Q is a good idea for default.src doesnt make sense to bypass Control-S but not Control-Q.

Well if you want to eat Ctrl-Q and Ctrl-S globally, you can just use dummy global hot key handlers, configured in SCFG->External Programs->Global Hot Key Events. Of course, that would only fix your BBS, not any others. Some sysops and scripts actually want to use Ctrl-Q and Ctrl-S to perform tasks. I think Ctrl-Q is used for quoting in some editors. And Ctrl-S is used to edit the subject in some.

The best fix would be to disable this XOFF/XON behavior in the terminal.

I wasn't thinking globally - just for the menus... as control-S is already dropped just for the menus.

Just tried disabling XON/XOFF for receive flow control and that works fine. The original setting was "XOFF after 64" chars, so I've changed it now to "XOFF & DTR at 128" as I still need flow control for talking to my unix box.

That setting seems to work ok with SBBS too.

Thanks for help as always.

closed