|
#1
|
||||
|
||||
SecureCRT and Nortel PBX sending extra CR
Hello,
The company i work for use SecureCRT and one of the employees use scrt to connect to a Nortel PBX and there is a strange issue i cannot figure out. I'm not the one using scrt to connect to the pbx so have limited experience with the PBX. I know it's a Nortel PBX. The employee connect to a telnet server and then dialup from that session to connect to the PBX. When typing commands and press enter it seems like two extra CR/LF is sent. I find it hard to explain this in more details since this is basically the information i got so far and don't know what information is needed to figure out why this happen. We tried to change most of the settings for the session with the same result. The version of SecureCRT used is 6.2.3 Build 313. I also attached the session, the alternative keyboard emulation used and a raw log. If you look at the raw log at line 6 where it says "sshs....". At this line the user type sshs, press space and then press enter once. At line 7 i see a CR which is correct, but at line 8 where it says "06 22 3 --" it should stop there for input from the user, but instead a new CR is sent and then once more on line 9. At line 6 the user press enter only once. Using Procomm plus and hyperterminal this is working fine so he only have this problem using SecureCRT. Please let me know if further information is required. Regards gan |
#2
|
|||
|
|||
Hi Gan,
It is hard to say exactly what might be happening, but there could be a couple of possibilities. In the Terminal / Emulation / Modes category of the Session Options dialog is New line mode enabled in the Current modes section? If so, you may need to disable this option. Additionally, it is possible that the PBX server is not a compliant Telnet server, or it is not even using Telnet. As background, RFC 854 (Telnet) specifies that a lone CR (Carriage Return) character must be followed by a NUL (ASCII zero) character: The sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. This rule gives assurance to systems which must decide whether to perform a "new line" function or a multiple-backspace that the TELNET stream contains a character following a CR that will allow a rational decision. Note that "CR LF" or "CR NUL" is required in both directions... However, not all remote telnet server applications implement the Telnet RFC specification, and these applications expect a CR to be sent alone (without an accompanying NUL character). An option was added to SecureCRT starting in version 5.5 that, when enabled, will prevent the NUL character from being sent along with a CR character. To enable this .ini file only option, insert the following line to the top of the .ini file associated with the telnet session used for establishing the connection: D:"Server Requires Bare CR"=00000001 To edit a session's .ini file:Again, as this option forces SecureCRT to violate the Telnet protocol RFC, it's best to only make this change in the sessions where it is required rather than across the board to all telnet sessions. If you connect using a session and want to try editing the session's .ini file, locate the session's .ini file in the Sessions folder, inside the configuration folder, which is specified in the General category of the Global Options dialog. Does this help resolve the issue you are seeing when connected to the PBX system? |
#3
|
||||
|
||||
Hello Todd,
The setting in the session file solved the problem so just as you said it seems like the PBX server is not a compliant Telnet server. If some users for some reason want this to be default for all sessions will it work to make this change to the "default.ini" file and that way all new session will be created with this setting as default? Or should it be specified in the "global.ini" to make this setting default? I know it's not recommened to make this default, but some of the employees connect to PBX's only so will have this issue with all sessions. In that case they might find it better to be set by default. Thanks a lot for your help. Best regards gan Last edited by gan; 10-16-2009 at 01:36 PM. |
#4
|
|||
|
|||
Hi Gan,
To ensure that this setting is included in all new sessions, you would need to add the line to the Default.ini file. I have tested this, though, and it doesn't currently appear to work in SecureCRT 6.2.3 and newer. We are researching this issue. I will post to this thread when I have an update regarding this issue. If you would like me to update you directly, please send an email to support@vandyke.com with a subject of Attn: Todd - Forum Thread #4153. Additionally, I have created a feature request in our SecureCRT development database to expose this option in the GUI. Should a future release of SecureCRT have this option we will post to this forum thread. If you would like to be notified directly, please send an email to support@vandyke.com with a subject of Feature Request in Forum Thread #4153. |
#5
|
|||
|
|||
Hi Gan,
I am posting an update to the issue of being able to configure the Default.ini file to cause new sessions to have the D:"Server Requires Bare CR"=00000001 setting such that all new sessions will have this setting. If you make the Protocol for the default session Telnet, the setting to accommodate non-compliant Telnet servers will be propagated. Does this information help to resolve the issue for users that will only be connecting to PBX systems? |
#6
|
|||
|
|||
Hi Gan,
A pre-release version of SecureCRT now has the option to set Server Requires Bare CR via the GUI which would allow you to modify all sessions at a time. If you would like to test this, please send a message to support@vandyke.com with a subject of Attn: Todd - GUI - Bare CR. |
![]() |
Thread Tools | |
Display Modes | |
|
|