#83 NULL byte (0x00) is sent after every CR (0x0D) ?

[Matthew]

When sending a byte of value 0x0D hex (Carriage-Return), RealTerm sends a NULL byte (0x00) following the 0x0D byte. I can find no other byte value that has the same behavior. This happens when typing in the terminal, as well as from the "Send" tab. As a matter of fact, I have not found any way to send 0x0D without RealTerm also sending a NULL (0x00) byte.

This is present in V3.0.0.33 and all earlier releases that I have ever used.

This has caused significant problems in the past and present. Actually it makes RealTerm not useable for my testing purposes.

[Simon Bridger]

I don't see it myself.

How are seeing this? What is the port? What is the DisplayAs mode?

a) start 2 instances , one as 127.0.0.1:server and other as 127.0.0.1:telnet. Does 0x00 get sent?
b) physically link RXD and TXD on a port?
c) Do you see it when half-duplex is checked?

[Matthew]

Hello,

You will not see the problem in the RealTerm display when connecting 2 instances of RealTerm server/client because RealTerm is (apparently) masking the problem. Sometimes we say about this, "It is drinking its own koolaide" ;-)

The easiest way I found to demonstrate is to run 2 instances of RealTerm on separate hosts, one as TCP server and the other as TCP client. For example....

hostA :  "server:5555"
hostB :  "<IP address of hostA>:5555".  

Now run Wireshark on hostA (or hostB, shouldn't matter). Note: before starting the capture, it makes things much cleaner if you enter a capture filter of "tcp && port 5555".

On hostB, go to the "Send" tab and send a single byte "0D".

Now observe your Wireshark capture, and you will see the magic happen...

You can also try sending "as ASCII" a string like "test\r" and you will also see that RealTerm always adds the NULL 0x00 byte after the 0x0D.

Hopefully that is enough for you to squash this bug. I would be very grateful! A while back I spent numerous hours troubleshooting a system because I thought it was erroneously generating null bytes, but then I realized RealTerm was the source. Argh, bummer!

Truly, RealTerm is a very handy tool! But this particular bug is a big problem for me. Thank you!

[Simon Bridger]

So this problem is only happening in TCP/IP mode then?

I think you are confused bout TCP/IP comms.
Telnet protocol involves escaping codes using NUL. That is what you are seeing.

RAW does not do the telnet escapes, and hence , won't be adding NUL

See the radio buttons Port-> WinsockIs

So this is easy to see on a single machine, with one instance set to RAW and the other to TELNET

[Simon Bridger]

Think I was talking bull about the escapes - 0xFF is escaped.
This describes how telnet handles EOL
http://www.freesoft.org/CIE/RFC/1123/31.htm

"When a user presses the "end-of-line" key, some User Telnet implementations send CR LF, while others send CR NUL (based on a different interpretation of the same sentence in RFC-854). These will be equivalent for a correctly-implemented ASCII server host, as discussed above. For other servers, a mode in the User Telnet is needed."

So I am sure the CR NUL is deliberate, and using RAW mode is probably what you were expecting.

Should I be changing it to send CRLF when enter is hit? I don't really think so, but I do see that when <shift>Enter is pressed CR NUL LF is sent instead of CRLF, so that is probably wrong, and should be fixed.

[Simon Bridger]

fixed, V34 behaviour in Telnet mode:
if CRLF checked, then ENTER sends CRLF otherwise sends CR NUL
if <shift>ENTER sends CRLF

[Matthew]

I think you are confused bout TCP/IP comms

Am I? Well since we're being brutally honest, perhaps I was indeed "confused", but not about TCP/IP comms. Rather, perhaps it was due to RealTerm's extremely busy UI with its many options all over the place, which can sometimes result in ambiguous or overlooked settings or combinations of settings.

Also notable... I have tested many telnet clients currently available, and yours is the only one that uses "CR NUL" by default for EOL. All others use "CR LF".

Thank you for pointing out the RAW option. That works.

[Simon Bridger]

The only one I use is TeraTerm, and it seems to do CR NUL

What others did you use?

[Gordon Rogers]

This issue also exists in the Send tab Dump File to Port feature, testing using 3.1.44
When sending a file <null> is added between <cr> & <lf>, causing <cr><lf> to send as <cr><null><lf></lf></null></cr></lf></cr></lf></cr></null>