[Solved] D-Link DIR-860L - OpenWrt 19.07.4 - Routed AP inconsistencies

Hi,

on my D-Link DIR-860L, running:

# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.4'
DISTRIB_REVISION='r11208-ce6496d796'
DISTRIB_TARGET='ramips/mt7621'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 19.07.4 r11208-ce6496d796'
DISTRIB_TAINTS=''

I get DHCP errors on WiFi 5 Ghz in a Routed AP configuration.
Inspiration for the Routed AP:

I've been using the Routed AP scenario for a long time on OpenWrt 15.x & 18.x because I always considered WiFi as public network (protected only by the WPA/WPA2) and disabled the forward to my LAN. Actually I allow some access to the LAN with some particular iptables FORWARD rules.

On OpenWrt 19.07.4 during the initial setup I was using LuCI to define the WiFi2 and WiFi5 interfaces together with the associated Firewall zones. I must admit it was a little shocking that I had to define two WiFi interfaces & networks & zones.
While defining the interfaces, the WiFi devices (Wireless section) were not yet enabled and configured and I only could choose some radio0 and radio1 for the interfaces (Physical Settings).
After this step I went on and configured the wireless devices in the Wireless section and learned that the previously defined WiFi2 and WiFi5 interfaces were attached to wlan1 & wlan0 instead of radio1 & radio0.
After rebooting the router I always needed to stop and start the WiFi5 interface because I get an error in LuCI telling that the device is not present and I'm not able to receive DHCP addresses through it - I suppose the WiFi5 device (driver) needs a little more time to load.
Today, after having the router on for more than 24 hours and able to connect and use the WiFi5 for several times during this period (yesterday), I stumbled again upon the DHCP issue when trying to reconnect. By inspecting LuCI - Interfaces section I haven't seen any "device not present" error.
Here is the relevant snippet from logread:

Thu Oct 29 17:04:57 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Thu Oct 29 17:04:57 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Thu Oct 29 17:04:57 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Thu Oct 29 17:04:58 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Thu Oct 29 17:04:58 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Thu Oct 29 17:04:58 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:02 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:07 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:15 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:30 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:34 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Thu Oct 29 17:05:37 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Thu Oct 29 17:05:37 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Thu Oct 29 17:05:37 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Thu Oct 29 17:05:37 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Thu Oct 29 17:05:38 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:44 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:47 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:05:56 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:06:11 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:06:13 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Thu Oct 29 17:06:17 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Thu Oct 29 17:06:17 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Thu Oct 29 17:06:18 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Thu Oct 29 17:06:18 2020 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Thu Oct 29 17:06:18 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:06:23 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:06:27 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:06:36 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5
Thu Oct 29 17:06:53 2020 daemon.warn dnsmasq-dhcp[2640]: no address range available for DHCP request via br-WIFI5

I got rid of this issue after manually stopping and restarting the WiFi5 interface.

And here are some relevant sections from the config:

  • /etc/config/network
config interface 'WIFI2'
        option ifname 'wlan1'
        option proto 'static'
        option netmask '255.255.255.0'
        option delegate '0'
        option ipaddr '192.168.100.1'
        option type 'bridge'

config interface 'WIFI5'
        option proto 'static'
        option netmask '255.255.255.0'
        option delegate '0'
        option ipaddr '192.168.200.1'
        option type 'bridge'
  • /etc/config/dhcp
config dhcp 'WIFI2'
        option start '100'
        option leasetime '12h'
        option interface 'WIFI2'
        option limit '10'

config dhcp 'WIFI5'
        option start '100'
        option leasetime '12h'
        option interface 'WIFI5'
        option limit '10'
  • uci show wireless | grep device
wireless.radio0=wifi-device
wireless.default_radio0.device='radio0'
wireless.radio1=wifi-device
wireless.default_radio1.device='radio1'

I noticed that in /etc/config/network I don't have a "option ifname" for the WIFI5 interface and I believe that I should. Should I add it manually in /etc/config/network ?
At least in LuCi I can see the wlan0 device in the Interface details for WiFi5 and I don't know from where does LuCi take it.

I'm a little confused over this radio/wlan naming and not sure what caused the issues I'm experiencing now. Is LuCI faulty? Or was I supposed to define and configure the WiFi first and only after that define the Wifi2 & Wifi5 interfaces?

Thanks in advance for any useful inputs / clarifications.

In /etc/config/network I added manually option ifname 'wlan0' and saved the file:

config interface 'WIFI5'
        option ifname 'wlan0'
        option proto 'static'
        option netmask '255.255.255.0'
        option delegate '0'
        option ipaddr '192.168.200.1'
        option type 'bridge'

Was curious if LuCI will be happy with it and by opening the Interfaces page I saw all the interfaces having the mention - something like "marked for deletion". Nice!
On the console (dropbear) I issued: reboot
After the reboot the whole configuration was messed up and I had to reset the router and restore the backed up config.

I'm wondering now if I should continue with OpenWrt 19.07.4 or maybe it's better to use the older OpenWrt 18.06.8. I'm fine with the latter if it's still maintained for 1-2 years.

Loaded OpenWrt 18.06.8 and followed exactly the same steps in LuCI to define the Routed AP configuration. Noticed that in 18.06.8 LuCI doesn't enable by default the bonding option when defining interfaces and the resulting config was working straight away:

config interface 'WIFI5'
	option proto 'static'
	option delegate '0'
	option ipaddr '192.168.200.1'
	option netmask '255.255.255.0'
	option broadcast '192.168.200.255'

config interface 'WIFI2'
	option proto 'static'
	option delegate '0'
	option ipaddr '192.168.100.1'
	option netmask '255.255.255.0'
	option broadcast '192.168.100.255'

Loaded OpenWrt 19.07.4 back and disabled the bonding option for both interfaces in LuCI, got the same clean config as above, the line option ifname 'wlan1' vanished too form the WIFI2 section.

It looks like there's a glitch in LuCI's logic and that combined with my inexperience in configuring two networks 2 & 5 GHz in Routed AP mode, resulted the reported mess. Then, apparently there's some internal logic in LuCI to switch and assign the radio0/radi01 to wlan0/wlan1 without needing to define them in /etc/config/network (relevant WIFI* interfaces sections)

Besides, some other observations and issues (maybe I should open some other threads for these):

  • OpenWrt 18.06.8 gets me some 8-10Mbit/s more over PPPoE compared to OpenWrt 19.07.4
  • in both OpenWRT versions iptraf-ng is segfaulting after just a few seconds of usage:
Fri Oct 30 09:03:41 2020 kern.info kernel: [93990.423798] do_page_fault(): sending SIGSEGV to iptraf-ng for invalid read access from 00000000
Fri Oct 30 09:03:41 2020 kern.info kernel: [93990.441156] epc = 77f871ec in libc.so[77f1b000+98000]
Fri Oct 30 09:03:41 2020 kern.info kernel: [93990.451299] ra  = 77f88e44 in libc.so[77f1b000+98000]
  • in OpenWrt 19.07.4, by using the default LAN GW 192.168.1.200 I'm noticing traffic sent from 192.168.1.1 (already reported in another thread), like:
    IGMP (46 bytes) from 192.168.1.1 to 224.0.0.1 on eth0.2

Yet another Solved monologue, hope it wasn't boring :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.