Should WiFi.reasonCode() be part of the API?

[JAndrassy]

In WiFiNINA Arduino has added a method WiFi.reasonCode(). It was not in the first WiFi library. The new WiFi libraries and the Renasas Core, C33 WiFi and WiFS3, both have it, but it only returns 0.

The return values in the WiFiNINA library are values directly from the ESP32 IDF framework used for the firmware implementation and there is no enumeration or constants in the library..

The reasonCode() should explain why begin failed. The AP can not be found, the password is wrong, ..

When the esp8266 core maintainers wanted to add more information about fail of WiFi.begin, they added a new value to wl_status_t. Only WL_WRONG_PASSWORD was missing. This enhanced WiFi.status() implementation with a useful information.

I think reasonCode() should not be part of the standard Arduino WiFi API. I like the new status value for esp8266 more.

What is your opinion on WiFi.reasonCode()?

[TD-er]

I think there is some argument to be made about keeping it a short list of return values.
However the options returned by the ESP8266WiFi are too limited.
I guess it should be considered something like a bitmask, as you can have various combinations of "connected" and "gotIP".

Also it is good to know whether the station got disconnected from the AP or did initiate the disconnect itself (or never attempted to connect)

The access point does return quite a lot standard disconnect reasons, so why not include those?
"wrong passwd" is not the only one.

[JAndrassy]

ESP32 IDF reason codes are here. I think there are too many for Arduino and other WiFi hardware doesn't have so detailed diagnostics.

[TD-er]

Those are not specific to ESP32, they are standard WiFi codes.

What you could consider is to pick some generic ones and another function to get the detailed WiFi codes.
Either way, the ESP8266 ones are too few.

Maybe the ones with an ID > 200 in that link you provided and nr 15 ((4Way handshake timeout) as that's a generic one sent by most modern AP's when you are not allowed to connect (either wrong password, MAC address block, too many requests, etc)
This way you can't mis-use an AP to send out replies and thus jamming the ether.