What's new

2 clients are connecting to RT-AC87U through this device

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I think that is the best approach. :)

Until someone difinitively relates it to a problem or security issue, it doesn't seem worth being concerned about. Personally, I don't see the need to watch the network map 24/7 :)

Yeah. "Head in the sand" can be very stupid, but with some tech problems "Ignore and hope for update to fix" can be the best approach. I can't tell one from the other, though!

Anyhow, I've read a few people's posts suggesting that it went away after flipping UPnP, or after assigning static, or after updating, or clearing NVRAM. All of that leads me to suspect a bug more than malware. So, I feel even better about "ignore", for now.

Still, Asus has given VERY weak documentation about what those numbers are, why they appear, and what they mean.
 
So, I'm having the same thing on my new router, and found this forum when trying to figure it out.

After reading all of the posts here and thinking about how I ended up with it on my device (I forced an IP x Mac address binding) I think I have a guess:

It could be that the device's MAC address has two outstanding DHCP leases out. DHCP leases have a timeout, so if you force a new one for some reason (I want the IP address to change, I shut the device off and then on, I left wireless range and then came back) the system will issue a new lease even if the old one hasn't expired (I think). It's totally a guess and I haven't done any research to back it up, but if that's the case, no, it's not a security risk at all, it's just a natural part of how your network works, and it should go away in a few days assuming you don't do something to issue a dual lease again.

Again, this is just a guess, but I've mostly convinced myself, and figured I'd see if anyone else had an opinion.
 
It could be that the device's MAC address has two outstanding DHCP leases out. DHCP leases have a timeout, so if you force a new one for some reason (I want the IP address to change, I shut the device off and then on, I left wireless range and then came back) the system will issue a new lease even if the old one hasn't expired (I think).

Hi tristfall, I don’t think this has anything to do with dhcp as in my case it happens both with local dns binding on server router side and also having fixed ip setup at client side, yet viewing the same there.
 
So, I'm having the same thing on my new router, and found this forum when trying to figure it out.

After reading all of the posts here and thinking about how I ended up with it on my device (I forced an IP x Mac address binding) I think I have a guess:

It could be that the device's MAC address has two outstanding DHCP leases out. DHCP leases have a timeout, so if you force a new one for some reason (I want the IP address to change, I shut the device off and then on, I left wireless range and then came back) the system will issue a new lease even if the old one hasn't expired (I think). It's totally a guess and I haven't done any research to back it up, but if that's the case, no, it's not a security risk at all, it's just a natural part of how your network works, and it should go away in a few days assuming you don't do something to issue a dual lease again.

Again, this is just a guess, but I've mostly convinced myself, and figured I'd see if anyone else had an opinion.
Yes, I saw this exact issue recently when I changed my wife's phone IP from random to determined, it only took a few hours to forget the old IP.

It's possible multiple issues are showing the same symptoms though, so YMMV.
 
I have seen this on several devices.... I can intentionally create it by assigning a new (different IP) reservation for a device, then rebooting that device. When it gets the new IP, the count in the message is increased by (1) for that device.

So it seems the message is really saying "there are (x) ip addresses that have recently been associated with this MAC". That would be fine, except.... Once the lease for the previous IP expires, or large amounts of time pass, the count is still not decremented. Even rebooting the router, the "multiple devices connecting" is again reported for the same devices.

My current opinion, based on these observations, is that this is (yet another) bug in the Asus network map code. It seems to recognizes that multiple IPs have recently been used (whether via lease or static) for the same MAC, and reports it as "x devices are connecting" using the same MAC. But there doesn't appear to be any process to reset the count once the lease expires or a specified amount of time passes since the MAC was seen communicating via a given IP.
 
Last edited:
Similar problem on my 86U with latest Merlin. Have a Lenovo Yoga Notebook which is assigned a static ip by DHCP. The Notebook itself shows that it has been assigned the proper address in my subnet, whether running Windows or Linux. However, the Network Map on the 86U shows the correct mac address but an autoconfig ip address which is of course outside the subnet. I too am putting it down to a problem in the Network Map code.
 
Similar problem on my 86U with latest Merlin. Have a Lenovo Yoga Notebook which is assigned a static ip by DHCP. The Notebook itself shows that it has been assigned the proper address in my subnet, whether running Windows or Linux. However, the Network Map on the 86U shows the correct mac address but an autoconfig ip address which is of course outside the subnet. I too am putting it down to a problem in the Network Map code.
I had the same problem with 2 Raspberry Pis both showing 2 connections after I switched them from static (assigned in the RPi) to manual (assigned in router webgui). They were like that for a month and only dropped the 2nd connection when I upgraded the Kernel on both of the RPis. Not sure if it was related to the kernel update on the RPis or I just happened to notice it after the update, but go figure.
 
