D-Link DIR-645 WiFi interface not maintaining connection

Hi all,

I recently flashed my D-Link DIR-645 (version A1) to this version of LEDE: lede-17.01 branch (git-17.152.82987-7f6fc16).

The wireless interface is effectively unusable. After router reboot, I can connect to the AP as normal, but within minutes (or sometimes longer) the network connection goes down entirely to the point where I cannot even access the router admin page. This is despite the fact that the wireless connection itself shows as remaining connected the entire time. Ethernet link remains and usable.

Here's my configuration:

  • OS X 10.12.6 and Windows 10 (separate laptops)
  • Thomson DCM-476 modem
  • D-Link DIR-645 (A1)
  • Configuration set to Access Point; 802.11n; IP addresses by DHCP
  • SQM is active, set to cake and piece_of_cake, respectively

Even more frustrating is that, despite the DIR-645 having a separate firmware restore capability, even when trying to flash the stock firmware via the emergency web interface, the 'reset' only resets the LEDE installation. In other words, I cannot seem to revert to stock firmware - which, at this point, I would very much like to do considering how unreliable the LEDE installation has been.

Any ideas?

Thank you

All - I've managed to reflash the stock firmware, and as such, I no longer need assistance on this particular issue.

While I was interested to try LEDE, it is nowhere near the level of "it just works" as Tomato was on my old WRT54GL. I will check back in a year or two in the hopes that the project will have had much more investment in user-friendliness by then.


This sounds like the exact same problem I had after installing openwrt (chaoscalmer) on my dir-645. It's unfortunate the problem still persists. Dlink have abandoned that router so it would be good to get some more mileage out of it with lede or a similar open-source firmware.

我在尝试编译新的固件 ,发现官方在选择交换芯片驱动有问题 , dir-645目前不在我身边, 还没确定, 但是我编译时发现默认配置驱动是有问题的, 应该是8367rb的驱动 ,但官方默认不是此驱动, 不知道是否和这个有关系;
其次想刷回dlink固件 需要改pc地址为10.10.10.x,uboot地址居然是10.10.10.123。。。让我不可思议,这是我通过ttl找到的
因为uboot不具有dhcp功能 所以不通过ttl方式没办法知道ip地址。。。好恶心。。。。
等我编译新固件来测试 看看能否改变wifi bug

I was trying to compile a new firmware and found that the official option in the exchange of chip-driven problems, dir-645 is not with me, not sure, but I found that the default configuration driver is a problem, it should be 8367rb driver, but The official default is not this driver, do not know whether it has a relationship with this;
Followed by brushing back dlink firmware need to change the pc address 10.10.10.x, uboot address is actually . . Made me incredible, this is what I found through ttl
Because uboot does not have the dhcp function so do not know ip address by ttl way. . . Disgusting. . . .
Wait for me to compile a new firmware to test to see if I can change wifi bug
PS:from China。。。。google translate:sweat_smile::sweat_smile::sweat_smile:

I installed LEDE 17.01.4 on my DIR-645 and use it as an access point with Guest Wifi.

I experience the problem that after som time (mostly not minutes, more hours) I get the following behaviour:

  1. With the native WLAN (on br-an), I cannot connect
  2. With the guest WLAN and its on DHCP service, I can connect but do not have internet access.

Did someone file a bug report yet?

@zhl416 If you need help testing the firmware let me know.

I created a bug report at

I have 3 of those and all work reliable, actually with 18.06.1, I never had any issues

That sounds interesting... In which configuration do you use the routers? Is it possible that you provide the config files?

We use it as an access point with additional isolated guest WLAN.

I did upgrade to 18.06.1 and got the wifi problem.

My DIR-645 acts as an AP without DHCP, as this is done by another device.
After a random period of time or after a big file download starts, the connected device looses its asigned IP Address, the wifi connection works but the IP obtained is 169.254.x.x. The only fix is to reboot the DIR-645, I did regular restarts every 4-6 hours with cron tasks as a simple fix, but it was annoying as the failure happens seemingly random.

So i *returned to 15.05.1 and behold... the problem is gone!

*Did it a bit unconventionally, but i wanted to see if it works:
I selected the old firmware in the webinterface and clicked on "Flash image", of course it didn't work and i went to the "debricking IP" without restarting after the flash attempt (no reset button was pressed), selected the old firmware again and minionvoice tadaaa we're back in business. :slight_smile:

sorry for the late reply, the first one is running as an LTE router with a ZTE Internet stick, the second one is behind a cable modem and the last one is the client of the second. There is no special configuration. The one behind the cable modem ran just fine for months and was mainly used by Wifi clients. The others are usually only used for hours. I don't know why I never ran into Wifi trouble?

No problem! I could establish a running router on another RJ45 connection with a different cable in our building. I did not test it properly, but I have the impression the the router with OpenWRT is quite picky with the selection of LAN cables...?