1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • Synchronet Classic Shell causes menu loop with response "unrecognised

    From Keyop Troy@1:103/705 to GitLab issue in main/sbbs on Sun May 2 18:11:26 2021
    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>^AnRemoving the ^Al fixes the issue.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sun May 2 18:21:55 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1952

    Reference to the text string above is at the beginning of head.msgOnly 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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sun May 2 19:21:44 2021
    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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sun May 2 19:36:02 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1955

    I'll do some more testing and let you know the results.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Mon May 3 14:17:33 2021
    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?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon May 3 16:46:16 2021
    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".
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From waldo kitty@1:103/705 to GitLab note in main/sbbs on Tue May 4 00:01:14 2021
    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?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Tue May 4 13:01:35 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1959

    General Settings:VT400 Mode, 7-bit controlsDECSCL = VT400Multinational ModeUser-Defined Keys UnlockedUser Features UnlockedNumeric KeypadNormal Cursor KeysNo NewlinePC InternationalVT420 IDWhen Available UpdateThe 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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Tue May 4 13:05:36 2021
    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?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue May 4 16:54:59 2021
    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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Thu May 6 12:29:44 2021
    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)?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Thu May 6 13:18:12 2021
    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 kcopy_char ksprintf str "Unsupported command: %02X" kprint_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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sat May 8 12:39:57 2021
    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 throughprint "\r\n\1c\1hUnrecognized command."int kcopy_char ksprintf str "Unsupported command: %02X" kprint_local "%s"compare_user_misc UM_expertif_true print " Hit '\1i?\1n\1c\1h' for a menu." end_ifcrlfend_cmd
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sat May 8 13:10:15 2021
    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 loopsThoughts?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sat May 8 13:12:59 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/258#note_1974

    Could SBBS set to ignore Control-Q like it ignores Control-S perhaps?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat May 8 13:33:19 2021
    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).
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sat May 8 13:35:28 2021
    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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat May 8 13:40:50 2021
    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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sat May 8 13:48:41 2021
    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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Keyop Troy@1:103/705 to GitLab note in main/sbbs on Sat May 8 15:00:23 2021
    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.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Sat May 8 15:20:49 2021
    close https://gitlab.synchro.net/main/sbbs/-/issues/258
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)