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

Sven Nielsen post
Fri Mar 7 05:08:17 PST 2008

Found the solution.

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


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.

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

Kind Regards,

Sven Nielsen schrieb:
> I did not try using NAT since this requires setting up dhcp on the
> embedded AP devices. It might work without the bridge, but I have to use
> some kind of bridge setup since, well, I need a LAN Access point and not
> a router here. ;-)
> At a guess, problem is Nokia together with madwifi, as WEP (no hostapd)
> and WPA exhibit the same connection problem (Nokia outbound ok, inbound
> to Nokia fails)
> I will try to get some info on the madwifi chat tomorrow. 
> Still, the problem is most probably caused by the Nokia phones since my
> laptop has a reliable and stable connection, so I can only hope the guys
> at madwifi know this problem already and know how to solve it.
> regards,
> sven
> Am Sonntag, den 02.03.2008, 21:03 +0900 schrieb Saber Zrelli:
>> Hi Sven,
>> Your problem could be caused by the bridge setup. Have you tried using NAT ?
>>> hi everyone,
>>> we are supposed to roll out about 20 new access points on our first test
>>> site in a few days, however, I haven't quite got them working yet.
>>> The APs are small Alix mainboards equipped with two Atheros miniPCI
>>> cards (madwifi driver). System is minimal Debian stable.
>>> bridgeutils version is 1.2
>>> hostapd version is 0.5.5
>>> (both from stable debian package)
>>> The current major problem at hand is as follows:
>>> Most important scenario for this test site is this:
>>> Asterisk Voip server <--> AP <--> Mobile SIP client (Nokia E65 / E51)
>>> (Everything in one LAN)
>>> We are using a bridge setup, with e.g. br0 containing eth0 and ath0 on
>>> the APs.
>>> Using no, WPA, or WPA2 encryption (with PSK) the mobile clients connect
>>> with no problem, they register to Asterisk Voip server, I can start a
>>> call, I can browse the internet on the mobiles, too.
>>> However, using CCMP algorithm in hostapd I cannot ping or reach the
>>> mobiles, neither from LAN nor from AP directly, but mobiles can reach
>>> PCs behind AP (wired) with no problem.
>>> Using no encryption, everything is _almost_ fine. Ping loss pinging the
>>> mobiles is about 6% at most.
>>> Using TKIP, it seems to work at first, like with no encryption (network
>>> reachable from both sides of AP), but after a few calls (udp
>>> connections), it is the same as with CCMP. Mobile clients can reach the
>>> net without problems, but the wireless clients are not reachable through
>>> the AP.
>>> And finally the weirdest: as long as call is actively transmitting
>>> (active UDP connection), the mobile client is fully reachable! with no
>>> ping loss at all, no matter what encryption is used! But, it vanishes
>>> instantly when the call ends.
>>> I wrecked my brain for 3 days now, it might be something with mtu sizes
>>> different for eth0 and ath0 (1500 vs 2290) it might be related to MAC
>>> addresses, it might be something totally different.
>>> Any help greatly appreciated, really! ;-)
>>> I can compose detailed information and logs instantly if someone thinks
>>> he might know the solution to this.
>>> Best Regards
>>> Sven Nielsen
>>> _______________________________________________
>>> HostAP mailing list
>>> HostAP at
> _______________________________________________
> HostAP mailing list
> HostAP at

More information about the Hostap mailing list