OK, had a chance to burn a few more sessions at the parents shop from my own job! Heres what I've learned that may help D-Link with these issues.
1) The error message in the log I reported earlier, "Invalid response packet from host <ip addr>", is only triggered by Windows 10 clients and my research indicates is due to a change Microsoft made in handling mDNS responses. You can google "Windows 10 avahi invalid response" for the details, but the net is embedded linux solutions that employ the avahi mDNS service will be affected by this Microsoft change. D-Link it would seem is using avahi and linux on the DAP-1665 and should apply the patch for this.
2) I could not get the "Error state of beamforming" unless there was an 802.11ac client connected. It is very intermittent, but I did find out the source code the error comes from and it appears only in a single section of the entire source tree, it is from the Realtek chipset C source code and from this snippet:
} else {
// Entry has been created. If entry is initialing or progressing then errors occur.
if (pBeamformEntry->beamforming_entry_state != BEAMFORMING_ENTRY_STATE_INITIALIZED &&
pBeamformEntry->beamforming_entry_state != BEAMFORMING_ENTRY_STATE_PROGRESSED) {
DBG_871X("Error State of Beamforming");
return _FALSE;
} else {
pBeamformEntry->beamforming_entry_state = BEAMFORMING_ENTRY_STATE_INITIALIZEING;
}
}
3) I found a stable non-rebooting configuration by introducing the DAP-1522 back into the environment. Using the DAP-1522 configured for 802.11n 2.4Ghz only, and the DAP-1665 configured for 802.11n 2.4Ghz only + Mixed 802.11n/802.11ac 5Ghz with all set to WPA2/AES only is now stable. The DAP-1665 is centrally located in the store, the DAP-1522 is placed towards the back of the store. The DAP-1665 has been configured with a user limit of 10, the DAP-1522 does not have this user limit feature (and apparently does not need it as I saw it handle 18 connections by itself with no stability issues). The DAP-1522 is running firmware 1.42 and the DAP-1665 is running 1.13.
So while this configuration "works", I find it unacceptable that a business class WAP cannot handle more than 10/11 devices in mixed 2.4/5Ghz bands simultaneously in a stable fashion. Having performance issues I could understand, but not rebooting/crashing. This seems like a firmware bug but you cannot capture what happened in enough detail to open a ticket as the syslog support has been removed from this models firmware UI and the local log information is thus lost.
4) Another new bug I've reproduced is with the logs screen of the firmware. Since I've been working with it so intimately
What the problem is as the log quickly grows (these Windows 10 caused invalid packets come in every few seconds) you regularly notice that the log pages are wrong. I can easily get situations like viewing "Page 4 of 2" or "Page 3 of 1" as I either click the refresh button or move between this screen and the "Wireless" or "Statistics" screens.
5) Btw, another bug is a translation bug. If you enter the wrong capcha you get this message "ERROR: The Graphical password is error", if you have the wrong password you get "ERROR: The password is error". Poor US English translation.