How should I set CCGMS on my Commodore 64 to login to a Linux machine?

Question

I have a Strikelink WiFi modem for the C64 (see here and here) and I can connect to a BBS without issues using CCGMS 2017 v4 and the following settings:
Baud = 9600
Modem Type = UP9600 / EZ232

For this reason I use the same settings also to connect to a Linux machine that is running Telnet Server (the official telnetd, works perfectly if I connect to it using another Linux machine).

If I type atdt192.x.y.z (clearly my Linux machine ip) I see it gets to the login prompt but the characters are all garbled graphics and at this point the terminal is stuck:

I use CCGMS 2017 v4 but I am more than happy to change it to whatever version can work better for this scenario.
I am also open to use other software that can make the connection to a Linux machine running Telnet possible.

What am I doing wrong?

In case I need to provide more details / info to allow further troubleshooting please let me know what is needed and I will update this question with all the data I am able to find.

Answer 1

Before changing settings, display the current settings using AT&V and make a note of their values

TLDR

Sending the following to the Strikelink may get things working:

ATNET1
ATPET=0
AT&W

If this doesn't work scroll down for an alternative connection method.

---

Analysis

The graphics characters displayed on the screenshot you posted in the chat looked a lot like TELNET protocol negotiation. I decoded the characters as follows:

Hex	Decimal*	TELNET
7F 7D ???	255 252 ???	IAC WONT ???
7F 7D 20	255 252 32	IAC WONT Terminal speed
7F 7D 23	255 252 35	IAC WONT X display location
7F 7D 27	255 252 39	IAC WONT Telnet environment

^{* I've set the high bit of the decimal values for the first two bytes of each command (IAC and the command number)}

As you can see these appear to be (mangled) TELNET handshake commands (see here and here). It looks like the high bits are being stripped and low bytes (<0x20 i.e. <32 decimal) are not being displayed (indicated by ???).

I took a look at the source code for both CCGMS 2017¹ and Strikelink². Here's what I found:

CCGMS

The receive and transmit code appears to be 8-bit clean³. The only thing unusual is that it reorders the bits read⁴ (and written) using a precomputed⁵ lookup table and a conditional addition for bit 7.

Strikelink

Looking through the options⁶ there are two that stood out:

• ATNETn (n = 0 or 1)
  Disable or enable TELNET protocol handling
  Enabling this enables TELNET command/escape handling, responds to all DO requests with a WONT, responds to all WILL offers with a DO, and halves the usable receive buffer size (to allow for character escapes)⁷. No escapes are done on transmit⁸. Note that this is not full TELNET support but it might be sufficient for your use-case.

• ATPET=n (n = 0 or 1)
  Disable or enable PET MCTerm translation
  When enabled (with ATPET=1) this clears the high bit⁹ before sending it to the C64.

I think that running ATNET1 and ATPET=0 may¹⁰ get things working the way you want. If all is working you can save the settings with AT&W

Alternative connection method

If connecting via TELNET fails to work you can try connecting to a raw TCP socket on the Linux host. To do this (assuming a Debian system like the Raspberry Pi) run the following on the Linux host: sudo apt-get install netcat followed by netcat -lvp 2323 -e /bin/bash You should now be able to turn off TELNET support on the Strikelink (with ATNET0) and connect to the Linux host on port 2323. Note that this method is horribly insecure (even worse than TELNET) so only do this if you're on a private network (e.g. 192.168.x.x) and don't care about the security of the Linux host.

---

¹ CCGMS 2017 v6 source from here (The source for v4 does not seem to be available)

² Strikelink firmware source from here (This is the only firmware source link I could find)

³ I'm not very good with 6502 assembler so I could be mistaken.

⁴ CCGMS receive routine bit reordering code (ccsrc.txt lines 8144-8152):

    lda  $dd0c              ; read SDR (bit0=databit7,...,bit7=databit0)
    cmp  #128               ; move bit7 into carry-flag
    and  #127
    tax
    lda  revtabup,x           ; read databits 1-7 from lookup table
    adc  #0                 ; add databit0
    ldx  wr_rptr            ; and write it into the receive buffer
    sta  recbufup,x
    inx

⁵ CCGMS look-up table population code (ccsrc.txt lines 8197-8209):

    lda  $dd0d              ; check for bit3 (SDR-flag)
    and  #8
    
    ldx  #0
-   stx  outstat            ; outstat used as temporary variable
    ldy  #8
-   asl  outstat
    ror  a
    dey
    bne  -
    sta  revtabup,x
    inx
    bpl  --

⁶ Strikelink options (adapted from juno12.ino lines 561-588):

DISPLAY HELP..: AT?
or............: ATHELP
DIAL HOST.....: ATDTHOST:PORT
SPEED DIAL....: ATDSN (N=0-9)
SET SPEED DIAL: AT&ZN=HOST:PORT (N=0-9)
HANDLE TELNET.: ATNETN (N=0,1)
PET MCTERM TR.: ATPET=N (N=0,1)
NETWORK INFO..: ATI
HTTP GET......: ATGET<URL>
AUTO ANSWER...: ATS0=N (N=0,1)
SET BUSY MSG..: AT$BM=YOUR BUSY MESSAGE
LOAD NVRAM....: ATZ
SAVE TO NVRAM.: AT&W
SHOW SETTINGS.: AT&V
FACT. DEFAULTS: AT&F
PIN POLARITY..: AT&PN (N=0/INV,1/NORM)
ECHO OFF/ON...: ATE0 / ATE1
VERBOSE OFF/ON: ATV0 / ATV1
SET SSID......: AT$SSID=WIFISSID
SET PASSWORD..: AT$PASS=WIFIPASSWORD
SET BAUD RATE.: AT$SB=N (3,12,24,48,96
                192,384,576,1152)*100
FLOW CONTROL..: AT&KN (N=0/N,1/HW,2/SW)
WIFI OFF/ON...: ATC0 / ATC1
HANGUP........: ATH
ENTER CMD MODE: +++
EXIT CMD MODE.: ATO
QUERY MOST COMMANDS FOLLOWED BY '?'

Note that the above isn't exactly correct. If you're having trouble setting an option try omitting the = from the command or adding a = before the option value.

⁷ See juno12.ino lines 1354-1402.

⁸ This means that 0xff (decimal 255, TELNET IAC) cannot be sent from the C64 when TELNET mode is enabled on the Strikelink. (Well technically it can, you just have to send it twice.)

⁹ Strikelink MCTerm high bit bit-clearing option (juno12.ino lines 1397-1402):

  // Fix PET MCTerm 1.26C Pet->ASCII encoding to actual ASCII
  if (petTranslate == true) {
    for (int i = len - 1; i >= 0; i--) {
      if (txBuf[i] > 127) txBuf[i]-= 128;
    }
  }

¹⁰ It might be the case that Strikelink's TELNET support is insufficient. Looking through the code it looks like there is only support for responding to DO and WILL commands, not DONT or WONT. Adding appropriate responses for the latter two to juno12.ino would largely be a matter of cut and paste (have DONT give a WONT response and WONT a DONT); e.g. insert the following at line 1450:

      else if (cmdByte1 == DONT)
      {
        tcpClient.write((uint8_t)255); tcpClient.write((uint8_t)WONT); tcpClient.write(cmdByte2);
      }
      else if (cmdByte1 == WONT)
      {
        tcpClient.write((uint8_t)255); tcpClient.write((uint8_t)DONT); tcpClient.write(cmdByte2);
      }