Cant connect some APs

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable
Hello all,

I have a problem connecting some APs using the snippets installed with WICED. I have five wifi APs available, but can only connect with three of them. With the other two I cant. Ive tried several settings like other channel, other security (WEP/WPA/WPA2), wifi mode (b/g/n), other SSID and passphrase, but none of the changes in the setting of the AP will make it work.

Ive also copied all settings of a not working AP to a working AP and than I can connect to that AP with the same settings (and SSID and passphrase).

Strange enough I have a precompiled firmware file delivered by the supplier of the SN8200EVK kit im using, and if I execute this firmware the module can connect with the AP where the snippets cant connect with. So probably its not the hardware, because this firmware can connect with the AP.

Does anyone have or had the same or similar problem? and how to solve this?

Modules Im using:

ISM43362_M3G_L44 (Inventek)

SN82xx (muRata)

Wiced version:

WICED 2.3.1 (also corrected the known issues, july 4, 2013)

APs I cant connect with, using the snippets:

ASUS RT-N10

HW version: B1

FW version: 2.0.2.1

TP-Link TL-WA830RE

HW version: WA830RE v1 00000000

FW version: 3.12.17 Build 111108 Rel.31187n

With kind regards,

Walter van der Meiden
0 Likes
1 Solution
Anonymous
Not applicable
As I looked at the traces I noticed that Wireshark has flagged almost all the packets from the bruwifi-guest AP as malformed.

On one of the failed join attempts I looked at the bruwifi-guest AP didnt reply to any of the client devices Authentication requests. Endless 802.11 retries before the client gave up. This could simply be low signal strength due to the distance between the client and the AP or could be a sign of a busy RF environment or poor RF performance of the board.

WICED, unlike PCs, tablet and phones, is very aggressive and unforgiving in classifying a failure to join to ensure energy is not wasted by the device attempting to join a non-existent AP.

View solution in original post

3 Replies
Anonymous
Not applicable
Please attach a wireless sniffer trace that captures a failing join transaction.

It sounds like you are configuring the app incorrectly.

Which app are you using to test with?

Did you try snip.https_client ?
0 Likes
Anonymous
Not applicable
Im testing a few weeks now and couldnt solve this problem. Ive tried several apps, but mostly with the snip.https_client app.

Somehow Ive really no idea why and how and whats changed, but now I can connect with the AP (ASUS RT-N10) I couldnt connect with before.

The way its connecting is not that smooth as with the other APs that already where working, but it connects most of the times. I have to admit, for other devices its also not always that easy to connect with this AP, but finally the connection will be made most of the times, whats still better than how the module could connect last weeks with the AP.

Like jasonrc asked, i have attached a zip file with wireless sniffer traces, made in wireshark.

The MAC of the broadcom device is: 02:0a:f7:ed:d3:08 (wlan.sa == 02:0a:f7:ed:d3:08 || wlan.da == 02:0a:f7:ed:d3:08) or in some traces 02:0a:f7:ed:d3:02 (wlan.sa == 02:0a:f7:ed:d3:02 || wlan.da == 02:0a:f7:ed:d3:02).

The file which name contains "bruwifi-beneden" is a  join to a AP which is nearly always succesfull and its join and http request is very smooth.

The files which name contains "bruwifi-guest" is a join to the problematic AP.

The files ending with "_googlerepliedhtml" are completely succesfull, thus including the http request and reply to/from google, for the other files the http request/response wasnt always succesfull or unknown.

The term "failedNx" in the file names says that the join fails N times.

The term "succes_N_time" in the file names says that the join succeeded the Nth time

I cant say this case is closed, because I still dont no why I couldnt connect with that problematic AP before. Im not  happy with that, but maybe the problem comes back...
0 Likes
Anonymous
Not applicable
As I looked at the traces I noticed that Wireshark has flagged almost all the packets from the bruwifi-guest AP as malformed.

On one of the failed join attempts I looked at the bruwifi-guest AP didnt reply to any of the client devices Authentication requests. Endless 802.11 retries before the client gave up. This could simply be low signal strength due to the distance between the client and the AP or could be a sign of a busy RF environment or poor RF performance of the board.

WICED, unlike PCs, tablet and phones, is very aggressive and unforgiving in classifying a failure to join to ensure energy is not wasted by the device attempting to join a non-existent AP.