telnet not working in MQX 4.0

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

telnet not working in MQX 4.0

Jump to solution
1,682 Views
bonzo
NXP Employee
NXP Employee

I have found an issue with the telnet demos with MQX 4.0.

Setup:

TWR-K60N512 + TWR-SER

Compiler:  IAR V6.40

Libraries compiled with debug enabled, with ttyd: as serial port (using the serial port on the TWR-SER)

The secure telnet demo (C:\Freescale\Freescale_MQX_4_0\demo\security_telnet\iar) does not work.

It prints out about 8 characters at a rate of about 2 characters per second, then stops.

The telnet-to-serial demo is also slow, but not as severe as the secure telnet demo.

I tested these programs with MQX 3.8 and it works as expected.

So there is an issue with MQX 4.0.

I also tested the hvac demo with MQX 4.0 and it seems to work OK.

Labels (1)
Tags (3)
1 Solution
782 Views
bonzo
NXP Employee
NXP Employee

Thanks Martin.

I found out that it is a reported bug and will be fixed in MQX 4.0.2.

Fixing Windows is certainly an option, but it's probably best that our demos run without modifying Windows registries.

Brad

View solution in original post

5 Replies
782 Views
stevejanisch
Contributor IV

On telnet working slow...

I've seen the same notes about "fixing" windows acknowledge.  I attempted to try and could really never get any of the numerous suggestions to work.

I was leery of this advise.  One thing I noted is that only output (what was written by printf) was slow.  The input appeared faster (in fact on my TWR the output actually appeared to go faster when you typed in characters.  So what I did was revise the samples to not use printf (or fprintf).  What I do instead is just keep the telnet service as a socket server, and use the socket commands send and recv.

There doesn't seem to be any delay using the send.

0 Kudos
782 Views
Martin_
NXP Employee
NXP Employee

These demos (like serial to telnet) send (outbound path from TWR) short TCP packets (just one character in payload).

If your remote peer is Windows TCP stack, there is 200 ms TCP ACK delay turned on by default, for example in Windows 7. If you check communication log you will see the TCP packets are about 200 ms apart from each other.

This default Windows TCP stack behavior can be changed with the help of two registry keys:

http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/9f476410-a7a6-4f5d-b9a9-0a...

This helps much, in both Win XP/Win 7.

However, we also identified a different behavior of the TCP PUSH flag (PSH) in these demo codes (short TCP packets) between MQX 3.8 RTCS and MQX 4.0 RTCS. MQX 3.8 sets the PSH flag into each outbound TCP packet, but the MQX 4.0 uses this flag differently. Therefore I think (maybe I am wrong) Windows is buffering incoming data and it flushes them on the terminal only time to time.

0 Kudos
783 Views
bonzo
NXP Employee
NXP Employee

Thanks Martin.

I found out that it is a reported bug and will be fixed in MQX 4.0.2.

Fixing Windows is certainly an option, but it's probably best that our demos run without modifying Windows registries.

Brad

782 Views
craigreed
Contributor I

Did these demos get fixed?  I can't even find the demo for security_telnet in the 4.0.2 release. Has it moved somewhere? Or been removed?

0 Kudos
782 Views
Martin_
NXP Employee
NXP Employee

MQX 4.0.2 RTCS has been fixed. There is "eth_to_serial" example in MQX 4.0.2 that you can try.

0 Kudos