On 16 April 2014 13:00, James Harper <james.harper(a)bendigoit.com.au> wrote:
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
Hi James,
I am explicitly setting mtu and mru to 1492 in the pppd config.
I don't have any of the faulty modems connected right now, so can't
check until tonight -- but last time I brought this up on list, I
checked and said "If I'm reading the tcpdump correctly (see reply to
myself with it this morning) then yes, there is a frag-required
response." I will re-confirm this tonight.
So outbound (masq clients to internet via linux router) appeared to be
doing the right thing.
Last time this came up, in 2013, you checked the inbound packets, and reported:
"I can confirm what we thought - pings <= 1492 bytes get a response,
pings > 1492 bytes get no response, not even a 'fragmentation
required'."
The issue that confuses me deeply is that half the modems work, and
half don't - yet they have similar internals, and are configured as
identically as they can be (given differing user interfaces).
They are all setup to use LLC, an 8/35 VPI/VCI and to bridge PPPoE in
full-bridge mode.
I think that fact rules out my ISP or there being a dodgy router
somewhere beyond the ISP, as surely that would affect me regardless of
which modem is bridging?
I was willing to write off one modem as having mysteriously broken
firmware, but it seems unlikely that two modems from different vendors
would be broken this way -- and also likely that I'll continue to hit
the problem if I buy more modems :(
tjc
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world