[Dnsmasq-discuss] Re: using DHCP to set clients' MTU

Jan 'RedBully' Seiffert redbully at cc.hs-owl.de
Fri Oct 31 11:31:42 GMT 2008


Peter wrote:
> Apologies for digging up this thread, but its exactly my issue, and
> after nearly 12 hours researching it, im jaded to the point of madness.
> 
> Same deal, theres a modem running off a pppoa dsl link (NZ), and the
> modem has a pppoe - pppoa pass through feature ( Draytek Vigor series)
> quite innovative actually, not like the half bridge hack implementations
> floating around the pppoa world.
> 

No, this translation is your problem!
Your actual "line-limit" is the pppoa size, but with this translation
your...

> Anyway, the gateway/firewall box is debian etch and is running kernal
> mode pppoe to log into the modem.

... router/firewall only sees a pppoe limit.
And this autotranslation is br0ken (What else to expect from an embedded box).
This explains...

> A typical XP client will be able to ping packet sizes up to 1464 bytes
> OK, but those sized between 1465 and 1472 will time out, and those 1473
> and over will return Needs fragment but DF set.
> 
... this funny "blackhole" between 1465 and 1472.

> The actual rule installed under /etc/ppp/ip-up.d/0clampmss is:
> 
> iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp  \
>  --tcp-flags SYN,RST SYN -m tcpmss --mss 1412 -j TCPMSS --clamp-mss-to-pmtu
> 

Is this the rule, to the letter?
Then it is wrong!

You are matching on an mss of EXACTLY 1412 to decide to clamp the mss. Why oh
why? Totally ... . Makes this whole rule a "no operation" (NOP). Maybe the
intention was to match a range? This needs two values.

And you are only applying it to your outgoing packets, ok, now the server sees
it should not send you packets bigger than N, but you are not applying it to the
SYN coming back from the Server, so your clients do not know not to send packets
bigger than N (you have problem uploading data, right?).
This rule should be in your case (since the router can not see the pppoa link):
iptables -t mangle -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --set-mss 1444

mss value is a guess. Since the outgoing router cannot see the pppoa link you
have to use the "--set-mss" option. Maybe you want to think about using a Kernel
very recent. Older kernel not only lowered the mss like "clamp" does, but maybe
raised the mss (i patch that out of 2.6.23 myself) with the "--set-mss" option,
newer kernel don't do this (2.6.26 was fine).

[snip]
> So ill give this a go, but if either of you cracked the pppoe mss
> clamping problem, id be happy to hear about it.
> 

Maybe i spotted it, test carefully, not to confuse cause and effect.

HTH

> I was really excited to get hold of one of these modems, because the
> only other option to us here in NZ (sim to UK) is half bridge
> implementations which arent totally stable.

hmmm, tell me more about it. Half bridged? The Modem always deencapsulte the
traffic, so needs ppp config and may also screw the mss?

> I feel im getting close, and sure as heck know more about TCP than i did yesterday morning ;-)
> 
> Regards
> 
> Peter
> 

Greetings
	Jan

-- 
John encountered the following Zen-like line in his generated XML:
	<>There is no phenotype</>
He was enlightened.



More information about the Dnsmasq-discuss mailing list