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