telnet command has problem with 0x0D content

[Edi_001]

To Whom it may concern,

I use the Labview telnet tools to connect to a unix machine and execute some diagnostics. One of the diagnostic tools generates a file with known test pattern kind of MPEG stream. Later I use  "cat filename" and parse the respond. The packet 13 should contain 184 0x0D0D's but the telnet read returns 0x0A0D, Until now I didn't find a way to correct this.

Copy the attached file to any unix system and connect via telnet tools and execute cat edi123.txt display the response in hex mode and compare the content of response and the file. BTW Labview ftp tools transfer the data correctly in both direction from unix or to unix.

If you have a code which works would be great.

Thanks,

Edi

[Rod42]

I don't have experience of the LabVIEW telnet tools, but have some ideas that may help you.

Telnet is/was mainly used for transfer of text. As such it can "helpfully" convert "new line"  from other systems to how a "new line" appears on your system. "New line" is often 0x0A on Unix. Other systems use 0x0D (Mac) or 0x0D0A (DOS/MS-Windows)

One option in the Unix telnet command is to convert incoming 0x0D characters to the two character sequence 0x0D0A. It looks like this conversion is what is happening for you (but it could be done be either by the telnet server on the Unix system or the telnet client in LabVIEW).

-- Extract from Unix man page for telnet ---

crmod       Toggle carriage return mode.  When this mode is enabled, most carriage return characters received from the remote host will be mapped into a carriage return followed by a line feed. This mode does not affect those characters typed by the user, only those received from the remote host. This mode is not very useful unless the remote host only sends carriage return, but never line feeds. The initial value for this toggle is FALSE.
--- End extract ---

So check the options with the LabVIEW telnet to see if it is doing the conversion, and also check the man page for your Unix telnet server (daemon). When you're sending binary data ypu will need to make sure that both send and receive ends have all their end of line conversion disabled. Of course this may cause other problems if you are changing what is received at the end of line and relying on what happened before.....

Good luck,

Rod.

[Edi_001]

Thanks for reviewing,

the cat command has some arguments. I didn't find any combination which is correct for my purpose. If you use telnet client example login to a linux system and use "cat edi123.txt > edi234.txt" then ftp edi234.txt back to windows and compare the content. This contains the correct content, but if you use "cat edi123.txt" then change the display from telnet client to show in Hexa display. You will realize the packets containing "0x0D0D"'s are converted to 0x0D00 0x0D00" or "0x0D0A 0x0D0A" depends from echo turned on or off. So this doesn't help much, I have not an idea how to display

-Edi