so I cant get back to the stock gui again. I attempted to exploit the gui by logging in then within the management page assign the new name string and new pw in order to have it accepted, then login then switch it back to admin after logging in w/string then back. This seemed to not fit the instruction to 'immediately' switch it back', but seemed like the only way to have it be realized.
Still on OEM, but cannot reach the UI. I've reset in all ways besides 3/30's(recalling thats bad for Qcomm chips) Now at green light and both radios are broadcasting and functional but I cannot reach the gui at 192.168.0.254
The reason you need to re-submit the username/password form immediately, is because the exploit leaves you with an invalid user authentication file on the device. That means that if you log out, or restart, before using the user admin form to submit valid account credentials, you will be left with a device where you cannot log in any more. You'll have to start over again in that case, by performing a factory reset.
Thank you for your input, I see that now.. So, I installed the omada app for standalone EAPs on my phone and found it at a different IP, then I could connect right away. I could also see that 192..0.254 as the fallback IP can be toggled either static or dynamic. Guessing that was involved w/the different IP.
Heyy.. 34 years later Progresss... But, the 2nd md5 does not match.
Looking back, was I supposed to place the patch file somewhere, in order for it to be applied??
Sorry, I checked the instructions again and noticed that I forgot to mention that you need to copy the file after extracting from the device. I just added step 7 to the Wiki:
- Create a copy of the file so that the patch can be applied later:
cp uclited uclited-patched
The patch is very short and is contained in and applied to the copied file by doing
- Apply the binary patch to uclited:
echo "000d2354: 24020000 00000000" | xxd -r - uclited-patched
If you didn't copy the file beforehand (because this step was missing), the MD5 sums can't match.
1 Like
Mornin! No sweat and thanks for putting the commands together. tftp was as deep as I've gone to get openwrt going.. But, I <3 arts and crafts, and can cut and paste like I'm 8.
Just noticed, might your wiki section be for 225 v1 and v2? Installation using SSH (EAP225v1 only)
I'm not sure where to put the .bin 12.) 'upload the factory file' to tmp/upgrade.bin. Ive got it parked in the gui browse box .. not ready to risk that at this point
pokey1kenobi@pop-os:~$
ssh -o HostKeyAlgorithms=ssh-rsa -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@192.168.0.254 "dd of=/tmp/upgrade.bin" < openwrt-ath79-generic-tplink_eap225-v1-squashfs-factory.bin
bash: openwrt-ath79-generic-tplink_eap225-v1-squashfs-factory.bin: No such file or directory
It's already past lunchtime where I live 
According to @svanheule it also works for the v2, but since I wasn't sure I only added what I could test.
You need to put the downloaded OpenWrt image in the same folder as you run the SSH command from - and the name needs to match (openwrt-ath79-generic-tplink_eap225-v1-squashfs-factory.bin).
The only way to upload the .bin file is by using this ssh command. It won't be accepted by the GUI.
1 Like
AFAICT the v1 and v2 have identical firmware, so although I have not tested it, I expect it work on both.
on the last command to install I get
"chmod: cannot access '/tmp/uclited': No such file or directory
any ideas?
Make sure that you copied the file correctly back to the AP. The error message sounds like something went wrong there. ls -l /tmp should list uclited. If it doesn't, go back (to step 11 from the wiki), and try again, solving anything that went wrong, to get the patched uclited on your device.
After running chmod +x /tmp/uclited, you should get something like
# ls -l /tmp/uclited
-rwxr--r-- 2128691 Feb 9 08:24 uclited
Then it should be possible to run the modified binary by executing /tmp/uclited -u from any location (or ./uclited -u when running from /tmp).
reset and again? My permissions are rw--r--r on uclited
The permissions won't have the execute bit set by themselves, you need to run chmod to achieve this.
There are two options:
- Add the execute bit for the owner:
chmod +x /tmp/uclited - Set all permissions explicitly:
chmod 744 /tmp/uclited
Both options should result in rwxr--r-- permissions.
1 Like
Success, But after 'rebooting manually' as the instruction from shell was, I now get long periods of fast blinking LEDs that finally settle on green.
Ok, I was able ssh into the snapshot just now... how should I proceed, can I CLI my sys?
I can confirm EAP225 v1/v2 is operational Snapshot w/Luci added.
Although without Https.
Any advice for a workaround?
1 Like
Enabling HTTPS on LuCI is not specific to this device, so check #general or the OpenWrt wiki for info on how to do that.
1 Like
Sorry, I was under the impression that it was a known issue with snapshots, as I found the issue was 'open' after SSL failed to install on the unit.. Most configuration items are beyond my current level. And thank you for your tips along the way to get my 225 up.
github.com/openwrt/luci/issues/5610
EAP225 v2 with Snapshot had been sysupdated to, v19 perhaps?
I'm back after having had to temp give up due to no longer being able to access UI of the device. plugging in the dev blinks 1x for each R,Y,G color then green fast blinks, then medium blinks, then longer slow blinks and settles on green. It seems recognised by compuer with arp -a revealing: OpenWrt.lan (192.168.1.1) at 50:c7:bf:8b:2c:ea [ether] on enp3s0
but I'm unable to find it.
Is the fast blinking I see a TFTP recovery opportunity that got enabled by Openwrt when it was converted? If it is, I feel confident that I can recover with the newer FW availible now... *crosses fingers
Any help to revive the UI will be greatly appreciated.
Did you try SSH? A fast blinking LED might indicate that the device is in failsafe mode.