From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: serial port again Date: Fri, 21 Aug 2009 18:34:39 +0400 Message-ID: <4A8EB07F.10703@msgid.tls.msk.ru> References: <4A6B6695.3040505@msgid.tls.msk.ru> <4A8E6282.8030704@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org To: KVM list Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:45073 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932214AbZHUOek (ORCPT ); Fri, 21 Aug 2009 10:34:40 -0400 In-Reply-To: <4A8E6282.8030704@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: [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 ]"... >> 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 > > -- > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeVCf-000857-No for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:34:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeVCb-000816-Hm for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:34:53 -0400 Received: from [199.232.76.173] (port=41648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeVCb-00080q-8L for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:34:49 -0400 Received: from isrv.corpit.ru ([81.13.33.159]:45412) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MeVCa-0008Sh-9D for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:34:48 -0400 Message-ID: <4A8EB07F.10703@msgid.tls.msk.ru> Date: Fri, 21 Aug 2009 18:34:39 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <4A6B6695.3040505@msgid.tls.msk.ru> <4A8E6282.8030704@msgid.tls.msk.ru> In-Reply-To: <4A8E6282.8030704@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: serial port again List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: KVM list Cc: qemu-devel@nongnu.org [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 ]"... >> 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 > > -- > 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