Could an OTA update be blocked by firewall? blink magenta and then solid magenta

Hi community
We experienced something weird for the first time in the field while flashing an update over the air to a Photon (running 1.5.2).
After flashing firmware from the Web IDE, the flash starts in the console, and the photon starts blinking magenta. Then after a couple of seconds the led goes solid magenta and we can only recover the photon by resetting it (reset button).
-Flashing same app, same device in the lab (i.e different network) is successful.
-Flashing same app, different device in the lab (i.e different network) is successful.
-Flashing same app, different photon, in the customer’s network fails. The photon get’s stuck in solid magenta.

Could the firewall in customer’s network be blocking specifically the OTA? In normal operation, the photon in customer’s network works perfect (breathing cyan) so the firewall is not blocking normal traffic.

I’ve tried to read similar topics in the forum but they’re very old. I read that solid magenta happened in the past when data messages during the flash were lost in the transmission, so I wondered whether something similar is happening here but not on particle’s servers but on customer’s network.

Thanks for the advice.

Hi @fenriquez,

You might have probably seen this:

Solid colors are rare. There only expected situation is:

** Solid magenta if you are loading code in ymodem serial mode.*

In most cases, solid colors are the side effect of a bug. If code crashes or infinitely loops with interrupts disabled, it’s possible that the LED animation will stop. The color of the LED is the color it last was before failure. So for example, it could be solid cyan if it was previously breathing cyan, or solid red if it was trying to output an SOS pattern.

Since you mentioned that you tried the device in different networks, maybe whitelisting is required. Here are the IP addresses:


Hi @fenriquez -

HHmmm… my experience with solid colour LED’s are unfortunately not good, to the extend that the units ended up being replaced. Having said that, it is not to say this is the case.

Of course there are some easy steps to follow to test this. If you can connect to a network not passing through the firewall and it works, well then @particle7888 is sport on and white listing the IP’s and certain port numbers or MAC addresses should resolve any issue. (depending on what firewall and to what extent the client will allow you to do this)

If it is easier, simply Whitelist the device from the start, but this might not be a clear indication of the issue unless of course it resolves the problem :slight_smile:

Firewalls can be troublesome to navigate, especially if not configured properly.

1 Like

Hi all, @friedl_1977 @particle7888
Thanks for your input. It was indeed the firewall blocking the firmware flash. The mac address was whitelisted in the firewall and then the flash started to work properly.

Just to clarify for future refence, this behaviour was strange, as normally all traffic is blocked when the firewall is restricting foreign devices in the network. I.e particle publish, functions, etc dont work behind such firewall rules; the photon simply does not connect to the particle cloud. In this occassion, the photon did connect to the cloud, reported all cloud functions and publish worked fine. The only thing the firewall was blocking was the firmware OTA update.

1 Like

H @fenriquez -

Great to hear you figured it out.

I used to work with Network Security products for a bit. This seems indeed possible. I recall the perimeter devices we used, had more ‘advance’ settings that meant rules could be customised for incoming and outgoing traffic separately. Seems in this might have been the case, as the Particle device was publishing successfully. Seems that it was allowing all/most outgoing traffic, but was restricting (at least at some level) incoming traffic from Particle server.

Nevertheless, glad you resolved the issues, Firewalls can be tricky.

Keep innovating :wink:

Regards, Friedl.