ePMP Force 180 damaged firmware by lightning strike

When upgrading the newer firmware version to 4.6 ePMP Force 180, a lightning strike occurred very close.
The device appeared on the network after a few minutes and as far as can be seen it has upgraded to a new version of the firmware but does not want to accept the new settings.

He does not allow any change in it.
Reboot does not solve anything.
It is not possible to upgrade the firmware of others because the upgrade is damaged in some ways.

You tried via TFTP but how to associate it with TFTP mode at all. I did not find a description of the procedure anywhere.
Mostly in several similar situations so far, the device is happy for TFTP transmission when plugged in.
the previous version was 4.5.6
I begged someone to give me a link where it is described in detail.

You can try recovery procedure. It works even if the firmware is not damaged.

1 Like

This is clear to me when the device itself goes into TFTP mode, and several times I have successfully recovered the firmware.
The device itself goes into TFTP mod, but in this case not.
In this case I have to send it to TFTP mod but I don’t know what I’m doing with that reset button,
Do I hold it for so many seconds on and off or some time when the firmware normally initializes.
This procedure is not described anywhere.

Do you mean if you simply connect F180 to TFTP with ip it does not try to download the firmware?

Could you check with tcpdump if there is an attempt?

I couldn’t detect that.
Please for information, at what time the device waits for the TFTP server from turning on the power so if it does not receive the request it goes to boot from memory.
I did not find that described anywhere.
And is there any procedure by which I can manually send (a fully functional device) to TFTP mode or not?

It takes around 10 sec after power on. Then it looks like this:

10:51:56.701202 ARP, Request who-has tell, length 46
10:51:56.701275 ARP, Reply is-at 00:68:eb:61:36:ec, length 28
10:51:56.701320 IP > ICMP echo request, id 0, seq 0, length 8
10:51:56.701359 IP > ICMP echo reply, id 0, seq 0, length 8
10:51:57.742508 ARP, Request who-has tell, length 46
10:51:57.742546 ARP, Reply is-at 00:68:eb:61:36:ec, length 28
10:51:57.742598 IP > 31 RRQ “firmware.bin” octet timeout 5
10:51:57.744504 IP > UDP, length 12
10:51:57.744633 IP > UDP, length 4
10:51:57.744784 IP > UDP, length 516
10:51:57.744868 IP > UDP, length 4
10:51:57.744947 IP > UDP, length 516
10:51:57.745063 IP > UDP, length 4


I was able to transfer the firmware from TFTP. The device is fully operational.
Thank you for your help
I have one more question.
Is the kos of the whole ePMP family the same procedure as you described in the previous post.
Thanks again

It is for devices with single flash bank only.

I understand
And what is the procedure to push the device into TFTP mode via the button?
Let’s say some leftover device that is below 2.6.2


If you have a device on firmware that doesnt support tftp recovery then you are basically hooped short of hardware hacking to force a bootstrap into good firmware. For the cost in time and effort just buy a new radio and recycle the dead one. For education use though, happy hacking!

If the firmware installation can be fixed why not.
Every unit that I recover, repair and extend the service life is valuable to me.
In my country, Bosnia and Herzegovina, a wireless bridge of the Cambium Force 180 type or equivalent costs half a month’s salary.
It’s not everywhere like in the USA or some similar country.
You know what half your monthly salary is, and you’d shudder at the thought of having to pay for a wireless bridge.
I don’t understand what should and could be hacked.
Best regards

I am in Canada and thus my salary appears to quite high in comparison to yours however there is much you are not aware of in this respect, mainly our cost of living is almost twice that of most of the USA and almost on par with countries like Germany, Sweden and the UK. So the numbers are different but the net effect is the same before we add import tariffs (which are very small for us if importing from the USA) which can kick the crap out of the budget.

The recovery process is built into the bootloader not the operating firmware. If you are not on a bootloader that supports the tftp recovery process then you need to shim a good firmware into memory to boot the radio. I can do this at our shop simply because I have the tools and the knowledge to do this. Having the tools is the hardest part, programming the SPI EEPROM via the UART connection is fairly straight forward IF you have done any WRT conversions, if not then it would be a learning curve.
I do not suggest you take on any repairs that you are not familiar with or those that will void your firmware license with Cambium, if you decide to pursue this, you are on your own.
I highly suggest you locate a Cambium Authorized repair center and see what the cost would be to get them to repair the radio. If not, there are companies like SWG that want your old and damaged radios.

A post was split to a new topic: How to configure VLAN on ePMP