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).

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.

Comment 4 Quim Gil 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.

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...

(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 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 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. :)

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.

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.

Marking patches of interest to Diablo (Maemo4) community updates, please excuse
the noise.

Comment 12 Andre Klapper 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] )