1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Device list and wired clients

Discussion in 'Tomato Firmware' started by rs232, Sep 3, 2012.

  1. rs232

    rs232 Network Guru Member

    As it stands now I can see the list of active network clients under status-devices.asp, and as I understand this is info coming from at least three elements:

    arp cache
    DHCP lease
    wlan client list

    But... how can I identify if a client is on or not?

    I would have though the client list should provide primarely two pieces of info:

    1) what is "visible" (e.g. DHCP lease and static map)
    2) is the device currently active or not (e.g. any port opened or mac in the arp cache?)

    About this second point:
    wireless client list works great as I can see when a wlan client is on if the signal strenght is available or not.
    wired clients: on/off status is not available/precise. Let me explain, the "interface" is empty if the mac is not in the arp cache.

    I suggest we send a packet (rarp? to try to populate the arp cache) every time we load the device list page. This way we can safely trust a device is on/off based on what tomato reports.

    Perhaps something we might want to change here to get an accurate report of the network status...

  2. mstombs

    mstombs Network Guru Member

  3. rs232

    rs232 Network Guru Member

    Thanks for that, it would be great to have it integrated that in tomato!

    About the ping, I suggest the arping command that comes with busybox:

        arping [-fqbDUA] [-c count] [-w timeout] [-I dev] [-s sender] target
        Send ARP requests/replies
        -f              Quit on first ARP reply
        -q              Quiet
        -b              Keep broadcasting, don't go unicast
        -D              Duplicated address detection mode
        -U              Unsolicited ARP mode, update your neighbors
        -A              ARP answer mode, update your neighbors
        -c N            Stop after sending N ARP requests
        -w timeout      Time to wait for ARP reply, in seconds
        -I dev          Interface to use (default eth0)
        -s sender      Sender IP address
        target          Target IP address
  4. Elfew

    Elfew Addicted to LI Member

    Information about speed, ping and activity would be great! Contact Shibby! :D
  5. rs232

    rs232 Network Guru Member

    Another improvement I thought about would be to be able to assign an alias to a hosts without having to do a DHCP static mapping. This applies to any network client really not only wired.
    If somebody in my network has called it's laptop e.g. q3rgbq3irg2387rg3qiurbq3fiuw I would love to be able to specify "Jim" instead.
    Don't you think Jim? ;)

    The same concept applies to devices with no hostname. Some of my IP in device list are just blank (mostly mobile handsets in my case). I don't want to ask people to specify one on their devices, but if I could add a personal reference in tomato...
    What do you think?
  6. Elfew

    Elfew Addicted to LI Member

    Now you can set own name for any devices in device list...
  7. rs232

    rs232 Network Guru Member

    Hemmm how?
  8. Elfew

    Elfew Addicted to LI Member

    device list - static under IP adress and there is a hostname collum... save olalalala :ú)ú
  9. rs232

    rs232 Network Guru Member

    That way I have to set up a static IP. As mentioned I don't want to.

    The closest I could get to it is to put in Advanced/DHCP-DNS


    This way though it becomes difficult to manage. It shouln't be too difficult to add this to the GUI
  10. koitsu

    koitsu Network Guru Member

    What you just listed off is the exact same thing as static DHCP. The above line literally means: "map MAC address 11:22:33:44:55:66 to a hostname of fred, for any DHCP requests which come in". This has nothing to do with ARP (aside from the MAC portion). Please read the dnsmasq documentation.

    Furthermore, I strongly recommend avoiding use of arp broadcasting when reloading the device page. That just spews excessive ARP broadcast traffic on the network segment for literally no gain. Network administrators, if they read what you proposed, would shove you up against a wall and beat you repeatedly for it. You do NOT spam ARP broadcasts like this. It's very, very rude. It also doesn't solve the issue of ""stale"" ARP entries. Keep reading for what I expect you to propose WRT solving that and why that's also a bad idea.

    All I've determined is that you want "a way to see who is on your network presently". ARP cannot be relied upon for that because ARP caches expire periodically (i.e. "I haven't seen any packets from MAC xx:xx:xx:xx:xx:xx in a while, time to clear it from the ARP cache"). DHCP is probably your best bet, because protocol-wise machines which are shut down cleanly are supposed to issue DHCP packets that say "hey I'm done with this IP" (as well as for static allocations, but those remain there forever).

    Ideally what I think you'd want is this: some kind of timestamp indicating when an IP last issued a DHCP request. For those on the network which are using static IPs (not talking about static DHCP, I'm talking about actual static IPs), ARP is the only thing you can go off of. However, Linux does not provide a way, that I can tell, of when a MAC address was last seen in the ARP table. More specifically: /proc/net/arp and /proc/net/stat/arp_cache. This is very sad, because on FreeBSD this is provided in "arp -a", where it tells you how many seconds have passed since it saw the last ARP announcement from that IP:

    12:27:39 $ arp -a
    gw.home.lan ( at e0:cb:4e:c0:00:c4 on em0 expires in 1185 seconds [ethernet]
    icarus.home.lan ( at 00:30:48:d2:22:d0 on em0 permanent [ethernet]
    koitsu.home.lan ( at 1c:6f:65:d3:9c:d5 on em0 expires in 634 seconds [ethernet]
    12:28:06 $ arp -a
    gw.home.lan ( at e0:cb:4e:c0:00:c4 on em0 expires in 1176 seconds [ethernet]
    icarus.home.lan ( at 00:30:48:d2:22:d0 on em0 permanent [ethernet]
    koitsu.home.lan ( at 1c:6f:65:d3:9c:d5 on em0 expires in 625 seconds [ethernet]

    Note the "expires in XXX seconds" phrase. That value will get re-set to the ARP timeout interval (sysctl net.link.ether.inet.max_age, which defaults to 1200 seconds) when a packet is seen from that IP address.

    However, this is also not entirely accurate -- Linux, for example, spams the hell out of ARP (something like every 10 seconds announces itself), while Windows and FreeBSD clients do not do this. See the comparison between the output in the two above "arp -a" results for proof (client doing the "arp -a" commands is via an SSH to So again there's no easy way to solve this.

    Finally, if you propose that when loading the device list that the ARP cache be cleared thus new packets flowing would induce an ARP broadcast thus would "always indicate the freshest data", I will also propose that you be shoved up against a wall and beat repeatedly. No no NO. That will cause packet loss briefly until the ARP "who-has" request is responded to! Don't make matters worse!

    The only solution I can think of would be to implement a button -- meaning something the person has to do MANUALLY -- that causes all existing devices in the *existing* ARP table/cache to be arping'd. This is not the same as doing an ARP broadcast. Multiple announcements would be needed, as wireless is not a reliable protocol so one broadcast might be lost while a subsequent broadcast is seen/responded to. This also covers the situation with DHCP (for DHCP to even work, since it's an IP protocol, there must be a MAC address in the ARP table). Again -- this should not be done automatically (i.e. during page refresh), but manually only when clicked.

    What you seem to suffer from is micro-management of your network. If this is security-oriented there are ways to solve that entirely and not through repeated reloading of the device list page. :p

Share This Page