Hi,

There are a couple of things that can cause this when the debugger is active. 

1)
When the debugger is running it currently stores the data waiting for a line feed character. It times out after a couple of seconds if it does not receive a line feed and displays what is in the buffer.

So the first question is to find out if when you send "1234567890 abcdef" that you are using println() and not print()? println() sends a line feed.

2)
The seconds thing is to consider that, optionally but by default, the debugger shares the serial port with the print() messages already in the sketch. 

You can see from the VMDPE messages that with debugging enabled we had a breakpoint running frequently. This combined with the messages in the sketch can cause the serial buffer on the Arduino to overflow causing characters (such as line feed) to be lost. Depending on your pc it can also cause the debugger to work very hard.

This can especially be a problem if a breakpoint is added to an Arduino code line that also sends a serial message. So it's best to keep breakpoints away from lines that contain manual serial.print() debug messages (might not be relevant but thought I would mention it.

It would help if you confirmed if you are using the automatically created demo breakpoint that Visual Micro  adds for new users or your own? and in any case what the conditions are that have been applied to the breakpoint which can be used to reduce the number of debug packets and therefore the amount of serial.

3)

I am familiar with the telnet console on the Yun but not with the way your telnet example has been configured to intercept serial. You mention your telnet shows 3 output but it display 2 lines of text. This suggests to me that there is some serial printing without a line feed. It is okay to print without line feed but the end of a line or command should then have a line feed included otherwise you will hit the 2 second timeout before the buffer is flushed to the screen.

Summary

So to recap, line feeds serial.println() or "\n" in a string cause the debugger buffer to flush to screen avoiding 2 seconds timeout. 

Too much/many Arduino serial or debugger statements on top of manual serial messages can cause packets to be lost or corrupted but normally I would expect Visual Micro to throttle the Arduino cpu and prevent too much serial data. However Visual Micro can't know wh This is the same if you do too much serial with the Arduino in a tight loop whilst also hammering the mcu with other functions. The debugger allows breakpoints to be filtered using timers (hit count) or simple/complex Conditional expressions.

This is an area that we do expect will develop further during the next few months but you can certainly get it to work quite easily armed with this knowledge (i hope).

If you understand how to create breakpoints but want to run debug without any, you can switch off the one that is automatically created in the loop by Visual Micro by deleting it then setting this Tools>options>visual micro property to False. 

Micro debug Automated > loop() - Auto create breakpoint 

Note: The auto created breakpoint can be deleted and if you have added your own breakpoints to the project then Visual Micro will not auto create another one. 

At the very least I suggest you put breakpoints within "if" conditions in the code, this is the same way that the Serial.println("Hello, client") only fires when a client connects not each iteration of the loop.

I hope this helps, you should find that by removing some of the manual print() messages in the code and/or using conditional breakpoints instead the problem is solved.

Let me know how you get on. If your problem persists then please zip and email your sketch to info [at] visualmicro.com. I have an arduino ethernet board in a box unopened so this might be a time to try it out and replicate your code 

Alternatively you can hook the debugger up to a couple of digital pins instead.