The PPP link works well at the beginning, but ...
Thomas TESTASECCA
I explain my problem :
i want to connect a PC (under W2000) and a developement board (under linux
2.2) throw a PPP link (using 2 modems).
The PC is the clients and the board is the server.
There is no problem to connect with PPP : i can send Ping, i can do Telenet
on the link ...
But when i load a Web page from the server ( Apache is running under
linux ), the Page starts to come and COUIC !!! thats'all , the link is
broken !!!
In fact, the connection becomes unidirectional ( Client -> server ) !!!!!
When i ping the server from the server : no response .
When i try to connect with TCP : no response.
Linux cannot send to the client.
PPP is 2.3.10
I think, that's come from PPP, or from a bad config of LINUX ??!!
Because the modems are OK, i tried with a null modem link and that's the
same problem
ok, i guess that someone will help me
thanks a lot
thomas
James Carlson
> i want to connect a PC (under W2000) and a developement board (under linux
> 2.2) throw a PPP link (using 2 modems).
> The PC is the clients and the board is the server.
> There is no problem to connect with PPP : i can send Ping, i can do Telenet
> on the link ...
> But when i load a Web page from the server ( Apache is running under
> linux ), the Page starts to come and COUIC !!! thats'all , the link is
> broken !!!
COUIC?
> In fact, the connection becomes unidirectional ( Client -> server ) !!!!!
> When i ping the server from the server : no response .
> When i try to connect with TCP : no response.
> Linux cannot send to the client.
It sounds like you have one of these four devices configured to do
software (XON/XOFF) flow control. Try setting "asyncmap a0000" on the
Linux machine.
--
James Carlson, Solaris Networking <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Thomas TESTASECCA
But i've done what you have said ( async map a0000 ), but the problem stays
....
I give you more informations about my configuration.
I'm currently evaluating, the LynuxWorks embedded Linux (BlueCat), it is
based on linux 2.2....
I test on a Developent board ( CyrrusLogic CDB 89712 ), with an ARM 7
processor. This board have
two UART, an Ethernet controller, 16 Mo of RAM.
The RTS is not supported, so i use no Flow Control.
The aim is to run, a web server on the board (Apache ), and to connect to it
throw a PPP link ( with 2 standard modems ),for now, i use, a null modem
cable (serial).
I use PPPD 2.10.
The client is a PC under W2000 (with an ethernet card, ...).
Ok, well ...
At the beginning of the story :), the client (PC) and the server are
connected by ethernet ( To load the soft into the board ), PC is
200.200.200.5 and the board is 200.200.200.33.
Now i want to connect throw a PPP link, so i disable the eth0 IF of the
board.
I launch PPP on the ttyS0 (9600), I launch the dialup of W2000 ... all works
fine : i'm connected.
Here is my "options" file :
lock
asyncmap a0000
debug
noauth
modem
nocrtscts
200.200.200.33:200.200.200.19
Rq : i keep the same address for linux, and i change for the windows one
else windows isn't happy ).
So, everything is fine, the IF ppp0 is up and running.
I can ping, telnet ....
The page i want to load from Apache, contains an applet which connects to a
little server in the board (TCP 6666), and contains several images and
classes.
Then i load a Page from the server (it starts to appear and blocks !!! from
now Linux cannot send throw the ppp0 IF :
For example I ping the PC from Linux (ping 200.200.200.19) : nothings appens
on the link, i CTR-C and i see that 10 ping request have been sent ..... BUt
in "netstat -s" i see "0 ICMP messages sent" !!!!!! ??????
What's the problem ????? Does it come from the PPP interface ??????????
Thomas TESTASECCA
ETIC telecom
38400 Meylan
FRANCE
NB : COUIC might be a french typical expression :)
James Carlson
> Fistly, thank you for your help ...
No problem. But please do *not* send me email copies of your
postings. Either send private email if you must, or post. (Doing
both is one way to get into some folks' blacklists ...)
> But i've done what you have said ( async map a0000 ), but the problem stays
> ....
>
> I give you more informations about my configuration.
>
> I'm currently evaluating, the LynuxWorks embedded Linux (BlueCat), it is
> based on linux 2.2....
>
> I test on a Developent board ( CyrrusLogic CDB 89712 ), with an ARM 7
> processor. This board have
>
> two UART, an Ethernet controller, 16 Mo of RAM.
>
> The RTS is not supported, so i use no Flow Control.
Ah ha! That's almost certainly the problem. You have overruns. Try
reducing the data rate to the modem down to some suitably low level --
say, 2400bps -- and see if the problem doesn't go away, or at least
diminish greatly.
If it does, then you need to find a way to do flow control here.
Software flow control works just fine with PPP, provided that it's
configured properly on all of the devices, and actually supported by
the implementation. (Sadly, I've heard credible rumors of bad flow
control implementation in Linux serial drivers, so your experience
here may well vary.)
> The aim is to run, a web server on the board (Apache ), and to connect to it
> throw a PPP link ( with 2 standard modems ),for now, i use, a null modem
> cable (serial).
>
> I use PPPD 2.10.
There's no such version. Perhaps you mean ppp-2.3.10. If so, that's
a fairly old one. The latest is ppp-2.4.1 (but that might not be
supported on your fairly old Linux kernel).
(I don't think that's the problem at all; just commenting on the
set-up you're using.)
> The client is a PC under W2000 (with an ethernet card, ...).
I don't do Windoze. Sorry.
> At the beginning of the story :), the client (PC) and the server are
> connected by ethernet ( To load the soft into the board ), PC is
> 200.200.200.5 and the board is 200.200.200.33.
That seems simple enough. Please don't just make up IP addresses like
that, though. Use RFC 1918 addresses instead. Pick from:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
> Now i want to connect throw a PPP link, so i disable the eth0 IF of the
> board.
>
> I launch PPP on the ttyS0 (9600), I launch the dialup of W2000 ... all works
> fine : i'm connected.
> Here is my "options" file :
> lock
> asyncmap a0000
> debug
> noauth
> modem
> nocrtscts
> 200.200.200.33:200.200.200.19
That's bound to be bad news. Running an async link with no flow
control at all is at best problematic.
> Then i load a Page from the server (it starts to appear and blocks !!! from
> now Linux cannot send throw the ppp0 IF :
>
> For example I ping the PC from Linux (ping 200.200.200.19) : nothings appens
> on the link, i CTR-C and i see that 10 ping request have been sent ..... BUt
> in "netstat -s" i see "0 ICMP messages sent" !!!!!! ??????
That certainly sounds like a serial driver problem of some sort;
perhaps aggravated by overruns.
If I were you, I'd be looking over the Linux async serial driver code
very carefully.
> NB : COUIC might be a french typical expression :)
You're not sure? :-/
Thomas TESTASECCA
so, it's pppd 2.3.10
for the 200.200.200.X, that is the local addresses used by my firm ... (i
know it's a bad thing ).
For the overrun, i tried at 1200 bps -> same thing.
With software flow control -> same thing
For information, sometimes i have some poor but better results with mgetty
(autoPPP) .... What's the difference ?????
"James Carlson" <james.d...@sun.com> a écrit dans le message news:
xoavd720...@sun.com...
Bill Unruh
]Fistly, thank you for your help ...
]But i've done what you have said ( async map a0000 ), but the problem stays
He said
asyncmap a0000
not
async map a0000
They are not the same thing.
]....
]I give you more informations about my configuration.
]I'm currently evaluating, the LynuxWorks embedded Linux (BlueCat), it is
]based on linux 2.2....
]I test on a Developent board ( CyrrusLogic CDB 89712 ), with an ARM 7
]processor. This board have
]two UART, an Ethernet controller, 16 Mo of RAM.
]The RTS is not supported, so i use no Flow Control.
]The aim is to run, a web server on the board (Apache ), and to connect to it
]throw a PPP link ( with 2 standard modems ),for now, i use, a null modem
]cable (serial).
]I use PPPD 2.10.
]The client is a PC under W2000 (with an ethernet card, ...).
]Ok, well ...
]At the beginning of the story :), the client (PC) and the server are
]connected by ethernet ( To load the soft into the board ), PC is
]200.200.200.5 and the board is 200.200.200.33.
Why are you using those addresses? It looks to me like you have just
made them up, which is a very bad thing to do. If they have really been
assigned to these two machines by some constituted authority, ignore
this comment.
]Now i want to connect throw a PPP link, so i disable the eth0 IF of the
]board.
]I launch PPP on the ttyS0 (9600), I launch the dialup of W2000 ... all works
]fine : i'm connected.
]Here is my "options" file :
]lock
]asyncmap a0000
]debug
]noauth
]modem
]nocrtscts
]200.200.200.33:200.200.200.19
]Rq : i keep the same address for linux, and i change for the windows one
] else windows isn't happy ).
Uh, this strengthens my suspicion. DO NOT JUST MAKE UP IP ADDRESSES. You
cannot simply use random numbers. If you want to use your own private
numbers which you do not want to get permission for, use
10.x.x.x numbers.
]So, everything is fine, the IF ppp0 is up and running.
]I can ping, telnet ....
]The page i want to load from Apache, contains an applet which connects to a
]little server in the board (TCP 6666), and contains several images and
]classes.
]Then i load a Page from the server (it starts to appear and blocks !!! from
]now Linux cannot send throw the ppp0 IF :
No idea. Could well be modem problems.
]For example I ping the PC from Linux (ping 200.200.200.19) : nothings appens
]on the link, i CTR-C and i see that 10 ping request have been sent ..... BUt
]in "netstat -s" i see "0 ICMP messages sent" !!!!!! ??????
]What's the problem ????? Does it come from the PPP interface ??????????
]NB : COUIC might be a french typical expression :)
Certainly is not English.
Clifford Kite
> I explain my problem :
> i want to connect a PC (under W2000) and a developement board (under linux
> 2.2) throw a PPP link (using 2 modems).
> The PC is the clients and the board is the server.
> There is no problem to connect with PPP : i can send Ping, i can do Telenet
> on the link ...
> But when i load a Web page from the server ( Apache is running under
> linux ), the Page starts to come and COUIC !!! thats'all , the link is
> broken !!!
Sounds like flow-control is failing. That could be caused by XON/XOFF
flow control on one side and hardware flow control on the other, as
James Carlson suggested. Or if the "development board" contains the
serial device and doesn't do flow control at all then that would do it.
In unison now, COUIC?? :)
--
Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
Bernd Harries
> for the 200.200.200.X, that is the local addresses used by my firm ... (i
> know it's a bad thing ).
Which box is connected to that net? The Linux hopefully. You might then whant to
use proxyarp on the linux box. (Not related to your overruns though)
> For the overrun, i tried at 1200 bps -> same thing.
> With software flow control -> same thing
Did you use xonxoff on the W2000 box, too? You have to to make it effective.
Otherwise the W2000 won't stop sending. This applys when you are using a
Nullmodem Cable.
Otherwise you will have to tell your modem to react on XON & XOFF
> > > Here is my "options" file :
> > > lock
> > > asyncmap a0000
> > > debug
> > > noauth
> > > modem
> > > nocrtscts
> > > 200.200.200.33:200.200.200.19
I see you already have debug enabled. Posting the logs might be helpful.
What kind of uart does that ARM 7 board use? Isn't it a 16550A? Where is the RTS
line?
With a Z8530 or Z85230 uart RTS should also not be a problem.
--
Bernd Harries
b...@gmx.de http://www.freeyellow.com/members/bharries
b...@nikocity.de Tel. +49 421 809 7343 priv. | MSB First!
har...@stn-atlas.de +49 421 457 3966 offi. | Linux-m68k
be...@linux-m68k.org 8.48'21" E 52.48'52" N | Medusa T40
<>_<> _______ _____
.---|'"`|---. | |_| |_|_|_|_|_|_|_ (_____) .-----.
______`o"O-OO-OO-O"o'`-o---o-'`-oo-----oo-'`-o---o-'`-o---o-'___
Thomas TESTASECCA
Thomas TESTASECCA
with the traces ):
firstly, the trace of the PPP establishment ( normal )
and secondly, the TCPDUMP trace of the communication when i try to download
th html page ( there is something strange at the end : linux try to send
a packet indefinitely (with a bad checksum) ).
I have remarked something strange, look :
1/ I connect with ppp ( pppd ttyS0 9600)
2/ i'm connected
3/ i do "echo toto > ttyS0"
4/ i see "toto" passing on the serial line
5/ i try to get the html page fropm apache
6/ the comm blocks and become unidirectionnal (linux cannot emit anymore)
7/ i redo the same thing : "echo toto > ttyS0"
8/ and now , I see NOTHING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
It means that, there is something broken at a very low level, isn't it ?? !!
Thomas TESTASECCA
// i can do some ping from and to the target board ...
bash# tcpdump -x -vv -i ppp0 > trace
05:08:46.020000 < ip_hl < 5 (0)
003c 6542 0000 8001 b3b8 c8c8 c813 c8c8
c821 0800 385c 1400 0100 6162 6364 6566
6768 696a 6b6c 6d6e 6f70 7172 7374 7576
7761 6263 6465 6667 6869
05:08:46.020000 > ip_hl < 5 (0)
003c 0360 0000 ff01 969a c8c8 c821 c8c8
c813 0000 405c 1400 0100 6162 6364 6566
6768 696a 6b6c 6d6e 6f70 7172 7374 7576
7761 6263 6465 6667 6869
05:08:58.810000 > ip_hl < 5 (0)
0054 0361 0000 4001 5582 c8c8 c821 c8c8
c813 0800 4242 c800 0000 6a48 0000 8c71
0c00 0809 0a0b 0c0d 0e0f 1011 1213 1415
1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
3637
05:08:59.010000 < ip_hl < 5 (0)
0054 6543 0000 8001 b39f c8c8 c813 c8c8
c821 0000 4a42 c800 0000 6a48 0000 8c71
0c00 0809 0a0b 0c0d 0e0f 1011 1213 1415
1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
3637
////////////////////////////////////////////////////////////////////////////
//////////
// Somùewhere here, i start to download the http page stored
////////////////////////////////////////////////////////////////////////////
//////////
05:09:03.730000 < ip_hl < 5 (0)
0030 6544 4000 8006 73bd c8c8 c813 c8c8
c821 05c3 0050 0b84 f653 0000 0000 7002
2238 3736 0000 0204 05b4 0101 0402
05:09:03.730000 > ip_hl < 5 (0)
0030 0362 4000 4006 15a0 c8c8 c821 c8c8
c813 0050 05c3 8f36 d239 0b84 f654 7012
3908 bee4 0000 0204 05b4 0101 0402
05:09:03.840000 < ip_hl < 5 (0)
0028 6546 4000 8006 73c3 c8c8 c813 c8c8
c821 05c3 0050 0b84 f654 8f36 d23a 5010
2238 0279 0000
05:09:04.160000 < ip_hl < 5 (1)
014c 6547 4000 8006 729e c8c8 c813 c8c8
2238 86c6 0000 4745 5420 2f69 6e64 6578
2e68 746d 6c20 4854 5450 2f31 2e31 0d0a
4163 6365 7074 3a20 2a2f 2a0d 0a41 6363
6570 742d 4c61 6e67 7561 6765 3a20 6672
0d0a 4163 6365 7074 2d45 6e63 6f64 696e
673a 2067 7a69 702c 2064 6566 6c61 7465
0d0a 4966 2d4d 6f64 6966 6965 642d
05:09:04.160000 > ip_hl < 5 (0)
0028 0363 4000 4006 15a7 c8c8 c821 c8c8
c813 0050 05c3 8f36 d23a 0b84 f778 5010
3908 ea84 0000
05:09:04.480000 > ip_hl < 5 (0)
00ed 0364 4000 4006 14e1 c8c8 c821 c8c8
c813 0050 05c3 8f36 d23a 0b84 f778 5018
3ebc e67f 0000 4854 5450 2f31 2e31 2033
3034 204e 6f74 204d 6f64 6966 6965 640d
0a44 6174 653a 2054 6875 2c20 3031 204a
616e 2031 3937 3020 3035 3a30 393a 3034
2047 4d54 0d0a 5365 7276 6572 3a20 4170
6163 6865 2f31 2e33 2e39 2028 556e 6978
2920 2028 5265 6420 4861 742f 4c69
05:09:05.130000 < ip_hl < 5 (1)
018a 6549 4000 8006 725e c8c8 c813 c8c8
2173 0577 0000 4745 5420 2f64 656d 6f2f
696d 6167 6573 2f4c 4f47 4f45 524d 464f
4e44 322e 6a70 6720 4854 5450 2f31 2e31
0d0a 4163 6365 7074 3a20 2a2f 2a0d 0a52
6566 6572 6572 3a20 6874 7470 3a2f 2f32
3030 2e32 3030 2e32 3030 2e33 332f 696e
6465 782e 6874 6d6c 0d0a 4163 6365
05:09:05.150000 > ip_hl < 5 (0)
0028 0365 4000 4006 15a5 c8c8 c821 c8c8
c813 0050 05c3 8f36 d2ff 0b84 f8da 5010
3ebc e2a9 0000
05:09:05.160000 > ip_hl < 5 (0)
00ed 0366 4000 4006 14df c8c8 c821 c8c8
c813 0050 05c3 8f36 d2ff 0b84 f8da 5018
3ebc bc02 0000 4854 5450 2f31 2e31 2033
3034 204e 6f74 204d 6f64 6966 6965 640d
0a44 6174 653a 2054 6875 2c20 3031 204a
616e 2031 3937 3020 3035 3a30 393a 3035
2047 4d54 0d0a 5365 7276 6572 3a20 4170
6163 6865 2f31 2e33 2e39 2028 556e 6978
2920 2028 5265 6420 4861 742f 4c69
05:09:05.590000 < ip_hl < 5 (0)
0028 654b 4000 8006 73be c8c8 c813 c8c8
20ae fff2 0000 0b84 f8da 8f36 d
05:09:06.140000 < ip_hl < 5 (1)
0143 654c 4000 8006 72a2 c8c8 c813 c8c8
c821 05c3 0050 0b84 f8da 8f36 d3c4 5018
20ae 01fb 0000 4745 5420 2f64 656d 6f2f
426f 726e 6541 7070 6c65 742e 636c 6173
7320 4854 5450 2f31 2e31 0d0a 4163 6365
7074 3a20 2a2f 2a0d 0a41 6363 6570 742d
456e 636f 6469 6e67 3a20 677a 6970 2c20
6465 666c 6174 650d 0a49 662d 4d6f 6469
6669 6564 2d53 696e 6365 3a20 5468
05:09:06.150000 > ip_hl < 5 (0)
00ec 0367 4000 4006 14df c8c8 c821 c8c8
c813 0050 05c3 8f36 d3c4 0b84 f9f5 5018
3ebc 78be 0000 4854 5450 2f31 2e31 2033
3034 204e 6f74 204d 6f64 6966 6965 640d
0a44 6174 653a 2054 6875 2c20 3031 204a
616e 2031 3937 3020 3035 3a30 393a 3036
2047 4d54 0d0a 5365 7276 6572 3a20 4170
6163 6865 2f31 2e33 2e39 2028 556e 6978
2920 2028 5265 6420 4861 742f 4c69
05:09:06.710000 < ip_hl < 5 (1)
0142 654e 4000 8006 72a1 c8c8 c813 c8c8
1fea 9d02 0000 4745 5420 2f64 656d 6f2f
426f 726e 6550 616e 652e 636c 6173 7320
4854 5450 2f31 2e31 0d0a 4163 6365 7074
3a20 2a2f 2a0d 0a41 6363 6570 742d 456e
636f 6469 6e67 3a20 677a 6970 2c20 6465
666c 6174 650d 0a49 662d 4d6f 6469 6669
6564 2d53 696e 6365 3a20 5468 752c
05:09:06.710000 > ip_hl < 5 (0)
00ed 0368 4000 4006 14dd c8c8 c821 c8c8
c813 0050 05c3 8f36 d488 0b84 fb0f 5018
3ebc ec45 0000 4854 5450 2f31 2e31 2033
3034 204e 6f74 204d 6f64 6966 6965 640d
0a44 6174 653a 2054 6875 2c20 3031 204a
616e 2031 3937 3020 3035 3a30 393a 3036
2047 4d54 0d0a 5365 7276 6572 3a20 4170
6163 6865 2f31 2e33 2e39 2028 556e 6978
2920 2028 5265 6420 4861 742f 4c69
05:09:07.300000 < ip_hl < 5 (1)
014d 6550 4000 8006 7294 c8c8 c813 c8c8
c821 05c3 0050 0b84 fb0f 8f36 d54d 5018
1f25 1ef4 0000 4745 5420 2f64 656d 6f2f
426f 726e 6550 616e 6524 4368 6563 6b53
2f31 2e31 0d0a 4163 6365 7074 3a20 2a2f
2a0d 0a41 6363 6570 742d 456e 636f 6469
6e67 3a20 677a 6970 2c20 6465 666c 6174
650d 0a49 662d 4d6f 6469 6669 6564
05:09:07.300000 > ip_hl < 5 (0)
00ec 0369 4000 4006 14dd c8c8 c821 c8c8
c813 0050 05c3 8f36 d54d 0b84 fc34 5018
3ebc 79f1 0000 4854 5450 2f31 2e31 2033
3034 204e 6f74 204d 6f64 6966 6965 640d
0a44 6174 653a 2054 6875 2c20 3031 204a
616e 2031 3937 3020 3035 3a30 393a 3037
2047 4d54 0d0a 5365 7276 6572 3a20 4170
6163 6865 2f31 2e33 2e39 2028 556e 6978
2920 2028 5265 6420 4861 742f 4c69
05:09:07.620000 < ip_hl < 5 (0)
0030 6552 4000 8006 73af c8c8 c813 c8c8
c821 05c4 0050 0b94 680f 0000 0000 7002
2238 c569 0000 0204 05b4 0101 0402
05:09:07.620000 > ip_hl < 5 (0)
0030 036a 4000 4006 1598 c8c8 c821 c8c8
c813 0050 05c4 8f0f 9868 0b94 6810 7012
3908 8710 0000 0204 05b4 0101 0402
05:09:07.700000 < ip_hl < 5 (0)
c821 05c3 0050 0b84 fc34 8f36 d611 5010
1e61 fc98 0000
05:09:07.740000 < ip_hl < 5 (0)
0028 6554 4000 8006 73b5 c8c8 c813 c8c8
c821 05c4 0050 0b94 6810 8f0f 9869 5010
2238 caa4 0000
05:09:07.940000 < ip_hl < 5 (0)
00da 6555 4000 8006 7302 c8c8 c813 c8c8
c821 05c4 0050 0b94 6810 8f0f 9869 5018
2238 8d74 0000 4745 5420 2f64 656d 6f2f
696d 6167 6573 2f62 6f75 746f 6e68 6175
742e 6a70 6720 4854 5450 2f31 2e31 0d0a
5573 6572 2d41 6765 6e74 3a20 4a61 7661
312e 332e 315f 3031 0d0a 486f 7374 3a20
3230 302e 3230 302e 3230 302e 3333 0d0a
4163 6365 7074 3a20 7465 7874 2f68
05:09:07.940000 > ip_hl < 5 (0)
0028 036b 4000 4006 159f c8c8 c821 c8c8
c813 0050 05c4 8f0f 9869 0b94 68c2 5010
3908 b322 0000
////////////////////////// here we are, the com becomes undirectionel
(client -> server) ///////
// and the following packet is "transmitted" periodically .... (i think it s
the rest of
// an http session )
// i put "" around transmitted because, of course ( it s my problem ), i
can't see this packet
// on the serial line.
////////////////////////////////////////////////////////////////////////////
/////////////////////
05:09:07.980000 > 200.33.200.200 > 200.19.200.200: (frag 16384:856@48) (DF)
[tos
0xdc] (ttl 15, bad cksum c8c8!)
05dc 036c 4000 4006 0fea c8c8 c821 c8c8
c813 0050 05c4 8f0f 9869 0b94 68c2 5018
3030 204f 4b0d 0a44 6174 653a 2054 6875
2c20 3031 204a 616e 2031 3937 3020 3035
3a30 393a 3037 2047 4d54 0d0a 5365 7276
6572 3a20 4170 6163 6865 2f31 2e33 2e39
2028 556e 6978 2920 2028 5265 6420 4861
742f 4c69 6e75 7829 0d0a 4c61 7374
05:09:07.980000 > 200.33.200.200 > 200.19.200.200: (frag 16384:857@48) (DF)
[tos
0xdc] (ttl 15, bad cksum c8c8!)
05dc 036d 4000 4006 0fe9 c8c8 c821 c8c8
c813 0050 05c4 8f0f 9e1d 0b94 68c2 5018
3ebc 1be4 0000 0002 1103 0421 1231 0541
5161 1322 7181 3206 1491 a1b1 4223 2415
52c1 6233 3472 82d1 4307 2592 53f0 e1f1
6373 3516 a2b2 8326 4493 5464 45c2 a374
3617 d255 e265 f2b3 84c3 d375 e3f3 4627
94a4 85b4 95c4 d4e4 f4a5 b5c5 d5e5 f556
6676 8696 a6b6 c6d6 e6f6 3747 5767
05:09:15.360000 > 200.33.200.200 > 200.19.200.200: (frag 16384:857@48) (DF)
[tos
0xdc] (ttl 15, bad cksum c8c8!)
05dc 036d 4000 4006 0fe9 c8c8 c821 c8c8
c813 0050 05c4 8f0f 9e1d 0b94 68c2 5018
5161 1322 7181 3206 1491 a1b1 4223 2415
52c1 6233 3472 82d1 4307 2592 53f0 e1f1
6373 3516 a2b2 8326 4493 5464 45c2 a374
3617 d255 e265 f2b3 84c3 d375 e3f3 4627
94a4 85b4 95c4 d4e4 f4a5 b5c5 d5e5 f556
6676 8696 a6b6 c6d6 e6f6 3747 5767
05:09:17.790000 < ip_hl < 5 (0)
0028 6556 4000 8006 73b3 c8c8 c813 c8c8
c821 05c3 0050 0b84 fc34 8f0f 9869 5004
0000 58d5 0000
05:09:17.840000 < ip_hl < 5 (0)
0028 6557 4000 8006 73b2 c8c8 c813 c8c8
c821 05c4 0050 0b94 68c2 8f0f 9869 5004
0000 ec36 0000
05:09:20.360000 > 200.33.200.200 > 200.19.200.200: (frag 16384:857@48) (DF)
[tos
0xdc] (ttl 15, bad cksum c8c8!)
05dc 036d 4000 4006 0fe9 c8c8 c821 c8c8
c813 0050 05c4 8f0f 9e1d 0b94 68c2 5018
3ebc 1be4 0000 0002 1103 0421 1231 0541
5161 1322 7181 3206 1491 a1b1 4223 2415
52c1 6233 3472 82d1 4307 2592 53f0 e1f1
6373 3516 a2b2 8326 4493 5464 45c2 a374
3617 d255 e265 f2b3 84c3 d375 e3f3 4627
6676 8696 a6b6 c6d6 e6f6 3747 5767
05:09:25.360000 > 200.33.200.200 > 200.19.200.200: (frag 16384:857@48) (DF)
[tos
0xdc] (ttl 15, bad cksum c8c8!)
05dc 036d 4000 4006 0fe9 c8c8 c821 c8c8
c813 0050 05c4 8f0f 9e1d 0b94 68c2 5018
3ebc 1be4 0000 0002 1103 0421 1231 0541
5161 1322 7181 3206 1491 a1b1 4223 2415
52c1 6233 3472 82d1 4307 2592 53f0 e1f1
6373 3516 a2b2 8326 4493 5464 45c2 a374
3617 d255 e265 f2b3 84c3 d375 e3f3 4627
94a4 85b4 95c4 d4e4 f4a5 b5c5 d5e5 f556
6676 8696 a6b6 c6d6 e6f6 3747 5767
05:09:30.360000 > 200.33.200.200 > 200.19.200.200: (frag 16384:857@48) (DF)
[tos
0xdc] (ttl 15, bad cksum c8c8!)
05dc 036d 4000 4006 0fe9 c8c8 c821 c8c8
c813 0050 05c4 8f0f 9e1d 0b94 68c2 5018
3ebc 1be4 0000 0002 1103 0421 1231 0541
5161 1322 7181 3206 1491 a1b1 4223 2415
52c1 6233 3472 82d1 4307 2592 53f0 e1f1
6373 3516 a2b2 8326 4493 5464 45c2 a374
3617 d255 e265 f2b3 84c3 d375 e3f3 4627
6676 8696 a6b6 c6d6 e6f6 3747 5767
bash#
Thomas TESTASECCA
bash# Jan 1 05:07:02 target pppd[195]: pppd 2.3.10 started by root, uid 0
Jan 1 05:07:02 target pppd[195]: Using interface ppp0
Jan 1 05:07:02 target pppd[195]: Connect: ppp0 <--> /dev/ttyS0
Jan 1 05:07:02 target pppd[195]: Warning - secret file /etc/ppp/pap-secrets
has
world and/or group access
Jan 1 05:07:02 target pppd[195]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <m
agic 0xcfeaf6a> <pcomp> <accomp>]
Jan 1 05:07:05 target pppd[195]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <m
agic 0xcfeaf6a> <pcomp> <accomp>]
Jan 1 05:07:05 target pppd[195]: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0>
<magic
0x42ba7ca8> <pcomp> <accomp>]
Jan 1 05:07:05 target pppd[195]: sent [LCP ConfAck id=0x0 <asyncmap 0x0>
<magic
0x42ba7ca8> <pcomp> <accomp>]
Jan 1 05:07:08 target pppd[195]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <m
agic 0xcfeaf6a> <pcomp> <accomp>]
Jan 1 05:07:08 target pppd[195]: rcvd [LCP ConfAck id=0x1 <asyncmap
0xa0000> <m
agic 0xcfeaf6a> <pcomp> <accomp>]
Jan 1 05:07:08 target pppd[195]: sent [IPCP ConfReq id=0x1 <addr
200.200.200.33
> <compress VJ 0f 01>]
Jan 1 05:07:08 target pppd[195]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f
01>
<addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0>
<ms-wins 0.
0.0.0>]
Jan 1 05:07:08 target pppd[195]: sent [IPCP ConfRej id=0x1 <ms-dns1
0.0.0.0> <m
s-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
Jan 1 05:07:08 target pppd[195]: rcvd [IPCP ConfAck id=0x1 <addr
200.200.200.33
> <compress VJ 0f 01>]
Jan 1 05:07:08 target pppd[195]: rcvd [IPCP ConfReq id=0x2 <compress VJ 0f
01>
<addr 0.0.0.0>]
Jan 1 05:07:08 target pppd[195]: sent [IPCP ConfNak id=0x2 <addr
200.200.200.19
>]
Jan 1 05:07:08 target pppd[195]: rcvd [IPCP ConfReq id=0x3 <compress VJ 0f
01>
<addr 200.200.200.19>]
Jan 1 05:07:08 target pppd[195]: sent [IPCP ConfAck id=0x3 <compress VJ 0f
01>
<addr 200.200.200.19>]
Jan 1 05:07:08 target pppd[195]: local IP address 200.200.200.33
Jan 1 05:07:08 target pppd[195]: remote IP address 200.200.200.19
Jan 1 05:07:08 target pppd[195]: Script /etc/ppp/ip-up started (pid 196)
Jan 1 05:07:08 target pppd[195]: Script /etc/ppp/ip-up finished (pid 196),
stat
us = 0x0
bash#
James Carlson
> Jan 1 05:07:05 target pppd[195]: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0>
> <magic
> 0x42ba7ca8> <pcomp> <accomp>]
> Jan 1 05:07:05 target pppd[195]: sent [LCP ConfAck id=0x0 <asyncmap 0x0>
> <magic
> 0x42ba7ca8> <pcomp> <accomp>]
This shows that the peer doesn't think it needs to escape the same
characters. This is very likely to be the problem. If the peer can't
be fixed to suggest 0xa0000 as well, then I think setting the
"xonxoff" option on the local side should take care of it.
(Or patching pppd to do the right thing -- Configure-Nak when peer
suggests fewer bits than are set by the asyncmap option.)
James Carlson
> and secondly, the TCPDUMP trace of the communication when i try to download
> th html page ( there is something strange at the end : linux try to send
> a packet indefinitely (with a bad checksum) ).
That indicates that one of the machines in the middle is corrupting
the data. It's probably a misconfiguration.
Try creating a test file with this:
% awk 'BEGIN { for (i=0;i<256;i++) printf "%c",i; }' < /dev/null > testfile
If you can transfer this tiny file over the link, and the link keeps
working, then the problem isn't with the special-character handling.
Otherwise, that's the problem.
> It means that, there is something broken at a very low level, isn't it ?? !!
Yes.
Clifford Kite
> "Thomas TESTASECCA" <thomas.t...@etictelecom.com> writes:
>> Jan 1 05:07:05 target pppd[195]: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0>
>> <magic 0x42ba7ca8> <pcomp> <accomp>]
>> Jan 1 05:07:05 target pppd[195]: sent [LCP ConfAck id=0x0 <asyncmap 0x0>
>> <magic 0x42ba7ca8> <pcomp> <accomp>]
> This shows that the peer doesn't think it needs to escape the same
> characters. This is very likely to be the problem. If the peer
> can't be fixed to suggest 0xa0000 as well, then I think setting the
> "xonxoff" option on the local side should take care of it.
Doesn't just adding xonxoff cause pppd to set the ACCM to a0000?
> (Or patching pppd to do the right thing -- Configure-Nak when peer
> suggests fewer bits than are set by the asyncmap option.)
Huh? Why would that be the Right Thing?
--
Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
/* The wealth of a nation is created by the productive labor of its
* citizens. */
Bernd Harries
>
> UARTS are similar to 16C550A ....
Is perhaps the 2nd srial port fully wired? The Linux drivers at least should
support RTS/CTS handshake.
Since Windows can Only run on PCs it may be too stupid to do Software Handshake
during PPP sessions. Or maybe you can select Software Handshake
in the serial port's settings somewhere near the Baudrate setting. Perhaps that
stays relevant during the PPP session and makes it negotiate reasonably.
Ciao,
pk...@mv.mv.com
Thomas TESTASECCA <thomas.t...@etictelecom.com> wrote:
>// ok now the ppp connection is up and running
>// i can do some ping from and to the target board ...
>
>bash# tcpdump -x -vv -i ppp0 > trace
>
>05:08:46.020000 < ip_hl < 5 (0)
> 003c 6542 0000 8001 b3b8 c8c8 c813 c8c8
> c821 0800 385c 1400 0100 6162 6364 6566
> 6768 696a 6b6c 6d6e 6f70 7172 7374 7576
> 7761 6263 6465 6667 6869
Forgive my ignorance, but where is the IP packet header? If nothing else,
the first 2 bytes of the packet are missing.
>////////////////////////// here we are, the com becomes undirectionel
>(client -> server) ///////
>// and the following packet is "transmitted" periodically .... (i think it s
>the rest of
>// an http session )
>// i put "" around transmitted because, of course ( it s my problem ), i
>can't see this packet
>// on the serial line.
>////////////////////////////////////////////////////////////////////////////
>/////////////////////
>
>05:09:07.980000 > 200.33.200.200 > 200.19.200.200: (frag 16384:856@48) (DF)
>[tos
> 0xdc] (ttl 15, bad cksum c8c8!)
At first glance, I notice that the IP addresses are skewed here (unless the
representation is incorrect). The IP addresses were 200.200.200.19 and
200.200.200.33, but these addresses are mixed up - 200.33.200.200 (looks like
it's skewed by 2 bytes) and 200.19.200.200 (also looks skewed, but odd that
it would end with .200.200?!?).
> 05dc 036c 4000 4006 0fea c8c8 c821 c8c8
> c813 0050 05c4 8f0f 9869 0b94 68c2 5018
> 3030 204f 4b0d 0a44 6174 653a 2054 6875
> 2c20 3031 204a 616e 2031 3937 3020 3035
> 3a30 393a 3037 2047 4d54 0d0a 5365 7276
> 6572 3a20 4170 6163 6865 2f31 2e33 2e39
> 2028 556e 6978 2920 2028 5265 6420 4861
> 742f 4c69 6e75 7829 0d0a 4c61 7374
The data shift is consistant with the previous packets, so I don't know
why tcpdump is interpreting this header any different. This looks like a
TCP IP packet with 1500 bytes of data.
I think you have a case here of tcpdump not interpreting the header correctly.
The bytes in the header are clearly skewed, but tcpdump doesn't know that.
Good luck!
Patrick
============================================================================
Patrick Klos Email: pat...@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
============================================================================
James Carlson
> Doesn't just adding xonxoff cause pppd to set the ACCM to a0000?
Doh. You're right. In both cases, it just sets wantoptions and
ignores allowoptions. There's no way to set
lcp_allowoptions[0].asyncmap in standard pppd.
> > (Or patching pppd to do the right thing -- Configure-Nak when peer
> > suggests fewer bits than are set by the asyncmap option.)
>
> Huh? Why would that be the Right Thing?
If you're setting "asyncmap", you're saying that these characters are
mangled in transit. The current interpretation is:
"these characters are mangled when sent by the peer; we can't
receive them right"
I'm asserting that one of the two answers is better:
a. "these characters are mangled in both directions; make sure
the peer doesn't send them, and we don't send them to the
peer"
b. "these characters are mangled on receive; use
'asyncmap_xmit' to handle mangled characters in the other
direction"
For the Solaris port of pppd, we did (a) because it's easier to
understand and a lot more obvious in implication. I can see why you
might want (b) for ultimate flexibility, but I'm not sure that
flexibility is really needed.
pk...@mv.mv.com
>In article <9ug6pe$na$1...@wanadoo.fr>,
>Thomas TESTASECCA <thomas.t...@etictelecom.com> wrote:
>>// ok now the ppp connection is up and running
>>// i can do some ping from and to the target board ...
>>
>>bash# tcpdump -x -vv -i ppp0 > trace
>>
>>05:08:46.020000 < ip_hl < 5 (0)
>> 003c 6542 0000 8001 b3b8 c8c8 c813 c8c8
>> c821 0800 385c 1400 0100 6162 6364 6566
>> 6768 696a 6b6c 6d6e 6f70 7172 7374 7576
>> 7761 6263 6465 6667 6869
>
>Forgive my ignorance, but where is the IP packet header? If nothing else,
>the first 2 bytes of the packet are missing.
O.K. Now I'm seeing a bit more of what's happening. The packets are
skewed going into tcpdump (I don't know why). tcpdump thinks the first
byte of the IP header is "00", which to it means version 0 of IP with an
IP header length of 0 32-bit words, this the message "ip_hl < 5".
This shift is consistant with the other packets from your dump, and
as such, consistant with tcpdump's misintepretation of the packets.
I think you need to fix tcpdump before you can use any of it's output to
debug your problem.
Clifford Kite
> Clifford Kite <ki...@see.signature.id> writes:
>> > (Or patching pppd to do the right thing -- Configure-Nak when peer
>> > suggests fewer bits than are set by the asyncmap option.)
>>
>> Huh? Why would that be the Right Thing?
> If you're setting "asyncmap", you're saying that these characters are
> mangled in transit. The current interpretation is:
> "these characters are mangled when sent by the peer; we can't
> receive them right"
> I'm asserting that one of the two answers is better:
> a. "these characters are mangled in both directions; make sure
> the peer doesn't send them, and we don't send them to the
> peer"
> b. "these characters are mangled on receive; use
> 'asyncmap_xmit' to handle mangled characters in the other
> direction"
> For the Solaris port of pppd, we did (a) because it's easier to
> understand and a lot more obvious in implication. I can see why you
> might want (b) for ultimate flexibility, but I'm not sure that
> flexibility is really needed.
I agree it's easier to understand since you don't need to understand
that it happens at all when you have no choice. I'm not sure it's more
obvious in implication except for the case of a three-wire nullmodem
where both sides are expected to use software flow control by escaping
XON and XOFF. In that case I'd expect the same person to configure
both sides and to know what to do.
I've never been fond of sacrificing freedom of choice because it makes
life easier, or at least simplier. But as you have often said, the
golden rule of networking software is that you should be conservative
in what you send and liberal in what you expect. You certainly know
better than I do about what consitutes the Right Thing.
Have I said "thank you" for your books lately? I've finally come around
to the view that the second book is actually better than the first, even
though it is thicker. :)
--
Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
/* The generation of random numbers is too important to be left
to chance. */
Thomas TESTASECCA
On W2000 null modem link via PPP, XONXOFF is not supported
So, i think i will retry XONXOFF with modems !!!
tom
"Bernd Harries" <b...@gmx.de> a écrit dans le message news:
3C0BB5B0...@gmx.de...
Thomas TESTASECCA
( FTP : client -> server )
( HTTP : server (linux) -> client )
I'have discovered when tracing the frames on the line, that Windows' PPP
on null modem cable) don't know
how to do XonXoff (even if you select the option in the ports settings).
So i'will try XonXoff, with two modems again.
But, not sure that the comes from flow control ??!! ...
"James Carlson" <james.d...@sun.com> a écrit dans le message news:
xoavlmgk...@sun.com...
Thomas TESTASECCA
putting two modems don't solve the problem ...
The problem is: i don't know how to tell Win2000 PPP : "Use XonXoff !!!!!!"
Thomas TESTASECCA
I don't know how to tell Win2000 to do software flow control !!!
"Thomas TESTASECCA" <thomas.t...@etictelecom.com> a écrit dans le
message news: 9uii0r$kcu$1...@wanadoo.fr...
Thomas TESTASECCA
the direction client->server.
but not in the oppposite direction ... Even if i set XonXoff in Windows port
setting !!!
So i have set "escape 11,13" in the options file on the server side : Now
chars are escaped on th both directions, but
this has not solved my problem !!!!!
Do you know that it really comes from a bad flow control ( same problem at
1200bps) ?,
from some chars that are badly escaped or misinterpreted ( same problem
without flow control) ?
Do you think that it may come from the serial driver ???!!!
How can i add RTS support to my board ( it seems the this just a software
problem ) ?
I'm so tired with this problem :(
tom
Clifford Kite
> OK, when i put "xonxoff" on server side, 0x11 & 0x13 chars are
> escaped in the direction client->server. but not in the oppposite
> direction ... Even if i set XonXoff in Windows port setting !!!
> So i have set "escape 11,13" in the options file on the server side :
> Now chars are escaped on th both directions, but this has not solved
> my problem !!!!!
Have you consider the possiblity that the Windows OS is broken with
respect to processing escaped characters? From RFC 1662:
Receiving implementations MUST correctly process all Control Escape
sequences.
That means whether the receiving implementation asked for them to be
escaped or not.
> Do you know that it really comes from a bad flow control ( same
> problem at 1200bps) ?, from some chars that are badly escaped or
> misinterpreted ( same problem without flow control) ?
What does the output of ifconfig show for the Linux PPP interface?
> Do you think that it may come from the serial driver ???!!!
You've already said it doesn't have flow control, so yes, it might
be that. It also might be a faulty or misconfigured serial port, or
the result of other hardware-related problems.
> How can i add RTS support to my board ( it seems the this just a
> software problem ) ?
I'm not a C programmer so the best I can suggest is to try reading
the Linux serial port source code. There is also a linux-serial
mailing list.
> I'm so tired with this problem :(
Believe me, you are not the only one. :)
--
Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */
James Carlson
> I agree it's easier to understand since you don't need to understand
> that it happens at all when you have no choice. I'm not sure it's more
> obvious in implication except for the case of a three-wire nullmodem
> where both sides are expected to use software flow control by escaping
> XON and XOFF. In that case I'd expect the same person to configure
> both sides and to know what to do.
The problem, of course, is that 'the same person' doesn't always have
administrative control over the far end. Thus, some means to set
lcp_allowoptions[0].asyncmap (Configure-Nak) is needed. There
currently is no way to do that at all. Only
lcp_wantoptions[0].asyncmap (Configure-Request) is configurable.
> I've never been fond of sacrificing freedom of choice because it makes
> life easier, or at least simplier. But as you have often said, the
> golden rule of networking software is that you should be conservative
> in what you send and liberal in what you expect. You certainly know
> better than I do about what consitutes the Right Thing.
In general I agree with leaning to the side of maximizing
configurability over "simplicity." The reason I chose to go the other
way here is that I really do think that it's an arguably marginal
feature (being able to set asyncmap differently in each direction) and
that doing this lessens the chance of a service call. At least
somewhat. Hmm. Ask me on another day, and I'll have a different
answer. ;-}
Anyway, the root problem is that there's a missing pppd feature (being
able to tell the peer that you know you need to escape certain
characters when sending data to the peer). Exactly how that gets
implemented is a detail.
> Have I said "thank you" for your books lately? I've finally come around
> to the view that the second book is actually better than the first, even
> though it is thicker. :)
Thanks! I tried to make it more complete than the first one by
covering more boundary issues (media, tunneling, configurations) in
addition to the core protocol. I agree that books that are too thick
are often devoid of useful content, and I deleted a lot before going
to press. Perhaps not enough. :-)
Bill Unruh
>OK, when i put "xonxoff" on server side, 0x11 & 0x13 chars are escaped in
>the direction client->server.
>but not in the oppposite direction ... Even if i set XonXoff in Windows port
>setting !!!
>So i have set "escape 11,13" in the options file on the server side : Now
>chars are escaped on th both directions, but
>this has not solved my problem !!!!!
The use of exclamation points is not really necessary.
It would be really helpful if, on the Linux side you put in the option
debug
for pppd and set up syslogd to record the output to some file eg
local2.*;daemon.* /var/log/ppplog
nd then do killall -1 syslogd.
Then look at that log. If you get a ConfReq from windows with
<asyncmap 0xa0000> that means it is escaping those characters. (I think
for many windows machines this is the default). Put in a
asyncmap a0000
into /etc/ppp/options on your side as well.
>Do you know that it really comes from a bad flow control ( same problem at
>1200bps) ?,
If we knew exactly what your problem was we would tell you. However all
one can do it try different things. It might even be a bad modem, or a
bad telephone line or a bad motherboard, or...
>from some chars that are badly escaped or misinterpreted ( same problem
>without flow control) ?
>Do you think that it may come from the serial driver ???!!!
I doubt it.
>How can i add RTS support to my board ( it seems the this just a software
>problem ) ?
If it does not have it you cannot. Note that you MUST use a full serial
port cable, not a cheap three wire modem cable, to use hardware flow
control.
>I'm so tired with this problem :(
Yes, these things are annoying.
Samuel Thibault
Hello,
On 30 Nov 2001, James Carlson wrote:
> (Sadly, I've heard credible rumors of bad flow control implementation
> in Linux serial drivers, so your experience here may well vary.)
Indeed, Linux is still bugged about xonxoff. My patches
http://youpibouh.thefreecat.org/info/prog/ppp.c.patch for 2.2.x or
ppp_async.c.patch for 2.4.x and 2.5.x kernels are still pending...
(ppp.c.2.0.36.patch for 2.0.x kernels wasn't tested, but should also work)
Regards,
--
Samuel Thibault
James Carlson
My problem with that is that the fault is not in the PPP driver --
it's in the async driver. The async driver should be handling flow
control.
The reasons for this are:
- It already handles out-of-band (RTS/CTS) flow control. Why
would a user expect that in-band (XON/XOFF) flow control is
handled in all other kernel software that might use the
async I/O subsystem, but that RTS/CTS is automatic?
- Many serial chips (other than the very old and very lame
8250/16550 series, of course) handle XON/XOFF flow control
in hardware. If the serial driver isn't involved in
handling XON/XOFF, then how could this feature ever be used?
This sounds to me like an architectural flaw as well as a bit of
missing functionality in the serial driver. PPP should not be
involved in flow control.
Clifford Kite
> Samuel Thibault <sa...@youpi.residence.ens-lyon.fr> writes:
>> On 30 Nov 2001, James Carlson wrote:
>>
>> > (Sadly, I've heard credible rumors of bad flow control implementation
>> > in Linux serial drivers, so your experience here may well vary.)
>>
>> Indeed, Linux is still bugged about xonxoff. My patches
>> http://youpibouh.thefreecat.org/info/prog/ppp.c.patch for 2.2.x or
>> ppp_async.c.patch for 2.4.x and 2.5.x kernels are still pending...
>> (ppp.c.2.0.36.patch for 2.0.x kernels wasn't tested, but should also work)
> My problem with that is that the fault is not in the PPP driver --
> it's in the async driver. The async driver should be handling flow
> control.
> The reasons for this are:
> - It already handles out-of-band (RTS/CTS) flow control. Why
> would a user expect that in-band (XON/XOFF) flow control is
> handled in all other kernel software that might use the
> async I/O subsystem, but that RTS/CTS is automatic?
> - Many serial chips (other than the very old and very lame
> 8250/16550 series, of course) handle XON/XOFF flow control
> in hardware. If the serial driver isn't involved in
> handling XON/XOFF, then how could this feature ever be used?
> This sounds to me like an architectural flaw as well as a bit of
> missing functionality in the serial driver. PPP should not be
> involved in flow control.
Is the Linux PPP implementation actually involved in doing software flow
control except to tell the kernel serial driver to use XON/OFF by setting
the serial port device file to signal XON/XOFF usage when the option
xonxoff is present? I don't *think* it is involved, although I can't
be entirely sure.
I don't understand what problem it is that he thinks exists concerning
software flow control in the serial driver. I just finished downloading
a kernel source file that is ~24 mB at ~50 kb/s with xonxoff and the
modem set to software flow control. Pppstats showed many ~6000 B/s
peaks as measured over 10 second intervals. Ifconfig showed there were
59 receive errors for 17716 received packets, something that might be
normal for XON/XOFF for all I know. The tar.gz file checked out as okay
using bzip2 -t. I've never seen any other complaint about the serial
driver in regard to software flow control.
If you understand the nature of the problem that he says exists, i.e.,
what his patches are supposed to correct, then I'd appreciate being
enlightened with an explanation. One simple enough for someone with
only a limited ability to read C to understand.
Samuel Thibault
Hello,
I do agree with you. Just reading RFCs clearly shows that flow control is
not the matter in ppp. Nevertheless, it seems Linux has that architectural
flaw, and my patch only helps in seldom occasions when one really need
software flow control, until the flaw is corrected.
I personally encountered such a situation : hp48 is a calculator with 128
Ko memory, and an old 8Mhz processor called saturn (instructions need
20-40 clock cycles in average), and doing 9600 bps ppp without xonxoff
can't work, all the more so since the ROM interrupt handler keeps trying
to receive data until no more comes. When the buffer is full, it can send
a xoff, but if data still come, it keeps looping in the receive function
so it merely locks, and it can't be easily avoided (because interrupt
table is in ROM). The solution really is xon/xoff. As I have those dumb
16550, i need really software xon/xoff.
> Is the Linux PPP implementation actually involved in doing software flow
> control except to tell the kernel serial driver to use XON/OFF by setting
> the serial port device file to signal XON/XOFF usage when the option
> xonxoff is present? I don't *think* it is involved, although I can't
> be entirely sure.
Well, a ppp implementation shouldn't, but it seems that as a line
discipline (yet another questionnable idea), the linux pppd driver should,
according to linux/drivers/serial.c:
(around line 2300 in rs_close)
/*
* Now we wait for the transmit buffer to clear; and we notify
* the line discipline to only process XON/XOFF characters.
*/
> I don't understand what problem it is that he thinks exists concerning
> software flow control in the serial driver. I just finished downloading
> a kernel source file that is ~24 mB at ~50 kb/s with xonxoff and the
> modem set to software flow control. Pppstats showed many ~6000 B/s
> peaks as measured over 10 second intervals. Ifconfig showed there were
> 59 receive errors for 17716 received packets, something that might be
> normal for XON/XOFF for all I know. The tar.gz file checked out as okay
> using bzip2 -t. I've never seen any other complaint about the serial
> driver in regard to software flow control.
Well, indeed, on fairly recent machines, xonxoff is almost useless :
50kb/s is so slow for them that buffers get empty early enough, and hence
almost no stopping/restarting is needed.
If I have time, I'll try to do such transfert, and examine how many times
xon/xoff chars are emitted. I expect it to be somewhat low.
> If you understand the nature of the problem that he says exists, i.e.,
> what his patches are supposed to correct, then I'd appreciate being
> enlightened with an explanation. One simple enough for someone with
> only a limited ability to read C to understand.
Well, if your modem handles it for you, that is no problem, but in the
situation I explained, only Linux has the possibility to do the xon/xoff
handling, and Linux's serial.c doesn't.
Anyway we already discussed about it here last year, and we do actually
agree. The only meaning of my post was to remind that Linux basically
doesn't handle xonxoff when using pppd (because of an architecture flaw),
but a temporary patch exists, if someone has troubles which may come from
it.
Best regards,
--
Samuel Thibault
Clifford Kite
> On Wed, 5 Dec 2001, Clifford Kite wrote:
>> I don't understand what problem it is that he thinks exists concerning
>> software flow control in the serial driver. I just finished downloading
>> a kernel source file that is ~24 mB at ~50 kb/s with xonxoff and the
>> modem set to software flow control. Pppstats showed many ~6000 B/s
>> peaks as measured over 10 second intervals. Ifconfig showed there were
>> 59 receive errors for 17716 received packets, something that might be
>> normal for XON/XOFF for all I know. The tar.gz file checked out as okay
>> using bzip2 -t. I've never seen any other complaint about the serial
>> driver in regard to software flow control.
> Well, indeed, on fairly recent machines, xonxoff is almost useless :
> 50kb/s is so slow for them that buffers get empty early enough, and hence
> almost no stopping/restarting is needed.
This caught my attention, I hadn't thought of that possiblity.
So, true to form, I tested it by using the pppd option nocrtscts, not
using the option xonxoff, and disabled both RTS/CTS and XON/XOFF flow
control on the modem. I download another kernel source that was actually
a few hundred bytes larger than the one downloaded on the previous test
and with a speed that was also very near 50 kb/s. The ifconfig output
showed that 55 receive errors had occurred during the download.
So as far as I am concerned, since I don't believe that software flow
control would fail at the same level that no flow control fails, this
makes it almost a certainty that you *have* found a bug in the Linux
serial kernel driver. You've suffered badly from it since, with the
8 mHz CPU and the broken 16550 (I take it that it is not a 16550A),
the UART FIFO buffer couldn't be emptied quickly enough. Even with a
16550A and my lightly loaded 500 mHz CPU, apparently the buffer isn't
emptied fast enough on some occasions.
Is there anything that I might do to encourage the patches to be put into
the kernel serial driver more quickly? I now have the patches and will
apply the ppp_async.c patch to the 2.4.12 kernel here, and then retest so
that I can be absolutely sure it works.
--
Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
/* Better is the enemy of good enough. */
Samuel Thibault
Hello,
On Thu, 6 Dec 2001, Clifford Kite wrote:
> Samuel Thibault <sa...@ens-lyon.fr> wrote:
> > On Wed, 5 Dec 2001, Clifford Kite wrote:
>
> >> I don't understand what problem it is that he thinks exists concerning
> >> software flow control in the serial driver. I just finished downloading
> >> a kernel source file that is ~24 mB at ~50 kb/s with xonxoff and the
> >> modem set to software flow control. Pppstats showed many ~6000 B/s
> >> peaks as measured over 10 second intervals. Ifconfig showed there were
> >> 59 receive errors for 17716 received packets, something that might be
> >> normal for XON/XOFF for all I know. The tar.gz file checked out as okay
> >> using bzip2 -t. I've never seen any other complaint about the serial
> >> driver in regard to software flow control.
>
> > Well, indeed, on fairly recent machines, xonxoff is almost useless :
> > 50kb/s is so slow for them that buffers get empty early enough, and hence
> > almost no stopping/restarting is needed.
>
> This caught my attention, I hadn't thought of that possiblity.
>
> So, true to form, I tested it by using the pppd option nocrtscts, not
> using the option xonxoff, and disabled both RTS/CTS and XON/XOFF flow
> control on the modem. I download another kernel source that was actually
> a few hundred bytes larger than the one downloaded on the previous test
> and with a speed that was also very near 50 kb/s. The ifconfig output
> showed that 55 receive errors had occurred during the download.
OK, thanks to have done this test. I'm now really convinced that what
happened is that since nowaday's hardware don't really need it (59
failures on 17716 is indeed acceptable), it was really *forgotten* !
> So as far as I am concerned, since I don't believe that software flow
> control would fail at the same level that no flow control fails,
=)
> You've suffered badly from it since, with the 8 mHz CPU and the broken
> 16550 (I take it that it is not a 16550A), the UART FIFO buffer
> couldn't be emptied quickly enough. Even with a 16550A and my lightly
> loaded 500 mHz CPU, apparently the buffer isn't emptied fast enough on
> some occasions.
Well, indeed, it isn't even a 16550 (it is an old calculator !)... I don't
really know which chip it is, but it can do 1200, 1920, 2400, 3840, 4800,
7680, 9600 and 15360 bps, and only has a 1-byte shift buffer. James, do
you have any idea about it ?
> Is there anything that I might do to encourage the patches to be put into
> the kernel serial driver more quickly?
Well, as James highlighted, my patch won't cure the big trouble : serial.c
should do it. It will only add xon/xoff capability to pppd, but not to
other line disciplines...
So we could either :
- apply my patch to ppp_async.c, so that ppp will itself handle xon/xoff.
I has worked for me for a year now, but it's the most dirty choice.
- decide that ppp is not itself a line discipline, but over a dedicated
line discipline which would handle xon/xoff, hence keeping ppp clean. This
would be easier, but would add much complexity for little improvement
- convince Linux' maintainers that xonxoff handling should be done in
character drivers, since serial.c may do it within some UARTs. Not that
easy =) but to my opinion the best choice
> I now have the patches and will apply the ppp_async.c patch to the
> 2.4.12 kernel here, and then retest so that I can be absolutely sure
> it works.
Have nice hacks =)
Best Regards,
Samuel Thibault youp...@yahoo.com
PS: patches are at
http://youpibouh.thefreecat.org/info/prog/ppp.c.2.0.36.patch for 2.0.x
kernels (not tested), ppp.c.patch for 2.2.x kernels, or ppp_async.c.patch
for 2.[45].x kernels
Clifford Kite
Samuel Thibault <sa...@ens-lyon.fr> wrote:
> On Thu, 6 Dec 2001, Clifford Kite wrote:
>> So as far as I am concerned, since I don't believe that software flow
>> control would fail at the same level that no flow control fails,
>
> =)
I still don't believe that but I've since applied the patch manually
to the 2.4.12 kernel here and experienced a problem. See below.
>> You've suffered badly from it since, with the 8 mHz CPU and the broken
>> 16550 (I take it that it is not a 16550A), the UART FIFO buffer
>> couldn't be emptied quickly enough. Even with a 16550A and my lightly
>> loaded 500 mHz CPU, apparently the buffer isn't emptied fast enough on
>> some occasions.
>
> Well, indeed, it isn't even a 16550 (it is an old calculator !)... I don't
> really know which chip it is, but it can do 1200, 1920, 2400, 3840, 4800,
> 7680, 9600 and 15360 bps, and only has a 1-byte shift buffer. James, do
> you have any idea about it ?
Maybe a 16450, that had a one byte FIFO. The 16550 had a 16 byte FIFO but
was broken. The 16550A quickly replaced it, but today some manufacturing
marketing departments don't see fit to make a distinction.
>> Is there anything that I might do to encourage the patches to be put into
>> the kernel serial driver more quickly?
>
> Well, as James highlighted, my patch won't cure the big trouble : serial.c
> should do it. It will only add xon/xoff capability to pppd, but not to
> other line disciplines...
I agree that it is the kernel serial driver that should be fixed. The
question is how to convince the maintainers.
> So we could either :
>
> - apply my patch to ppp_async.c, so that ppp will itself handle xon/xoff.
> I has worked for me for a year now, but it's the most dirty choice.
>
> - decide that ppp is not itself a line discipline, but over a dedicated
> line discipline which would handle xon/xoff, hence keeping ppp clean. This
> would be easier, but would add much complexity for little improvement
>
> - convince Linux' maintainers that xonxoff handling should be done in
> character drivers, since serial.c may do it within some UARTs. Not that
> easy =) but to my opinion the best choice
I think that is what is intended. Pppd's only chore seems to be to set
XON/XOFF flow control for the device file so the serial driver will use
it.
>> I now have the patches and will apply the ppp_async.c patch to the
>> 2.4.12 kernel here, and then retest so that I can be absolutely sure
>> it works.
>
> Have nice hacks =)
Well, I inserted the patch code in what looked like the correct spot and
the kernel compiled without a hitch. Unforunately when I tried to connect
to one of my ISPs with a script that has served me well and has not been
changed recently, I failed to complete a connection. Many trys, and while
I'm used to some failures, there were too many failures and my debugging
messages this time showed some anomalies that I had never seen before and
don't understand. BTW this script uses hardware flow control.
Here is one such message:
Dec 6 16:26:13 corncob chat[359]: send (\d)
Dec 6 16:25:25 corncob last message repeated 8 times
I've never seen the second line before.
Another odd thing was that the other side hungup often, again something
I've seen happen before, but not nearly as many times relative to the
number of connection attempts. The other cause of failure was that the PPP
negotiations never reached the stage where a network protocol was running,
again something that I've seen on rare occasions, but this was occurring as
often as the hangups.
So I finally gave up and rebooted to the kernel I was using before and
connected on the first try. I can't recommend the patch since it seems
pretty certain that the modified ppp_async.c caused all the connection
attempts to fail. :( As I often point out I'm not a C programmer, so I
can't say what in the patch caused the problem. What I did do is to put
the diff up on my web site where you can check it to see if it looks right.
It is found at the end of the "Files for download" section.
--
Clifford Kite <Email: X@Y.Z with X=kite, Y=inetport, Z=com>
/* Editing with vi is a lot better than using a huge swiss army knife.
Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */
Thomas TESTASECCA
If i understand well, linux serial driver doesn't support Xon Xoff flow
control.
I have transmit the problem to my reseller hotline and i wait for news, i
will inform you as soon as possible.
thx again
Thomas
"Clifford Kite" <ki...@see.signature.id> a écrit dans le message news:
vb5ru9...@corncob.inetport.com...