Ticket #1250 (reopened defect)

Opened 7 years ago

Last modified 6 years ago

No Wifi in Managed Mode

Reported by: mickey@… Owned by: openmoko-kernel@…
Priority: highest Milestone:
Component: kernel Version: unspecified
Severity: critical Keywords:
Cc: buglog@…, ace@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

I have an open network at home, but our wifi does not want to associate. This
is the log (yes, prototype #30 is supposed to have the 2.0.0.89 firmware):

Connect called with authmode 1 dot11 auth 1 PW crypto 1 PW crypto Len 0 GRP
crypto 1 GRP crypto Len 0
AR6000 disconnected from 00:18:f8:b8:b4:11
Disconnect Reason is 6
Protocol Reason/Status? Code is 19
AssocResp? Frame =
10 00 3a 01 00 12 cf 74 1f 98 00 18 f8 b8 b4 11
00 18 f8 b8 b4 11 f0 9c 21 04 13 00 00 00 01 08
82 84 8b 96 a4 b0 c8 ec 32 04 8c 92 98 e0 dd 06
00 10 18 02 03 f5
AR6000 disconnected from 00:18:f8:b8:b4:11
Disconnect Reason is 6
Protocol Reason/Status? Code is 19
AssocResp? Frame =
30 00 3a 01 00 12 cf 74 1f 98 00 18 f8 b8 b4 11
00 18 f8 b8 b4 11 40 9d 21 04 13 00 00 00 01 08
82 84 8b 96 a4 b0 c8 ec 32 04 8c 92 98 e0 dd 06
00 10 18 02 03 f5
AR6000 disconnected
Disconnect Reason is 1
Protocol Reason/Status? Code is 0
AssocResp? Frame = NULL
AR6000 updating target stats
AR6000 scan complete: 0
AR6000 disconnected from 00:18:f8:b8:b4:11
Disconnect Reason is 6
Protocol Reason/Status? Code is 19
AssocResp? Frame =
10 00 3a 01 00 12 cf 74 1f 98 00 18 f8 b8 b4 11
00 18 f8 b8 b4 11 70 a5 21 04 13 00 00 00 01 08
82 84 8b 96 a4 b0 c8 ec 32 04 8c 92 98 e0 dd 06
00 10 18 02 03 f5
AR6000 disconnected from 00:18:f8:b8:b4:11
Disconnect Reason is 6
Protocol Reason/Status? Code is 19
AssocResp? Frame =
30 00 3a 01 00 12 cf 74 1f 98 00 18 f8 b8 b4 11
00 18 f8 b8 b4 11 b0 a5 21 04 13 00 00 00 01 08
82 84 8b 96 a4 b0 c8 ec 32 04 8c 92 98 e0 dd 06
00 10 18 02 03 f5

Attachments

bug1250-wifinoproblem.2.dump (97.2 KB) - added by alphaone@… 6 years ago.
Dump of a successful association
bug1250-wifinoproblem.dump (97.2 KB) - added by alphaone@… 6 years ago.
Dump of the failed association
bug1250-wifiproblem.dump (52.9 KB) - added by alphaone@… 6 years ago.
Dump of the failed association
ar6k-short_preamble.patch (1.3 KB) - added by sameo@… 6 years ago.
Patch: enabling shor preamble
wpa_dump (14.5 KB) - added by ChristW 6 years ago.
dump of wpa_supplicant -dd to show no association

Change History

comment:1 Changed 7 years ago by mickey@…

* Bug 1249 has been marked as a duplicate of this bug. *

comment:2 Changed 7 years ago by mickey@…

Ok, using another AP it works. Now we should find out what goes wrong with the
first AP. Sameo?

comment:3 Changed 7 years ago by will@…

  • Priority changed from high to highest

P2 changed to P1

comment:4 Changed 7 years ago by andy@…

Mickey can you specify the brand and actual model number of the APs that work
and fail?

Also to be mega clear, "open" is a bit overloaded for Wifi, Open is an auth
mode but also "open" can mean no encryption informally. We mean "no
encryption" here I assume?

comment:5 Changed 7 years ago by mickey@…

Linksys WRT54GS (Tomato Firmware) -- does not work.
Linksys WAP54G (Stock VmWorx? Firmware) -- does work.

Open Wifi for me means:

  • no encryption
  • no mac filter
  • no click through
  • no nothing

comment:6 Changed 7 years ago by tony@…

What is the passed aceess point? Is also thw linksys AP with OpenWRT firmware
or standard access point (brand/model)?

comment:7 Changed 7 years ago by andy@…

When I google about the "Protocol Reason/Status? Code is 19" or "Disconnect
reason is 6" I only get a hit from this bug report itself. This usually means
something highly specific to the setup makes the problem.

Because the problem only comes with nonstandard firmwire in the AP (which is
generating the 6 / 19 codes I guess -- 0x06 and 0x13 appear in the packet) I
don't know what we can do about it (the WLAN firmware is closed by the vendor)
if Sameo doesn't have any ideas.

comment:8 Changed 7 years ago by tony@…

So the default firmware comes with Linksys WRT54g is OK? Only DD-WRT or Tomato
like firmware may not working?

comment:9 Changed 7 years ago by graeme@…

I could not get my GTA02 to associate with a WRT54GL with openwrt 7.09 firmware.

comment:10 Changed 6 years ago by sameo@…

  • Status changed from new to assigned

Finally found some time to look at that bug.
So, we get an association response from the AP, with status code being 19.
According to 802.11, this means we have a PLCP preamble mismatch.

Mickey, would it be possible for you to sniff the whole process, before you
start associating with the openwrt AP, until you receive this association
failure frame ? From the AP's beacon I'd be able to check which preamble it
allows, and from our association request I could understand which preamble we use.

Thanks in advance.

Changed 6 years ago by alphaone@…

Dump of a successful association

comment:11 Changed 6 years ago by sameo@…

Not sure if firefox is playing games on me or not, but both attachements are
identical for me.
They're showing a succesful association with an AP which SSID is "linksys".

Am I missing something ?

Changed 6 years ago by alphaone@…

Dump of the failed association

comment:12 Changed 6 years ago by alphaone@…

  • attachments.isobsolete changed from 0 to 1

comment:13 Changed 6 years ago by tony@…

I bought a linksys wrt54g v6 today, miles do some iperf test on default
firmware, could successful link and finish the transmission performace test.

Changed 6 years ago by sameo@…

Patch: enabling shor preamble

comment:14 Changed 6 years ago by graeme@…

I just re-tried this with the new phone I was issued while in Taiwan.

It now associates with with OpenWRT kamikaze firmware fine. So I think seeing as
prototype #36 which I had before had other "issues" it probably doesnt actually
affect me.

comment:15 Changed 6 years ago by tony@…

I will close this bug if no other update tomorrow

comment:16 Changed 6 years ago by mickey@…

Tony, please let me close it. I'm not in Frankfurt atm., but will be on sunday.

comment:17 Changed 6 years ago by mickey@…

Problem still exists after applying the patch -- same protocol output.
(By the way, it's not OpenWRT, but Tomato)

comment:18 Changed 6 years ago by sameo@…

Mickey, I would once again need a sniffing dump of your failing association.
Also, could you let me know if your AP is running in 11g mode only ?

comment:19 Changed 6 years ago by andy

  • Status changed from assigned to closed
  • Resolution set to wontfix

Closing because nobody is looking at it for two months, it won't get solved. Association in managed mode works fine here too on Belkin routers in unencrypted and WPA.

comment:20 Changed 6 years ago by gdevenyi

  • Status changed from closed to reopened
  • Cc ace@… added
  • Resolution wontfix deleted

I'm seeing this bug with the latest kernel/2007.2 daily image as of 21.07.2008

AR6000 disconnected from 00:16:b6:b5:3e:a7
Disconnect Reason is 6
Protocol Reason/Status? Code is 19
AssocResp? Frame =
10 00 3a 01 00 12 cf 8e e5 85 00 16 b6 b5 3e a7
00 16 b6 b5 3e a7 d0 b3 21 04 13 00 00 00 01 08
82 84 8b 96 24 b0 48 6c 32 04 8c 12 98 60 dd 09
00 10 18 02 01 f0 00 00 00

This is with WRT54GL v1.1 with DD-WRT v24

comment:21 Changed 6 years ago by gdevenyi

I should also note, I've now tried connecting to this router in both Open mode (no encryption, just MAC filtering) and WPA2. Neither of these works. Error is the same for both.

comment:22 Changed 6 years ago by will

there's been some interesting threads on community lists:

http://lists.openmoko.org/pipermail/community/2008-July/022284.html

don't know if this helps.

comment:23 Changed 6 years ago by ChristW

I also have problems associating with my AP at home. I have a stock WRT54G ver 7 with no firmware updates (there aren't any available).

Running wpa_supplicant in debug mode tells me that associating with the AP fails because of a timeout. I'll re-run the wpa_supplicant command at home and attach the results.

Changed 6 years ago by ChristW

dump of wpa_supplicant -dd to show no association

comment:24 Changed 6 years ago by werner

comment:25 Changed 6 years ago by werner

I had a quick look in my books about those preambles. Here's what
I found:

  • the preamble can be long or short. New equipment, particularly .11g, supports short preambles.
  • the AP should signal if short preambles are okay
  • if a station tries to use short preambles but the AP doesn't support them, you get that error 19

Now, this raises a few questions:

1) why does the AP not support short preambles ? They're good for

performance, so one shouldn't suppress them needlessly.

2) does it signal that they're not supported and the Atheros stack or

firmware ignores that ? Or does the AP fail to signal this ?

3) Can we make the AR6k not try to use them ?

