Re: serial port again

[Michael Tokarev <mjt@tls.msk.ru>]

[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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html