Re: [Dnsmasq-discuss] using DHCP to set clients' MTU
Jan 'RedBully' Seiffert on 12/09/08 12:53, wrote: Adam Hardy wrote: Jan 'RedBully' Seiffert on 11/09/08 21:17, wrote: [snip] Hmmm, a mtu of 1430 looks a bit strange, but propably depends on your link. Some kind of VPN or PPPoA on your side? Or are you saying paypal has some kind of Tunnel/Route/Whatever which limits THEIR mtu? [SNIP] Oh, initially i wasn't even talking about you, but problems on the remote end where you have no control how they configure their stuff. Then you are forced to employ ugly workarounds on your side. If you check your firewall rules, make sure there is a path for icmp-fragmentation-needed packets. (iptables right table -p icmp --icmp-type fragmentation-needed -j ACCEPT) OK, I'll go with that, but I'm trying to work out logically if I have blocked it. What state are the ICMP fragmentation-needed packets returned? Surely they are RELATED or ESTABLISHED? In that case, I am not blocking them. I only block INVALID and NEW for most ports. [SNIP] I read a little on BT, seems they use PPPoA, and this is terminated on the modem... Hmmm, ATM equipment for PCs is rare, so your router has normal ethernet to the modem and sees an mtu of 1500, while the true mtu is hidden in the modem. And i thought one of the benefits of pppoa was, that the mtu is kept at 1500. Any chance your new hosting service has a funny uplink? (should not, a big site should have a real connection and not a dsl line...) /me is tottaly confused Gnarf, seems this is even a bigger PITA than PPPoE ... Searching for the right mtu turned up a lot of values, does someone know the true mtu of a BT PPPoA link? (note: first and foremost you better find the real mtu of the link, to get a grip on the problem, then one can think about adjusting/tuning it to better match the ATM-part of the connection) The modem faced interface of your router needs the MTU set to the true value. This way your router should not send packets to big (or fragment them), your clients should get an fragmentation-needed when they try to. Using http://www.dslreports.com/tweaks I see that my network is unpingable under the 'ICMP (ping) check' result. That looks bad in view of the above. But it also tells me: Max packet sent (MTU): 1488 Max packet recd (MTU): 1418 Retransmitted packets: 4 sacks you sent: 2 so I guess that 1488 is what I should set my ADSL modem to? [SNIP] Since you are talking about SMTP, so you had problems sending large packets? Then the problem can be on your side, according to my crystal ball ^^. But can be also on the remote side... It's important which packet choked, your outgoing packet or the incoming packet not coming through to you. Are you sure this is a true modem and not also a little router, do you have a non-private ip-address on your router? Maybe its also twiddling some values... Maybe you should go back to sqare one, set everything back to 1500 and then use tcpdump to see where your packets vanish, or how big they are with other known to work sites. Maybe later if there's no joy with the latest stuff I've learnt about something with 145[0-9] from what i read. Or is BT adding another encapsulation like L2TP? I searched the most useful UK broadband users forum for L2TP and only saw references to it in connection with resellers or wholesale. It doesn't look like something that BT are using on my ( other retail customers') connection. Regards Adam
Re: [Dnsmasq-discuss] using DHCP to set clients' MTU
Adam Hardy wrote:
Jan 'RedBully' Seiffert on 11/09/08 21:17, wrote:
[snip]
Hmmm, a mtu of 1430 looks a bit strange, but propably depends on your
link.
Some kind of VPN or PPPoA on your side? Or are you saying paypal has
some kind of Tunnel/Route/Whatever which limits THEIR mtu?
In an ideal World you would not need to fiddle with your mtu, because
a thing
called path mtu discovery should catch this. Your kernel sends packets
with the Don't Fragment-Bit (DF) set, and every router on the way to
the
target should sent you a packet back when your packet is to big, so your
kernel can lower the pmtu, till it fits. Unfortunatly, this does not
always
work, either because the setup is so complex (vpn over a tunnel over
dailup...) that errors are not properly propagated, or, and this is more
anoing, because some Admins block ICMP, which is needed for this to
work. In
their view ICMP is evil and a 1337 H4x0r protocol, neglegting that
it is a
needed part for {TCP|UDP}/IP to work. A big german freemail provider was
notoriously known for this braindamage for years.
But before you lower your clients mtu, do you know where the mtu
bottleneck
is and/or is your router by chance a Linux box? (such things can
shurely also
be done with other gear, but i don't know how)
Because there are two other and maybe more interresting solutions:
1) Linux knows an iptables target named TCPMSS. It adjusts the tcp
mss, so it
won't help you on UDP, but fixes the most commen case, that tcp
connection
hang. But only if your router sees the mtu bottleneck (PPPoE or
something
similar). Look at your iptables man-page, it comes with an example
command. Most SOHO-router-in-a-box implement this, maybe it it
switched off? This also
fixes problems with other sites, until their pmtu is lower than yours and
they do the braindamaged stuff...
2) You can try setting the pmtu early (so icmp messages reach the
client) by setting up a route with the right mtu on your router. Hmmm,
you can even set
it on the clients. Example:
Hi Jan,
I really appreciate the feedback - although I think your option (2) is
slightly beyond what I want to get into for the sake of network admin
here!
Yeah, it is a possible workaround for a one oddball situation, but if your
link is the permanent bottleneck, you will hit this problem again and again...
I must admit that I set up the iptables firewall on my gateway
machine, and I need to look at it to check whether I inadvertantly
blocked this ICMP business.
Oh, initially i wasn't even talking about you, but problems on the remote end
where you have no control how they configure their stuff. Then you are forced
to employ ugly workarounds on your side.
If you check your firewall rules, make sure there is a path for
icmp-fragmentation-needed packets.
(iptables right table -p icmp --icmp-type fragmentation-needed -j ACCEPT)
The gateway has a NIC connected to a DSL modem and that has no firewall,
it's just my machine and BT on the other side.
I read a little on BT, seems they use PPPoA, and this is terminated on the
modem...
Hmmm, ATM equipment for PCs is rare, so your router has normal ethernet to the
modem and sees an mtu of 1500, while the true mtu is hidden in the modem. And
i thought one of the benefits of pppoa was, that the mtu is kept at 1500.
Any chance your new hosting service has a funny uplink? (should not, a big site
should have a real connection and not a dsl line...)
/me is tottaly confused
Gnarf, seems this is even a bigger PITA than PPPoE ...
Searching for the right mtu turned up a lot of values, does someone know the
true mtu of a BT PPPoA link? (note: first and foremost you better find the real
mtu of the link, to get a grip on the problem, then one can think about
adjusting/tuning it to better match the ATM-part of the connection)
The modem faced interface of your router needs the MTU set to the true value.
This way your router should not send packets to big (or fragment them), your
clients should get an fragmentation-needed when they try to.
But this still leaves problems with the path back to you when the remote side is
blocking icmp (a bottleneck has two sides ;). Lowering the mtu of your clients
is a cheap trick to repair this: the clients set the right tcpmss when they
start a connection (you can only set it at the start, but the first packet (the
SYN, approx. 60 bytes) doesn't trigger the pmtu...), so the remote end will not
run into trouble on the path back. In effect you are doing their work (But this
will not help for UDP)
This is where the:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
comes into play. Your router now hopefully knows the pmtu, and will lower the
tcpmss set by the clients as a band aid, the connection will be (hopefully) the
right size from the beginning.
I had problems with SMTP and a new hosting service - a solar powered
hosting service
Re: [Dnsmasq-discuss] using DHCP to set clients' MTU
On Fri, 12 Sep 2008 13:53:28 +0200, Jan 'RedBully' Seiffert redbu...@cc.hs-owl.de wrote: ... I think 1430 is one of those optimised values, and 1458 maybe still to big for pppoa, but i'm not sure. Did you tried 1454 1452? I think it's something with 145[0-9] from what i read. Or is BT adding another encapsulation like L2TP? From my firewall script: #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- # maximum mss or mtu # ``` # Policy: the firewall controls this value as it is required when ethernet # access to ADSL modem is used, clamping MSS here removes the need to # modify any localnet machines' MTU setting. # # Information: http://www.cisco.com/warp/public/794/router_mtu.html states # baseline (lowest) MSS value is = 1360, highest is 1452 for PPPoE, add # 40 for matching MTU values. # # Check you have rp-pppoe.conf 'CLAMPMSS=no' # # Leave MAX_MSS empty to perform path mtu discovery, this doesn't work with # ISPs that drop ICMP traffic -- refer `man iptables`. # # MAX_MSS=1452 # maximum MSS (ref: cisco) # MAX_MSS=1360 # minimum MSS (ref: cisco) MAX_MSS=1412 # default MSS (ref: rp-pppoe default) # MAX_MSS=# use PMTU discovery # ... # clamp MTU for new TCP connections to world if [ -n $MAX_MSS ] then # use preset iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \ -o $X_WORLD -j TCPMSS --set-mss $MAX_MSS else # use path discovery iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \ -o $X_WORLD -j TCPMSS --clamp-mss-to-pmtu fi ... Grant.
Re: [Dnsmasq-discuss] using DHCP to set clients' MTU
Steven Jan Springl on 11/09/08 15:20, wrote: On Thursday 11 September 2008 14:08, Adam Hardy wrote: Hi, searched the archives and the net and was surprised not to see any hits for MTU except its generic appearance in log statements. I had to change my MTU on my workstations to1430 to get SMTP and some websites to work (e.g. paypal). Can I tell dnsmasq to send the MTU setting with the DHCP information? My attempts to hack it into the config haven't worked. Thanks Adam Adam I use the following statement to set the mtu size to 1492 for clients connected to eth0: dhcp-option=eth0,26,1492 Steve, thanks for the info! For anyone else looking at this in future, there's a good doc here: http://www.faqs.org/rfcs/rfc2132.html All the best Adam
Re: [Dnsmasq-discuss] using DHCP to set clients' MTU
Adam Hardy wrote:
Steven Jan Springl on 11/09/08 15:20, wrote:
On Thursday 11 September 2008 14:08, Adam Hardy wrote:
Hi,
searched the archives and the net and was surprised not to see any hits
for MTU except its generic appearance in log statements.
I had to change my MTU on my workstations to1430 to get SMTP and some
websites to work (e.g. paypal).
Can I tell dnsmasq to send the MTU setting with the DHCP information?
My attempts to hack it into the config haven't worked.
Thanks
Adam
Adam
I use the following statement to set the mtu size to 1492 for clients
connected to eth0:
dhcp-option=eth0,26,1492
Steve, thanks for the info!
For anyone else looking at this in future, there's a good doc here:
http://www.faqs.org/rfcs/rfc2132.html
Hmmm, a mtu of 1430 looks a bit strange, but propably depends on your link. Some
kind of VPN or PPPoA on your side? Or are you saying paypal has some kind of
Tunnel/Route/Whatever which limits THEIR mtu?
In an ideal World you would not need to fiddle with your mtu, because a thing
called path mtu discovery should catch this.
Your kernel sends packets with the Don't Fragment-Bit (DF) set, and every
router on the way to the target should sent you a packet back when your packet
is to big, so your kernel can lower the pmtu, till it fits.
Unfortunatly, this does not always work, either because the setup is so complex
(vpn over a tunnel over dailup...) that errors are not properly propagated, or,
and this is more anoing, because some Admins block ICMP, which is needed for
this to work. In their view ICMP is evil and a 1337 H4x0r protocol, neglegting
that it is a needed part for {TCP|UDP}/IP to work. A big german freemail
provider was notoriously known for this braindamage for years.
But before you lower your clients mtu, do you know where the mtu bottleneck is
and/or is your router by chance a Linux box? (such things can shurely also be
done with other gear, but i don't know how)
Because there are two other and maybe more interresting solutions:
1) Linux knows an iptables target named TCPMSS. It adjusts the tcp mss, so it
won't help you on UDP, but fixes the most commen case, that tcp connection
hang. But only if your router sees the mtu bottleneck (PPPoE or something
similar).
Look at your iptables man-page, it comes with an example command.
Most SOHO-router-in-a-box implement this, maybe it it switched off?
This also fixes problems with other sites, until their pmtu is lower than yours
and they do the braindamaged stuff...
2) You can try setting the pmtu early (so icmp messages reach the client) by
setting up a route with the right mtu on your router. Hmmm, you can even set it
on the clients. Example:
$ dig paypal.com MX
[snip]
;; QUESTION SECTION:
;paypal.com.IN MX
;; ANSWER SECTION:
paypal.com. 461 IN MX 10 data.ebay.com.
[snip]
;; ADDITIONAL SECTION:
lore.ebay.com. 3462IN A 66.135.195.181
$ whois 66.135.195.181
OrgName:eBay, Inc
[snip]
NetRange: 66.135.192.0 - 66.135.223.255
CIDR: 66.135.192.0/19
NetName:EBAY-1
# ip route add to 66.135.192.0/19 via gateway mtu 1430
$ tracepath 66.135.195.181
1: my_box.lan (192.168.0.2)0.224ms pmtu 1430
1: my_gateway.lan (192.168.0.254) 0.286ms
[snip]
Problem is, you would have to set this up for every pmtu blackhole...
HTH
All the best
Adam
Greetings
Jan
--
Murphy's Law of Combat
Rule #3: Never forget that your weapon was manufactured by the
lowest bidder