The answer to 2) may be in the logs. Haven't looked at them yet.
The answer to 1) is Mickey's problem :-)
Perhaps I can help with 3):

svn co http://svn.openmoko.org/trunk/src/target/AR6kSDK.build_sw.18/host/tools/wmiconfig
cd wmiconfig
make CC=arm-angstrom-linux-gnueabi-gcc
scp wmiconfig neo:
ssh neo ./wmiconfig -i eth0 --setlongpreamble 1

Does this help ? By the way, thanks to Marek ! Your hunch about wmiconfig
may have been right.

comment:26 Changed 6 years ago by werner

Okay, I decoded part of the dump. The answer to 2) is that the AP
claims that it supports the short preamble:

The first packet in bug1250-wifiproblem.dump is a beacon frame and
its capability field has the following settings:

(ESS, !IBSS) = it's an AP
(!CF-Pollable, !CF-PollReq?) = no point coordination
!Privacy = no WEP
ShortPreamb? = network uses short preambles
!PBCC = no packet binary convolution coding
ChannelAg = no channel agility
ShortSlot? = supports 802.11g shorter slot
!DSSS-OFDM = duh, too lazy to look that one up

If setting the long preamble with wmiconfig still causes a failure,
but this time with code 25 (0x19), then the AP is also confused about
the short slot option.

comment:27 Changed 6 years ago by andy

  • HasPatchForReview unset

How is current andy-tracking or stable behaving on this AP now? Any change?

comment:28 Changed 6 years ago by werner

Here's an update:
http://lists.openmoko.org/pipermail/devel/2009-February/004722.html

My original interpretation that the AP was first offering a
capability which it later refused was incorrect. I can even
reproduce the problem. But this still doesn't explain the root
of this particular evil.

  • Werner
Note: See TracTickets for help on using tickets.