Nokia E65, E51 problem and Solution - connection to AP with bridge, madwifi, and hostap

[Jouni Malinen]

On Fri, Mar 07, 2008 at 02:08:17PM +0100, Sven Nielsen wrote:

> Problem was that Nokia E65 / E51 would associate with AP and everything
> worked fine using _no_ encryption, but the phones were not reachable
> when using encryption, although browsing and initiating calls from phone
> was fine.

> Solution was, of course, easy ;-), but not being a total network guru,
> it took me some time to find the right parameters. Also, I first did not
> think it to be a settings problem since using no encryption everything
> worked perfectly, so I thought it was a bug using encryption. :-(

This is somewhat surprising since I would not expect these settings to
have much difference regardless of whether encryption is used or not..
Or at least UAPSD should affect both. Maybe there are some WMM-related
interop issues that apply to encryption, too.

I've seen number of interoperability issues between Nokia S60 phones and
some APs when power saving is enabled and this happens also in the
unencrypted configuration.

> To get Nokia E65, E51 (and possibly others) working, parameters
> "uapsd" and "wmm" both have to be _disabled_ by setting them to zero
> with iwpriv. This has to be done _before_ the phone associates with the
> bridging AP. Changing these parameters while the phone was associated
> did not (always) work reliably.

Did you try just disabling UAPSD? I haven't done much testing with WMM,
but I've been able to work arounds most issues by disabling power saving
the phone configuration (advanced options for Wireless LAN).

> Also, I set rts very low to 250 and frag to 512 with iwconfig which
> might also help with the bridging setup since the bridge-utils docs say
> something about MTUs on bridged interfaces have to be same, but using
> encryption, hostapd raises ath MTU to 2239 (while eth has MTU 1500).
> Getting only small packets from ath might prevent bridging problems here.?

RTS and Fragmentation Thresholds for IEEE 802.11 do not actually change
the MTU at all; they are done at a lower layer in the network stack.
Changing of the MTU could probably be removed from hostapd, but I would
not expect it to cause problems in most cases since the bridge interface
MTU would likely be used for figuring out how large a frame can be sent
out and most other sources of packets would use 1500 octet MTU anyway.

-- 
Jouni Malinen                                            PGP id EFC895FA