From: Michael Tokarev Subject: Re: serial port again Date: Fri, 21 Aug 2009 13:01:54 +0400 Message-ID: <4A8E6282.8030704@msgid.tls.msk.ru> References: <4A6B6695.3040505@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: KVM list Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:34875 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755035AbZHUJBz (ORCPT ); Fri, 21 Aug 2009 05:01:55 -0400 In-Reply-To: <4A6B6695.3040505@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: 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) ? 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 ]"... > 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 ... > 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 ... > > 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 ]"... > 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 ]"... > 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 = ; > eol2 = ; swtch = ; 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 = ; > eol2 = ; swtch = ; 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