Status of network devices

Posted on 2007-08-08
Last Modified: 2013-11-05
I am looking for some advice on the best way to know if a TCPIP device is online? We are developing an Access control system which consists of a Server that contains the database and also runs a service which is how the access controllers valadate cards from the database. The controllers which have the card readers connected and also trigger the door to open. There are two situations why we need to know if the controller is connected as follows
1 at the server end there will be a utility that shows how many controllers are online - this is so an offline controller   can be detected and fixed
2 The controller needs to know if it is online otherwise it will default into its offline mode where it stores transactions to unload later. - ideally it would be best if the controller was aware it was offline before a card was presented otherwise it may be slow while it attemts to valadate the card then fails.

We have considered some form of polling either from the controller to the server, every second or so, the server will know that it hasnt received a poll from the device for over 2 seconds so its indication can show offline, the controller knows it didnt get a response form the server so it can fall into offline and continue to poll.
I doubt if polling is the best way to do this as polling was really used by 485 serial devices and I dont think it is appropriate for this sort of situation.
We also need to be minfull of introducing network traffic, and not using a method that get blocked on some peoples network - e.g Ping is often turned off on lots of networks.
I am keen for peoples suggestions and comments on this subject



Question by:monitorwa
    LVL 7

    Accepted Solution

    It's not easy to detect if something's not there without either polling, or 'heartbeat'.  Obviously if a device goes offline, the only way to prove that is either it's not responding, or it's not done something it's supposed to do.  I fyou want to do that in a timeframe then I'd suggest that polling (or heartbeat - ie device sends a packet) is going to be a necessary evil.

    If it were things other than 'offline' you were tracking (like an error condition when the remote was still alive) then you could look at (depending on the devices) SNMP traps which would reduce polling.

    Regarding a universal method - I'd say ICMP/Ping was your best best - if ppl are blocking ICMP - then it's a safe bet they're likely to block EVERYTHING that they don't specifically need (I know I do..).  ICMP is the lowest common denominator, and will be the easiest for ppl to allow (and carries little(r) risk than some other protocols)


    Author Comment

    Hi Telnetservices, thanks for your reply, As I mentioned PING or ICMP isnt really an option as some of our clients (quite a few) will block this and it will be a big issue to get them to allow.
    There must be some other way to do this?
    I would be surprised it some other systems dont use something similar?


    LVL 28

    Assisted Solution

    by:Bill Bach
    I think GL's response makes the most sense.  First of all, blocking PING is usually done at the external gateway to the network (in a firewall).  I have seen very few companies blocking PING traffic internally, as it is a very useful troubleshooting tool.  Most peop[le will block it at their borders, though.  If I understand the question, these access readers will be in the same building, thus on the local network, and a PING block shouldn't impact you anyway.

    Conversely, you can always implement your own system.  I assume that the server is setting up a LISTEN port at a given port number. This port number will need to be static so that the controllers can find it again.  Of course, THIS port will also need to be allowed through the network (and firewalls, if any controllers are remote).  

    The best solution then is a very simple protocol.  The controller runs a timer (say, 30 seconds) that is reset every time a transaction occurs.  If a transaction arises, it is sent to the server immediately, along with a number indicating the number of transactions pending and a block of data for those transactions (i.e. a variable-sized network block). When the timer expires, a 0-transaction request is sent.

    Now, for busy areas, you'll see accesses very rapidly, so the device will send 1-transdaction packets, and the server will authenticate normally and send a reply.  The idle timeout (30 seconds in this example) will ensure that some "heartbeat" is heard from every device periodically, and when the server receives a 0-transaction request, it can simply update the online list and return an ACK immediately.  When a device reconnects after a comm failure, if it has stored up multiple transactions, it sends a large request.  When the server receives a request with multiple transactions, the server then logs the requests only, assuming that the transactions were already authenticated.

    The real benefit of this solution is flexibility, as the same protocol can be used for the heartbeat, normal ops, and recovery ops.

    Author Comment

    Thanks for both of your comments, I think both answers have given enough of an idea to run with so I will split the points as I think thats the fairest way. Just a little more on one of the comment above about PING only been blocked from an external source - Some of the universities we do work for here in Perth Australia do block pings even internally, I think it has something to do some virus that flooded the network with pings (not that technical so am not really sure). The other point is that we intend for these controllers to run across the WAN as some of these places have multiple campus's which will all need to valadate back to one central server.
    thanks again


    Featured Post

    Top 6 Sources for Identifying Threat Actor TTPs

    Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

    Join & Write a Comment

    Great sound, comfort and fit, excellent build quality, versatility, compatibility. These are just some of the many reasons for choosing a headset from Sennheiser.
    This paper addresses the security of Sennheiser DECT Contact Center and Office (CC&O) headsets. It describes the DECT security chain comprised of “Pairing”, “Per Call Authentication” and “Encryption”, which are all part of the standard DECT protocol.
    Viewers will learn how to properly install and use Secure Shell (SSH) to work on projects or homework remotely. Download Secure Shell: Follow basic installation instructions: Open Secure Shell and use "Quick Connect" to enter credentials includi…
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

    729 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now