maemo.org Bugzilla – Bug 2863
Allow setting of MTU per access point
Last modified: 2012-03-24 11:45:37 UTC
You need to
before you can comment on or make changes to this bug.
OS2008 v: 2.2007.50-2
STEPS TO REPRODUCE THE PROBLEM:
sit behind a DSL router which uses PPPOE to connect to the internet.
packets should route correctly instead of being dropped because they are too
big. Some networks can't deal with path MTU, so allow user to override default
and set the MTU manually.
Intermittent application, like app manager, failures because not all
destinations support path MTU.
EXTRA SOFTWARE INSTALLED:
pidgin, camera, flashblock-webaddon, grsync, libuiw, load-applet,
adblock-plus-webaddon, additional pidgin preferences, map, mplayer,
openssh-client|server, osso-xterm, pigdgin otr, rsync, skype
I can work around this manually by logging in via SSH and modifying the udhcp
script to set the MTU for all connections. What I would really like is an
override per Access point and/or default value for all wireless connections.
Confirming, since the connectivity settings in 5.2008.43-7 do not have MTU
(IMHO any IP network that blocks all ICMP indiscriminately and thus stops path
MTU discovery (among other things) from working is broken by design. So, do
complain to your network provider, loudly.)
Asking the end user to set a specific MTU is not ideal. How are they supposed
to know what value might work on any specific network? A better alternative
would be to offer to disable PMTU discovery altogether (echo 1 >
/proc/sys/net/ipv4/ip_no_pmtu_disc or similar).
Also, in theory the router should provide the correct MTU via DHCP in which
case a better fix would be to make udhcpc and its event script apply it to the
interface. The current Diablo udhcpc doesn't ask for the interface mtu, but
it's simple to make it do so (will attach patch in a minute).
Created an attachment (id=1108) [details]
Ask for interface MTU in DHCP queries
Created an attachment (id=1109) [details]
Set interface MTU according to DHCP reply
Warning: not actually tested on an actual device. Busybox ifconfig does
support setting the MTU though.
fwiw here you have the udhcp sources for Fremantle:
From your comments I understand that this request should be either ignored for
an official release or pushed to udhcp upstream.
Note that the "patch" is essentially just a configuration change (ideally it
would be runtime-configurable, like the server side) so upstream probably won't
Also, there's no guarantee that it will actually fix things in any particular
case - since we are dealing with a known-broken network all bets are off (for
example, even if the router does advertise the correct wan-side link MTU, an
upstream router may have an even smaller one).
IMHO the only reliable workaround is to disable PMTUD altogether and eat the
fragmentation cost. In current kernels we also have the option of using PLMTUD
(RFC4821, enabled via /proc/sys/net/ipv4/tcp_mtu_probing) but AIUI this will
only work for TCP connections and will only go as low as
/proc/sys/net/ipv4/tcp_base_mss (default 512).
So, I guess either offer an advanced option to disable pmtu discovery or
(In reply to comment #4)
> fwiw here you have the udhcp sources for Fremantle:
Hm, this is now (pre-alpha2) gone, and the busybox version is still disabled.
Is this a temporary thing or is udhcp being replaced with something else?
No idea. :) Let's wait to the alpha release (soon) since it will contain most
of the platform components, including those packages having closed source
dependencies (we have been avoiding those in the pre-alpha releases).
(In reply to comment #6)
> > http://repository.maemo.org/pool/maemo5.0/free/u/udhcp/
> Hm, this is now (pre-alpha2) gone, and the busybox version is still disabled.
> Is this a temporary thing or is udhcp being replaced with something else?
http://repository.maemo.org/pool/maemo5.0alpha/free/u/udhcp/ now exists for the
Fremantle SDK alpha.
Lucas, updated comments/patches with regard to Fremantle welcome. :)
It's identical to the Diablo version apart from a CFLAGS change, so most of the
above still applies. I can't find /etc/udhcpc/libicd_network_ipv4.script
(which comes from libicd-network-ipv4 in Diablo) but it's a trivial change
email@example.com Just to update. Since this is such a hard problem to
resolve, I'm simply working around the problem by using sudo and then manually
setting the mtu after the wifi connection is established. I had this problem
recently when trying to download the fennec beta client, their firewall is
apparently eating PMTU information and so no downloads work unless I use this
Marking patches of interest to Diablo (Maemo4) community updates, please excuse
The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)
Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).
There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates.
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
Please note: The Maemo CSSU project is not related in any way to Nokia.
( Tag for mass-deleting bugmail: [cleanup20120324] )