Thank you for updating. There are a few minor code formatting complaints. Mostly trailing spaces and wrong indentation. And a wrong formatted commit message. But that is easy to fix.
The documentation about the new methods should go to docs, not esp32/README.md. The latter is dedicated to build information of the port. At the docs directory the documentation could for instance go into docs/library/network.WLAN.rst. There is also esp32/quickref.rst, but that is less suited. Both places do not tell much about the security setting. So it might be a good time to spend a few words about all possible options.

Thank you for updating. There are a few minor code formatting complaints. Mostly trailing spaces and wrong indentation. And a wrong formatted commit message. But that is easy to fix.
The documentation about the new methods should go to docs, not esp32/README.md. The latter is dedicated to build information of the port. At the docs directory the documentation could for instance go into docs/library/network.WLAN.rst. There is also esp32/quickref.rst, but that is less suited. Both places do not tell much about the security setting. So it might be a good time to spend a few words about all possible options.

No problem, I'll take care of it tomorrow.

@robert-hh

OK The checks now finish successfully and all should be clean. If I should add anything to the documentation just drop me a message.

@h-milz
To understand what you have already tested, and where others could help I have tried to put this in a table.
Is this correct or are there other parts you have already confirmed ? ( I'll update where needed)

@Josverl I forgot to mention that since my first tests in December, my uni apparently implemented EAP-TTLS entirely, so the five methods are all tested and working fine. The only test missing is EAP-TLS which is not supported in our network according to our network admins.

As far as FAST, Espressif does support it in ESP-IDF as documented in https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_wifi.html but as far as I'm aware, I have no way of testing it, so I omitted it for now. I think this is a call for other developers to jump in and provide the proper interface. But then, the whole WPA3 enterprise stuff is still missing as well. Basically, WPA3 is supported in eduroam but I don't know if my uni implements it. Let me check, and if yes, I may be able to provide some working code as well.

Yes, please add a documentation.
Looking through the code it does not seam reasonable to add a new method eap_connect(). It should all be handled within connect() and diverge depending on an authentication type argument, which defaults to the existing mode. But Damien may have a different opinion.

Yes, please add a documentation.
Looking through the code it does not seam reasonable to add a new method eap_connect(). It should all be handled within connect() and diverge depending on an authentication type argument, which defaults to the existing mode. But Damien may have a different opinion.

I understand. Thing is, I intended to be as little intrusive as possible. Integrating it in connect() would probably require adding another switch, or I can just use eap_method and branch accordingly. But we would have to pack the whole arg parsing into connect() ...

... the five methods are all tested and working fine. The only test missing is EAP-TLS which is not supported in our network according to our network admins.

Thanks - Updated the table accordingly

But then, the whole WPA3 enterprise stuff is still missing as well.

Perhaps that can be a follow-up PR, having this merged in would be a step forward.
Lets keep it in mind in the API design though

Yes, please add a documentation.
Looking through the code it does not seam reasonable to add a new method eap_connect(). It should all be handled within connect() and diverge depending on an authentication type argument, which defaults to the existing mode. But Damien may have a different opinion.

I understand. Thing is, I intended to be as little intrusive as possible. Integrating it in connect() would probably require adding another switch, or I can just use eap_method and branch accordingly. But we would have to pack the whole arg parsing into connect() ...

About integrating this, from a Python perspective I think this can be modelled as an overload
The interface could be something like :

class WLAN: 
   # not sure if these should be classvars as that takes some space , or just documented 
    AUTH_EAP_PWD = 0
    AUTH_EAP_PEAP = 1
    AUTH_EAP_TTLS = 2
    AUTH_EAP_TLS = 3

    TTLS_PWD = 0 
    TTLS_MSCHAPV2= 1 
    TTLS_MSCHAP = 2 
    TTLS_PAP = 3 
    TTLS_CHAP  = 4 

    @overload
    def connect(
        self,
        ssid: str | None = None,
        password: str | None = None,
        /,
        *,
        bssid: bytes | None = None,
    ) -> None:
        """
        Connect to the specified wireless network, 
        ...
        """
        ...
    @overload
    def connect(
        self,
        ssid: str | None = None,
        /,
        password: str | None = None,
        *,
        bssid: bytes | None = None, 
        eap_method : int  = AUTH_EAP_PWD , # what is a sensible default 
        username: str | None = None,
        identity: str | None = None,
        ca_cert: bytes | None = None,  # or server_cert ? 
        ttls_method: int = TTLS_MSCHAPV2,
        client_cert: bytes | None = None, 
        private_key: bytes | None = None,
        private_key_passphrase: str | None = None,
        disable_time_check: bool = False, 
    ) -> None:
        """
        Connect to the specified wireless network using WPA2

        """
        ...

( Actually it could be a Protocol as the same protocols can be used for wired network access as well. but I think that is of less concern now)

So - what should we do? Leave it as-is and leave it to the user to use a wrapper on top, or go the whole nine yards and modify network_wlan_connect() (of which I pretty much copied the whole idea and structure as you can tell)? From the amount of code there is, this would rather mean to absorb connect() into eap_connect() and rename it ;-)

From a timeline perspective, I'd vote for leaving it as it is right now, as an intermediary step so to speak. Let people use the code, find potential issues and pitfalls, identify things to add like FAST and WPA3, and plan for a unified and extended solution for the next release. I must also say I have a pretty busy semester ahead of me, and potentially little spare time until early August.

In the earlier conversation @dpgeorge commented:

Thanks for the contribution, this is a very nice feature to add.

And yes, it is port specific and will not help the STM32 or RP2 guys

Right, so this is the main thing to discuss and get right first: how this API will generalise to other WLAN drivers.

Should it be a new method like eap_connect(), or should the existing connect() method be reused and new security arguments/options added to it? The latter seems the more obvious path to me.

