Please don't. The wiki is not the place to share big files like firmware images.
Can you upload the images to a google drive or thelike?
Please don't. The wiki is not the place to share big files like firmware images.
It's a recovery image that will be used only for going back to stock firmware. Bandwidth utilization is going to be minimal since I doubt many people will need this at any time.
I don't think space is an issue either (I'm probably going to load only the sysupgrade image though, so it's going to be 6-ish MB, not 30MB).
Using an external site is bad for the same reason OpenWrt developers don't allow people to put links to docs and files in the commit messages. External links will go dead, you can't rely on them.
Besides, I'm not going to be maintaining a secondary account on Drive/Dropbox/whatever for a couple files that can be placed on the wiki server, that's silly imho.
If we start to get a lot of them in the wiki and the drive is filling up (I doubt it) or you see that they somehow attract too much traffic for the server (I also doubt it), then it can make sense to migrate them outside.
I'm not afraid of the occasional user downloading this file, but more of the bots that don't identify themselves as such and download everything they can get hold of.
OK then, I will try to keep an eye on how the downloads of this file evolve over time.
Quick update: I have to apologise to @NoTengoBattery for suggesting earlier today I had not not yet heard back from him.
It transpires I did receive a very detailed email which includes the 21MB sysupgrade image with full instructions, which I have yet to digest.
It looks like Yahoo is having problems today because this and a couple of other emails arriving in my Inbox this evening were delayed by over 12 hours.
Update 15 Aug 2019: I'm informed by @NoTengoBattery that he plans to upload his prebuilt sysupgrade to GitHub.
I have also been reviewing the instructions included with the prebuilt sysupgrade image, and to hopefully use it as a basis for writing a short guide to help newbies, and to also update the wiki for the ea6350v3 later. (Similar to PDF guides I have written for BT Home Hub 5A)
I am hoping to test the prebuilt image and linksys FW restoration procedure at the weekend if not sooner.
Sadly i don't have a switch to try though the router drops the Lan twice at boot so i'm not sure if it can be captured via Lan?
Thanks for making the image file but as Bill has heard from NoTengoBattery i'd like to wait to see on the full procedure so not to mess up.
Thanks for the update and working on a download and install guide.
Link to NoTengoBattery's Github page
Scroll through the page and locate this particular release which I can confirms is working.
Under 'Assets', download and extract contents of the highlighted tar.bz2 file to obtain the squashfs-sysupgrade.bin image:
Link to my PDF instructions based on above release using SFTP and USB.
NoTengoBattery's Github page no longer hosts the v0.1x sysupgrade images. If you cannot extract .tar.zst archive files of the latest v1.x images or wish to use the older images, then you can find zipped up copies of the original v0.11 and v0.14 sysupgrade images in my Dropbox folder. Look in 'Old NoTengo v0.1x builds' folder
OpenWrt wiki has been refreshed with shortened version of same instructions.
I had been using 19.07 r10269 snapshot for over a week. I installed 19.07 r10302 today using LuCI, and can confirm when I perform the 3x power On/Off reset sequence, I can toggle between both versions of 19.07, similar behaviour as reported by @zakporter.
I can confirm my EA6350v3 has been returned to running Linksys OEM firmware. I have written a PDF describing how to do it step by step using above NoTengoBattery's prebuilt sysupgrade image.
The script has proven to work out of the box and no extra configuration is needed when using my prebuilt. As for the origin of the script, it is inspired on the script found inside the original firmware, it’s not a surprise for me.
And instead of adapting the script it to the standard OpenWrt, is always better to modify OpenWrt to make the script work. It needs a custom configuration for Busybox, which forces people to build it’s own image.
As the whole purpose of my work is to make OpenWrt easier and more accesible, it makes the whole process as easy as installing, transferring and executing 2 commands (one of which is “sudo”), rather than cloning, configuring, building, uploading, testing and finding a random misconfiguration to repeat the whole process.
I said in the other thread that the script itself is a nice added value, but they just made fun of me. I don’t understand it but... hey, enjoy my work anyway.
fwiw, while I had stock Linksys firmware reinstalled on my ea6350v3, I thought I'd try to use a TFTP client to send OEM fw to the router at 192.168.1.1. No luck using Linksys windows tftp.exe, or with TFTPD64 client with ethernet switch in between laptop and router.
Thanks for confirming that Bill , I'd be interested to hear how anyone is supposed to do it via Lan without a serial connector but i can't find anything online.
Could openwrt be changing the boot sector in some way that stops TFTP capture?
U-Boot is untouched. On the similar EA8300, I was unable to find a way to trigger TFTP upload without serial access.
Thanks for confirming that Jeff.
@bill888 @NoTengoBattery Thankyou ever so much for your time spent on this as i'm now back on stock firmware on both partitions , NoTengos firmware works perfectly and Bills PDF is really easy to follow.
Cheers to everyone that contributed to this thread and i hope one day NoTengoBattery feels welcome here as his way doing things could help lots of other people on other Linksys models seeing as TFTP doesn't seem to work.
fwiw, when comparing the OEM bootlogs of EA8300 vs EA6350v3 posted in openwrt wiki, I have a suspicion the bootlog for the EA6350v3 may be incomplete (or invisible).
No mention of Uboot at all.
In ART, mac0=0xFFFFFFFFFFFF, mac1=0xFFFFFFFFFFFF, mac2=0x6038E08B6235, mac3=0x6038E08B6236 get_eth_mac_address@1407: the base hw_mac_addr='60:38:E0:8B:62:33' is valid! Using machid 0x8010100 from environment Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.14.43 (root@build-vm) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.01 r40864) ) #1 SMP PREEMPT Sat Jul 1 06:01:09 PDT 2017 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
(Above is copied from wiki for EA6350v3)
I may one day open up my EA6350v3 and hook up a serial console connection to confirm Uboot is the same as for EA8300, but not at this moment in time.
The U-Boot will be different as the EA6350 boots the kernel from NOR, as I recall, and the IPQ4109 in the EA8300 can boot directly from NAND.
For my information, did you have to use the 'Reset' button as described in the guide to clear settings, after first flash of the Linksys firmware to your EA6350v3 to be able to bring up the linksys web UI password box?
Yeah , i had a blank blue Linksys Web UI so i powered off and rebooted as per your PDF , when i retried it had hung again but while i was away from the PC trying to find something for the pinhole reset the login had appeared.
I logged into the web UI and done a software reset and when i rebooted i got the first time welcome screen asking you to agree with their terms.
I then done the standard factory firmware update and i then swapped to the other partition and done the same, i then swapped and done both again to be sure it was embedded correctly, no blank screens after that.
@NoTengoBattery out of interest does your firmware alter the boot sector at all and have you ever manged to get TFTP to work via Lan?
Sorry for late response...
TFTP will not work on LAN for me, and I would like to reverse engineer the firmware (just like I did with the script that is proven to work) to see if I can make it work, but I only have one device and I’m using it for production (it’s my NAS for Time Machine).
As for the procedure in both my script and it’s inspiration, the Linksys OEM update script, boot sector is not touched at all.
The only thing that is done is to enable the autorecovery feature (not needed in OpenWrt as it’s always enabled) and to switch the boot partition to the one which is not booted. It uses the default uboot-env-tools available in OpenWrt.
An extra step made by my script is wiping the “syscfg” partition, where the OEM firmware stores it’s settings. Nothing else is done.
But, as far as I understand (did not test), TFTP should be usable on LAN (Linksys even provided the tools). More research is needed, but as long as the device is not hard bricked, the BackToStock method should always work.
Any bug reports are welcome, but you should use the Issues feature on my repository on GitHub to grab my attention regarding to the prebuilt, the scripts and it’s documentation.