Received the Flint 4; it's going great, but my old Elan internet radio won't connect at all. I assume it's because the radio most likely has older hardware. Has anyone else come across old IoT and the like not playing well with the Flint 4? Also, the Flint's Wi-Fi was set for Germany and not the UK, which was easy to change in the terminal.
First you should check what kind of Wi-Fi your internet radio supports and then adapt the settings for it. Most likely it will be something like 2.4 GHz, 20 MHz channel bandwidth, WPA2 encryption.
You can use the IoT network for it.
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?
Try this: Static IP + Broadcast for that device
uci add dhcp host
uci set dhcp.@host[-1].name='ELAN'
uci set dhcp.@host[-1].mac='30:58:90:4b:f9:72'
uci set dhcp.@host[-1].ip='192.168.10.50'
uci set dhcp.@host[-1].tag='force_broadcast'
uci add_list dhcp.@dnsmasq[0].dhcp_broadcast='tag:force_broadcast'
uci commit dhcp
/etc/init.d/dnsmasq restart
Reboot the ELAN as well, maybe it could help 
To revert the static IP and broadcast:
# 1. Remove the broadcast tag entry from dnsmasq
uci del_list dhcp.@dnsmasq[0].dhcp_broadcast='tag:force_broadcast'
# 2. Find and delete the host reservation for ELAN (by MAC address)
IDX=$(uci show dhcp | grep -i '30:58:90:4b:f9:72' | cut -d'[' -f2 | cut -d']' -f1 | head -n1)
[ -n "$IDX" ] && uci delete dhcp.@host[$IDX]
# 3. Commit changes and restart dnsmasq
uci commit dhcp
/etc/init.d/dnsmasq restart
Might try the other suggestions as well:
uci set wireless.iot2g.ieee80211w='0'
uci commit wireless
wifi reload
uci set wireless.MT7990_1_1.legacy_rates='1'
uci commit wireless
wifi reload
uci set wireless.iot2g.encryption='psk-mixed+tkip+ccmp'
uci commit wireless
wifi reload
To revert last one:
uci set wireless.iot2g.encryption='psk2+ccmp'
uci commit wireless
wifi reload
There can be many things here.
It is possible that your device just don't like a router change and you need to go over the whole wifi setup process again on this device because it is stuck on a handshake.
A other issue can be that your device is having a ip conflict either with a different device and gets stuck on this, or: the ip is very close assigned to your broadcast ip or overlapping.
I had a situation recently that a dumbap dhcp client requested the maximum length of the subnet, and then ironically tries to add /24 which is invalid and overlapping lol, I have sent under a different post a feature request for sequential reservation, for some reason some clients want to pick extremely high numbers.... if my dhcp server start was 2 and my limit 254 it takes 236 lol... with that kind of behaviour I think it still creates a higher chance for conflicts than what I observed with sequential reservation by the dhcp server.
1 Like
Flint 4 WiFi UK country code not available i’m not sure that the UK country code is available for the Flint 4
Thanks for the help, ive tried but to no availe i reckon sadly the radio will be dab on now, so it’ll be like listening to radio underwater 
Hi,
Thank you for the detailed testing and information you have provided.
Since the ELAN Connect+ is able to associate with the 2.4 GHz Wi-Fi and complete the WPA2 handshake, could you please try one additional compatibility setting for older 2.4 GHz Wi-Fi clients.
Please SSH into the Flint 4 and run the following commands:
uci set wireless.MT7990_1_1.legacy_rates='1'
uci commit wireless
wifi restart
This enables legacy 802.11b rates on the 2.4 GHz radio and may help with compatibility for some older Wi-Fi clients.
After the Wi-Fi comes back up, please try connecting the ELAN Connect+ again and check whether it can obtain an IP address and access the network normally.
If there is still no change, could you please set the ELAN Connect+ back to DHCP and capture the DHCP/ARP exchange during one connection attempt.
Please SSH into the Flint 4 and run:
tcpdump -i br-iot -nn -e -s 0 -w /www/elan-dhcp.pcap \
'arp or (udp port 67 or 68) or icmp'
Then reconnect the ELAN Connect+ and allow the issue to occur once or twice. After that, press Ctrl+C to stop the capture.
Please send the generated elan-dhcp.pcap file to us via forum private message.
Thank you for your support and understanding.