From a timeline perspective, I'd vote for leaving it as it is right now, as an intermediary step so to speak.
It would be confusing to publish an API which is known to be changed later. Breaking changes are bad. Since the official review has not yet started, there is plenty of time to make a change. It should require only some re-ordering of the code.
You could keep the network_wlan_eap_connect() function and call that from the network_wlan_connect() function with slightly modified arguments. You can use a common file-scope list of parameters which can be used by both network_wlan_eap_connect() and network_wlan_connect(). The formal args parse step would be in network_wlan_connect(). It needs an additional argument for the authentication method, and once it is one of the EAP methods, it would call network_wlan_eap_connect() with a pointer to args and n_args as arguments.
And obviously the line that defines network_wlan_eap_connect() as wlan method has to go.

Hi guys, I finally managed to find some time to merge wlan_connect() and eap_connect() as discussed, and I also enable WPA3. Sadly, after extending the eap_connect() function, I get an compiler error which leaves me wondering. I'm attaching the local diff against the last successfully compiling version and the new one, as well as the relevant part of the idf.py build log. ATM I'm stuck.

Does it have to do with the number of args? I can't see how and where MP_DEFINE_CONST_OBJ_TYPE_NARGS_2 would be used in this case, and why it would complain.

network_wlan.c.errs.txt
network_wlan.c.diff.txt

Thanks for any insight.

Sadly, after extending the eap_connect() function, I get an compiler error which leaves me wondering. I'm attaching the local diff against the last successfully compiling version and the new one, as well as the relevant part of the idf.py build log. ATM I'm stuck.

G'day! Take a look at this diff when you get a chance. I haven’t tested Wi-Fi. But it builds fine for ESP32-S3, flashed without issues, and all added attributes are in place.
network_wlan.c.diff.txt

>>> import network
>>> wlan = network.WLAN(network.WLAN.IF_STA)
>>> wlan.active(True)
True
>>> dir(wlan)
['__class__', 'EAP_NONE', 'EAP_PEAP', 'EAP_PWD', 'EAP_TLS', 'EAP_TTLS', 'EAP_TTLS_PHASE2_CHAP', 'EAP_TTLS_PHASE2_EAP', 'EAP_TTLS_PHASE2_MSCHAP', 'EAP_TTLS_PHASE2_MSCHAPV2', 'EAP_TTLS_PHASE2_PAP', 'IF_AP', 'IF_STA', 'PM_NONE', 'PM_PERFORMANCE', 'PM_POWERSAVE', 'SEC_DPP', 'SEC_OPEN', 'SEC_OWE', 'SEC_WAPI', 'SEC_WEP', 'SEC_WPA', 'SEC_WPA2', 'SEC_WPA2_ENT', 'SEC_WPA2_WPA3', 'SEC_WPA2_WPA3_ENT', 'SEC_WPA3', 'SEC_WPA3_ENT', 'SEC_WPA3_ENT_192', 'SEC_WPA3_EXT_PSK', 'SEC_WPA3_EXT_PSK_MIXED_MODE', 'SEC_WPA_WPA2', 'active', 'config', 'connect', 'disconnect', 'eap_connect', 'ifconfig', 'ipconfig', 'isconnected', 'scan', 'status']

@mrcreatd thank you for the heads up but your diff lacks my latest changes, merging wifi_connect() and eap_connect() as well as a few wpa3 extensions. My earlier version compiles and works fine as well but my question is what in my latest diff causes the problem. Maybe I don't see the forest for the trees.

@robert-hh @Josverl sorry to bother you but can you please look at the issue? Thank you !

I doubt that I can help. I have no access to a WPA-Enterprise net.

OK, the reason was a missing closing brace m(

I have everything up and running and thoroughly tested as listed in Jos' list above, and all the new stuff is merged into connect(). I'll do some cleanups by tomorrow EOB, and if there's any documentation to add just ping me.

Other than that, I noticed that this extension dropped from the 1.26 merge list because the old PR was closed. Can you add this one then?

extension dropped from the 1.26 merge list because the old PR was closed

@dpgeorge , @projectgus , can you please re-add this PR to the 1.26 milestone if that is still feasible .

@h-milz I based it on the master branch and just tried to get the PR and your patch compiling.
You're right — I should've sent only the diff on top of your patch.
Glad you found the issue already.

I'm happy to help with testing this PR going forward if needed.
That said, for my projects, I prefer to keep esp_eap_client logic in a separate wrapper module, rather than embedding it directly into the network_wlan code.

OK, that seems to work now. I had to reword some older commits that still had "ports/esp32" in the commit messages which made the old code pop up again.

@Josverl, @dpgeorge, @projectgus is there anything missing to add this to the 1.26 merge list?

@projectgus Thank you for your feedback, and I will definitely look into it. Albeit not before the 1.26 merge / release date because I will have to write two uni exams next week and need some prep time.

As for some of the comments:

Should it be a new method like eap_connect(), or should the existing connect() method be reused and new security arguments/options added to it? The latter seems the more obvious path to me.

That's what I did, merge my original eap_connect() into connect(). I would have had to add all the new options to connect() anyway in order to then invoke eap_connect(), so this seemed more straightforward.

Then, it would be great to try implementing this on at least one other WLAN driver, to see how general it can be.

Not at all, because it is a wrapper around methods in ESP-IDF. Someone else would have to look into this one at a later date, because I have no other Wifi capable / MPY supported MCU at hand. My take is, let's start with this one and other MCUs can be added later if someone volunteers to do so.

As this is a large amount of specific documentation I suggest putting it under its own section at the bottom of this doc and linking to that section from here (i.e. "ESP32 port supports additional arguments for WPA Enterprise support, see (link)").

No problem, but again, not before release date.