Unknown Connected Device

Discussion in 'Tomato Firmware' started by Rastan, May 21, 2014.

  1. Rastan

    Rastan Network Newbie Member


    I'm using Victek Version 1.28.9014 series (Beta) firmware and the other day while I was checking the Device List menu, I noticed an unknown device that was connected (1 bar & 1 quality strength) but it didn't have an IP address assigned to it. I'm using WPA2 encryption & I use a randomly generated 64 character string as my password.

    The only details that I could see was the name of the device - the mac address D8:D1:CB:36:ED:CE. It appears to be an Apple device. I don't have any apple devices. Since this device had a 1 bar connection, albeit a very poor one, does this mean that they were able to connect to my router even though an IP address was not assigned to it? Once I blocked the mac address, this device was no longer shown in the list.
  2. koitsu

    koitsu Network Guru Member

    All it means is that the device showed up in the ARP list of arp -a on the router itself. Whether or not it was able to actually authenticate I do not know, but I would say it's unlikely if you're using WPA2 Personal + AES (TKIP is a different story...).
  3. Rastan

    Rastan Network Newbie Member

    Thanks for the info. Do you mean that if someone has wifi enabled on their device and they're in the vicinity, my router will pick it up in their ARP list? If so, would it continue to remain listed until the device is out of range?

    I'm using WPA2 Personal (PSK) + AES. With this firmware, if a device connects to the network, isn't an IP address automatically assigned to it? I don't understand how it had 1 bar without an IP address. It's unlikely that someone brute forced my password unless they were in the vicinity for several days but perhaps there's a vulnerability we aren't aware of.
  4. jerrm

    jerrm Network Guru Member

    Assignment of an IP via DHCP is a completely separate process and unrelated from authenticating/connecting to the wireless.

    If the client has a manually assigned IP address and connects, the client IP address will fall out of the router's arp table after a few minutes if the client doesn't generate any traffic to/from/through the router. The result in the device list is the client mac with signal data and no IP.

    If a client attempts to connect with an invalid key, it will show in the device list for a brief period with no IP. With Shibby RT-N 117, the device is dropped from the list after only a few seconds, but there could be driver differences (most likely) or code differences that may cause it to linger longer with victek. I'm not sure if he is on the same driver revision as Shibby.


    This was just posted in the RAF thread: http://www.linksysinfo.org/index.php?threads/tomato-raf-releases.63093/page-35#post-245851

    Could be completely unrelated, but close enough to wonder if related.
    Last edited: May 21, 2014
  5. Rastan

    Rastan Network Newbie Member

    In your second scenario, where a client attempts to connect with an invalid key, could it appear that it has 1 bar connection when it shows up on the list?

    I took a look at the image in that thread and it's not similar to what I saw. In my case, there was a mac address and it had 1 bar & 1 quality. I assumed that since this unknown device had 1 bar, even though the quality was only 1, then it had successfully connected to the network. I guess this is not the case?
  6. jerrm

    jerrm Network Guru Member

    "Bars" are irrelevant. They depend on the quality of the signal. The unauthenticated client could be 1 bar or just as easily 5.
    The image was not posted by the poster who reported the issue. I would consider the image only showing an unexpired lease without anything "connected." Only the problem poster knows if it matches his scenario or not.

    That display would be consistent with either of my scenarios.

    If it is persistent, my skeptical assumption would be it is connected. As I said, with Shibby an invalid connection attempt drops within a few seconds.

    But the data is reported by the drivers and they are a black box. There could be a driver bug and an unauthenticated client may not be dropping from the driver tables. If it was/is a week signal, it could be the auth negotiation never completed, leaving the driver in some unknown state without dropping the client. Too many possibilities to list.
    koitsu likes this.
  7. Rastan

    Rastan Network Newbie Member

    Thanks for the info. I can try to unblock the mac address and keep an eye on which devices connect to find out if it appears again. I guess it's possible that someone in my area brute forced the password but typically when a device connects it's given an IP address. I know that this has been addressed already but this still seems odd to me.
  8. JoeDirte

    JoeDirte Networkin' Nut Member

    You could try changing and not broadcasting your SSID and see if that keeps the device from attempting to connect. If you don't see it - and I suspect you won't - then broadcast the SSID and see if the device tries to connect and displays the same behavior. It sounds like a device is out there scanning for connections, but without knowing the connection pw key, it cannot obtain an IP. Essentially, connecting at layer 2, but not at layer 3.

    If that doesn't fit, you may need to clear your NVRAM if you upgraded your fw without doing so. Odd stuff can happen if you don't erase NVRAM during fw upgrades. Not always though.
  9. Rastan

    Rastan Network Newbie Member

    I found out that the device belongs to a family member. I discovered this suspicious device several hours after she left my place on that day. I only discovered that it was hers the other day when she was over and told me that she wasn't able to connect. When I unblocked the mac address she was able to connect again.

    I don't know why my router was still picking up on her device several hours after she left. She doesn't live near me so there's no way it was connected. Thanks for all of the replies, the mystery has now been solved. :)
  10. koitsu

    koitsu Network Guru Member

    The next time this happens, providing output from ip -s neighbor list might be helpful. Please do not edit any of the output (including MACs; I cannot stress this enough). The default ARP expiry time on Tomato is 120 seconds, but before Googling around it's very important to note that the kernel used is 2.6.22; the methodology/model is different in newer kernels.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice