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...) Confirm that it sends unfragmented packets of IP! size 1501. When you get an answer, your peer is indeed able to handle packets > 1500 Bytes. If you get that answer _unfragmented_ your peer does also actually _use_ your bigger mru! If you don't get an answer, the PPP peers does not really know what it negotiates... Try with "-s 1472" to see that at least everything up to 1500 Bytes is okay. > Having a bigger mtu set does not automaticly mean I will send/receive bigger > packets as other restriction may exist in the path. Indeed. > I look with tcpdump when using download or upload. > Even if I am not understanding everything in the log, it look to me I did > not receive packets bigger than when standard mtu=1500 was used. I saw > mss=1460 in the log. You could use etherreal and look at the _IP_ size (IP -> total length, or something). Try with ping as suggested. TCP MSS does not really say something about packet size. But it looks like packets of 1500 Bytes work quite well (this was not possible without the patch). The linux kernel doesn't seem to use the possibility to use IP packets > 1500 Bytes for TCP on it's own. > Is MTU=65535 for the modem ethernet interface necessary|intented? > > eth3 Link encap:Ethernet HWaddr 00:60:4C:0C:BD:E6 > inet addr:10.0.0.139 Bcast:10.255.255.255 Mask:255.255.255.254 > UP BROADCAST RUNNING MULTICAST MTU:65535 Metric:1 It was to small before (packets got dropped in the kernel before even asking the driver). I changed it to encapsulation limit. It's a little wholehearted as the driver handles only 18xx because of buffer limits... Now too large packet get's dropped on behalf of the driver. Maybe with indication of success to pppoa. As the pppoa source locks a little hackish anyway, this is probably not the biggest problem... (-: Bye, Robert PS: Please send the test results... <-:
