Unable to access UART in WAP300N

[dc101]

I wasn't able to get the multi-part zip to work, but I was able to check out the first 3MB.

It looks like the version of firmware on your flash matches FW_WAP300N_v1.0.03.001_20141222.bin, up until 0x344547 in the flash memory when everything in your flash dump is all 0xFF's. Not sure if that's an error in dumping the flash, or part of the problem.

[mrmuzzio]

Thank you for looking at the files !

Maybe you could try the link I posted... it will onlye last for a few days, but it has the whole file as a single ZIP, if you want to download it.

For the splited zip files you may need to remove the last ".zip" extension, and unzip with 7z.

Back to the firmware... I tryed the same comparison as you with the firmware "FW_WAP300N_v1.0.03.001_20141222.bin" and it matched 100% of the bytes, at least that part of the image is the same, and thats why I believe the problem may be at uboot or other part of the image.

I believe the difference you area seeying is related to the fact that the downloaded file is missing some bytes at the end.

I'm attaching my screen of the comparisson and a draft of my findings about the layout.

Thanks a loooooot !!!

[Monkeh]

I was able to check out the first 3MB.

up until 0x344547 in the flash memory when everything in your flash dump is all 0xFF's.

Ahem. Yes, you ran out of file.

a draft of my findings about the layout.

0x0 - 0x30000 is indeed uboot. 0x30000-0x40000 is some sort of simple config store, whether it holds default values or is updated in operation is hard to say. 0x40000 to 0x50000 contains factory cal for the radio - 0x4e000 is the ethernet MAC. The wifi MAC is at 0x48004. 0x4a0000 is likely a config store but I don't recognise the header. Blanking that would be an interesting experiment.

I'm wholly untalented in MIPS machine code so determining if u-boot is damaged is well beyond my pay grade - and, no offence, motivation for trying to recover such a badly abandoned piece of hardware.

[dc101]

It looks you like are correct, I expected a multi-part zip failure to just cause an abrupt end of file and not have it padded with 0xFF's, but perhaps that's an artifact of the way zip works?

I downloaded it from the other link you sent and it matches what you see, I will look closer at it tomorrow.

I believe the difference you area seeying is related to the fact that the downloaded file is missing some bytes at the end.

I'm attaching my screen of the comparisson and a draft of my findings about the layout.

Thanks a loooooot !!!

[mrmuzzio]

Hi ! Thanks a lot for your input, I can confirm that the posittion 4e000 is the mac address, as it matches the label on the case... The other mac address seems to be right also, but it's not printed on the label.

For addresses 0x40000 to 0x50000.. what you mean by radio cal? is callibration data ?

The data at 4a0000 also got my attention, I'll try to overwrite that with FF to see what happens and I'll let you know.

I know this old hardarware is not worth the effort but I'll give it a try...

Thanks again!

[dc101]

The data at 4a0000 also got my attention, I'll try to overwrite that with FF to see what happens and I'll let you know.

If there isn't code that is telling the processor to read instructions from that section of code, then there's no harm in leaving it there.

I looked at the u-boot code in a disassembler. It looks ok for the most part, although I was surprised to see it's little endian. Most MIPS processors are usually big endian, although there are a few notable exceptions like PIC and the (now defunct) MIPS Creator boards.

There were a few sections of the u-boot image that didn't look right though, it's hard to say without really looking into it if it's supposed to be data, or if it's actually garbage. I'm going to try and compile u-boot for an architecture that is hopefully close to the RT6856F processor and see what that looks like in the disassembler.

[dc101]

Well after a bit of searching I was able to find a Ralink fork of u-boot very close to what you dumped from your flash: https://github.com/swiftgeek/ralink-uboot

I'm not sure if this version is compatible with your board though, perhaps that is why your device is not working? It's for an RT6855A, not an RT6856. You would think it would be compatible, but perhaps something changed in the 56? After compiling the Ralink u-boot fork and learning of the base address, I was able to properly look at the file in IDA Pro and the image looks fine, everything looks intact and I didn't find any sections that were corrupt.

Do you have an oscilloscope or can you borrow one to check uart tx pin? It's possible the baud rate is different and it's only displaying one or two lines of text, which might be to quick for a meter to register any voltage. I saw a comment in u-boot that implied the default baud rate was 57600, have you tried that speed previously?

[mrmuzzio]

Hi! thanks a lot for your efforts!

I've made an adapter and solder it to the board so I could plug and unplug the flash chip easy.

Since the chip had the "v3" of the firmware, I tried flashing over the "v2" and "v4" and the same address ( 0x50000). The v2 behiaved the same as the v3, the same flashing pattern for the power led.

The v4 had more flashes, but after a few flashes, the ethernet led flashes for a split second and the pattern starts over.

I've tried the serial port again at 57600, no flow control with "putty" and also reversed the Tx and Rx pins just to be sure... tryed sending some keys like the enter key, but I had no output from the board.