Further update. The Network Map list view shows for each device whether the ip is static, assigned by dhcp or manual (mac and ip address binding). The offending device showed static when it should have showed manual. I deleted the fixed ip assignment for the device and did a release renew in Windows. The device then showed correctly as dhcp. When I again assigned a fixed address it again showed the device as having a static ip, this time with 3 devices rather than 2 behind it and showing the last address assigned by dhcp. After rebooting the router and rebooting the device into Linux, it is finally showing as having the correct assigned IP with no devices behind it and as assignment type fixed.

Seems to suggest that the problem is with the code and previous ip addresses assigned to the device, though I'm still mystified as to how a windows autoconfig ip came to show as the ip address in the Network Map as per my first post in this thread. At least it seems unlikely to be a security issue.
 
There could be some security issues related to this specific problem. When I have Parental Control -> Time Scheduling enabled on a device, and when this "2 clients are connecting" happens on the device, the device will get internet access even though it is supposed to be blocked in Parental Control. Does anyone figured out something to workaround this?
 
There could be some security issues related to this specific problem. When I have Parental Control -> Time Scheduling enabled on a device, and when this "2 clients are connecting" happens on the device, the device will get internet access even though it is supposed to be blocked in Parental Control. Does anyone figured out something to workaround this?
I haven't seen that issue, and am confused as to how it could happen. When blocking a device via parental control, an IPTables DROP rule is added for the MAC. I've tried this with devices that show "multiple devices are connecting" and the MAC is correctly added to the chain, thus successfully blocking its access.

Try an ssh to your router, and issue the command "iptables -L FORWARD" and see if the devices in question have a DROP rule for their MAC. If they aren't there, double check your schedule and time settings.
 
For those who have this issue, try this:
Go to LAN - DHCP Server - Manually Assigned IP around the DHCP list
Click on Client Name. At the bottom of the list you will see "Show Offline Client List". Click on it to show old remembered clients.
Just click on the "x" on each to delete the clients from the router. Note you may have multiple records for the same client.
Hopefully the multiple client issue will disappear. See attached.
Asus.jpg
 
For those who have this issue, try this:
Go to LAN - DHCP Server - Manually Assigned IP around the DHCP list
Click on Client Name. At the bottom of the list you will see "Show Offline Client List". Click on it to show old remembered clients.
Just click on the "x" on each to delete the clients from the router. Note you may have multiple records for the same client.
Hopefully the multiple client issue will disappear. See attached.

Nope -- already tried that. Did not have any effect. I have completely emptied that "offline client list" multiple times, and still have devices showing "X clients are connecting" in Network Map.

But what did just clear them all up.... I shut down my AP (88U with Ethernet backhaul running stock 384_45717), then rebooted the router (86U with Merlin 384.11), then powered the AP back up. All of the multiple counts are currently gone from the Network Map. When I previously rebooted the Router alone (with AP still running), the counts did not go away. AND.... The devices with multiple counts were NOT all connected to the AP; some were connected to the Router and some to the AP.

The problem isn't directly related to "roaming", either. I have several mobile devices that frequently roam between the router and AP, and none of them show up with the multiple counts. Also, (2) of the devices that did show up with multiple counts have never connected to the AP (they are actually MAC filtered to prevent it).

What may be related.... The AP does "see" all the devices on the network, and lists them in its Network Map. So could one cause of the "multiple devices connecting" count be some interaction between the AP's network map code and the Router's network map code? I couldn't clear the counts by rebooting the router while the AP was still running. But shutting down the AP and then rebooting the Router cleared the counts. Odd.

Anyone else seeing this behavior also have an AP as well as a router?
 
Last edited:
I've been searching to find the appropriate thread to post this. This one seems close. If not, maybe someone can redirect me.

My setup -
Model: (QTY 2) RT-AC68 using AiMesh w/ ethernet backhaul
FW: Merlin 384.13 on the mesh router, asus 3.0.0.4.384_81039 on the mesh node

My issue -
I have an AppleTV 4 connected over 5GHz wifi to the mesh node.

The Asus Client Status pane shows a badge on the AppleTV (name is brain-sieve, see jpegs) that indicates two clients are connecting through that device. I know of no Apple tvOS bug that would allow client connections through an AppleTV. This badge survives an unplug/wait/reboot of the AppleTV.

