MTU discovery with wireless ap

j-osh · 08-18-2009, 01:32 PM

I have setup a wireless AP and use DNSmasq for DHCP. The outgoing traffic is NATed and then tunneled such that the path MTU is about 1472.

The problem is that I am not able to ask the average wireless client to always change their MTU value when they connect. So is there a way to push this MTU value down to the clients when they connect?

I notice that by default the mtu discovery is turned off in linux:

Code:

~/$ cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0

This MTU discovery seems to also be shut off by default in many other devices I have tried.

I also have found someone that posted an iptables rule:

Code:

/usr/sbin/iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1421:65535 -j TCPMSS --clamp-mss-to-pmtu

but this iptables rule would appear to only benefit TCP traffic and not UDP.

I have also included an option to dnsmasq.conf file to set the MTU to 1472:

Code:

dhcp-option=ath0,26,1472

but this option seems to only work if the client also requests the MTU value when requesting an IP which none have seemed to do.

Is there anyway to force a client connecting to this AP to use an MTU of 1472?

Any help or ideas will be much appreciated.

business_kid · 08-20-2009, 03:33 AM

An mtu is set or agreed between modem and isp. The rest of the system would be wise to use that. As you stand, if you do nothing with the mtu, how does it work?

j-osh · 08-21-2009, 11:49 AM

Thanks for the reply,

If nothing is done, packets will reach the tunnel code (it's an openVPN like implementation) and are fragmented there. The machine at the other end of the tunnel re-assembles them which is a pretty slow process. Using a Nokia n800 as a client we sent video from it's web cam and found that the traffic never really got through. I think this is because the "don't fragment bit" might have been set in the IP header. So then we lowered the mtu on the nokia n800 the video played just fine but in the normal case I cannot ask general users to change their mtu values. For web traffic this fragmentation really makes page loading slow...I think one time it took 5 minutes to load digg.com

We also tried an iPhone and Palm Pre and both had the same issues. The issue is the biggest problem on the iPhone where there is no way to change the mtu unless you jail break it.

So then we set the mtu of the actual AP to be lower which helped. I think this is because the fragmentation happens at the hardware level and such is much faster and the tunnel no longer re-assembles the packets but instead just forwards the fragments.

I was really hoping that clients could be told what mtu to use when they request an IP from the DHCP server but this seems to only happen if the client asks first.

business_kid · 08-22-2009, 03:02 AM

It sounds to me like this is company research that you wish to tap our knowledge base for. The only thing I would suggest is shrink your mtu below the minimum you expect to find in the world outside.

j-osh · 08-22-2009, 05:57 PM

It is a research project I have been working on over the summer and this was the one issue that has been there from the beginning and and I was hoping to be able to have my professor be able to connect to the system I built with his iPhone to demo the project

From digging around the internet it seems this is also an issue seen with PPPoE connections. However the solution is to lower the mtu to something like 1496. But this doesn't really work for my setup. I have done a lot of searching/research on this problem and haven't found anything so I figured I would check to see if anyone else knew of something that might help.

Thanks for the suggestions. If there isn't a solution to this issue maybe it will become my project for next term.

business_kid · 08-23-2009, 10:20 AM

Can you not simply split the packet as a bodge? packet=1492/2, and you send your info in 2 packets.

BTW, next year's project should be the writing of something to discover mtus - if there's going to be free coding done. You seem to have done the digging. A new project is born - MTUtweak to enable the linux user to play about with such things.

j-osh · 08-24-2009, 04:49 PM

Well this works fine with most traffic but if the traffic is sent with the don't fragment bit set then it will be dropped instead of fragmented. This was the case when I tried to send streaming video from a Nokia n800. I believe some traffic that is real-time tends to be sensitive to the delays and jitter introduced from fragmenting and re-assembling of packets.

MTU discovery is already in most machines but just turned off by default...thus creating my current issues.