The Flint 4 is running firmware v4.9.1.
The ELAN Connect+ works correctly when connected to a Google Pixel Wi-Fi hotspot, but will not establish a usable network connection through the Flint 4.
The Flint's 2.4 GHz network has been configured as follows:
-
SSID: BTWholeHome-VT7
-
2.4 GHz only
-
Channel: 11
-
Channel width: 20 MHz
-
Security: WPA2-PSK
-
Encryption: AES/CCMP
-
Client/AP isolation: Disabled
-
MAC randomisation/BSSID randomisation: Disabled
-
DHCP subnet: 192.168.10.0/24
-
Gateway: 192.168.10.1
-
ELAN MAC address: 30:58:90:4B:F9:72
The router's runtime interface confirms:
Interface ra3
addr 98:83:c4:ea:c5:51
ssid BTWholeHome-VT7
type AP
channel 11 (2462 MHz), width: 20 MHz
txpower 27.00 dBm
The UCI configuration for this SSID shows:
wireless.iot2g.device='MT7990_1_1'
wireless.iot2g.network='iot'
wireless.iot2g.mode='ap'
wireless.iot2g.ifname='ra3'
wireless.iot2g.ssid='BTWholeHome-VT7'
wireless.iot2g.wds='1'
wireless.iot2g.isolate='0'
wireless.iot2g.encryption='psk2+ccmp'
There is no explicit ieee80211w setting on iot2g.
Connection log
A live logread capture during an ELAN connection attempt shows that Wi-Fi association and the WPA2 handshake complete successfully:
received auth req from 30:58:90:4b:f9:72
send auth resp to 30:58:90:4b:f9:72 (status=0)
received assoc req ... SA=30:58:90:4b:f9:72
send assoc resp ... (status=0)
hostapd: ra3: STA 30:58:90:4b:f9:72 IEEE 802.11: associated
dnsmasq-dhcp: DHCPDISCOVER(br-iot) 30:58:90:4b:f9:72
dnsmasq-dhcp: DHCPOFFER(br-iot) 192.168.10.171 30:58:90:4b:f9:72
hostapd: ra3: STA 30:58:90:4b:f9:72 WPA: pairwise key handshake completed (RSN)
dnsmasq-dhcp: DHCPREQUEST(br-iot) 192.168.10.171 30:58:90:4b:f9:72
dnsmasq-dhcp: DHCPACK(br-iot) 192.168.10.171 30:58:90:4b:f9:72 Elan Connect+
However, immediately afterwards the ELAN declines the address:
dnsmasq-dhcp: DHCPDECLINE(br-iot) 192.168.10.171 30:58:90:4b:f9:72
The Flint subsequently offers another address:
DHCPOFFER 192.168.10.172
DHCPREQUEST 192.168.10.172
DHCPACK 192.168.10.172
and the ELAN again sends:
DHCPDECLINE(br-iot) 192.168.10.172 30:58:90:4b:f9:72
Neither address appears to be occupied by another client. ip neigh show dev br-iot reports both as FAILED rather than showing another MAC address.
I also tested the ELAN using a static IPv4 configuration to eliminate DHCP:
IP: 192.168.10.50
Subnet: 255.255.255.0
Gateway: 192.168.10.1
DNS: 1.1.1.1
192.168.10.50 is outside the DHCP pool and was verified unused before the test.
With this configuration the ELAN initially reports Connected, but changes to Network Error after several seconds.
During this period, the Flint cannot ping the ELAN:
--- 192.168.10.50 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
Therefore, this does not appear to be simply a DHCP-server problem. Association and WPA2 authentication complete, but normal IP/data communication between the legacy client and the Flint does not operate correctly.
Other troubleshooting performed
I have also tested:
-
2.4 GHz at 20 MHz
-
Channel 6 and Channel 11
-
WPA2-PSK
-
WPA/WPA2 mixed mode
-
DHCP and static IPv4 addressing
-
Factory reset of the ELAN Connect+
-
ELAN configured for WPA/WPA2 with AES
None resolved the problem.
The same ELAN Connect+ connects and operates normally using a Google Pixel Wi-Fi hotspot, which strongly suggests an interoperability issue with the Flint 4 rather than a hardware or service failure in the radio.
Regulatory-domain issue also discovered
During troubleshooting I discovered that the Flint 4 was configured with the German regulatory domain:
global
country DE: DFS-ETSI
phy#0 country DE
phy#1 country DE
phy#2 country DE
UCI also contained:
wireless.MT7990_1_1.country='DE'
wireless.MT7990_1_2.country='DE'
wireless.MT7990_1_3.country='DE'
The router is being used in the United Kingdom.
I changed all three entries to GB, committed the wireless configuration and reloaded Wi-Fi. iw reg get now correctly reports:
global
country GB: DFS-ETSI
phy#0 country GB
phy#1 country GB
phy#2 country GB
Correcting the regulatory domain did not resolve the ELAN connectivity problem.
I would therefore appreciate it if this could be investigated as a possible Flint 4/MediaTek 2.4 GHz legacy-client interoperability issue.
In particular, could you advise whether there are any known issues or firmware fixes involving older 802.11 clients that successfully associate and complete the WPA2 handshake but subsequently fail to exchange normal data?