Setting up Photon/P1 on WPA Enterprise (0.7.0)


@avtolstoy - don’t know if these are the logs/information you’re looking for, but I was able to get the following by typing in these commands into my RPi3 running raspbian:

Find the PID:

ps aux | grep supplicant 

Kill it:

sudo kill ###

Run wpa_supplicant manually:

sudo wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf -f/home/pi/wpa_supplicant.log -dddd

Go to /home/pi/wpa_supplicant.log and see what it spits out.

Update: I think I finally figured out how to get all the output. It’s long so I posted it here. I hopefully redacted most things specific to me. It’s like, really long, so here’s a less verbose version (used -dd instead). The SSID seeking to connect to is either “MYSSID” or “eduroam”.

I also found this in reference to the network I’m trying to connect to:

IE: IEEE 802.11i/WPA2 Version 1
    Group Cipher : CCMP
    Pairwise Ciphers (1) : CCMP
    Authentication Suites (1) : 802.1x

Thanks for any help you can provide!


@griffgj Thanks for the full log!

I’ve quickly looked through it and here is something interesting:

EAP-PEAP: Start (server ver=1, own ver=1)
EAP-PEAP: Using PEAP version 1

RADIUS server is offering PEAPv1, which is not supported on Photon/P1.

I’ve just tested with my test FreeRADIUS server and authenticating with wpa_supplicant shows:

EAP-PEAP: Start (server ver=0, own ver=1)
EAP-PEAP: Using PEAP version 0

It would be great if you could force wpa_supplicant to use PEAPv0 (phase1="peapver=0") in order to see if RADIUS server will accept PEAPv0.


I’ll be honest, it’s taken me most of the day to get you that log file, so needless to say I’m pretty inept at knowing what you’re talking about. When getting my Pi connected to my network, it did take some trial and error but here’s what I ended up with in my wpa_supplicant.conf file.


I put your line into the above wpa_supplicant file and got this log. I thought I had done something like that in the past with failure, but it actually connected and works. So looks like my network does support v0:

EAP-PEAP: Start (server ver=1, own ver=0)
EAP-PEAP: Using PEAP version 0


@griffgj @naikrovek I’ve had the chance this week to reproduce possibly the same issue you are seeing. While the issue itself is somewhere within WICED TLS implementation, a rather simple workaround of disabling TLS 1.2 seemed to have helped.

I would appreciate if you could try this branch in your environment. It’s based on 0.7.0-rc.6.

You can also find prebuilt system firmware binaries here:



I tried the binaries you provided, without success.

Reading up a bit, I do not know if we use PEAPv1 or v0.


Have you tested with outer identity set to inner identity as well? Some RADIUS server configurations do not support anonymous outer identities, which we use by default.


Yep, same results here. I did the same slew of tests as before (university network/eduroam, no outer identity/used my identity, certificate/no certificate - mixing and matching all scenarios) and still got no connection. 1006,1007 most errors, occasional 1024, 1025. Thanks for sticking with us and trying!


@naikrovek @griffgj Thank you for taking the time to test this! I really appreciate it, as it’s really difficult to debug issues dependent on the environment.

Just FYI, there is a discussion about a similar issue on WICED community forums (and there is even a link to this thread there). Seems that it’s still present in WICED 6.0.0 (we are still using 3.7.0-7).

But despite that I suggest we try some additional debugging. I’ve enabled unhelpful logging in WICED and added packet dumping within the supplicant. Please try the debug binaries at the same gdrive link.

Please note that they are based on 0.8.0-rc.1, so you should update the bootloader first (OTA or via serial). Please also take a look at 0.8.0-rc.1 release notes, specifically the downgrade section about downgrading from 0.8.0-rc.1.

I suggest flashing a simple user application containing nothing more than a Serial1LogHandler (115200 baudrate at the very least) or SerialLogHandler instance with LOG_LEVEL_ALL level to fetch the logs from the device.

Please either PM me or email the logs to andrey (at)

The region of intereset should be between wlan_supplicant_start(): TRACE: Starting supplicant and [hal.wlan] wlan_hal.cpp:537, wlan_supplicant_stop(): TRACE: Stopping supplicant.



Quick question: just uploaded step 1 and step 2 (didn’t read your instruction very well - sorry) and noticed it didn’t update my bootloader. Information is sparse and confusing on how to update that, can you give me a quick tutorial? Thanks!


That should have all the info you need. Either OTA or over Serial should work. It’s up to you to pick one. Anything in particular you’re struggling with?


I’ve received the logs from @griffgj and already replied by email, but will duplicate here for visibility:

I took a look into the certificate chain sent by the server and a couple of intermediate certificates use SHA-384, which is not supported on Photon unfortunately.

I’m going to see how much of an impact enabling SHA-512/SHA-384 will make on flash space usage and if possible will try to push for its support to be included in the next 0.8.0 prerelease.

I will also post an update in this thread once this feature is ready (but not released yet), so those interested in trying it out can build the feature branch manually or try out the prebuilt binaries.

I’ll also try to make sure that the firmware is more verbose during the connection process to a WPA Enterprise access point either by default or by switching some feature flag making it easier to report the issues.


Debug information sent. I had difficulty getting the Photon to behave when flashing via USB so I dug out my ST-Link and Programmer/Debug Shield and flashed that way.


Hello!! someone can help me with this topic in Spanish? Thanks a lot!


This worked for me! Thanks so much!


@avtolstoy Sorry this has been a while to reply. I have now acquired a DrayTek Vigor AP902 which has a built in RADIUS server and thus I can experiment with trying to connect photons to WPA2 Enterprise. I have just tried with 0.8.0-RC.11 to programmatically connect to the WAP and also via CLI - both with no success. I added SerialLogHandler to my application. The output on the serial monitor is included here. Can I assume that you have not been able to enable SHA-512/SHA-384 in the Device OS yet? I am getting the 1007 error- not keyed. Do you know if the length of the password matters? i.e. does it need to be a certain length to work.

Step 1: Turn On Wifi module and confirm MAC address
Step 2: Clear WAP credentials if they exist
Device has existing WAP credentials stored - delete these
0000007847 [hal.wlan] WARN: Clearing WiFi credentials
0000007959 [hal.wlan] INFO: Clearing enterprise credentials
0000007959 [hal.wlan] TRACE: Trying to set EAP credentials
0000008051 [hal.wlan] INFO: EAP config valid: 0
0000008052 [hal.wlan] INFO: Writing EAP configuration
Device WAP credentials cleared successfully
0000008148 [hal.wlan] TRACE: connect cancel
Step 3: Set WPA Enterprise credentials (hard coded)
Step 4: Connect to WPA Enterprise WAP
0000008911 [hal.wlan] TRACE: Trying to set EAP credentials
0000009004 [hal.wlan] INFO: EAP config valid: 1
0000009004 [hal.wlan] INFO: Writing EAP configuration
0000009101 [hal.wlan] INFO: Saving credentials
0000010523 [hal.wlan] TRACE: Free RAM before suppl: 46376
0000010523 [hal.wlan] TRACE: Starting supplicant
0000010546 [hal.wlan] TRACE: Supplicant started 0
0000010546 [hal.wlan] TRACE: Free RAM after suppl: 32936
0000010546 [hal.wlan] INFO: Joining ZTEST
0000010547 [hal.wlan] TRACE: Free RAM connect: 32936
0000017553 [hal.wlan] ERROR: wiced_join_ap_specific(), result: 1007
0000017553 [hal.wlan] TRACE: Stopping supplicant
0000017555 [hal.wlan] TRACE: Supplicant stopped
0000017555 [hal.wlan] TRACE: Free RAM after suppl stop: 46376
0000018069 [hal.wlan] TRACE: Free RAM before suppl: 46376
0000018069 [hal.wlan] TRACE: Starting supplicant
0000018092 [hal.wlan] TRACE: Supplicant started 0
0000018092 [hal.wlan] TRACE: Free RAM after suppl: 32936
0000018093 [hal.wlan] INFO: Joining ZTEST
0000018093 [hal.wlan] TRACE: Free RAM connect: 32936
0000025097 [hal.wlan] ERROR: wiced_join_ap_specific(), result: 1007
0000025098 [hal.wlan] TRACE: Stopping supplicant
0000025099 [hal.wlan] TRACE: Supplicant stopped
0000025100 [hal.wlan] TRACE: Free RAM after suppl stop: 46376
0000025614 [hal.wlan] TRACE: Free RAM before suppl: 46376
0000025614 [hal.wlan] TRACE: Starting supplicant
0000025637 [hal.wlan] TRACE: Supplicant started 0
0000025637 [hal.wlan] TRACE: Free RAM after suppl: 32936
0000025638 [hal.wlan] INFO: Joining ZTEST
0000025638 [hal.wlan] TRACE: Free RAM connect: 32936
0000032643 [hal.wlan] ERROR: wiced_join_ap_specific(), result: 1007
0000032644 [hal.wlan] TRACE: Stopping supplicant
0000032645 [hal.wlan] TRACE: Supplicant stopped
0000032646 [hal.wlan] TRACE: Free RAM after suppl stop: 46376
Device has new WAP credentials stored
0000034653 [hal.wlan] TRACE: connect cancel
Connection unsuccessful


Very disappointed not to have received a reply to this thread or a support ticket I raised. Is Particle serious about support for WPA Enterprise security on WiFi networks? Without this working a chunk of corporate and university business is out of reach.


@armor, I just poked the Particle folks on Slack. The impeding Mesh shipments are taking a lot of bandwidth but hopefully they will respond to my poke. :wink:


Hi Will,

My apologies – this is going to sound suspiciously like an excuse but as I said in the ticket, the engineer that can help has been totally immersed in developing his part of the mesh infrastructure. I will contact him again so that we can move forward.



@ParticleD @peekay123 Thanks for replies - hope to hear something soon.


FYI to everyone: I sent Will a special build of Device OS that will hopefully help him figure out what’s not working in the WPA2 Enterprise/RADIUS stuff. It’s configured to send out log information as it tries to connect.