Thx! Wish me luck! 
It was successful! Thx!
But now I have another question)
I'm tried to setup wireguard according to this manual:
But when I want to install those packages, I'm getting this:
The installed version of package kernel is not compatible, require 5.10.161-1-3134fc05… while 5.10.161-1-c0b9a083… is installed.
I'm installed the latest build from github, how can I update that kernel package without messing everything up?
Sorry for dumb questions, I'm very new in this.
The problem is described here: https://openwrt.org/faq/cannot_satisfy_dependencies
As my images are self-compiled, it looks like there is no possibility to solve this without building a new image which contains wireguard.
Update: I built the last image again with wireguard support:
Link: https://github.com/RolandoMagico/openwrt/releases/tag/Build_2022-12-30_wireguard
1 Like
Thx! Now I see it in my settings, but whole OpenWRT thing is much more complicated than I expected...
I should start with basic settings, because I can't even setup Internet to work.
I have a modem from my provider with working Internet and want to create wireless network with VPN connection on AX1800.
At first I'm connected AX1800 via LAN to my laptop, to configure it and created WLAN connection on AX1800.
Then I'm connected AX1800 to my modem via LAN and connected my laptop to that WLAN.
But I have connection only with AX1800 without internet.
Some vendors use basic gzip metadata (original filename and timestamp)
to verify valid images, along with the size of it's contents.Also, add a new device profile variable FACTORY_IMG_NAME
which would be ideal to use with this new recipe.
Maybe relevant for the "browser does not detect correct size of image problem"?
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fc9dd3f0834317ceb20700fd7033987695661097
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3410f010a20a60e9fc47a280fdfdc2dc8fa0e447
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9a07895729a9701a673951a31ceb71f16f0a6fad
were just merged. Since the patch has not been accepted to OpenWRT yet and these commits do not account for the D-Link DAP-X1860, the patch that was sent probably needs to be adjusted to account for new firmware package names. To be honest, what's up with the patch that was sent? Has there been any feedback?
Looks like DAP-X1860 was merged here: https://github.com/openwrt/openwrt/commit/3c31f6b521bb5fc49e222a8f2bcd454b73452a0e
Update: I built a new image with the applied patch. The kernel partition size was changed from 4096k to 8192k, so sysupgrade doesn't work. Flashing the factory image via recovery web interface is working.
Image: https://github.com/RolandoMagico/openwrt/releases/tag/Build_2023-01-07
3 Likes
After sysupgrade, the LAN port has only a speed of 100MBit here. After power off/on, link speed switches to 1GBit again. Does anybody face the same issue?
So this was not after flashing via Recovery (with LAN port initialized by bootloader), but sysupgrade?
Curious, I have not seen this, however most of the time I connect via a 10/100 USB Adapter anyways, Gigabit was just tested with a switch once, in general this is not so much if an issue with Mediatek as with ath79 and external PHYs...
Indeed, it was suggested to increase KERNEL_SIZE to 8MiB, so the final images are not compatible, you need to re-flash the new image via recovery.
Snapshots should appear tonight 
@SPI-Flasher I tried to see what happens when writing initramfs to the flash, and it turns out the bootloader would just complain it can't find an image header at either of the two partition offsets, i.e. the image without elx is apparently not correctly written, so I was looking to build an image with elx-header appended, but could not exactly find what to append that to, i.e. what would be the (undeclared for this device) actual build recipe used for initramfs in the first place...
Then came the merge discussion, so I prioritized that, also changing the kernel format from uImage to FIT, so now it's finally time to continue trying to build a flashable initramfs
Can sysupgrade be used after having re-flashed the new image via recovery?
Sure, the (new format) sysupgrade was tested successfully for being flashed from the (new) factory, also the initramfs was tested, but only when booting via tftp (serial console required). I'm currently trying to build an initramfs image for flashing as well.
1 Like
Thanks for the fast reply! Also, thank you both a lot for the work and committment you put into supporting the D-Link DAP-x1860! I think this had to be said, now that it actually has been merged into the official OpenWRT.
I am so glad and happy about having the option to run OpenWRT. I don't have to fumble anymore to find this certain "sweet spot" in the corner of my room when I try to use my wifi clients and I got rid of a whole lot of disconnections that were caused by the OEM software. Except for the one disconnect i reported above, I have not encountered anything like it since then. With the version from 2022-12-27 and setup as repeater via relayd, so far, it's running very stable. Restarted the repeater only once manually by accident. Of course, I cannot say how the device will behave in the long run.
1 Like
@SPI-Flasher: Could you try to flash this via recovery and see if it boots? You should see LuCI at 192.168.1.1, telling you the initramfs would not save any changes etc.
openwrt-ramips-mt7621-dlink_dap-x1860-a1-initramfs-kernel-nandflash.bin
From this you should be able to sysupgrade to an image with the new format (either official snapshot, which does not contain LuCI, or the images from @RolandoMagico in post #107).
// edit: ok I just saw there is only factory.bin there 
I just copied the kernel recipe, appended elx and declared that as initramfs:
KERNEL_INITRAMFS := kernel-bin | relocate-kernel 0x80001000 | lzma | \
fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb | \
elx-header 011b0060 8844A2D168B45A2D
Yes, it was the last two times a did a sysupgrade. I did some ipef3 measurements after the update and the speed was always limited to about 100MBit. Also saw in my router that there is a 100MBit link. But I didn't check the link speed in OpenWrt.
Now I tried to reproduce the issue but it's working now. Not sure what went wrong during the previous updates.
If anyone is still interested, the device is currently available for € 17,- at MediaMarkt and Saturn in Germany.
1 Like
Uptime for ~ 10 days with RolandoMagico release from 2023-01-07 configured as repeater with relayd: Not a single disconnect, even though there are 3 walls in the way. RAM usage remains stable as well. Running great 
2 Likes
Hi, i've installed Build_2022-12-22 and everything works as expected, thx for that. After i've changed the IP for the LAN-Port to DHCP i can't get access to the LuCI. Any ideas to revert it back? I've tried to get into Recoverymode but still no Access to the Webinterface 
Edit:
Nevermind, got it working again.. have to manually set IP to: 192.168.0.2 after that i get access to the Recovery interface
btw. Thanks for your great work!
powercycle + press button for reset, then reflash the image following the usual instructions:
- OpenWrt Support for D-Link DAP-X1860 - #69 by dKoco
- OpenWrt Support for D-Link DAP-X1860 - #78 by ThiloteE
- OpenWrt Support for D-Link DAP-X1860 - #107 by RolandoMagico
If you don't want to do a hard reset, you could
A) check your main router, if the repeater is connected, check the given IP adress and then try to access LuCI at the given IP adress. This only works, if you have configured the repeater accordingly.
B) try to access without LuCI. In this case, please send us the output of /etc/config/network and /etc/config/wireless/.
Edit: To prevent further lockouts, follow guidelines. The docs for Wi-Fi extender / repeater / bridge configuration are up to date and work great: https://openwrt.org/docs/guide-user/network/wifi/relay_configuration
2 Likes
Usually the OpenWrt recovery mode should work, press reset during the fast-flashing period of the orange LED, it should then start flashign even faster and you end up in recovery mode with default settings (192.168.1.1. DHCP enabled).
1 Like
