Bug 2863

Summary: Allow setting of MTU per access point
Product: [Maemo Official Platform] Connectivity Reporter: Yan-Fa Li <yanfali>
Component: NetworkingAssignee: unassigned <nobody>
Status: RESOLVED WONTFIX QA Contact: networking-bugs
Severity: enhancement    
Priority: Low CC: andre_klapper, maemo, quim.gil
Version: 5.0-beta2Keywords: community-diablo, patch
Target Milestone: ---   
Hardware: All   
OS: Linux   
Attachments: Ask for interface MTU in DHCP queries
Set interface MTU according to DHCP reply

Description Yan-Fa Li (reporter) 2008-01-30 22:35:29 UTC
SOFTWARE VERSION:
OS2008 v: 2.2007.50-2

STEPS TO REPRODUCE THE PROBLEM:
sit behind a DSL router which uses PPPOE to connect to the internet.

EXPECTED OUTCOME:
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.

ACTUAL OUTCOME:
Intermittent application, like app manager, failures because not all
destinations support path MTU.

REPRODUCIBILITY:
always

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

OTHER COMMENTS:
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.
Comment 1 Lucas Maneos 2009-01-19 19:36:46 UTC
Confirming, since the connectivity settings in 5.2008.43-7 do not have MTU
settings either.

(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).
Comment 2 Lucas Maneos 2009-01-19 19:37:59 UTC
Created an attachment (id=1108) [details]
Ask for interface MTU in DHCP queries
Comment 3 Lucas Maneos 2009-01-19 19:43:39 UTC
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.
Comment 4 Quim Gil nokia 2009-01-25 18:37:03 UTC
fwiw here you have the udhcp sources for Fremantle:

http://repository.maemo.org/pool/maemo5.0/free/u/udhcp/

From your comments I understand that this request should be either ignored for
an official release or pushed to udhcp upstream.
Comment 5 Lucas Maneos 2009-01-25 20:57:21 UTC
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
care.

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
WONTFIX...
Comment 6 Lucas Maneos 2009-02-10 20:29:48 UTC
(In reply to comment #4)
> fwiw here you have the udhcp sources for Fremantle:
> 
> 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?
Comment 7 Quim Gil nokia 2009-02-11 08:42:07 UTC
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).
Comment 8 Andre Klapper maemo.org 2009-03-25 14:48:09 UTC
(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. :)
Comment 9 Lucas Maneos 2009-03-25 22:20:37 UTC
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
anyway.
Comment 10 Yan-Fa Li (reporter) 2009-03-26 19:16:07 UTC
yanfali@gmail.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
workaround.
Comment 11 Lucas Maneos 2009-10-22 07:57:08 UTC
Marking patches of interest to Diablo (Maemo4) community updates, please excuse
the noise.
Comment 12 Andre Klapper maemo.org 2012-03-24 11:45:37 UTC
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
enhancement/wishlist request. 
(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
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )