Argon fast-blinking green, TinkerDebug files available?

I’m having an issue with a fast-blinking green Argon, that can’t seem to connect to my wifi network. It connects fine to my cell hotspot, but stays permanently in fast-blinking mode when I connect to the router. I’ve confirmed with IT that this wifi network isn’t using WPA2 Enterprise (which I know isn’t yet available for Gen3) - it should only need WPA2_AES, with username/password.

I have:

  • Reset Wifi (long press on mode till blue flashing)
  • Updated DeviceOS to 1.2.1
  • Flashed tinker
  • Run particle serial wifi to set up with the CLI

One thing that would be helpful is an Argon version of the TinkerDebug070.bin file mentioned in the WPA2 Enterprise topic - is there one available? It would be great to get more detailed error messages about is happening.

From a search around the forums, it seems that getting stuck at fast-blinking green usually means the Argon has cleared the WiFi credentials, but it stuck either with DHCP or a firewall? Is that correct?

After posting this, I was able to find @rickkas7’s excellent clouddebug code, which he’s ported to Argon - thanks for doing that! It should be a lot easier to understand with the logs.

Here’s a snippet of the relevant section of the log, with the Argon seeming to fail to connect with the AP (while blinking fast green):

0000003027 [hal] TRACE: NCP state changed: 0
0000003028 [net.esp32ncp] TRACE: NCP event 1
0000005000 [system.nm] INFO: State changed: DISABLED -> IFACE_DOWN
configured credentials:
ssid=APName security=wpa2 cipher=3
available access points:
0000006306 [ncp.at] TRACE: > AT
0000006307 [ncp.at] TRACE: < OK
0000007308 [hal] TRACE: NCP ready to accept AT commands
0000007309 [ncp.at] TRACE: > AT+CMUX=0
0000007311 [ncp.at] TRACE: < OK
0000007312 [gsm0710muxer] INFO: Starting GSM07.10 muxer
0000007314 [gsm0710muxer] INFO: Openning mux channel 0
0000007315 [gsm0710muxer] INFO: GSM07.10 muxer thread started
0000007368 [gsm0710muxer] INFO: Resuming channel 0
0000007369 [gsm0710muxer] INFO: Openning mux channel 1
0000007470 [gsm0710muxer] INFO: Resuming channel 1
0000007471 [gsm0710muxer] INFO: Resuming channel 1
0000007473 [ncp.at] TRACE: > AT
0000007524 [ncp.at] TRACE: < OK
0000007525 [ncp.at] TRACE: > AT+CWDHCP=0,3
0000007574 [ncp.at] TRACE: < OK
0000007574 [hal] TRACE: NCP state changed: 1
0000007575 [net.esp32ncp] TRACE: NCP event 1
0000007577 [ncp.at] TRACE: > AT+CWLAP
0000010128 [ncp.at] TRACE: < +CWLAP:(3,"APName",-47,"APMAC",6)
SSID=APName security=wpa2 channel=6 rssi=-47

//Other APs listed here

0000010179 [ncp.at] TRACE: < OK
connecting to WiFi
0000010187 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000010191 [net.ifapi] INFO: Netif wl3 state UP
0000010192 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000010199 [gsm0710muxer] INFO: Openning mux channel 2
0000010278 [gsm0710muxer] INFO: Resuming channel 2
0000010279 [hal] TRACE: Connecting to "APName"
0000026330 [ncp.at] TRACE: < +CWJAP:3
0000026331 [ncp.at] TRACE: < ERROR
0000026332 [ncp.at] TRACE: > AT+CWLAP
0000028884 [ncp.at] TRACE: < +CWLAP:(3,"APName",-49,"APMAC",6)

//Other APs listed here

0000028915 [ncp.at] TRACE: < OK
0000028916 [net.esp32ncp] TRACE: Failed to connect to WiFi: -170

The error seems to be happening after the +CWJAP:3 call, but I’m not sure how that means it’s failing. Does anyone have any advice?

That sounds like a captive portal which neither the Photon or the Argon support.

Thanks for responding, @peekay123 - I’ll take a look into that. At the moment, I don’t believe there’s a captive portal running on that network, as we’ve been able to get other IoT devices and wearables attached to it without being challenged by a portal. Unfortunately for me, the Argon is the first device that has given us any trouble.

I was hoping that the logs would help, but the nature of this error didn’t leave a big trail of breadcrumbs behind it - just:

0000026330 [ncp.at] TRACE: &lt; +CWJAP:3 
0000026331 [ncp.at] TRACE: &lt; ERROR

I’m working with IT to figure it out, but I don’t have a lot of details to provide them - it seems like the wifi connection fails as soon as it starts the connection.

We made some headway, and I’m able to actually get connected to the AP now. However, it’s getting hung on something new:

connecting to WiFi
0000010095 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000010100 [net.ifapi] INFO: Netif wl3 state UP
0000010101 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000010108 [gsm0710muxer] INFO: Openning mux channel 2
0000010162 [gsm0710muxer] INFO: Resuming channel 2
0000010163 [hal] TRACE: Connecting to "APName"
0000012064 [ncp.at] TRACE: < WIFI CONNECTED
0000013014 [ncp.at] TRACE: < OK
0000013014 [hal] TRACE: NCP connection state changed: 2
0000013015 [net.esp32ncp] TRACE: NCP event 2
0000013017 [net.esp32ncp] TRACE: State changed event: 2
0000013019 [net.ifapi] INFO: Netif wl3 link UP
0000013020 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP

Does anyone know why it would hang on this last line of the log?

@jameshallam, does it just hang there at the IFACE_LINK_UP line? What’s happening with the RGB LED?

It seems to just hang there. The RGB LED is stuck in fast blinking green at this point - so far it doesn’t change anywhere in the process.

I just reset the Argon wifi again (long press on mode till blue flashing), and set up the network fresh:

0000006306 [ncp.at] TRACE: > AT
0000006307 [ncp.at] TRACE: < OK
0000007308 [hal] TRACE: NCP ready to accept AT commands
0000007309 [ncp.at] TRACE: > AT+CMUX=0
0000007311 [ncp.at] TRACE: < OK
0000007312 [gsm0710muxer] INFO: Starting GSM07.10 muxer
0000007313 [gsm0710muxer] INFO: Openning mux channel 0
0000007313 [gsm0710muxer] INFO: GSM07.10 muxer thread started
0000007365 [gsm0710muxer] INFO: Resuming channel 0
0000007367 [gsm0710muxer] INFO: Openning mux channel 1
0000007467 [gsm0710muxer] INFO: Resuming channel 1
0000007468 [gsm0710muxer] INFO: Resuming channel 1
0000007471 [ncp.at] TRACE: > AT
0000007521 [ncp.at] TRACE: < OK
0000007522 [ncp.at] TRACE: > AT+CWDHCP=0,3
0000007571 [ncp.at] TRACE: < OK
0000007572 [hal] TRACE: NCP state changed: 1
0000007574 [net.esp32ncp] TRACE: NCP event 1
0000007576 [ncp.at] TRACE: > AT+CWLAP
0000010130 [ncp.at] TRACE: < +CWLAP:(3,"APName",-54,"APMAC",6)
SSID=APName security=wpa2 channel=6 rssi=-54

//other APs

0000010170 [ncp.at] TRACE: < OK
connecting to WiFi
0000010179 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000010183 [net.ifapi] INFO: Netif wl3 state UP
0000010185 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000010192 [gsm0710muxer] INFO: Openning mux channel 2
0000010275 [gsm0710muxer] INFO: Resuming channel 2
0000010277 [hal] TRACE: Connecting to "APName"
0000012177 [ncp.at] TRACE: < WIFI CONNECTED
0000013127 [ncp.at] TRACE: < OK
0000013128 [hal] TRACE: NCP connection state changed: 2
0000013128 [net.esp32ncp] TRACE: NCP event 2
0000013129 [net.esp32ncp] TRACE: State changed event: 2
0000013131 [net.ifapi] INFO: Netif wl3 link UP
0000013132 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP
0000013134 [ncp.at] TRACE: > AT+CWJAP?
0000013178 [ncp.at] TRACE: < +CWJAP:"APName","APMAC",6,-52
0000013179 [ncp.at] TRACE: < OK
0000013210 [ncp.mgr] TRACE: Updated file: /sys/wifi_config.bin

Outside of the extra AT+CWJAP and the config file, it doesn’t get any further.

From looking at other people’s logs, it seems like IP assignment would typically come next. Something like:

[system.nm] INFO: State changed: IFACE_LINK_UP -> IP_CONFIGURED

Our IT department is asking if I can disable IPv6, or force an IPv4 address on my end, though I’m not sure if that’s something I can do. I know that the Argon has successfully leased an IPv4 address in the past on this network, but it may not be doing so now.

I’ve seen that this thread back in November showed logs failing at the same spot, and @ScruffR commented that:

That’s what I get when my DHCP server tries to assign an IPv6 to the Argon (or merely checks whether IPv6 is supported on the device?).
Currently my workaround is to add an intermediate WiFi router where I can disable IPv6 support entirely.
Hopefully 0.8.0-rc.26 will address this issue.

That thread ends with an announcement that v080-rc.26 was supposed to take care of some of the IPv6 issues. I’m running v1.2.1, so I’m not sure if there are remaining issues with IPv6. Our IT department has told me that the network is “dual stack IPv4/IPv6”, so I don’t think I have the option to disable IPv6 on their end.

Has anyone run into this recently? Any strategies for getting past it that don’t involve adding a new router in the middle? Thanks for your help!