Archer C60 doesn't connect to Acher VR600 when access control on
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Internet is connected using Acher VR600
An Archer C60 is used in Router Mode , to extend it's range
If I enable access control on the VR600 , using white list, and add the C60 MAC address ( for both 2.4Ghz and 5.Ghz ) it doesn't connect , and the devices connected to the C60 can't access the internet
If I disable access control, it works
Any advice
Thanks
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi,
If the C60 in Router Mode is connected to the VR600 via Ethernet cable, then you need to add the MAC address of the C60's Internet (WAN) port to the VR600's white list.
If you are using WDS Bridging to connect the C60 wirelessly to the VR600, then you likely need to add the MAC addresses of all the devices connected to the C60 to the VR600's white list, because when using WDS Bridging the C60 acts basically as an Access Point.
Furthermore, the MAC address used by the C60 for a WDS bridge might not be the actual hardware MAC address of the C60's 2.4 GHz or 5 GHz radio. Instead it may use a spoofed MAC address for this purpose. To get this MAC address disable Access Control on the VR600 and then look it up in the VR600's DHCP list or Client list.
- Copy Link
- Report Inappropriate Content
Thanks for your reply
It's connected using WDS bridging
All clients that need to connect are on VR600's white list
With access control enabled, If I connect the client to the VR600 directly, it connectsto the internet, if I connect it to the C60, it doesn't connect to the internet.
When I disable access control and connect the C60 , it doesn't show on the DHCP list nor client list, it seems being in WDS mode hides it from these lists.
If I do a scan of the network I can find the C60 , and it's MAC address that connects it to the VR600 is the same MAC address I have it in the white list for it
- Copy Link
- Report Inappropriate Content
Ok, I've tried to simulate your setup here at my home, using an older TP-Link router as WDS client and another router running OpenWrt as the "main router".
On the OpenWrt router I added the TP-Link router's hardware MAC address (30:fc:68:4c:c9:04) and the MAC address of my PC to the "allow" list.
The result of the test was exactly like what you described. The TP-Link router was not able to establish the WDS connection when the MAC filter was activated on the main router.
Since OpenWrt allows direct access to its Linux system I had a look at the logs, which revealed that the TP-Link router's WDS interface "authenticated" itself using a MAC address different to the actual MAC address of the wireless radio.
In case you are interested you can have a look at the actual log below.
After I added that MAC address (02:fc:68:4c:c9:04) to the whitelist as well, the TP-Link router was able to establish the WDS connection just fine.
So, I am thinking your case is likely similar and you need to find out what that other "virtual" MAC address is and also add it to the whitelist.
Sun Jun 25 22:21:49 2023 daemon.info hostapd: wlan1: STA 02:fc:68:4c:c9:04 IEEE 802.11: authenticated
Sun Jun 25 22:21:49 2023 daemon.info hostapd: wlan1: STA 02:fc:68:4c:c9:04 IEEE 802.11: associated (aid 2)
Sun Jun 25 22:21:49 2023 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 02:fc:68:4c:c9:04
Sun Jun 25 22:21:49 2023 daemon.info hostapd: wlan1: STA 02:fc:68:4c:c9:04 RADIUS: starting accounting session 000CD940593FAD32
Sun Jun 25 22:21:49 2023 daemon.info hostapd: wlan1: STA 02:fc:68:4c:c9:04 WPA: pairwise key handshake completed (RSN)
Sun Jun 25 22:21:49 2023 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED 02:fc:68:4c:c9:04
Sun Jun 25 22:21:52 2023 daemon.notice hostapd: wlan1: WDS-STA-INTERFACE-ADDED ifname=wlan1.sta2 sta_addr=02:fc:68:4c:c9:04
Sun Jun 25 22:21:52 2023 daemon.info ipsec: 15[KNL] interface wlan1.sta2 activated
Sun Jun 25 22:21:52 2023 daemon.notice netifd: Network device 'wlan1.sta2' link is up
Sun Jun 25 22:21:52 2023 kern.info kernel: [ 197.781646] br-lan: port 3(wlan1.sta2) entered blocking state
Sun Jun 25 22:21:52 2023 kern.info kernel: [ 197.781697] br-lan: port 3(wlan1.sta2) entered disabled state
Sun Jun 25 22:21:52 2023 kern.info kernel: [ 197.786832] device wlan1.sta2 entered promiscuous mode
Sun Jun 25 22:21:52 2023 kern.info kernel: [ 197.792509] br-lan: port 3(wlan1.sta2) entered blocking state
Sun Jun 25 22:21:52 2023 kern.info kernel: [ 197.797159] br-lan: port 3(wlan1.sta2) entered forwarding state
Sun Jun 25 22:21:53 2023 daemon.info ipsec: 11[KNL] fe80::ea9f:80ff:feaf:6379 appeared on wlan1.sta2
Sun Jun 25 22:21:55 2023 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 32:fc:68:4c:c9:05
Sun Jun 25 22:21:55 2023 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.218 32:fc:68:4c:c9:05
Sun Jun 25 22:21:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 30:fc:68:4c:c9:04
Sun Jun 25 22:21:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.155 30:fc:68:4c:c9:04
Sun Jun 25 22:21:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 30:fc:68:4c:c9:04
Sun Jun 25 22:21:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.155 30:fc:68:4c:c9:04
Sun Jun 25 22:22:00 2023 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.1.156 30:fc:68:4c:c9:04
Sun Jun 25 22:22:00 2023 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.155 30:fc:68:4c:c9:04
Sun Jun 25 22:22:01 2023 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.155 30:fc:68:4c:c9:04
Sun Jun 25 22:22:01 2023 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.155 30:fc:68:4c:c9:04 TL-WDR7500-lan
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 472
Replies: 3
Voters 0
No one has voted for it yet.