Looks like the recovery kernel has bad CRC checksum, so it does not load... 
So you have serial access to the device, and can see the CRC error when the recovery boots?
I think there is a script called ubootwrite which allows uploading mtd partitions even without tftp (or anything that would require ethernet). You can dump the linux4b partition (I think that's what it was called) from your other device if OpenWrt is running (the partition is called recovery and contains both the recovery kernel and rootfs). Flashing the kernel should be enough, if it's just about the crc error during boot.
When the recovery is fixed, you can use that to flash OpenWrt (which is a lot faster than flashing full openwrt image via uboot 
)
Thanks you for your help!
Actually i am waiting for a device to dump the mx25xx. I want to make a full backup of existing content from the IC, if something goes wrong. 
If i have a backup i will try the ubootwrite script…
Sounds great, especially with AC powered devices it's probably the safest and easiest way to access the flash directly rather than powering this thing from 12V (or even AC).
In that case you don't need ubootwrite anymore, just write the recovery partition (dumped from the other device via LuCI) to offset 0x50000 in the backup file and flash it back.
Thanks for this! I got it running (version B1, a EU plug) after a couple of tries. However, it gets pretty hot, and I think it smells a little funky now. Do your plugs give away a burnt smell as well? I didn't use the downclocked variants.
Also I have built a web UI running on the plug if someone's interested in that.
I have posted detailed instructions for what worked for me, together with instructions on how to give the plug a functional local web UI (with GETtable URLs), at my web page.
3 Likes
Thank you for helping prevent e-waste! 
@s_2 Is there an alternative location to get the firmware?
@mangrove your instructions are amazing and I can't wait to put them to use!
Has any progress ever been made on supporting the A1 variant?
I've got a stack of 9 of them that I would love to get working locally and would be happy to donate a couple to the cause if anyone needs them.
Can anything be done with the Dlink DSP-W110 units? Perhaps it would be easier to add something on a local PC and the router of the same network that would emulate the D-Link server and could be accessed as a web page to control the devices? i.e. Redirect the communication to a local PC rather than the DLink Home server?
I have a dozen of them that have become useless~
For other D-Link devices from the DCH and DSP series, I saw lots of people writing scripts to use HNAP to access these locally, after the D-Link Cloud was switched off.
For example there are several attempts of controlling DSP-W215 without the cloud:
https://github.com/search?q=DSP-W215%20HNAP&type=repositories
Maybe the protocols are similar enough so you could adapt something for the DSP-W110 as well?
So sad you didn't get the A1 image and it got so complicated in a short while, I was going to use this d link abandoned plug I hadn't touched in 10 years it to create a timed wake up light.
Here is what AI told me: The problem you're encountering with the A1 variant, where the WiFi SSID, PSK, and MAC are configured correctly but there's no connectivity and no network UCI entry for LAN (only loopback), suggests a configuration issue in the OpenWRT setup, particularly in relation to the network interfaces and possibly the firmware image creation process.
Addressing WiFi Connectivity Issue
- 02_network Configuration:
- For the A1 variant, you might need to manually add the LAN interface configuration in
/etc/board.d/02_network. This script is responsible for setting up network interfaces based on the device's specifics. Even if you didn't need to do this for the B1 variant, hardware differences between A1 and B1 could necessitate additional configuration steps for A1. - Typically, you would add a section in
02_networkfor your device model, specifying the LAN ports and, if applicable, the WAN port. This script ensures the UCI system configures the network interfaces correctly at boot.
- Comparing with B1 Variant:
- Revisit the configuration steps or scripts used for the B1 variant to identify any steps that might be implicitly necessary for A1 due to hardware or software differences. Sometimes, a step not required for one variant might be crucial for another.
Regarding the Firmware Image and Error Messages
- Firmware Image Creation Process:
- The manual process you described for creating the factory image, including stripping metadata, calculating the checksum, and adjusting header information, is a solid approach given the constraints. However, ensure that the checksum calculation and header adjustments are accurate. An incorrect checksum or header can lead to issues during firmware flashing or operation.
- Given the similarities between A1 and DIR-505 and the legacy methods used for DIR-505, your approach to manually compose the factory images seems appropriate. However, consider automating this process or validating it against known working examples to minimize errors.
- SIGSEGV Error:
- The
SIGSEGVerror message indicates a segmentation fault in the libc library, which could be related to incorrect memory access or corruption. This might not be directly related to the network configuration issue but could indicate a deeper problem with the firmware running on the device, possibly due to the manual firmware composition process or even hardware constraints/issues.
- The
Steps Forward
- Revise Network Configuration:
- Ensure that
02_networkcorrectly configures the LAN interface for the A1 variant. This might involve explicitly declaring the interface in the script.
- Validate Firmware Image Creation:
- Double-check the manual firmware image creation process, especially the checksum calculation and header adjustments, to ensure they're correctly applied.
- Memory and Firmware Stability:
- Investigate the segmentation fault error further to determine if it's a symptom of a broader issue, such as memory corruption or a problem with the firmware image.
- Documentation and Community Input:
- Publishing what you have (with a clear disclaimer about its current state) could invite input from others who own the A1 variant or have experience with similar issues. Community input can be invaluable in diagnosing and solving complex problems.
- Serial Access and Debugging:
- If possible, gain serial access to the device for real-time debugging. Logs and direct interaction can provide insights that are otherwise not apparent.
Given the complexities involved in porting and configuring firmware for specific hardware variants, especially in constrained environments, it's essential to proceed methodically, documenting each step and change to track what influences the outcomes.
Hi @GAMPR,
it's been more than a year since I last touched the revision A1 device, just dug it out on my desk to see what was the issue back then 
It seems I hadn't pushed my latest experimental state to github since I could not successfully build it with LuCI, so here's the last state from January 2023:
Maybe you can build it without adding any of the feeds (including LuCI, which did not successfully build against that old branch of OpenWrt back then). Rebasing to a more current OpenWrt is probably useless as well, since the image would grow even bigger, and flash space was already tight back then that a few unneeded partitions needed to be overwritten...
It's probably best to start the build with a fresh clone, since lots of build artifacts would be incomaptible to current branches, and it would take a few hours for rebuilding all the tools and toolchain etc., I don't have the time and (several gigabytes of) disk space on my machine at the moment (and probably there would be errors anyways)
This was based on the wireless-defaults branch from dangowrt, a PR that was never accepted to OpenWrt. But technically, the wifi setup could also be done manually using a script, I had done this for DAP-1320 (somewhere on my github), but here it probably makes no difference, since we need to stick with an outdated version of OpenWrt anyways.
Maybe one day someone comes along and will port ath79 to FreeRTOS or something, so that we would avoid the memory requirements of the modern Linux kernel The wifi driver is probably the hardest part, since it's written for use the Lniux wireless subsystem...
Hello, I'm trying to revive two W215 devices (one B1 and one B2). For B1 it worked flawlessly. Thank you for all efforts to make it even possible. However I faced a problem with B2. This one unit doesn't allow even to switch into factory restore to upload openwrt firmware. Have you heard about such situation? I tried all possible combination, holding reset, power button, WPS button and nothing. Red LED stays on and don't want to blink no matter what. Appreciate for any hints.
Does it show any other LED patterns than solid red at all times?
Maybe this is indeed a hardware issue, or the bootloader is corrupted or something; I can't remember if the images above would overwrite the recovery, (but iirc that was for other devices).
The next step would probably be to attach a TTL UART adapter to get a bootlog, though this is somewhat complicated on a wall-plug device (it should be powered from a dedicated 12V DC supply, rather than plugging the opened device into an outlet).
Yes it does. When plugged in, the LED is solid red, then turning to orange and flashing. After pressing WPS, it turns green and also flashing. I can find new network access point, broadcasting as DSP-W215-XXXX. When reset button is hold pressed while LED flashing green or orange, the device seems to reset as the color of LED change to red and after approx. 15 sec. start flashing orange.
Whenever I connect via wi-fi to plug, it asks for login and pwd. Admin and PIN code do the trick, however after login it only displays text about the plug version, model, ect. (basic info).
I already ordered TTL UART adapter (should arrive before 21 Nov) and try to connect to get the bootlog. However I will need to check where to connect with safe voltage and not operate under 230V.
1 Like
Hello,
I'm new to openwrt. And not so familiar with Linux. But I have a bricked DSP-W215 B1 which I cannot use, since with the original Firmware I cannot connect to Wifi with WPS to use it with HA.
@s_2: can you please provide the firmware to flash the switch? I do not have the needed tools and knowledge to build it myself. And the place You provided is no longer accessible.
Thanks a lot.
Hi,
so you want to use it with the D-Link firmware but it's not connecting via WPS, or use it with OpenWrt? When it's running stock firmware, do you see any network broadcast by the device? (I think it was DSP-W215 without the mac address suffix).
I found openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-factory.bin on my server (there is no https currently, so there might be a warning in your browser, the md5sum should be a67304394a830632162beaad3e6e17cd), which was also mentioned above, you could try to flash this one for Revision B via the recovery, i.e. keep the reset button pressed during plug-in. Do you still see the wifi network (DSP-W215-XXXX) being broadcast in reovery mode, X being the last two bytes of mac address?