Zugg Software :: View topic

Novice Joined: 26 Jul 2002 Posts: 35 Location: USA

New or existing sessions don't seem to hold their value for Terminal Type when set and applied in preferences. I've tried setting to all the types (cmud, zmud, ansi, and xterm) but it always reverts to vt100.

What additional information would be helpful?
Z

Posted: Tue Jun 10, 2008 5:20 pm

I cannot reproduce this in a new session. Seems to save fine here. My guess is that the MUD is sending something to CMUD to force it into VT100 mode. There are Telnet option negotiation commands that the MUD can use to negotiate a terminal type. Most MUDs don't do this, so you might try a different MUD to see if it still happens. But if the MUD is specifically setting CMUD to VT100 mode, then you'll want to leave it like that.

The Terminal Type is not used internally in CMUD at all. It is only there for the MUD to use to auto-detect terminal types. Usually a MUD just uses this to detect what type of terminal you are using. Forcing the terminal to VT100 can be done by the MUD, but it doesn't actually do anything in CMUD itself. As the end-user, you still have control over whether VT100 emulation is enabled or not, regardless of the terminal type.

Novice Joined: 26 Jul 2002 Posts: 35 Location: USA

Perhaps it helps that I'm not trying to connect to a mud and it's when using SSH. This is happening when I connect with a variety of Linux machines (Centos, SuSE) and a Solaris machine. It will not accept xterm as an option. The reason for the switch is because the VT emulation is less performant than PuTTY and thus I had hoped to test another terminal type. Seems in 2.26 I must enter a crtl-ret in applications that expect a simple ^M. I was hoping this would not persist if I switched terminal types. (Note: I don't believe ths ^M behavior challenge existed in 2.25)

The same systems have no problem with PuTTY switching terminal types. echo $TERM returns xterm for PuTTY and for xsessions. Forcing the same with CMud is a no op.

I am aware of the negotiation standards in the telnet RFCs. I've not bothered trying to sniff an ssh line...<blink> to identify if the WILL/DO exchange sequence is taking place as expected. I know when I was working with the same in zMUD (telnet) I didn't have this problem and in fact wrote the server side code to handle the negotiation. For now I'll stick with PuTTY... If I catch a few free moments, I'll try to squeeze in some additional testing. I don't have time today to fire up a ssh server stub to bang against and observe the decoded low-level traffic.
Z

Posted: Tue Jun 10, 2008 8:04 pm

I'll check the Ctrl-M instead of Enter problem in 2.26...that sounds like a bug.

If there is a problem with the Terminal Type for SSH, I'd definitely like to fix it in the new 2.27 version this week. If you can capture the raw text from the server, that would be a huge help. Just type:

#DEBUGFILE test.raw test.txt

and send me both files as email attachments to support@zuggsoft.com. Capture the initial connection of the session. You can do this by first using the "Open Offline" for your session, then typing the #DEBUGFILE command, then typing the #CONNECT command to connect to the server.

Not that many people are using the SSH stuff yet, so I'd appreciate any help that you have time to give in tracking down this problem. I'd really like CMUDPro to be a good replacement for PuTTY in most cases. Thanks!

Posted: Tue Jun 10, 2008 10:08 pm

I used it for a little bit to some basic web admin. It worked fine, but then again I wasn't doing anything complex. One suggestion, when you select an SSH session can we default the port number 22?

Posted: Tue Jun 10, 2008 10:35 pm

Tech, it actually works the other way around. If you enter a port of 22, then it will default to SSH. There are other problems caused if clicking the Telnet/SSH button would cause the port to change. I tried that at one point and it was a mess.

Posted: Wed Jun 11, 2008 12:13 am

Ok no worries. I only noticed because I hadn't used SSH for a while and forgot the default port for a split second. Either we trust in the wisdom of Zugg.

Posted: Wed Jun 11, 2008 6:14 pm

OK, I found the problem in the original post. Yes, in SSH mode it seems to be forcing VT100. I think the problem I was trying to fix was to prevent CMUD from sending "cmud" or "zmud" as the terminal type. But I forgot about xterm. So I'll fix this in v2.27 so that it will only force VT100 if you try and select "zmud" or "cmud" as the terminal type. This should allow you to use xterm or any other custom terminal type.