Adding support for EAP235-WALL

I don't see a serial port on the outside, so this must be on the board itself. I guess I can do that, but I was hoping I wouldn't have to.

How did you flash yours? What version did you flash from?

I worked on this port a few months ago, so before the v3 firmware was released. Currently I don't have the hardware any more, so I also can't try flashing from that version.

To access the serial port, you have to open the device (and solder in a header). IIRC you don't need to bridge any missing SMD resistors as with other TP-Link devices, but it's been a while since I looked at this AP.

If you're not in a hurry, you could also wait a few days and see if I can figure it out from the disassembled binary, without the associated console output.

2 posts were split to a new topic: EAP235-WALL v1.6 port mapping

I can wait for you to do that, as I have no clue how to solder and that seems overkill be able able to flash openwrt.

So I was looking at the relevant binaries, but I decided it would be really convenient to have a console log after all. Soldering is a useful skill in any case :slight_smile:

The error message generated by the web interface is mapped from an error code returned by the binary performing the upgrade. But I don't know which, and currently I don't have much time to hunt it down. :confused:

1 Like

I dug a bit more, and found the likely cause of this issue: starting from FW v3, downgrades are disallowed. Since OpenWrt carries version number "0.0.0", the firmware considers this a downgrade and refuses the file.

[NM_Error](nm_fwup_verifyFwupFile) 02278: EAP235/230-Wall forbid fw reverted from 3.x.x to lower version!

As a quick fix, you could patch the "soft-version" partition of a TP-Link image into an OpenWrt factory image.

  1. Download my safeloader patching script
  2. Download a v3 (or later, must be different from the current firmware version) firmware, and the OpenWrt factory image (e.g. for 21.02-rc4)
  3. Run the patch script (change file names accordingly): python patch.py -f OPENWRT_FACTORY.bin -i EAP235-WALLv1_3.0.0.bin -p soft-version -o FACTORY_PATCHED.bin
  4. Flash the patched factory image

Please let me know the results, then I can come up with a proper solution for OpenWrt.

Edit: People building their own firmware can also test patches

1 Like

Thanks, I will try this Monday when I have the device back with me. Do I still need to ssh and run the

  • run cliclientd stopcs, this should return "success" ?

The firmware patching changes nothing about the flashing procedure, so you still need to perform the other steps.

Edit: I realised patching the soft-version partition from TP-Link's image won't work. The FW version would be identical, which will also cause the upgrade to fail. I've built an image including my version-override patch, which you should be able to install.

1 Like

You are awesome. I was about to ask if upgrading to the same version would cause conflict, but you beat me to it. I will try to flash tomorrow.

So I finally had a change to test this. It did accept the file, upgrade status bar when to 100 percent, but the device didn't come back up from what I can tell. Its not getting an IP address (as it was before on TP-Link firmware). I am doing this remotely, so I wasn't able to just plugin to see if maybe its handing out leases on the LAN side.

Have any idea the default config on your image?

I actually think it worked as I see a 192.168.1.1 for the IP now for that MAC. Guess the WAN ethernet port in your config is different. Do you know which ethernet port is labeled what?

1 Like

This image should be using all the OpenWrt defaults (i.e. DHCP sever at 192.168.1.1), with all ports configured as LAN ports. You should be able to SSH into the device to configure wireless, etc.

So does this default image have luci enabled? Are you saying all ports are considered lan ports, and none of the ethernet ports are wan ports?

I plugged into the device, and to my surprise I didn't get a DCHP lease.

No, LuCI wasn't included in this build. And yes, all ports should indeed be part of the lan bridge interface.

Can you ping the device at 192.168.1.1? Even if you don't get a DHCP lease, you could set a static address on your machine to connect to the AP.

Ah now that I know all ports, including the one in the back, are set to lan this makes more sense. I should be able to get into it tomorrow by statically assigning it.

Once I get in, how would I then upgrade to a version that had luci installed?

This should be useful to read: https://openwrt.org/docs/guide-user/installation/sysupgrade.cli This is more of a generic question though, not really related to the EAP235-Wall port specifically. So, best to start a new topic if you need more help with that.

1 Like

What does cliclientd stopcs do exactly?

These devices (and others in TP-Link's EAP series) normally perform a signature check on firmware images. However, the binary that performs the upgrade, has some override built in, that allows one to disable the check. Likely for development, where the people at TP-Link don't want to sign every test image with the (one and only) release key.

I don't remember the details, but by running cliclientd stopcs, you instruct a userspace utility (cliclientd) to send a message (stopcs) to a process running as root, which then disables the signature checks. This feature is undocumented, but luckily for us they didn't remove it from their official firmwares.

Since we don't have access to the signing key, we can only build unsigned OpenWrt images. The images still need to have the same length, as if a signature was present, but this value is then no longer checked. So in the case of OpenWrt, it is just padded with zeros.

I have confirmed that this did indeed work. Once this was installed, I could upgrade via the CLI just fine as well.

Will a patch be added to the official openWRT images so future people trying to upgrade from version 3 on of TP-Link code will be able to upgrade?

1 Like

I've submitted the required patches, but they still need to be merged. Then at least people will be able to install snapshot images built from the latest master.

For the 21.02 release, I'm not sure if this will still be able to make it in, since there are some formal issues I need to resolve about backporting the changes. However, people could install a snapshot image, and then install a 21.02 release from there.