Serial I/O troubles between Guest and Host

[joho68]

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.

Scenario:

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.

[domyes]

Edit: Issue described in a closed ticket: #5135

---

I'm experiencing similar flow control problems on Windows 7 x64 (v5.2.0)

---

Setup

Host: Windows7 x64

Client: Ubuntu 16.04

My setup uses com0com to create a pair of virtual serial ports, where the RX/TX of the first port is connected to TX/RX of the second (same as a hardware echo). This is so that you can have control of:

HOST <--> CLIENT (virtual COM4)

This is ultimately done with a (COM11, COM12) pair:

HOST <--> COM12 <--> COM11 <--> CLIENT (virtual COM4)

The host, running host.py, sends variable sized packets to the client. The client repeatedly checks its serial (dev/ttyS3) for anything on the RX buffer.

When sending data from the host, it is expected that the client would receive the data in full, followed by repeated zero reads (as there is nothing left on the buffer)

---

The Problem

When sending large packets from the host machine, only the first 256 bytes are received, until another payload is sent. For example, if you send a payload of size 300, it successfully reads the first 256 bytes; the remaining 44 bytes are not received until the next packet is sent.

HOST:

Enter a packet size (>=4): 300
Sending the data 0 (300 size)
Enter a packet size (>=4): 4
Sending the data 1 (4 size)
Enter a packet size (>=4):

CLIENT:

256: 'S0**************************************************************************************************************************************************************************************************************************************************************'
0: ''
0: ''
0: ''
0: ''
48: '******************************************F0S1F1'

Given that the 0th packet is transferred in it's entirety, it would seem as though the virtual port does not have correct flow control (as there must be data buffered, but the port is not readable)

On the host machine, the same procedure between COM11 and COM12 (i.e. what com0com is responsible for), behaves as expected. This indicates that the problem is not caused by com0com

---

Links

host: https://www.virtualbox.org/attachment/ticket/17093/host.py

client: https://www.virtualbox.org/attachment/ticket/17093/client.py

com0com: ​http://com0com.sourceforge.net/

[Mihai Hanor]

I can't reproduce it on real hardware. I've tested with two bare-metal PCs, one running Windows 10 with VirtualBox 5.2 and an Ubuntu 17.10 64 bit guest, having attached a USB-to-serial adapter (guest serial is set to Host device). The 2nd PC, an older PC, with a build-in serial port, running Windows 7 32 bit and Python3. It doesn't matter which one runs client.py or host.py.

[domyes]

Okay, it seems to work fine with some hardware. I can verify that it works without a fault using a setup similar to MihaiH. The setup I used is (usb-to-serial --> null modem --> usb-to-serial)

However - the problem still occurs when using ports created with com0com. I reiterate that there is only a problem when forwarding the port through VirtualBox, since it works perfectly when running host.py and client.py outside of VirtualBox. The problem also occurs on a serial device with different hardware

Perhaps there are differences in the drivers that cause this behaviour?

[Mihai Hanor]

I've cloned my Ubuntu VM and used a Host pipe for both VMs to communicate over it as serial line. In this test case, it's looses characters, even when sending only 4 characters, the client.py script reports the receive of 2 or 3 characters.

[Mihai Hanor]

This seems to occur only on the Windows 10 host. On my Debian host, same PC, I can't reproduce the issue with the Host pipe serial connection.

[aeichner]

The issue with named pipes on Windows hosts is known and will be fixed in the next maintenance release (see ticket #17227). As for the issue with host serial ports, I have currently no idea what the problem is nor do I have enough COM ports to test this. I already ordered a USB to 4x serial converter which will hopefully arrive soon. I'll be able to debug this particular problem afterwards.