Unless this is related to some kind of Apple Wireless Direct Link “feature” nastiness I tend to think this is an Asus reporting bug. Anyone have an idea?

Screen Shot 2019-08-30 at 5.04.00 PM.png
Screen Shot 2019-08-30 at 5.06.22 PM.png
 
I didn't have time to read all of the replies, however I had a 2 just like that. I figured out what caused it on my end though. I had my desktop set with a static IP(local) and then changed it in windows to receive an IP from the DHCP server. My static IP was 192.168.1.181 but I have DHCP pool set to start at 192.168.1.11 and end at 192.168.1.49. Therefore it assigned me an IP in that range which was 192.168.1.8 - That is what made the 2 come up on my end.
 
I am running into this situation now as well. I am still having a hard time figuring out this now. Seems as though I may have to shutdown the whole network and then reboot the router first followed by the switches and finally the servers?
 
The simplest way I found to fix it, disable and reactivate ipv6.Do not ask me why it work :D
 
I just run into this on RT-AC86U. I got 2 on an ESP32 IOT I am playing with. The microPython code was asking for a lease with an specific address. This may be causing two IP assignment operations, one after the other and somehow the network map memorizes it. I found in another post how to reset network map, which clears the 2 until I recycle the ESP32.
Code:
/usr/sbin/networkmap &

Then I assigned the static address manually on the router and the problem does not reoccur.
 
So, I'm having the same thing on my new router, and found this forum when trying to figure it out.

After reading all of the posts here and thinking about how I ended up with it on my device (I forced an IP x Mac address binding) I think I have a guess:

It could be that the device's MAC address has two outstanding DHCP leases out. DHCP leases have a timeout, so if you force a new one for some reason (I want the IP address to change, I shut the device off and then on, I left wireless range and then came back) the system will issue a new lease even if the old one hasn't expired (I think). It's totally a guess and I haven't done any research to back it up, but if that's the case, no, it's not a security risk at all, it's just a natural part of how your network works, and it should go away in a few days assuming you don't do something to issue a dual lease again.

Again, this is just a guess, but I've mostly convinced myself, and figured I'd see if anyone else had an opinion.

My guess is the same as @tristfall's.

I'm running Merlin 384.14 on a RT-AX88U. I manually changed the IP pool address range. At the time DHCP had assigned two mobile devices outside of the new range. After I changed the IP range the network map gave the "2 clients are connecting to the RT-AX88U through this device" for both mobile devices. When I googled the issue, I found this thread and @tristfall's guess. Sure enough, I waited a few hours and the issue disappeared for me. While other users might have other things going on that cause the same condition, if you've adjusted the IP range, you might be seeing a temporary dual lease issue.
 
My guess is the same as @tristfall's.

I'm running Merlin 384.14 on a RT-AX88U. I manually changed the IP pool address range. At the time DHCP had assigned two mobile devices outside of the new range. After I changed the IP range the network map gave the "2 clients are connecting to the RT-AX88U through this device" for both mobile devices. When I googled the issue, I found this thread and @tristfall's guess. Sure enough, I waited a few hours and the issue disappeared for me. While other users might have other things going on that cause the same condition, if you've adjusted the IP range, you might be seeing a temporary dual lease issue.

I've seen it persist long beyond my 24 hour dhcp lease time (i.e., it has shown up for days). And the "old" lease isn't displayed in the router's DHCP lease list. But it is certainly plausible -- and this could even differ between firmware versions I suppose -- that part of the cause is NetworkMap sometimes failing to clear some entry or "count" it maintains for each MAC.

I can 100% re-create the condition by letting a new device get a random IP from DHCP, then creating a reservation assigning a different IP and restarting the device. In that scenario, it will pull the reserved address, and the "2 devices" condition will show up in NetworkMap for that device. Sometimes it disappears in 24 hours, but many times it persists for days (and my DHCP lease time is 24 hours).

I'll also reiterate that the "2 devices are connecting through this device" seems to be a bad choice of words on the part of Asus. In every case I have experienced, the cause is a single device (single MAC) having recently communicated via more than one IP address. The Amcrest cameras are a frequent offender because when factory reset they initially do some communication on a hard-coded "192.168.1.108" looking for a firmware server -- before broadcasting a DHCP request and getting a DHCP-assigned IP. The Asus NetworkMap shows that as "2 devices connecting", and often will even still show the camera's CURRENT address as 192.168.1.108 long after the camera has been actively using its DHCP-assigned IP.

TLDR: The NetworkMap code is a mess.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top