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
