serial port again
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
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:
Quoted 117 lines
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:43send(3, "<31>Jul 25 23:18:43 pppd[3199]: sent [PAP AuthAck id=0x1 \"\"]"..., 60, MSG_NOSIGNAL)= 60 23:18:43write(7, "\300#\2\1\0\5\0"..., 7)= 7client:
23:18:44read(7, "\300#\2\1\0\5\0"..., 1502)= 7
23:18:44send(3, "<31>Jul 25 23:18:44 pppd[31168]: rcvd [PAP AuthAck id=0x1 \"\"]"..., 61, MSG_NOSIGNAL)= 61as 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:44write(8, "\200!\1\1\0\n\3\6\300\250\2\21"..., 12)= 12and 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:44write(8, "\200\375\1\1\0\4"..., 6)= 6client:
23:18:44read(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:44write(8, "\200\375\4\1\0\17\32\4x\0\30\4x\0\25\3/"..., 17)= 17client:
23:18:44read(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:47write(8, "\200!\1\1\0\n\3\6\300\250\2\21"..., 12)= 12and 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)= 12So, 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(quoted diff) +0
-2-ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0bs0 vt0 ff0
(quoted diff) +0
-2-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echokeHOST:
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;(quoted diff) +0
-3-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
(quoted diff) +0
-2-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echokewtf. 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
[Adding qemu-devel@ since kvm@ is not interested
and since serial port seems to be qemu thing]
Quoted 3 lines · Michael Tokarev
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!
Quoted 123 lines
Michael Tokarev wrote at Sun, 26 Jul 2009 00:09:57 +0400:
Quoted 117 lines
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:43send(3, "<31>Jul 25 23:18:43 pppd[3199]: sent [PAP AuthAck id=0x1 \"\"]"..., 60, MSG_NOSIGNAL)= 60 23:18:43write(7, "\300#\2\1\0\5\0"..., 7)= 7client:
23:18:44read(7, "\300#\2\1\0\5\0"..., 1502)= 7
23:18:44send(3, "<31>Jul 25 23:18:44 pppd[31168]: rcvd [PAP AuthAck id=0x1 \"\"]"..., 61, MSG_NOSIGNAL)= 61as 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:44write(8, "\200!\1\1\0\n\3\6\300\250\2\21"..., 12)= 12and 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:44write(8, "\200\375\1\1\0\4"..., 6)= 6client:
23:18:44read(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:44write(8, "\200\375\4\1\0\17\32\4x\0\30\4x\0\25\3/"..., 17)= 17client:
23:18:44read(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:47write(8, "\200!\1\1\0\n\3\6\300\250\2\21"..., 12)= 12and 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)= 12So, 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(quoted diff) +0
-2-ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0bs0 vt0 ff0
(quoted diff) +0
-2-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echokeHOST:
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;(quoted diff) +0
-3-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
(quoted diff) +0
-2-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echokewtf. 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
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html