RC2 and MTU troubles

[hotzenpl0tz]

Hi there,
the release notes of kamikaze rc2 state this problem and workaround:

Known issue:

The workaround for broken Path MTU detection in some buggy ISPs is now disabled by default,
because it produced a significant throughput decrease for TCP.

If you have problems connecting to some web sites, or form submission no longer works,
you can enable it again, either manually in /etc/config/firewall (see comments),
or in the web interface under 'Network -> Firewall -> Traffic Control'

Problem is I can't find any comments in the firewall config file and I suffer from exact that problem. I can't go to www.myspace.com as an example. What do I have to do to get the old behaviour ?

Thanks !

[FRiC]

There's an "mss-correction" option, maybe that's it?

[Eric]

edit the forwarding config section in /etc/config/firewall, adding "option mtu_fix 1" which means it should now look like:

Code: Select all

config forwarding 
        option src      lan
        option dest     wan
        option mtu_fix  1

alternatively, run:

Code: Select all

uci set firewall.@forwarding[0].mtu_fix=1

[hotzenpl0tz]

Thanks, tried that and it didn't fix my problem though Will have to go back to an old version or try a different router to see if the problem really stems from the update - but since some old posts in a forum of my provider from people suffered from the same problem with the same websites pointed to wrong mtu values as the source of their troubles - I am somehow still suspecting the current kamikaze release (also I first noticed the problem after having switched to gargoyle with rc2, coincidence ?). Is there an easy way to change mtu values ? I tried to set it in the router interface but the value didn't seem to stick - after the page reloaded the checkbox was unchecked again with the value of 1500.

[Eric]

After setting mtu_fix=1, did you either reboot the router or restart the firewall?

My ISP doesn't seem to have this problem so I can't test what is going on, but after setting mtu_fix=1 I can confirm that the necessary rule to clamp MTU to an appropriate size gets generated and is applied (matching jumps to the necessary chain in the zone_lan_forward chain).

The reason that the mtu control gets inactivated if you try to set mtu to 1500 is that 1500 is the default, and such a setting would be redundant. If you set it to something other than 1500 the box would remain checked.

It would help to know whether you experience the same problems with the standard 8.09 RC2. I suspect that you will, since I haven't altered anything to do with this fix, and I can't imagine how any of my add-ons would affect this issue.

[hotzenpl0tz]

Yeah, I restarted then firewall and after that didn't have an effect I rebooted the router. Didn't solve the problem though, there are still several webpages I can't connect to.

You misunderstood me with the mtu though - I tried to change the value from its default value of 1500 to something lower. I believe I tried 1492 and 1454 (had those values from the forum of my provider) and after the pressing save and waiting for the page to reload the checkbox was unchecked again with the default value of 1500 in the box.

When I get the time I will try flashing both vanilla rc2, the old rc1 and white russian again to see if I can find out where the problem comes from. Thanks for your help !

[Eric]

Thanks for reporting the bug with the MTU setting. I think I've fixed it now. The fix is committed to the SVN, and you can download broadcom firmware with this fix here.

Of course, I have no idea whether this will solve your issue (again, no way to test) -- I just know that this fixes the bug with setting the MTU option in the connection/basic section.

[hotzenpl0tz]

And tada! This did the trick

After changing my mtu value down to 1454 AND activating the mtu_fix I can now visit myspace.com again Also all the other domains that didn't do before work again - so thanks alot !

But to be honest: a normal user who has no idea what an MTU value is (heck, I don't even really know exactly and I have quite a bit of computer experience, I just knew that that value was probably the problem) will never be able to find that out on his own. I am not sure if this is the right way to deal with the problem in openwrt, especially since setting just the mtu value doesn't even fix it - it has to be the combination of mtu_fix 1 and a lower mtu setting in the case of my provider it seems (although I find that quite strange since I never changed anything on the mtu side with my old white russian firmware).

Especially your goal of providing a very userfriendly but still powerfull router interface gets compromised if users can't use it. This is no criticism on your work of course - what you are building here is just beatiful - I really love it

[Eric]

Just FYI, MTU stands for "maximum transmission unit". It's the biggest packet size that can be sent through the network. The problem stems from trying to send packets that are too big through a network that can't handle them. Ideally your ISP would take care of this issue and allow you to use the default ethernet packet size (1500) , but some are idiots and do not.

I agree completely that the current situation is not ideal, and contradicts the goal of having an easy-to-use interface. However, I don't plan on making any adjustments to automatically handle the issue -- yet. This is because the OpenWrt developers are clearly aware of the problem, since it was mentioned in the release announcment, and are likely working on a solution themselves. There was a post on the OpenWrt mailing list indicating that the fix will likely become the default in the final release. I intend to wait until the final 8.09 release is made and see if the problem has been corrected then. If not, I will look into implementing some sort of automatic fix for this, perhaps setting the MTU to 1450 if connecting via PPPoE (which I believe is the only time the problem occurs).

It would be very helpful if, when the final OpenWrt 8.09 release comes out, you could test this for me. It would be great if in a month or two, when the new release arrives, you could test whether the problem has, in fact been fixed. I'll decide exactly what to do about the problem then.

Also, keep the bug reports coming -- I try to fix issues as soon as I know about them. I'm really glad you're finding Gargoyle useful -- it's always great to hear that my work is appreciated!

[hotzenpl0tz]

Your work is superb and I am glad to be able to help out and will of course test the new version when it comes out. I would be reporting more bugs, if there were any I was aware of I have tried almost all of the functions available and everything now seems to work - so atm I am very happy