So QEMU looks like it’s the answer to many things when it comes to virtualization, regardless of your needs for a Guest OS. This post is not about whether or not QEMU is the greatest thing since sliced bread though, which may disappoint you if you’re a QEMU fan. I’ve spent the better part of three days reading up on virtual devices in QEMU Guests, more speficially serial (or “COM”) ports.
And I need, of course, “something”, that will expose a serial port to the Guest, and on the Host side, it needs to connect to “other systems”. The connecting to other systems part is fairly simple. When told to, it needs to “call” a remote system using TCP/IP and establish a connection. Once connected, it needs to act as a bridge between the remote system and the virtual serial port that the Guest is using.
You would think that using your favorite search engine and looking for “Virtual Serial Port” or “Virtual Ports in QEMU” would yield a barrage of hits, with detailed instructions on how someone has already done this. That’s what I was thinking anyway. Three days later, it turns out that this is not the case. There are many projects that, by name and first impressions, look very promising. But they all come up short in one way or another. And I do need this to be simple, because the problem is not complex in itself. The best candidate so far is something called “tcpser” (originally written Jim Brain). It also emulates a modem (to some extent) so that the application in the QEMU Guest can issue an “ATDT thedestination.com” to establish a data connection. I also ran across a few forks and improved versions.
There is only one problem with tcpser, or rather, with the equipment I often develop on: Most modern laptops have no physical serial ports. tcpser wants to talk to /dev/ttyS0 or COM1 (or any other physical serial port) because it needs to read line status like DCD/CD/DTR/DSR and so on.
If you can find a Virtual COM Port emulator for 64-bit Linux or 64-bit Windows that actually behaves like a serial port, then you’re better at “internet searching” than me :) But for the time being, I’m trying to see if I somehow can fake the appearance of a port to tcpser and then take it from there. This is not was I was supposed to be working at in regards to the Reboot project, but then again, sometimes you dig way too deep for your own good :)
If you want the “requirements list” for what I need, here you go:
- Must be able to establis a raw Telnet session with system over Internet
- Must not be suffering from problems with “special characters”
- Must not require the remote system to be hardwired
- Must not require the remote port to be hardwired
- Must support ATDT as the signal to create the connection
- Must somehow honor DTR to disconnect
- Must work with QEMU
- Must work with 64-bit Linux, as a minimum requirement (Host)
2 thoughts on “Virtual COM Port for 64-bit QEMU Hosts and Guests”
The reverse direction in my case.
VirtualBox TCP connects into tcpser on the Host OS, and Host OS telnets to remote BBS.
My Host OS: Ubuntu 16.04
My Guest OS: MS-DOS 6.22
My Hypervisor: VirtualBox
VirtualBox Serial Port Config:
Port Mode: TCP
Connect to existing pipe/socket: Yes (seems backwards)
tcpser on Host OS: tcpser -v 25232 -n 2568954786 bbs.sursum-corda.com
Right now I have a problem with tcpser holding back inbound data until I transmit again from the client. Aside from holding back an echo’d character by one keystroke, it’s working.
46:30:-367675648:DEBUG:Data available on socket
2019-06-25 07:46:30:-367675648:DEBUG:Read 57 bytes from socket
2019-06-25 07:46:30:-350890240:DEBUG:Initial Break Delay detected
2019-06-25 07:46:30:-350890240:DEBUG_X:Waiting for modem/control line/timer/socket activity
2019-06-25 07:46:30:-350890240:DEBUG_X:Command Mode=0, Connection status=1
2019-06-25 07:46:32:-350890240:DEBUG:Data available on serial port
Hi there Steven, are you sure this is not a matter of “incorrect” flow control settings? Or have you already tried adjusting that in your application?