> > Hi, > I posted last year about a problem I was having with Linux's PPPoE > functionality in regards to a specific modem. At the time I put it > down to a dodgy modem and moved on, but now I've hit it on another > modem, and twice seems more than coincidence. > > The problem is that path MTU detection seem to break when the "bad" > modems are involved. So the Linux box running pppoe is OK, because it > knows the interface has an mtu+mru of 1492, but masqueraded clients do > not. > You can work around the problem a bit, by having an iptables rule with > --clamp-mss-to-pmtu, but it's a kludge.. and importantly, only > required for two of these four modems. The other two work just fine > *with apparently identical configurations* (ie. LLC / bridged) > > Can anyone think of a reason for this? > The rp-pppoe and other mailing lists offer tantalising hints that I'm > not alone, but sadly those threads do not lead to any solutions. > > Modems that work: > * TP-Link TD-8817 (Trendchip chipset) > * Billion 7300RA (Trendchip chipset) > > Modems that don't work: > * TP-Link TD-8840T (Trendchip) > * Billion 7800NL (Broadcom chipset)
In which direction "doesn't work for masq clients"? For sending (client -> internet), the ICMP Fragmentation Required packet should get sent from the ppp endpoint (eg your linux router). Pinging with 'do not fragment' packets from your masq clients should confirm that this is working. For receiving (internet -> client), something upstream of the LT2P endpoint has to send the ICMP Frag Required packet to the sender of the packet. It can't be (directly) the fault of your modem. What could upset things though is if the ppp mtu and mru settings aren't getting passed to the other end. So if your end has an mtu of 1492, your router won't allow larger packets through and should (easily testable) send the frag required packet back, but if the other end didn't know that your mtu was set thus, because you hadn't specified an mru and/or because (maybe) the modem wasn't doing some magic somewhere to let the other end know what sized packet you could receive, then you would have problems. Are you definitely setting both mtu and mru in your ppp config? Can you confirm that your router is behaving correctly for your clients? Eg on your clients do "ping -M do -c 1 -s 1472 8.8.8.8". Then "ping -M do -c 1 -s 1464 8.8.8.8". The first should give you a fragmentation required response. The second should not (don't know if google dns answers pings. Now can do you the same from an external IP address (with 1500 MTU - not another PPPoE endpoint)? Email me with your external IP privately and I can test this for you if you don't have such access. The other possibility is that somewhere between you and the LNS is an even lower MTU restriction, so you'd need to set your mtu and mru to something lower. I would expect you'd have problems with the host in that case though. One further possibility is that even in bridge mode, some of these modems are snooping your packets and setting the MSS for you. That would be easy enough to test too by making a connection to something running wireshark. (can help you with that too if you want) All that said though, you still do need to set the MSS. There are too many broken routers out there. James _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
