open https://gitlab.synchro.net/main/sbbs/-/issues/258

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:

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

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

^An^Al^A<80>^An

Removing the ^Al fixes the issue.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1952

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

Only other occurance of "Unreconised command" is after exiting [L]list/View messages, which results in one occurance of message, pressing a key (such as enter) redraws the menu just fine.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1954

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1955

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1956

So with ANSI off, no issue (SBBS days 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?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1957

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".

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1958

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?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1959

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1960

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?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1961

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1962

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)?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1963

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1972

In exec/default.src, I think the first occurance of "Unrecognized command" is the main menu. I've added the extra code and compiled with baja ../exec/baja default, which compiles ok, but I still don't see the hex debug when entering an invalid response (i.e. its the same as before I made the code change).

I've also tried restarting the sbbs service.

------

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

compare_user_misc UM_expert
if_true
print " Hit '\1i?\1n\1c\1h' for a menu."
end_if
crlf
end_cmd

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1973

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?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1974

Could SBBS set to ignore Control-Q like it ignores Control-S perhaps?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1975

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).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1976

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1977

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1978

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1979

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

close https://gitlab.synchro.net/main/sbbs/-/issues/258

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net