Which version of OpenWRT is your EA4500 running? I just captured a crashlog after some efforts. It's for a recent snapshot. But 18.06.2 also suffers infinite restarts after enabling radio1 (5GHz) on an EA3500/EA4500.
The crash pretty much disables the 5GHz radio on EA3500/EA4500's:worried:
I booted the router, pushed the reset button for 30 seconds and the router booted correctly this time, now I am a bit puzzled as I don't know which version I am running, the viper-squashfs-factory image or the viper-squashfs-sysupgrade, could you please tell how to find out ? I don't want to risk flashing again with the latest image as I don't know what will be outcome, thank you.
And how would that be relevant? Typically the only difference is that factory image file contains additional ID or special formatting, so that the OEM flash routine accepts the file. There is no difference in a live system. (That holds true for 99% of routers)
As hnyman said, they are pretty much the same thing. When ssh'ing into it, the /etc/banner should spell out 18.06.2. Going forward, you can (1) flash viper-squashfs-factory from Linksys stock firmware's Web UI or (2) sysupgrade in OpenWRT with viper-squashfs-sysupgrade.
The older version of sysupgrade (LEDE 17.01.4?) can flash Linksys' stock firmware to another partition. I did it by booting from a USB drive.
EA4500 is one of most flash-friendly routers, with 2 boot partitions and USB booting capability: 2+multiple booting. Really hard to brick it and easy to test new code/settings.
Hi guys, now I am trying to revert to the stock firmware since these problems came back again, basically the router will restart itself multiple times in a loop until I do a failsafe reset, when I try to use the sock firmware from the UI I obtain this error :
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
You need to check the wiki's device page for an answer to that, I don't know the device/ arch in question well enough to answer, but in general.
OpenWrt has introduced image meta data 'recently' (starting with 17.01.x, depending on the target). This meta data is JSON encoded and appended to the actual firmware image, it's technically optional - but sysupgrade will use it and require its presence on the targets supporting this image meta data already (not all do), this is done to achieve better consistency checks before flashing a new firmware and to avoid accidents/ flashing firmware for a different device.
OEM firmwares, respectively the vendor SDKs they're based upon, typically predate the existance of these - so they usually don't provide this image meta data, meaning sysupgrade will reject to flash these images. For OEM images that are sysupgrade compatible, but just lack the image meta data (or for reverting to an older OpenWrt version without it), sysupgrade -n -F linksysfirmware.img is an option. What I cannot answer, is if you can revert to OEM via sysupgrade, or if that needs a different procedure - as that's device specific.
In that case, -F will flash the firmware image you provide it with, ignoring the missing meta data (the wiki entry is just predating the existence of these additional checks), given that the webinterface won't provide you to flash an image without meta data.
(I'm a bit careful in my phrasing here, as I don't know the device/ target in questions and -F will flash the provided image ignoring all sanity checks, no matter what, even if that would brick- or harm the device otherwise).
As suggested by @builder, maybe you could try to flash an old version first and flash the stock firmware from there to see if it works. He has done it as he said in his post, using USB boot. I wonder thought if this was just because that old release didn't process the checks performed on newer releases, easily bypassed now using the -F switch (assumption dismissed, see his post below).
Just to add that nobody confirmed what is causing the flash failure using serial console. My guess is firmware code check at stock bootup.