Solved Cannot see virtual serial port in Workstation VM

P

Pegasus711

Hello

I am trying to add a virtual serial port (as a named pipe) on two FreeBSD 10 VMs in workstation. One end, I am keeping it as the server (the one VM which will actually be having the virtual serial port) and the other VM will connect to the other end.

MY host is Windows 8.1. However when I power on the server, I try to see log messages to verify if the kernel detected my serial port using
dmesg | grep -E "^sio[0-9]" I see absolutely nothing. I believe
siois the name of the serial port driver, isn't it?

On checking if the corresponding device node got created, I check the contents of /dev/ and I see that /dev/ttyu0 is indeed there and I can indeed see it's configuration using stty -a -f /dev/ttyu0.

As an aside, what does the 'u' in ttyu0 signify? Does it mean virtual terminal number 0 now has a physical (from the VM's perspective) port attached to it? Since running stty on those other terminals like ttyv1 gives nothing.

So what does this mean? The device apparently there however the driver for it is no where to be found. Do I have to manually configure the serial port (as per this)? I think the port has been configured properly with some defaults so this part is presumably covered. So what are your suggestions could be behind this anomaly?

I am keen to hear your suggestions. What I am looking forward to, is to do some single stepping in the kernel via a serial debugger like one does in Linux. The server machine would be the one debugged and I would connect gdb via the other VM. So the first step is to have one VM talk to the other VM (both FreeBSDs) via the serial port.

And since I have a Windows host, I do not want to dual boot the system. Thus the use of virtualization
 
uart(4) shows this handy list:
Code: 
FILES
     /dev/ttyu?           for callin ports
     /dev/ttyu?.init
     /dev/ttyu?.lock      corresponding callin initial-state and lock-state devices

     /dev/cuau?           for callout ports
     /dev/cuau?.init
     /dev/cuau?.lock      corresponding callout initial-state and lock-state devices
 
SirDice said:
uart(4) shows this handy list:
Code: 
FILES
     /dev/ttyu?           for callin ports
     /dev/ttyu?.init
     /dev/ttyu?.lock      corresponding callin initial-state and lock-state devices

     /dev/cuau?           for callout ports
     /dev/cuau?.init
     /dev/cuau?.lock      corresponding callout initial-state and lock-state devices
Click to expand...

Thanks for the heads up sir!!

wblock@ said:
Not any more, no. Look for /dev/cuau0, that is the first serial port.
Click to expand...
The handbook suggests using 'uart' as the search phrase on dmesg whereas the FAQ suggests searching for sio. Time to update the FAQ, isn't it? Perhaps I should have gone for the handbook first!!! FreeBSD is famed for it's up to date and coherent documentation when compared to the much more popular Linux so I think this is really important to keep the FAQs synced with the other doc. Just my two cents :).

Coming back to the topic at hand, so this means that we have two interfaces for this "physical" serial port, one for dialing in and another for dialing out. And I can see both of them:
Code: 
crw-------   1 root  wheel     0x2d Feb 22 15:47 ttyu0.lock
crw-------   1 root  wheel     0x2c Feb 22 15:47 ttyu0.init
crw-------   1 root  wheel     0x2b Feb 22 15:47 ttyu0
crw-rw----   1 uucp  dialer    0x30 Feb 22 15:47 cuau0.lock
crw-rw----   1 uucp  dialer    0x2f Feb 22 15:47 cuau0.init
crw-rw----   1 uucp  dialer    0x2e Feb 22 15:47 cuau0

So basically, what I want is to use minicom on the client and be able to remotely log in to the server. To that end, I added console="comconsole" into /boot/loader.conf and I could barely see the boot up messages (an issue related to baud rate I believe and can be looked at later) but saw the final login prompt. Thus confirming that the boot messages as well as the login screen have been redirected to /dev/ttyu0 on the server.

However when I use minicom from the client side I get a cannot open /dev/ttyu0. permission denied error(although I am root). On trying to connect to it via Putty, I get a
unable to open connection to \\.\pipe\com_1 error.

I'd love to get this thing to work so I can start exploring and single stepping the FreeBSD kernel. Waiting for your input
 
The last time I tried minicom, it offered essentially nothing that was not already available with cu(1). So that is one way you might simplify testing.

/dev/ttyu0 is an incoming port. It will not work on the "client". Use the correct port: cu -l /dev/cuau0 -s 9600.

Updates for the FAQ will be gratefully received.
 
wblock@ said:
The last time I tried minicom, it offered essentially nothing that was not already available with cu(1). So that is one way you might simplify testing.

/dev/ttyu0 is an incoming port. It will not work on the "client". Use the correct port: cu -l /dev/cuau0 -s 9600.

Updates for the FAQ will be gratefully received.
Click to expand...
Regarding the FAQ, should I just send the maintainer an email with my "findings"? Or should I first write to the mailing list or some such?

cu works like a charm. I wonder why minicom was giving me so much trouble. I can now log into the server with this.

And can I tail the /dev/ttyu0 file on either side to listen to messages sent by the peer? Any best practices followed by the community for something like this?

Once this is working, It'll be best to create a new thread related to kernel debugging between these two VMs
 
aijazbaig1 said:
Regarding the FAQ, should I just send the maintainer an email with my "findings"? Or should I first write to the mailing list or some such?
Click to expand...
A bug report with patches is the best. You can also send a message to the freebsd-doc mailing list. In either case, it is important to not just identify what is wrong, but show specific changes to make it right.
 
Do you mean a patch file created with the patch utility for changes in the doc?? Perhaps best to send a message to the mailing list, no?

And lastly could you please let me know how to monitor incoming messages if not redirected to the getty process? Just reading /dev/tty* file is enough?

I connect with /dev/ttyu0 on one of em and with /dev/cuau0 on the other one and I can read and write stuff in either direction which isn't displayed locally although one can read it on the peer. I tried doing the other way around and that works as well. So what could be the use to have two interfaces? I know they differentiate between "dial-in" and "dial-out" devices however a utility like cu works identically with both of them. So I can even read messages when cu is connected to /dev/cuau0 and I can even write messages when cu is connected to /dev/ttyu0. This is rather confusing for me.

Are are any best practices/convention followed by the community?
 
Long time ago, you used to put gettys on ttys for incoming phone calls, and then if needed, used a cua to call out, stealing the line to the modem. tty was supposed to freeze, while cua was in use.

I would have called it an ytt :)
Juha
 
aijazbaig1 said:
Do you mean a patch file created with the patch utility for changes in the doc?
Click to expand...
Or svn diff, as shown in the FDP Primer: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/overview-quick-start.html

The important part is to show exactly what is wrong, and an actual corrected version. We often see people saying "section 49.2 is wrong and should be fixed." This assumes that we know what they are talking about and also know how to fix it.

Perhaps best to send a message to the mailing list, no?
Click to expand...
Mail messages are transient, while bug reports remain in the database.
 
You must log in or register to reply here.
Back
Top