TP-Link RE450 v2 (6MB) as WPA?-Enterprise AP

Maybe easier to read the same post on the forum

You have to interrupt the boot process by hitting a key, and then enter a few commands. Per above post:

> setenv ipaddr 192.168.1.1
> setenv serverip 192.168.1.3
> ping ${serverip}
> tftp 0x80060000 re450bs.bin&&erase 0x9f020000 +$filesize&&cp.b $fileaddr 0x9f020000 $filesize
> boot

I would definitely say so. All hope is not lost until serial console have failed :slight_smile:

(And even then hope is not lost.. you can buy a ch341a for 5€ and have another shot at it, just clip it on and re-flash firmware while the router is turned off.)

Have a good night's sleep!

1 Like

oh, sorry, should have scrolled down the boot logs.
They both end at a ogin prompt.
So is it that I only get skd of a "live system" in memory as a stepstone to reflash?
Still thinking in concepts of x86 ... sorry ....

Yes according to wiki, the router boots into modified vendor firmware.

From there I imagine you can just flash an openwrt-blah-factory.img via the web ui.

You know what would be a "fun" excercise?

The console output is always 7-bit right..

So if someone designed a tiny PCB with a CPLD or an ATtiny ARM processor or whatever on it and a few megabytes of flash memory.

Program the CPLD / ARM with some hare-brained protocol that only listens for and sends characters with bit #8 set high, and uses the remaining 7 bits for a minimal protocol that can exchange a couple opcodes like "read block" and "write block" over a 115200 8n1 serial console.

Connect it to GND+VCC+RX+TX on these tiny routers.

And write a small kernel module to reach the superfluous flash through this protocol over the serial connection.

Could even put an extra serial header on top of the tiny PCB where it just shuffles any characters that are 7-bit only, so you would still have console access.

Mathing a bit here, 7*8 = 56, so 7 bytes of data will fit into 8 console characters (with bit #8 / high bit always set). Let's make the blocksize some multiple of that to make it easy. Maybe 10x it, so a block is 560 characters = 490 bytes.

Add an extra 14 bits of CRC (safety first!), 7 bits of opcode and maybe 42 bits of address field to select the block to read or write (gives about 2000TB addressable? should be enough) and off we go.

TX: [OpCode=0x1(read)    | Address=yyyyyy | FrameCRC=xx]
RX: [OpCode=0x2(read-ok) | Address=(same) | DATA*560 | FrameCRC=xx]

TX: [OpCode=0x3(write)   | Address=yyyyyy | DATA*560 | FrameCRC=xx]
RX: [OpCode=0x4(write-ok)| Address=(same) | FrameCRC=xx]

TX: [OpCode=0x5(size)    | FrameCRC=xx]
RX: [OpCode=0x6(size-ok) | BlockCount=yyyyyy | FrameCRC=xx]

(Any console stuff being multiplexed into the frames would be 7 bits and just get ignored. And if something does go wrong, just wait a bit for the serial line to go quiet and try the command again...)

Perhaps also needs a one-liner patch to the linux tty driver to drop any characters with high bit set, so the kernel does not try and interpret data from the tiny flash pcb as console commands.

(And maybe use an SD card slot instead of a small flash chip if that is cheaper.)

Plug this imaginary device in the console port and Bob's your uncle! much extra flash memory

... :upside_down_face:

For a more practical approach, check the "OpenWrt One" for an examples of a very-hard-to-brick device, with multiple layers of different recovery options, down to reload everything via serial using SOC-internal features.

ah - coming from here

now I was just looking for IP and filename in this bootlog

https://openwrt.org/toh/tp-link/re450#debricking

But instead I found these stanzas:

scorpion> setenv ipaddr 192.168.1.1
scorpion> setenv serverip 192.168.1.3
scorpion> ping ${serverip}
scorpion> tftp 0x80060000 re450bs.bin&&erase 0x9f020000 +$filesize&&cp.b $fileaddr 0x9f020000 $filesize
scorpion> boot

Educated guess tells that this looks like console input.
This matches the lack of broadcast messages on tcpdump.
So no hope without soldering, right?

If you see zero broadcast messages then it is probably stuck somewhere after u-boot.

Yep I think you need a console cable on it.

Toying seems attractive, but I have to take care of my time.
Think when I need more AP, I'll just get more of those DAP-X1860 I know how to handle.

Is there any advatage on the RE450 with it's fancy antenna tree, at all?

Anybody interested in buying my two RE450?

One in a bricked stage, wating for the solder iron, as written.
the other one in operable condition, with OpenWrt 21.02.6, r16842-bc99ce5b22 on it.
Close to brand new, genuine package available, just opened 3 days ago.

It's very nice, but the idea was to rescue all the old hardware :slight_smile:

good call

soldering off a few SMD components and adding the console header is a learning experience so that's nice - but then there are many other things one could spend time learning out there.

(it doesn't take too long once you have the right equipment, by the way...)

Heh, maybe we should have a Trade / Sell / Buy category in the forum

Quite new here, haven't even looked for such a thing.
Don't they / we have a privat message option?

In this particular case I'd consier it quite reasonable to post this offer here.
No DAU user want's to buy bricked AP / extender, but for sbd trained in debricking, this might be a real bargain.

to be honest: I know the equipment is buried somewhere in a pile of moving boxes...

:grinning:Why on earth would you do that?

I believe if you got hold of a V3 uboot, then you can backup the neccesary partitions on the V2, replace uboot on the V2 with the V3 uboot, flash image for V3, then restore the neccesary partitions.

But just flashing over some modified V1-image without even wireless functioning (which makes for a really sad AP), that was never going to work.

btw a superminimal 23.05.5 image with only these components selected
wpad-mbedtls
luci-app-snmpd
luci-app-statistics
luci-app-lldp

Even when built from source with ALL space saving tricks, will NOT fit within 5697kb.