Many browsers have removed ftp support today, but the server is also reachable via https using the same domain / path, v2.24 is the latest version available there.
1 Like
I have the AR93xx device and is now collecting dust since dlink dropped support. Can you please help me with the openwrt image for this device? I tried uploading B1 image but it failed. Thanks in advance.
I would assume this is the US plug version, or was Revision A1 actually sold in Europe as well?
Checking the firmware on the US FTP (ftp://ftp2.dlink.com/PRODUCTS/DSP-W215/REVA, not reachable via http), it seems Revision A1 does neither use the mkdapimg2 nor mkdapimg header, the image looks more like:
uint32_t checksum;
uint32_t image_size;
uint32_t kernel_size;
char platform[20];
char version[44];
uint32_t header_size; // shifted left by 8 bit? (or inconsistent byte order)
uint32_t zero;
Has anyone seen other devices from D-Link sharing this format, or could identify this as one of the supported formats in the firmware-utils project?
But first of all, we would need a serial bootlog to figure out the mtd partition layout and build an initramfs image to be loaded via tftp.
Yes mine is US version. This has similar hardware I believe i,e. AR9322: https://openwrt.org/toh/d-link/dir-505
More info: https://www.youtube.com/watch?v=rjry28Ym7kI
Thanks, so this thing differs quite much from the B1 (at least with the European socket), and there is also not a full serial bootlog as well, since they need that interface to communicate with the PL83xx.
At least we know the firmware starts at 0x00040000, though that's probably not enough to dare flashing something without opening the device. Is there any kind of recovery system, like when you keep the reset button pressed during plug-in? But we'd still need to build the factory image, so tftp is probably better for a first attempt.
I ordered one of these from the US, though it might take a few weeks to arrive in Germany.
By the way, I like the comment at 36:12, who knew it would only be 8 years from introduction of these devices to trashing them...
1 Like
A little update on the A1 variant: My device has arrived, I was able to build a recovery-flashable image, the wifi is coming up with SSID, PSK and MAC as intended, but no connectivity. There is not even a network uci entry generated for lan, just loopback. Do I need to set something in 02_network? I can't recall doing this for the B1 variant, which had the wifi working as well.
The image format for A1 turns out to be identical to DIR-505, however that device only has sysupgrade images available, since it was merged from ar71xx.
Digging back to ar71xx, the DIR-505 was part of the legacy subtarget already, which seemed to have used a different way of declaring build recipes for factory images: https://github.com/openwrt/openwrt/blob/openwrt-18.06/target/linux/ar71xx/image/legacy.mk#L902
This refers to CameoAP121_8M which eventually uses the mkcameofw tool from firmware-utils (which is still present).
I have not yet attempted to recreate this pile of build recipes to reproduce the long forgotten image format in ath79, so I composed the factory images manually for now, i.e. use a sysupgrade, strip the metadata, calculate the checksum (which is literally just a sum):
def cameochk(image_data):
result = 0
for i in range(len(image_data)):
result += image_data[i]
return result & 0xFFFFFFFF
print(hex(cameochk(open(infile, 'rb').read())))
copy the header from the OEM image, fix the checksum (bytes 0-3) and the image size (bytes 4-7). The kernel size (bytes 8-11) should remain at 00100000 since that's the size of the kernel partition, however this does not make a difference, since the rootfs would be written directly after the kernel (the updater would think it is writing rootfs already when the data is still part of the kernel, but it won't complain and just write).
Also wondering what this means, and whether it might be related to the issue of no lan interface being created?
[ 7.450064] do_page_fault(): sending SIGSEGV to lock for invalid write access to 0000000c
[ 7.456806] epc = 77e2aa48 in libc.so[77dae000+a9000]
[ 7.461922] ra = 77e2a9cc in libc.so[77dae000+a9000]
And not the forget: due to the location of the recovery Linux partitions, space is even more constrained than with the B1 variant, I had to use mtd-concat to overwrite the mydlink and several log partitions, to have sufficient free erase blocks for overlay to work at all. However for initial factory flashing, only the 4.6 MiB of the main firmware partition can be used, so there will be no image with LuCI fitting in that partition.
Does anyone own the A1 version and is having serial access to it (can be powered from 12V)?
I could publish what I have already, but at the moment it's not of so much use for everyone else.
I used to be using HomeAssistant but the DSP-W215 was sending a lot of requests to the cloud. I just installed the openwrt so just thank you for the hard work!!
I wonder though if anyone has in the end made it work with the
echo "1" > /sys/class/gpio/gpio:ac_output_enable/value in HA(HomeAssistant).
I also do not know what to do with it now that it is an Access Point tbh lol (I know, it can do so much more, but I do not know what more I would be using).
If I make it a client, I lose access to the Luci. I am really newbie in Openwrt, I was used to tomato and ddwrt.
Edit: I guess as a WiFi extender on the 802.11n would be ok and make it a dumbAP?
At the moment this is just a Linux system with access to some GPIOs, there is by default no server running on it dedicated to switching those GPIOs remotely (although you could technically use ssh, not sure if this is available in HA 
)
I also thought about some project similar to Tasmota, that would be based on OpenWrt but deliver firmware images with some user applications for home automation pre-installed, not sure what would be the ideal protocol to use though?
Maybe MQTT is the way to go, there are OpenWrt packages for mosquitto-client, but I haven't set this up myself yet.
A new open standard endorsed by big tech would be matter, focusing on 802.15.4 but also everything that speaks IP. This could one day even work with products like smart speakers etc. without the need for an additional HA instance, but then again few OpenWrt enthusiasts would probably want a cloud-based comemrcial service.
Regarding losing access to LuCI: The device can be wireless AP and client at the same time, but that's probably a waste of energy, and pollutes air with further beacons. When joining your wifi network, just add the new interface to the br-lan bridge (not wan), then you should be able to access LuCI at the new IP assigned by your main router's DHCP.
For repeaters, there is also a wiki article on using relayd, but that seems complicated indeed...
1 Like
I will try at some point the ssh, it seems to be easier than thought 
Tasmota seems nice indeed. It seems that the Tasmota can communicate with HA through MQTT indeed.
However, having a non-ethernet router might be more powerful to some here (maybe for VPN servers?, DNS and adblocking features? idk)
I have not explored Thread/Matter so far, I do have Smartthings so I have an edge/border router/hub. I will see in the future. Maybe this does make sense, as it will give our switch a new life indeed with the previous functionality as it once had. Would be cool to have both thread functionalities and routers ones but the space left (a few hundred kB) seems rather limiting tbh.
Luci-wise: I will try again, I believe I might have made something wrong in the conf when I connected to the WiFi.
Edit: Following this guide in order to connect the DSP-W215 to the WiFi seems not to be working 
https://openwrt.org/docs/guide-user/network/wifi/connect_client_wifi
I am confused cause the channel is the 6th for me and here it says not to change it and the author of the page have the 1st one being picked for them (cause this was theirs, but mine does not pick the 6th chanell despite having picked the right ssid) And in the first page it creates a new network called wwan which later on we pick in the interface conf. Where do I get to pick the br-lan entry??
Edit#2: Not even editing it in the wireless overview works as it should... I knew I was newbie in Openwrt but the repartition of the tabs and stuff is a bit strange to me.
Edit #3: I went to Wireless Overview, Scanned, picked my SSID, create/assign firewall the lan entry and in the next page the network picked the newly created wwan with the adjusting the various stuff. That did the trick. Now onto finding if ssh works 
Seems that the echo commands do work perfectly fine through the ssh. The led light is not in sync, but this is for some other time @s_2 do you know the link to change the leds, perhaps? Edit#1: found it, see below if it is ok, please?
It is working as it should in HomeAssistant. You need to sudo -u homeassistant -H -s first (to become the user homeassistant), then source /srv/homeassistant/bin/activate (to get into the space) then cd .homeassistant and then you need to save the rsa into the environment so just run once the command
ssh root@192.168.xx.xx 'echo "1" > /sys/class/gpio/gpio:ac_output_enable/value' where 192.168.xx.xx is your own DSP-W215. Click on yes to save the rsa.
Then,
nano configuration.yaml and append the following
switch:
- platform: command_line
switches:
dlink_powerplug:
command_on: ssh root@192.168.xx.xx ' echo "1" > /sys/class/gpio/gpio:ac_output_enable/value && echo "255" > /sys/devices/platform/leds/leds/green:power/brightness'
command_off: ssh root@192.168.xx.xx ' echo "0" > /sys/class/gpio/gpio:ac_output_enable/value && echo "0" > /sys/devices/platform/leds/leds/green:power/brightness'
Then Control+X and save the new configuration file.
Go back to HomeAssistant -> Developer Tools -> YAML -> Check configuration and then Restart. It should then appear in your Overview and you can click accordingly
It is not awesome (it does not read its current state, HA only knows the last state it had given itself) but it is good for a start.
Edit: I wonder if it is ok to say echo "0" > /sys/devices/platform/leds/leds/green:power/brightness to show that it is off (it works btw). But is this the right way to turn off the led or a hacked approach?
Edit#2: Edited the file above to reflect it nonetheless. It seems to work ok.
Edit #3: I might look to see if we can check the value by read var1 < "/sys/class/gpio/gpio:ac_output_enable/value" and then echo $var1 back to HA.
For the leds, 255 would be the value written to brightness, or 0 for off. But since the ath79 GPIO driver does not support PWM natively, any value greater than 0 will turn the LED full on. Brightness (for LED) and value (for GPIO) can also be read back (e.g. using cat).
Just the toggle button on the device is not so easy to capture, I think this just needs to have a keycode, e.g. BTN_1 declared in the .dts, which can then be configured as a trigger. I should probably add that in the dts when making a new build 
I think LuCI binds to all interfaces, so it should work when connecting to a wifi without changing the config.
1 Like
Awesome, thanks, changing it to 255 then for the on state. Not sure how it would work with the toggle either in HA.I might have some time to play again in 2 weeks from now. At least, we all know now that the DSP-W215 is saved from going to the trash bin.
1 Like
Always great to see devices saved from the trash 
Same here 
Whenever you have the new upgrade file with the trigger button, please let us know
I have created the initial wiki page for the smart plug here.
Some aspects above are a bit too technical for me (it's been ages that I last dealt with electronics) and I am not sure if they should go to the wiki.
1 Like
Awesome, thanks! I always feel a little scared by the structure the wiki would impose on new pages by the template for new devices
I can build an image with the button trigger included when I'm back home, hopefully this will work (last time it didn't or the A1 revision, maybe my build tree is dirty and needs a full clean, which can take hours to rebuild...)
Also wondering what the ideal way of declaring ac_output_enable would be, since gpio-export is a deprecated way of setting non-LED GPIO within OpenWrt, but this is not upstream-compatible. Maybe it should eventually use the regulator-fixed driver with a voltage range set to 230 million microvolts But I don't see how the user could then change the on/off state via sysfs, even when the enable-gpio is declared in the dts.
1 Like
@nickolasemp after following your steps on W215 wikipage I can see the plug emitting an SSID but is has a password, any clue what's the password?
The PIN Code from the bottom label was too short for a password, so it is now SSID + Pin Code.
1 Like
It seems this branch will no longer build with latest LuCI (which is independently updated when running scripts/feeds update and install. The build breaks due to a mismatch in iwconfig constants, probably because I had built newer branches in the meantime.
Would be great if the PR this is based on (introduce dynamic wireless defaults) would make some progress, not sure if I can just rebase the whole thing including the changes from that PR to master Probably the kernel would grow too big anyways 
Maybe this was also why my build for A1 did not work. So, no idea how to rebuild this with just the linux,code = <BTN_0>; trigger added for the ac toggle switch, maybe I can try to manually checkout an older LuCI version or something. Or manually switch back to a script-based approach, as done earlier e.g. for DAP-1320.
Have you tried with a previous LuCI? Don't know how easy it would be though.
Hi!
I have 2 pieces of dsp-w215 smart plug.
The first one flashed to openwrt via recovery without any problem. Working fine…
The second unit driving me crazy. I cannot boot it to recovery. Is it possible that dlink closed the recovery method?
Any help from the masters?
Thx