serial port again

serial port again

[Michael Tokarev]

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

Re: serial port again

[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) ?

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 <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

Re: serial port again

[Michael Tokarev]

[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 <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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html