AR300M - continuous WiFi drops after MAC clone

danull · 2018-04-02T02:56:13.054Z

I have a new AR300M. MAC cloning does not work well so far. I am at home doing all of this and WISP is connecting to my home router, a linksys EA9500 - no captive portal or anything. I saw this same issue at a friend’s house with an ASUS router. It looks like if the device that cloned MAC to AR300M remains on the network wirelessly, it will cause problems with WiFi even for other devices. If the device that cloned the MAC stays off after clone, things are OK.

Whenever I do clone mac address from my iPad when connected via WISP wirelessly, it takes the iPad’s MAC and restarts Wi-Fi, and then I reconnect with my iPad and try to run Oooka’s Speedtest IOS app…but then within the space of a minute, it restarts the wireless again, and then again, and then again as though the AR300M is having serious problems communicating with the iPad. If I go back in and do RESTORE of the factory default MAC address, it stabilizes and the Wi-Fi restarts stop, but then I have reverted to the factory default MAC address and not the cloned one that I want, since it would be the iPad I use to logon to first login to a hotel network for example, which defeats the purpose of MAC cloning.

I tried on 2.264 and 2.27 (testing) firmware builds, and I also backleveled via factory restore to 2.261 but that didn’t work either.

I think maybe this other person had the same problem but it was never resolved:

Clone mac address Technical Support for Routers

Ok, thanks, just wanted to be sure if I have an issue here or not. If I do not clone my phones mac address, I don’t have problem connecting my phone to GL. If I clone my phones mac address the phone constantly looses wlan connection, tries again to reconnect and authenticate, keeps it up some seconds and looses it again and so on. During that, other devices cannot connect anymore (I suppose the GL is busy with the phone reconnections). I have to remove wlan connection from phone to use my GL …

These logs are from build 2.27 but I saw the same behavior on all levels referred to above. I thought I had it working one time when I used DHCP/ethernet cable to help get WISP going, but then after removing the ethernet cable and running OK on wireless for a while, I enabled/disabled OpenVPN and it immediately went back into these constant restarts of WiFi whenever the iPad with same MAC was connected and trying to talk through this AR300M router… also DHCP/ethernet is not always going to be available for me to “jumpstart” things when I am travelling.

Here are some logs that may help understand, I left the first two parts of the MAC in each case and censored the rest in this post - d0:4f: is the iPad.

Sun Apr 1 22:10:18 2018 daemon.info hostapd: wlan0: STA d0:4f:mac:addr:censored IEEE 802.11: authenticated
Sun Apr 1 22:10:18 2018 daemon.info hostapd: wlan0: STA d0:4f:mac:addr:censored IEEE 802.11: associated (aid 1)
Sun Apr 1 22:10:18 2018 daemon.notice hostapd: wlan0: AP-STA-CONNECTED d0:4f:mac:addr:censored
Sun Apr 1 22:10:18 2018 daemon.info hostapd: wlan0: STA d0:4f:mac:addr:censored RADIUS: starting accounting session 2D7905F751258913
Sun Apr 1 22:10:18 2018 daemon.info hostapd: wlan0: STA d0:4f:mac:addr:censored WPA: pairwise key handshake completed (RSN)
Sun Apr 1 22:10:18 2018 daemon.info dnsmasq-dhcp[6707]: DHCPREQUEST(br-lan) 192.168.8.195 d0:4f:mac:addr:censored
Sun Apr 1 22:10:18 2018 daemon.info dnsmasq-dhcp[6707]: DHCPACK(br-lan) 192.168.8.195 d0:4f:mac:addr:censored Daniels-iPad
Sun Apr 1 22:10:18 2018 daemon.info odhcpd[1310]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr 1 22:10:19 2018 daemon.warn dnsmasq[6707]: possible DNS-rebind attack detected: www.tes500.zillow.net
Sun Apr 1 22:10:23 2018 daemon.info odhcpd[1310]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr 1 22:10:27 2018 daemon.info odhcpd[1310]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: AP Ok=1
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: network(caIfnames) = wan wan6 wwan
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: check wpa runing = 7082
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: STA Ok=1
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: Everthing is OK!!!
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: check wpa runing = 7082
Sun Apr 1 22:10:29 2018 daemon.info gl-health>>: Connected Hotspot: SSID = Fort, BSSID = 48:f8:mac:addr:censored

Sun Apr 1 22:10:36 2018 daemon.notice netifd: Network device ‘wlan-sta’ link is down
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ has link connectivity loss
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.169699] wlan-sta: deauthenticated from 48:f8:mac:addr:censored (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.211658] wlan-sta: authenticate with 48:f8:mac:addr:censored
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.230479] wlan-sta: send auth to 48:f8:mac:addr:censored (try 1/3)
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.238387] wlan-sta: authenticated
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.291102] wlan-sta: associate with 48:f8:mac:addr:censored (try 1/3)
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.312313] wlan-sta: RX AssocResp from 48:f8:mac:addr:censored (capab=0x411 status=0 aid=12)
Sun Apr 1 22:10:36 2018 kern.info kernel: [ 579.320916] wlan-sta: associated
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Network device ‘wlan-sta’ link is up
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ has link connectivity
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ is setting up now
Sun Apr 1 22:10:36 2018 daemon.notice netifd: wwan (11568): udhcpc: received SIGTERM
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ is now down
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ is disabled
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ is enabled
Sun Apr 1 22:10:36 2018 daemon.notice netifd: Interface ‘wwan’ is setting up now
Sun Apr 1 22:10:36 2018 user.notice mwan3: ifdown interface wwan (unknown)
Sun Apr 1 22:10:36 2018 daemon.notice netifd: wwan (15845): udhcpc: started, v1.25.1
Sun Apr 1 22:10:36 2018 daemon.notice netifd: wwan (15845): udhcpc: sending discover
Sun Apr 1 22:10:37 2018 daemon.notice netifd: Network device ‘wlan0’ link is down
Sun Apr 1 22:10:37 2018 kern.info kernel: [ 580.171231] br-lan: port 2(wlan0) entered disabled state
Sun Apr 1 22:10:37 2018 daemon.info odhcpd[1310]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr 1 22:10:38 2018 daemon.notice netifd: bridge ‘br-lan’ link is down
Sun Apr 1 22:10:38 2018 daemon.notice netifd: Interface ‘lan’ has link connectivity loss
Sun Apr 1 22:10:39 2018 daemon.notice netifd: wwan (15845): udhcpc: sending discover
Sun Apr 1 22:10:40 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:40 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:40 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:40 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:42 2018 daemon.notice netifd: wwan (15845): udhcpc: sending discover
Sun Apr 1 22:10:44 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:44 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:45 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:45 2018 daemon.notice hostapd: handle_probe_req: send failed
Sun Apr 1 22:10:46 2018 kern.info kernel: [ 589.328634] wlan-sta: deauthenticating from 48:f8:mac:addr:censored by local choice (Reason: 3=DEAUTH_LEAVING)
Sun Apr 1 22:10:46 2018 daemon.notice netifd: Network device ‘wlan-sta’ link is down
Sun Apr 1 22:10:46 2018 daemon.notice netifd: Interface ‘wwan’ has link connectivity loss
Sun Apr 1 22:10:46 2018 daemon.notice netifd: wwan (15845): udhcpc: received SIGTERM
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.519384] wlan-sta: authenticate with 48:f8:mac:addr:censored
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.538272] wlan-sta: send auth to 48:f8:mac:addr:censored (try 1/3)
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.546168] wlan-sta: authenticated
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.551522] wlan-sta: associate with 48:f8:mac:addr:censored (try 1/3)
Sun Apr 1 22:10:47 2018 daemon.notice netifd: Network device ‘wlan-sta’ link is up
Sun Apr 1 22:10:47 2018 daemon.notice netifd: Interface ‘wwan’ has link connectivity
Sun Apr 1 22:10:47 2018 daemon.notice netifd: Interface ‘wwan’ is setting up now
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.563032] wlan-sta: RX AssocResp from 48:f8:mac:addr:censored (capab=0x411 status=0 aid=12)
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.571674] wlan-sta: associated
Sun Apr 1 22:10:47 2018 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED d0:4f:mac:addr:censored
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.590446] br-lan: port 2(wlan0) entered forwarding state
Sun Apr 1 22:10:47 2018 kern.info kernel: [ 590.596252] br-lan: port 2(wlan0) entered forwarding state
Sun Apr 1 22:10:47 2018 daemon.notice netifd: Network device ‘wlan0’ link is up
Sun Apr 1 22:10:47 2018 daemon.notice netifd: bridge ‘br-lan’ link is up
Sun Apr 1 22:10:47 2018 daemon.notice netifd: Interface ‘lan’ has link connectivity
Sun Apr 1 22:10:47 2018 daemon.notice netifd: wwan (16036): udhcpc: started, v1.25.1
Sun Apr 1 22:10:47 2018 daemon.notice netifd: wwan (16036): udhcpc: sending discover
Sun Apr 1 22:10:49 2018 kern.info kernel: [ 592.591374] br-lan: port 2(wlan0) entered forwarding state
Sun Apr 1 22:10:50 2018 daemon.notice netifd: wwan (16036): udhcpc: sending discover
Sun Apr 1 22:10:50 2018 daemon.notice netifd: wwan (16036): udhcpc: sending select for 192.168.1.253
Sun Apr 1 22:10:50 2018 daemon.notice netifd: wwan (16036): udhcpc: lease of 192.168.1.253 obtained, lease time 86400
Sun Apr 1 22:10:50 2018 daemon.notice netifd: Interface ‘wwan’ is now up
Sun Apr 1 22:10:50 2018 user.notice mwan3: ifup interface wwan (wlan-sta)
Sun Apr 1 22:10:51 2018 daemon.info odhcpd[1310]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr 1 22:10:52 2018 user.notice firewall: Reloading firewall due to ifup of wwan (wlan-sta)
root@GL-AR300M:~#

root@GL-AR300M:/etc/config# cat wireless

config wifi-device ‘radio0’
option type ‘mac80211’
option path ‘platform/qca953x_wmac’
option htmode ‘HT20’
option hwmode ‘11ng’
option txpower ‘20’
option channel ‘9’

config wifi-iface
option device ‘radio0’
option network ‘lan’
option mode ‘ap’
option encryption ‘psk-mixed’
option wds ‘1’
option ifname ‘wlan0’
option ssid ‘censoredssid’
option key ‘censoredpassword’

config wifi-iface ‘sta’
option device ‘radio0’
option ifname ‘wlan-sta’
option network ‘wwan’
option mode ‘sta’
option ssid ‘censoredssid’
option key ‘censoredpassword’
option encryption ‘psk-mixed’
option macaddr ‘d0:4f:mac:addr:censored’

Please let me know if there is any other info I can provide, I would love to get a fix for this as so far I like the other aspects of this router.

EDIT: In further testing I found that I can also use my iPhone to help get it working. I find that if I use my iPhone (rather than iPad) to do the clone mac, pretending like I had used my iphone to get through a captive portal for example, and then leave the iphone off the network after doing the clone mac, I am OK. But if the iPhone remains on Wifi and then my iPad does a speedtest, via Ookla’s app, during the server lookup phase it drops the iPad connectivity. If I turn off Wifi for the iPhone, I can run speedtest without issue and iPad connectivity is stable. This is not a good workaround as I want to be able to have my iphone connect too via Wifi especially when there is no LTE available (such as on a boat or plane).

So to summarize, my findings so far seem to indicate that if whatever wireless device has cloned MAC to AR300M is on the network, it or any other device cannot do Speedtest and maybe similar I/O without that device losing wireless connectivity repeatedly. Seems like GL-inet should be able to recreate this phenomenon?

danull · 2018-04-05T15:04:16.368Z

Maybe too much detail in my first post or too confusing?

I should be able to use an iPad or iPhone with the same MAC as the AR300M in WISP mode after a MAC clone on the same network without causing Wi-Fi drops due to duplicate MAC, right?

alzhao · 2018-04-07T05:21:36.566Z

Actually I don’t know why you have a problem with ipad. Maybe it is old?

I suggest you don’t use mac clone, but rather uncheck the DNS rebind protection.

Overview - GL.iNet Docs

chuyeupr · 2023-01-13T22:17:13.743Z

Hello,

I was just wondering if you figured out the fix for it? I’m using their new model the GL-AXT1800-61a and I’m running into the exact problem.

Hope to hear back from you

danull · 2023-01-14T02:56:42.068Z

Sorry, I have not needed to do a MAC clone in years. The last time I did I was still using a “burner device” to make things work as described above.
These days many devices have “Private Wifi address” to change mac to reduce tracking. If I were to try this again I would think about having it disabled when I first registered with the Wifi service and then enabling it after doing the mac clone on Gl inet router to have it take over.