----- Original Message ----- From: "Robert Siemer" <[EMAIL PROTECTED]> To: <[email protected]> Cc: "Gilles Espinasse" <[EMAIL PROTECTED]> Sent: Monday, September 06, 2004 1:11 AM Subject: Re: [Eagleusb-dev] Patch PPPoA: lift artificial limits --> MTU = 1500
> Hello everyone! > > On Sun, Sep 05, 2004 at 09:59:28PM +0200, Gilles Espinasse wrote: > > From: "Robert Siemer" <[EMAIL PROTECTED]> > > > I use now v1.9.9 driver and so try to remove MTU=MRU=1492 and MSS=1410 from > > my script. > > > > This way ppp0 set automaticly MTU to 1500 even if advertised of a bigger MRU > > Sep 4 11:02:01 ipcop pppd[321]: rcvd [LCP ConfReq id=0xbe <mru 9178> <auth > > pap> <magic 0x276af147>] > > Sep 4 11:02:01 ipcop pppd[321]: sent [LCP ConfAck id=0xbe <mru 9178> <auth > > pap> <magic 0x276af147>] > > You could say it is because pppd works > with caution. It doesn't enlarge the MTU on it's own because pppoa or > the underlying driver maybe don't handle it right. And indeed they don't > do so out of the box. > > May I recommand reading http://backsla.sh > I updated it today to correct some UDP issues. > > > As a testing purpose, I try to use bigger MRU MTU. > > I set mru=36000 and mtu=16383 (pppd don't accept a bigger mtu size) > > Sep 5 01:03:17 ipcop pppd[12716]: sent [LCP ConfReq id=0x1 <mru 36000> > > <asyncmap 0x0> <magic 0xd93060ff>] > > Sep 5 01:03:17 ipcop pppd[12716]: rcvd [LCP ConfReq id=0xe2 <mru 9178> > > <auth chap MD5> <magic 0x11652be6>] > > Sep 5 01:03:17 ipcop pppd[12716]: sent [LCP ConfNak id=0xe2 <auth chap > > MS-v2>] > > Sep 5 01:03:17 ipcop pppd[12716]: rcvd [LCP ConfReq id=0xe3 <mru 9178> > > <auth pap> <magic 0x11652be6>] > > Sep 5 01:03:17 ipcop pppd[12716]: sent [LCP ConfAck id=0xe3 <mru 9178> > > <auth pap> <magic 0x11652be6>] > > Sep 5 01:03:20 ipcop pppd[12716]: sent [LCP ConfReq id=0x1 <mru 36000> > > <asyncmap 0x0> <magic 0xd93060ff>] > > Sep 5 01:03:20 ipcop pppd[12716]: rcvd [LCP ConfAck id=0x1 <mru 36000> > > <asyncmap 0x0> <magic 0xd93060ff>] > > > > ifconfig ppp0 > > ppp0 Link encap:Point-to-Point Protocol > > inet addr:82.64.103.183 P-t-P:192.168.254.254 > > Mask:255.255.255.255 > > UP POINTOPOINT RUNNING NOARP MTU:9178 Metric:1 > > RX packets:386 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:182 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:3 > > RX bytes:30888 (30.1 Kb) TX bytes:12143 (11.8 Kb) > > > > So, it work for me (tm) > > This was possible with eagle < 1.9.9, too. The difference is that it > doesn't drop packets with sizes up to the critical 1500 Bytes. Now it > drops the packets at uncritical sizes > 1500 Bytes. Exact limits > see http://backsla.sh > > So your configuration isn't stable because the driver (and pppoa) still > are not able to handle packets up to the theoretical limit. > > But as I cant generate an equivalent situation (see, guess, > http://backsla.sh) it is very interesting to me. > > Please send some packet sniffing output of: > ping -s 1473 <IP of PPP peer> > (try a normal ping before, to see if the peer answers on ping at all...) > I don't have said that I am doing my test behind a NATed linux box. I try from a w2k box ping -l 1473 www.google.com and receive nothing ( when it work with 1472) I try from a w2k box to ping www.01net.com and 1600 was the maximum working size ping -l 1600 www.01net.com Envoi d'une requête 'ping' sur www.dev.01net.fr [213.186.39.31] avec 1600 octets de données : Réponse de 213.186.39.31 : octets=1600 temps=151 ms TTL=60 Réponse de 213.186.39.31 : octets=1600 temps=140 ms TTL=60 Réponse de 213.186.39.31 : octets=1600 temps=140 ms TTL=60 Réponse de 213.186.39.31 : octets=1600 temps=270 ms TTL=60 Sometime, I loose one or more packets which may have taken another route where bigger than 1500 bytes packets are not supported. With bigger than 1600 bytes, packet is rejected by the driver with "[Eagle-usb] Packet transmission error: result=-90" I try too from a linux box with similar result ping -s 1600 www.01net.com PING www.dev.01net.fr (213.186.34.33) from 192.168.1.5 : 1600(1628) bytes of data. --- www.dev.01net.fr ping statistics --- 31 packets transmitted, 0 received, 100% loss, time 30018ms Another attempt had more result (same address was resolved to a different machine) ping -s 1600 www.01net.com PING www.01net.com (213.186.39.31) from 192.168.1.5 : 1600(1628) bytes of data. 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=1 ttl=60 time=144 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=2 ttl=60 time=150 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=3 ttl=60 time=148 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=4 ttl=60 time=145 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=5 ttl=60 time=148 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=6 ttl=60 time=146 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=7 ttl=60 time=144 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=8 ttl=60 time=142 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=9 ttl=60 time=140 ms 1608 bytes from ns2.01net.com (213.186.39.31): icmp_seq=10 ttl=60 time=137 ms --- www.01net.com ping statistics --- 10 packets transmitted, 10 received, 0% loss, time 9091ms rtt min/avg/max/mdev = 137.951/144.909/150.511/3.656 ms So it may work with bigger than 1500 bytes packets but sometime it fail, when a different route is used or a different machine is reached, so it is not reliable to use over Internet.
