Did you use the web interface to upload the image? In my case it says firmware update failed.
I think I used the sysupgrade command via SSH. Do you already have OpenWrt installed on your device? Then flashing the sysupgrade via web interface should work. Otherwise use the factory image as described here: OpenWrt Support for D-Link DAP-X1860 - #49 by s_2
Currently the stock firmware is installed. I tried using factory image as described above, but it fails as soon as i click upload.
Which browser do you use? I had update problems with Firefox but it worked with Chrome. If the problem still exists, I’ll double check my uploaded files
Chrome. Will try others just in case and report back.
Edit: It is the same problem with Edge & Firefox.
Ok, I re-tried the files on my device, I can upload the factory image:
Upgrade process is started:
And finished successfully:
To be sure: You're using the factory image? Where exactly in the process does it fail?
I see where I have made the mistake. I thought reset button was to factory reset the repeater (maybe I held the button too long as I didn’t get into recovery mode). Anyways thanks for your time, now it works.
Steps:
- Download the openWRT image.
- Connect to the repeater with ethernet cable.
- Enter recovey mode. (Hold RESET button, before plugin in the repeater, until orange power light starts blinking)
- In Chrome open http://192.168.0.50
- Upload factory.bin
- Wait a couple of minutes.
- Note: I did not get update completed message, but when the orange light was on (not blinking) it was finished and I could acess LuCI on http://192.168.1.1
4 Likes
Might be relevant.
what is currently preventing a pull-request? More test results?
A patch was sent to the mailing list:
https://patchwork.ozlabs.org/project/openwrt/list/?series=332606
1 Like
If required, I provide new images for the DAP-X1860 time to time:
4 Likes
Thank you Rolando. I have not seen the patch from S_2 arrive in the OpenWRT repository or as Pull-request at GitHub yet, so thank you for keeping us updated.
It seems like there will be some changes to package and firmware dependencies for mt7615e and 7915e: mt76: refine package dependency for mt7615e and mt7915e. They have not yet taken the DAP-X1860 into account though.
1 Like
Hi all devs,
hope you guys doing well.
As a casual OpenWRT user i hope to get a little help on flashing this device as i really stuck rn. I tried to flash the fw but I always get stuck in recovery mode.
When I try to upload the OpenWrt images I always get something like:
"Size: 1259 Bytes" or "Size: 1301 Bytes", depending on which browser I use and on every upload the MD5 is different for the same file.
Only thing that shows correct size and MD5 information is when I upload a stock d-link FW .bin file
I get then:
Upgrade complete!
Rebooting ...
but also end in recovery mode again.
What I tried so far:
-
renaming the openwrt files (to factory.bin and to the name of a stock d-link fw file)
-
tried to reset the device by holding the reset button some seconds after power on
-
different OpenWRT factory and initramfs-kernel images linked in this Thread directly and newer files from RolandoMagico's Github
-
D-LINK support chat trying to get an unencrypted file or anything i could flash they send me an link to try but i think it is also encrypted and not meant for recovery use, however it leads me to the same result as the newer stock fw from the d-link support site I tried first. Finally the chat was out of informations and asked me to open a ticket for the experts to reach out to me, i agreed, i got now answer on the ticket after few minutes, they offer me a RMA. So no luck but was worth the try.
This was the link they sent me btw if it helps for anything: https://ftp.dlink.de/dir/dir-x1860/driver_software/DIR-X1860_fw_reva_103b07_ALL_multi_20200818.zip
(my bad i wrote them by mistake about DIR device not DAP, thats why i got a wrong link from them, however, the problem persists) -
i also tried different browsers(Opera, Firefox, Edge, Seamonkey, Chrome)
Btw i have two devices in the same state now, so its definitely not a hardware problem.
Oh and the devices were on the 1.0 FW they came with from factory as i started trying maybe this is important because of the recovery mode version is updated on newer stock fw versions idk.
One of the devices was in use already (linked wifi) the other one put directly to recovery mode
Maybe someone has a little hint for me on what I could try next or where could be a possible reason.
thanks in advance
Looks like Mediamarkt in Germany still wants to get rid of them. You can currently buy one for 30€. But if you buy two of them, there is a 30€ discount. So 30€ for both in the end with free shipping.
1 Like
Which firmware file do you use exactly? Do you have serial access to the devices? in the former mentioned pull request there is an instruction how to extract and download the stock image did you try that?
I flashed just now and came across the same problem. Used openwrt-ramips-mt7621-dlink_dap-x1860-a1-squashfs-factory.bin from https://github.com/RolandoMagico/openwrt/releases/tag/Build_2022-12-22, which i renamed to "factory.bin". Followed these instructions: OpenWrt Support for D-Link DAP-X1860 - #69 by dKoco, except that I first tried to use it with Firefox. When I did so, i encountered the 1259 Bytes problem (the file should be way bigger!). Then I tried the same with Microsoft Edge and it showed a file size that I deemed more accurate (but I did not crosscheck), so I flashed and it worked just like described in instructions. I am not completely sure if using Microsoft Edge fixed it, or if it was a timing issue.
1 Like
I used DAP-X1860_RevA_Firmware_101b94.bin, thanks for the help, i was now able to get back to stock using this technique described in the pull request you mentioned. I needed to flash it twice for some reason to work. For the OpenWRT, i tried your posted file from OpenWrt Support for D-Link DAP-X1860 - #62 by RolandoMagico and the last 2 releases from your github repo (2022-12-19 and 2022-12-22). Name: openwrt-ramips-mt7621-dlink_dap-x1860-a1-squashfs-factory.bin
I do have serial access but im not sure how to flash it using serial
I tried Edge again now a few times, didn't helped me on OpenWRT files but with the extracted stock fw file it worked to flash on Edge, but same <1301 Bytes problem on Firefox. So it seems to has something to do with browser. I tried another computer but that didn't help. Maybe its only a small thing that makes the difference which makes it work for you but not for me. For some reason different filename of the same file means also different byte size showed in Firefox,(but alway < 1301 Bytes), really strange behaviour of this WebGUI...
I use the same guide [#69 by dKoco] btw
I also noticed there is telnet access possible on stock firmware. I'm not familiar with telnet, only SSH so I dont know how to get any benefit of that (flash OpenWRT somehow maybe)
I don’t know if flashing via serial is possible in general, but can you provide the serial boot log after flashing openwrt fails?
I have never used telnet before, but are we not lucky to have access to knowledge from our ancestors?!
Found a couple other OpenWRT devices that use telnet as flash method. For example: How to flash via telnet for Netgear 6220. Maybe a similar method will work here as well?
There are a multitude of other flash methods one could try as well, of course not all may work.
Anyway, with great joy I can announce that Rolandos Image from 2022-12-22, works pretty well!
The best news first:
-
OpenWRT has higher range than stock firmware. Whereas with stock firmware I had a location in my house (behind two walls and far distance), where my phone constantly lost connection to the repeater (I assume it was because stock firmware automatically tries to switch between 2.4G and 5G, when low signal strength is detected), now with OpenWRT, there are no connection issues at all when I am with my phone in this specific location. I simply configured two separate wifi SSIDs (one for 2.4G(ax) and one for 5G(ax) and my phone only connects to one of them (roaming disabled). It is rock stable. I was able to switch from 144p to 720p youtube video quality
-
Low amount of laggs. I was playing computer games (Heroes of the Storm from Blizzard) yesterday for a few hours and had zero laggs. (At this specific location, I rarely had laggs with Stock firmware either, so actually no change here). Client is located behind two walls. It is the location from my iperf3 measurements down below.
The bad news:
- Speeds in certain distance ranges are lower than stock OEM (but for me that is ok, since I gain control over configuration, (hopefully) more stability, increased range and the potential for future improvements in OpenWRT)
Here a glimpse of my Iperf3 measurements:
Remarks about iperf3 measurements and experiences with varying number of client streams:
- Higher number of client streams seems to have low impact on maximum achieved bandwidth, (that is the achieved sum of adding all client streams bandwidth together)
- with 8 streams, OpenWRT performance with bidirectional tests is roughly comparable to stock OEM, but OpenWRT has LESS retries (In one of my tests, OpenWRT had 20-50, whereas Stock OEM had 800-1300). Though, Stock OEM performs a lot better in simple non bi-directional tcp tests, regardless of number of client streams.
- Many client streams lead to whacky performance (Similar on both stock OEM and OpenWRT), as a higher number of clients has a very strong impact on median speed and standard deviation. Speed per stream varies wildly. Speed per stream varies especially for RX-C. TX-C is more stable. Some streams can capture full speed, whereas the speed of other clients drops rapidly in comparison. There seems to be no bandwidth fairness or alternative system in place to keep these fluctuations in check.
1 Like