Re: serial port again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Adding qemu-devel@ since kvm@ is not interested
 and since serial port seems to be qemu thing]

Michael Tokarev wrote:
Is it just me with this issue?  Anyone who has serial port
working for anything more than serial console (that is, with
control chars etc, not only text) ?

I just ran a quick test.  Telling pppd(8) to escape all
control characters on  both ends (default-asyncmap option)
let the connection to run.  So kvm/qemu interprets (some)
control characters or sequences somehow.

Anyone here who's able to tell something about the
8bit cleaness of the qemu serial ports?

Thanks!

Michael Tokarev wrote at Sun, 26 Jul 2009 00:09:57 +0400:
Finally, I'm trying to use serial port in a kvm guest.
And as in my previous attempt, it does not quite work.

qemu-kvm-0.10.5, 2.6.27.latest guest, 2.6.30.latest host.

Running pppd over real serial/model lines for now.  Dialing
into kvm virtual machine from another location, kvm pppd
acts as dial-in server.  Authentication succeeded, 2 pppd
starts exchanging options.  But at least one option never
reaches the dialing in machine from a ppp server.

Here's some straces.  I'm omitting client to server
communicatiins, leaving only server to client.

server:
23:18:43 send(3, "<31>Jul 25 23:18:43 pppd[3199]: sent [PAP AuthAck id=0x1 \"\"]"..., 60, MSG_NOSIGNAL) = 60
23:18:43 write(7, "\300#\2\1\0\5\0"..., 7) = 7

client:
23:18:44 read(7, "\300#\2\1\0\5\0"..., 1502) = 7
23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[31168]: rcvd [PAP AuthAck id=0x1 \"\"]"..., 61, MSG_NOSIGNAL) = 61

as you see, the 7 bytes "\300#\2\1\0\5\0" were received successfully.

server:
23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[3199]: sent [IPCP ConfReq id=0x1 <addr 192.168.2.17>]"...
23:18:44 write(8, "\200!\1\1\0\n\3\6\300\250\2\21"..., 12) = 12

and this one is never ever received by client.

server:
23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[3199]: sent [CCP ConfReq id=0x1]"...
23:18:44 write(8, "\200\375\1\1\0\4"..., 6) = 6

client:
23:18:44 read(8, "\200\375\1\1\0\4"..., 1502) = 6
23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[31168]: rcvd [CCP ConfReq id=0x1]"...

and again, this 6-char string gets received ok.

server:
23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[3199]: sent [CCP ConfRej id=0x1 <deflate 15>...
23:18:44 write(8, "\200\375\4\1\0\17\32\4x\0\30\4x\0\25\3/"..., 17) = 17

client:
23:18:44 read(8, "\200\375\4\1\0\17\32\4x\0\30\4x\0\25\3/"..., 1502) = 17
23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[31168]: rcvd [CCP ConfRej id=0x1 <deflate 15>...

got this 17-char string ok.

server, after some more exchanges which are all ok, repeats the IP request: 23:18:47 send(3, "<31>Jul 25 23:18:47 pppd[3199]: sent [IPCP ConfReq id=0x1 <addr 192.168.2.17>]"...
23:18:47 write(8, "\200!\1\1\0\n\3\6\300\250\2\21"..., 12) = 12

and again, this request never reaches the other end....

and finally the client disconnects, timing out waiting for the addresses
being agreed upon.

Another thing that never reaches client:

23:18:44 send(3, "<31>Jul 25 23:18:44 pppd[3199]: sent [IPCP ConfRej id=0x1 <compress VJ 0f 01>]"...
23:18:44 write(8, "\200!\4\1\0\n\2\6\0-\17\1"..., 12) = 12

So, either we've issue with 12-byte strings sent from kvm to host
(no 12-byte string gets received actually, but those mentioned are
the only sent), or an issue with certain character (sequence) --
but I see all the individual chars in other places -- maybe only
except \6 (ACK).

Exact same config, on exact same machine but on host (not guest) worked for some 10 years already, and works today still. Client immediately sees the
IPCP ConfReq message and connection progresses.



That was long and tiring excercise. Now something simpler: stty outputs on both host and guest for the same (physical) serial port while pppd is running
in guest.

GUEST:
speed 57600 baud; rows 0; columns 0; line = 3;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

HOST:
speed 57600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke


wtf.  The line discipline is wrong, it looks like.  Especially important
is opost (together with onlcr) on host: it's output processing which gets
enabled while it should not be.  Guest correctly turned it off.  Also of
interest is echoctl but it's not that important. For others, like local/-local and crtscts/-crtscts I can imagine the difference since kvm should pass the
info to guest instead of beiong blocked itself.


Any comments on all this?

Thanks!

/mjt

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux