Biometrics device ping becoming failed after sometime

Question

I have ZKTeco Biometrics device which is connected with a C# windows application using This tutorial (C# ZKTeco Biometric Device Getting Started).

It is working fine but after sometime, my application becoming failed to ping the device. As below code suggested, I am trying to ping the device after every 25 seconds.

  private void TimerCheckPingAndCloseAttendanceForm() {
  timerCheckPingAndCloseAttendanceForm            = new Timer();
  timerCheckPingAndCloseAttendanceForm.Tick       += new EventHandler(CheckPingAndCloseAttendanceForm);
  timerCheckPingAndCloseAttendanceForm.Interval   = 25000;//25 seconds.
  timerCheckPingAndCloseAttendanceForm.Start();
        }


 private void CheckPingAndCloseAttendanceForm(object sender, EventArgs e) {
     string ipAddress = tbxDeviceIP.Text.Trim();
     if (UniversalStatic.PingTheDevice(ipAddress) == false) {
           //CloseAttendaceListForm();
           IsDeviceConnected = false;
           string infoString = "Application started on " + applicationStartDateTime.ToString() + " and ping failed on " + DateTime.Now.ToString() + " then, app closed while device ip is "+ ipAddress;
          File.AppendAllText("ConnectionLog.txt", infoString + Environment.NewLine);
          Application.Exit();
          //timerCheckPingAndCloseAttendanceForm.Tick -= new EventHandler(CheckPingAndCloseAttendanceForm);
            }
        }

And when I am trying to ping the command from cmd the device show destination host is unreachable. But whenever I restart the device, the ping working fine. I don't know where is the problem? Either the network problem or its coding issue?

Note: I am doing a ping on regular time interval, because on Disconnected Event is not working. I am assuming ping failed meaning is the device has disconnected with the application.

Answer 1

This sounds like the device misbehaving. The error "destination host is unreachable" corresponds to an ICMP packet, same type of packet as ping but different job, being sent by your router saying "I have no idea which device has that IP". This normally happens when the device stop responding to ARP, which basically asks "who has this IP?" and expects a machine to respond "I have it" with its MAC address. The router constantly refreshes its ARP table, forgetting old values.

So when you boot the device it is 'happy', responding to ARP and responding to pings; however, something happens and it at least stops responding to ARP (probably something more wrong with it). Depending on its architecture it could be loaded down doing other stuff and unable to respond, or it could just be locked up.

Try slowing down other actions to the device (if your polling it for information other than ping, do it slower) and also see if you can get status from the device via another output (does it have a uart?).

Answer 2

OPTION 1

Since that restarting the device fixes your problem for a period of time, check that the IP that you are using is not in use on another device/computer/element_of_the_network.

ZKTeco devices come with the IP 192.168.1.201 configured by default. Configure a different static IP and avoid using DHCP (it´s well known that using DHCP in ZKTeco devices isn´t a good choice since they don´t refresh automatically the IP after rebooting the system or any network change).

Make sure that the IP is not in use and that nobody else will use it.

OPTION 2

Another thing that It may be the cause of your problem, is that you are using zkemkeeper in a different part of your application (or into a different application) and you are not closing the oppened connections properly... That may be blocking all network activity from the device. To close the connection just make sure that you call this sdk method after performing all the necessary actions:

sdk.Disconnect();

Answer 3

It looks like a code issue. While investigating UniversalStatic.PingTheDevice(ipAddress), its found that its calling System.Net.NetworkInformation.Ping.Send setting DontFragment = true. Reference: https://github.com/zaagan/BioMetrix/blob/master/BioMetrixCore/Utilities/UniversalStatic.cs#LC51. The timeout for the ping is set to 120 milli seconds. This tries to send 32 bytes of data to the given IP.

Following is the snippet taken from https://learn.microsoft.com/en-us/dotnet/api/system.net.networkinformation.ping.send?view=netframework-4.7.2 would answer the root-cause of your issue

If the DontFragment property is true and the total packet size exceeds the maximum packet size that can be transmitted by one of the routing nodes between the local and remote computers, the ICMP echo request fails. When this happens, the Status is set to PacketTooBig.

So when you restart your device, possibly, the data travelling on the network gets lost. Hence it started working till the packets reaching its limit.

Few suggestions:

• Try calling System.Net.NetworkInformation.Ping.Dispose in PingTheDevice before returns
• Increase the timeout from 120 milliseconds to seconds.
• Increase the timerCheckPingAndCloseAttendanceForm.Interval to 1 min.
• Check the return code of the System.Net.NetworkInformation.Ping.Send and find the associated failure meaning

Please share your findings if the above suggestions do not help you finding the root-cause.

Answer 4

Not having the actual code and the hardware setup, this answer is a bit of a shot in the dark, but here goes …

Since it works initially, this is not a hardware configuration or network configuration issue. Yet it says that after a while the destination (reader) becomes unavailable. This is probably not a network keepalive issue because you are pinging every 25 sec. Looking at the code that you referenced, it shows opening a connection and hooking up callbacks, and making a call to a hardware feature.

My guess would be maybe you are opening the connection each ping and not closing the connection, then after a number of attempts the hardware jams because there are too many open connections. Just a guess. If this is the problem then to fix it, either close the connection or, better, keep the connection open and re-use it.

Alternative possibility would be that the router(s) between your code and the device are detecting too many pings and blocking the connection as a possible DOS attack. If this is the problem then to fix it, configure the router to allow the traffic.

Answer 5

First of all : Thank you for going through my article

You are doing it the wrong way.

Trying to ping the device after every 25 seconds is unnecessary.

The only job of the UniversalStatic.PingTheDevice method is to check if the device is presumably active, the first time you connect with the device.

If you want to check the status of the device i.e IsDeviceConnected, All you need to do is register to the device OnDisConnected event provided by the SDK.

It seems the code here at line number 57 has already done the OnDisConnected event registration for you.

All you need to do now is set your IsDeviceConnected to false when the objCZKEM_OnDisConnected method in the ZkemClient.cs class is called upon by the device itself.

Sample snippet : In the ZkemClient.cs class file, between line number 81-84

void objCZKEM_OnDisConnected()
{
     IsDeviceConnected = false;  // <-- Add this line
}

Now, Every time you try to make a call to the device, All you need to do is check for the value of your IsDeviceConnected.

Answer 6

you try this code for ping the device,

try
        {
            IPAddress ipAddress = IPAddress.Parse(ipAdd);

            Ping pingSender = new Ping();
            PingOptions options = new PingOptions();
            options.DontFragment = true;

            // Create a buffer of 32 bytes of data to be transmitted. 
            string data = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
            byte[] buffer = Encoding.ASCII.GetBytes(data);
            int timeout = 120;
            PingReply reply = pingSender.Send(ipAddress, timeout, buffer, options);

            if (reply.Status == IPStatus.Success)
                return true;
            else
            {
                return false;
            }
        }
        catch (Exception)
        {
            return false;
        }

Thanks.