I do have a "usbee AX pro" clone and I will plug it to try to capture data from the serial port and let you know. I'll try with this software: https://sigrok.org/wiki/PulseView

I will also make a video of the flashing leds to share and since the pattern changed, I'm thinking of connecting it again to a PC and use Wireshark to try to capture some packets....

Thanks again for your hard work with uboot! If that is ok... and changing the linux image firmware does not recover it... What else could be wrong? Some configuration that is not reset with a 30-30-30 reset ? ....

[dc101]

I will also make a video of the flashing leds to share and since the pattern changed, I'm thinking of connecting it again to a PC and use Wireshark to try to capture some packets....

Do you mean that the lights turn on and flash in different ways depending on which version of the firmware is written to 0x50000?

If that's the case, I would suspect u-boot is working.

The v4 had more flashes, but after a few flashes, the ethernet led flashes for a split second and the pattern starts over.
I will also make a video of the flashing leds to share and since the pattern changed, I'm thinking of connecting it again to a PC and use Wireshark to try to capture some packets....

Yes, that's an excellent idea. The ethernet port makes me wonder if u-boot is failing to load the image and then trying to load it via tftp.

This is from your u-boot:

bootcmd=tftp
bootdelay=5
baudrate=57600
ethaddr="00:AA:BB:CC:DD:10"
ipaddr=10.10.10.123
serverip=10.10.10.3

So if it is trying to load the image via tftp, you might see something coming from 10.10.10.123. Usually there is a user env that overrides the compiled defaults, but I haven't seen that in your flash dump

bootcmd=tftp

[dc101]

Thanks again for your hard work with uboot! If that is ok... and changing the linux image firmware does not recover it... What else could be wrong? Some configuration that is not reset with a 30-30-30 reset ? ....

If u-boot is actually loading the kernel and the device is still not working then I would say yes, most likely some sort of invalid configuration was set, or the drivers in that firmware version are buggy. When the device stopped working, how exactly did it happen? We're you upgrading the firmware, or just changed a setting in the menu?

On a related note, after looking closer at the Ralink APSoC SDK that LateLesley posted, it would seem that data you were mentioning at 0x4a0000 is most likely the compressed root filesystem. Although I haven't figured out how to decompress it yet.

[Monkeh]

That's too small to be the rootfs.

Considering the age of this device, the 'kernel' is way too huge to be just a kernel.

[mrmuzzio]

Thanks again !!!

My nephew tried to update the firmware, and after the update he lost access to the device... it seems he was updating from v2 to v3... from the files in his PC...

Looking at the memory layout you posted the config starts at 0x30000 but in my dump it starts at 0x32000... Maybe is out of place ?

I've tried the serial capture with no results other that my key presses (enter -> 0x0d) . At the start of the device it seems to send a "FE" packet. I'm attaching a zip file with the capture and some screenshots.

 Serial.zip

Also, I did some tests with my notebook and wireshark.

1st Test : no protocols configured, router sends some ipv6 "router solicitation" from the MAC address printed on the label of the device.

2nd Test : ipv4, ipv6 configured with dhcp, with pings being sent to the ipv6 address of the router, wich the router replied some times !!!

Wich is really wierd, its seems that only ipv6 is working on this device !

And I'm attaching another zip with wireshark data...

 Wireshark.zip

Finally, the video of the device leds with the v4 of the firmware... wich is the version I have now...

 video of leds.zip

I'm really confused with this device... no Uart, no Jtag working, no ipv4 and now onlye some ipv6 packets ...

Do you think there is anything else to try ? maybe moving the config block from 0x32000 to 0x3000 to match the layout from the SDK ?

Thanks a lot for your help !!!

[Monkeh]

Don't take the SDK as gospel, you have no idea what version this firmware was developed from or what changes were made to it.

[dc101]

I don't think ~4.5MB for a kernel is way too big, especially if initramfs included.

If you're seeing DHCP6 and can ping it, I would say it's at least getting u-boot. But that doesn't really solve the serial port issue.

If you were seeing your key presses in your serial log, then you were probing RX and not TX. You need to capture on pin 4 TX.

Without any console access it's hard to say what's happening. U-boot may be trying to load the Kernel from an incorrect address, or not even trying to load the Kernel, or the Kernel could be booting and then going into a panic for any number of reasons.

Curious to see what happens if you try setting your IP address to 10.10.10.3 and connect to the ethernet port on your device. Can you try that along with some wireshark captures?

It's possible the root filesystem was destroyed during the firmware update process. If the 3.5MB of flash space after the kernel really is supposed to be for the filesystem, then something is definitely not correct because there's only 11K of data in that entire area. Also, I would expect to see a signature for at least some form of compression, gzip, lzma, squashfs, but there's nothing there. Unfortunately the stock firmware updates only seem to include the kernel itself. I suppose the root filesystem could be stored someplace else, ie on a different flash device, but that's not very common.

I don't think the offset's are incorrect. Looking at the flash layout and comparing it to your flash dump it looks like a match. The problem I see is that you're missing u-boot parameters. 0x0 - 0x1000 should be uboot parameters, the environmental config I was talking about earlier. If these aren't present then uboot should fall back to whatever it was compiled with as far as I know. 0x1000-0x2000 is reserved, and 0x2000-0x6000 is the WLAN0 config, which looks like a match for what is in your flash dump.

The RF config looks like a match as well, however your flash dump seems to be missing RF 1 parameter, could that be part of the problem too? 

True, things might not match the SDK exactly. We are looking at the manual for 4.3.0.0 and the u-boot version from your flash dump is from 4.0.1.0 so there have most likely been changes, but so far things seem to mostly correlate to what is in the SDK user's manual. It is true though that we are ignorant of any changes that Linksys might have made (patches, mods etc...) to the SDK when the firmware was built.

[mrmuzzio]

Thanks for the info...

About that serial monitoring, I'm seeing the keypresses because I'm capturing both RX (row 2) and TX (row 3). The RX goes from 0 to 1 when I power on the board, and stays that way.

Looking at the settings at 0x32000, seaching for some ipv4/ipv6 config I've found at 0x33247 an attribute "um_kernel_md5" that pointed to the md5 of the old bin file for the kernel... I've updated with the md5 of the v4 wich is the last I flashed.... and IT WORKED !!!!!

Fixing that parameter, out of pure luck, made this crap work again !!! It started flashing the power led as usual, but... it turned on the wifi led, and stayed that way... I plugged the ethernet cable with dhcp, got an IP and the web portal was running at 10.100.1.1 !!!

Thanks a lot to everyone who helped to solve this, I've learned a lot, and I got this board running again !!!

Serial port and Jtag still not working... but... the rest seems to be OK !!!

[mrmuzzio]

I'm attaching the photos of the "UGLY flash adapter board" and how its fits in the case....

[mrmuzzio]

And here I'm attaching the full dump of my flash, with firmware v 04.

It's zipped with 7z, just remove the last ".zip" extension from each file.

Thanks again to everyone who helped solving this !!!

[dc101]

Awesome, that MD5 hash was a good find, nice job! 

You can see now as Monkeh mentioned, that not everything will match the SDK. There are still so many questions, like where is the uboot config? Where's the root filesystem? It doesn't check according to the SDK documentation, yet your device still works. This is what makes reverse engineering challenging, and why I like it so much. It's the ultimate puzzle.

[mrmuzzio]

Second part of the firmware...

[Monkeh]

I don't think ~4.5MB for a kernel is way too big, especially if initramfs included.

The initramfs is the rootfs, that's my point. Kernel alone would never be that big for a 2.6 series. Any additional filesystem would be an overlay (which this could be, although it seems rather small and the header means nothing to me) or a custom config store.

I am also concerned there appears to be no u-boot environment. It's possible the block was erased during upgrade and never rewritten due to a firmware bug or a power failure.

Pre-post edit: Nice catch, I hadn't thought to check that checksum. Ahh, Linksys, you so special.

[dc101]

These are cheap on eBay in the states ~$25 or so, so I placed an order for one.

Regarding the serial port, it's entirely possible Linksys just decided to compile uboot and the kernel without serial support?   That seems easier than spinning a new rev of the board with the uart lines disconnected/modified.

I will do some probing with my scope when the AP I ordered arrives.

[dc101]

I'm attaching the photos of the "UGLY flash adapter board" and how its fits in the case....

I hold on to a huge stash of old IDE cables for all my home stuff for this exact reason. If it's for work though, I use very small (30/32AWG) wire-wrap wire since they're paying for it

[mrmuzzio]

Yes !!! they are cheap and some time ago you could get a batch of 10 bricked devices for the same price. But, the shipping costs to my country are about 50-60 USD for one device....

I keep a bin of old IDE cables, pieces of CAT5 and some USB cables for this kind of ""quick prototyping"" ...  the are indeed really useful...

[mrmuzzio]

Just a tip... if you configure the operation mode to "Wireless Media Connector mode" the device will stop responding, even if you do first a "factory reset"

I've tried this with firmwares v4 and v6 and both have the same problem, the device will enter a boot-loop and will no start wifi....

Luckly I can take the flash chip out of the board and overwrite the settings at 0x32000 with the backup....

[dc101]

Just a tip... if you configure the operation mode to "Wireless Media Connector mode" the device will stop responding, even if you do first a "factory reset"

I've tried this with firmwares v4 and v6 and both have the same problem, the device will enter a boot-loop and will no start wifi....

Luckly I can take the flash chip out of the board and overwrite the settings at 0x32000 with the backup....

Do you know what the differences are? Can you post the config when it's in wireless media connector mode?

Luckily there are enough for sale in the US that most offer free shipping, so $25 total isn't a huge amount of money for a weekend of entertainment.