Serial I/O troubles between Guest and Host
|com port, uart, serial, flow control
I've only personally seen this in a Windows 10 Pro (64-bit) host environment. But some others I've been in touch with seem to have this with other configurations too.
Host running Windows 10 Pro (64-bit) on computer with no physical COM ports (Lenovo T470p laptop). Guest can be "anything", but I've tested with FreeDOS, Ubuntu Linux 16/17, and Windows XP. Using NetSerial (http://pcmicro.com/netserial/) to emulate a COM port. NetSerial will behave as a COM port and as a "modem emulator" to allow "ATDTfoo.bar" to establish a Telnet session to foo.bar.
In VB Guest Config, I set up the serial port as needed. When Guest OS is launched, the results vary. But there seems to be flow control issues between the Guest and the Host. I've been talking to the author of NetSerial and have been testing with beta versions of NetSerial as well. He sets the correct flags for flow control, etc. But somwhere between the Guest and the Host, data is lost or delayed indefinitely.
When booting a Linux Guest in this setup, doing "dmesg |grep tty" does reveal that Linux has detected a 16550A UART on COM1, which is good thus far. Opening a Linux terminal emulator (any will do) using /dev/ttyS0, data IS being sent to NetSerial on the Windows Host. Using it's "monitor", I can see data being received from the Client terminal emulator. I can also see data being sent FROM NetSerial into the COM port. On the Guest, however, nothing is received.
When booting a FreeDOS Guest in this setup, I get similar results to the above. Data missing. Data delayed. Flow control issues, etc.
Every application that I have tested with is requesting flow control to be CTS/RTS (hardware) and not XON/XOFF.
In almost exactly the same scenario, if I "move" NetSerial so that it runs inside the guest (Windows XP), there is no problem whatsoever. In that case, NetSerial is emulating a COM port and using Windows XP Guest Network to reach the Internet. No data being lost. No flow control issues.
So this is definitely related to the "bridge" between the COM port emulator running on the Host side of things.
There's still quite a bit of use left for serial device I/O, so I would expect this to work 100% in a product of VirtualBox's maturity. This problem has been present in at least the past 8-10 releases, and I suspect before that.
This is not a case of misconfiguration.