[solved] troubleshooting a WiFi connection

[mzimmers]

This falls under the category of "it used to work, but somehow I screwed it up and don't know what I did."

In order to get a WiFi client up for multicasts, I borrowed heavily from the example in examples/protocols/udp_multicast. For the unfamiliar, it runs an infinite loop, using lwip_select (a linux-style select() call) to notify of an incoming message. I had it working, and then it abruptly quit on me this morning. My WiFI event handler has an entry SYSTEM_EVENT_STA_GOT_IP, which is used (via group bits) to gate the loop I mentioned above. But this event never occurs.

I'm new enough to networking that I can only assume this isn't right. Could I get someone to confirm or refute this for me, and possibly to point me in the direction to look for why this isn't working?

Thanks.

[kolban]

If your ESP32 is being a station connecting to an access point and DHCP is in play, then when the ESP32 connects to the access point and is allocated an IP address, you should expect to receive a SYSTEM_EVENT_STA_GOT_IP. Have you switched on log-level=verbose to see all the events arriving? If you are failing to get an IP it might be that your access point is in a "weird" state. This might also explain why your ESP32 ran fine and then stopped. Try rebooting your access point to see if things improve.

[mzimmers]

Hi Neil - I didn't turn on verbose logging, but I did put a telltale printf in the event handler. The program that works correctly gets:

- SYSTEM_EVENT_STA_START
- SYSTEM_EVENT_STA_CONNECTED
- SYSTEM_EVENT_STA_GOT_IP

The program that doesn't work gets:

- SYSTEM_EVENT_STA_START
- SYSTEM_EVENT_STA_DISCONNECTED
- SYSTEM_EVENT_STA_DISCONNECTED
- SYSTEM_EVENT_STA_DISCONNECTED (ad infinitum every 2.5 seconds wall-time)

That's why I was wondering what might prevent the program from receiving an IP address in this program, when the other program does get one. I could post code fragments, but I was hoping to solve this one myself; I just wanted to get some ideas where to look.

Thanks...

[kolban]

Howdy,
The messages tell me that the ESP32 is attempting to connect to an access point and is failing to connect. Since it didn't connect, it won't be allocated an IP address. If it were me, I'd investigate why it failed to connect. The SYSTEM_EVENT_STA_DISCONNECTED is likely to include some reason codes. Possibilities:

1. The access point you are trying to connect with isn't running.
2. You are supplying an incorrect password.
3. There is a coding (or data) error in the parameters that you are using to construct the connection options.
4. The access point has become confused (rare but seen). When you connect to an access point, the access point knows your ESP32 by its MAC id. Some access points can "get confused" thinking that they already have a connected device by that MAC or that the MAC has been disallowed because of some firewall or other rule. A reboot of the access point may be worth a try.

[mzimmers]

Hi Neil -

The program that works runs on the same device, connecting to the same AP, as the one that doesn't, so I don't think the AP is the culprit here. (Besides, I already tried restarting it.)

Can you tell me more about these "reason codes?" Is this information perhaps contained in the event_info field?

[kolban]

If we look here:

https://github.com/espressif/esp-idf/bl ... vent.h#L85

We see the description of the STA disconnected event. We see that it contains a reason byte. If logged, that may give us a clue. I wonder if it is automatically logged if we switch on verbose logging?

Code: Select all

typedef struct {
    uint8_t ssid[32];         /**< SSID of disconnected AP */
    uint8_t ssid_len;         /**< SSID length of disconnected AP */
    uint8_t bssid[6];         /**< BSSID of disconnected AP */
    uint8_t reason;           /**< reason of disconnection */
} system_event_sta_disconnected_t;

[mzimmers]

Well, here's what I got...not sure what to make of it:

D (592) event: SYSTEM_EVENT_STA_START
V (592) event: enter default callback
D (592) tcpip_adapter: check: local, if=0 fn=0x4011ca3c
0x4011ca3c: tcpip_adapter_start_api at C:/esp-idf-v3.0-rc1/components/tcpip_adapter/tcpip_adapter_lwip.c:1065


D (602) tcpip_adapter: call api in lwip: ret=0x0, give sem
D (602) tcpip_adapter: check: remote, if=0 fn=0x4011ca3c
0x4011ca3c: tcpip_adapter_start_api at C:/esp-idf-v3.0-rc1/components/tcpip_adapter/tcpip_adapter_lwip.c:1065


V (612) event: exit default callback
I (612) multicast: event handler event_id = 2. event_info = 0
D (3032) event: SYSTEM_EVENT_STA_DISCONNECTED, ssid:mz_eng, ssid_len:6, bssid:00:00:00:00:00:00, reason:201
V (3032) event: enter default callback
D (3032) tcpip_adapter: check: local, if=0 fn=0x4011cd94
0x4011cd94: tcpip_adapter_down_api at C:/esp-idf-v3.0-rc1/components/tcpip_adapter/tcpip_adapter_lwip.c:1065

So the reason code is 201 (haven't found the description for that yet), but that tcpip_adapter_down_api looks like it might be trying to tell me something.

[kolban]

According to here:

https://github.com/espressif/esp-idf/bl ... ypes.h#L91

201 means access point not found.

Maybe check the settings for the definition of the access point you are trying to reach?

Did I hear you say that you have multiple ESP32 devices? Maybe switch out the one that is failing and see what results you get with a different module with the exact same binaries.

[mzimmers]

printfs (and good programming practices) are my friend.

Through copious use of printf telltales, I determined that the problem was some invalid entries in the wifi_config_t struct, caused by my failure to fully initialize the struct before using it. I guess I'd been getting away with it in earlier, just due to what the value overlaid on the heap, but some change I made later on caused it to fail.

Anyway it's working now...thanks for the help Neil, and sorry for the red herring.