Announcement

Collapse
No announcement yet.

Random Downtimes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Random Downtimes

    Our Lantronix xPrintServer is inconsistent with its uptime. Often it can randomly go down and require a restart. What can be the cause of this and what are some solutions?

  • #2
    Did you check out this? https://forums.lantronix.com/forum/x...al-days-uptime

    Comment


    • #3
      Originally posted by 3DES View Post
      An interesting solution and one I would consider pursuing but before I try something like daily resets I am trying to see if it is possible to negate the need for such measures by preventing downtime to begin with.

      Comment


      • #4
        If you are using the Cloud functionality on the xPrintServer that is most likely 90% what is causing the issues.

        Outside of that when the down issue happens can you still reach the xPrintServer?

        Comment


        • #5
          Originally posted by TechSupport2 View Post
          If you are using the Cloud functionality on the xPrintServer that is most likely 90% what is causing the issues.

          Outside of that when the down issue happens can you still reach the xPrintServer?
          Yes, we are using Google Cloud Print. Our intention of purchasing the xPrintServer was to use it in conjunction with GCP. Is the device not really compatible with it?

          Comment


          • #6
            The xPrintServer is able to work with GCP. The issue lies with a firewall or a stateful monitoring security appliance on the network. Usually this is a Sonicwall, or at least in our finding 80% of the time a Sonicwall is envolved. The digital timer is the only method to keep the xPS from going offline. This by far is not the cleanest way to handle this, but is currently the only Lantronix solution. I also recommend this method as it fixes most customer concerns.

            Background of what is happening (Not required to read)
            So once the GCP is setup the xPrintServer check in with Google Cloud with a token to see if there are print jobs available. This token and communication is a very small data packet. Firewalls and Sonicwalls doing state-full minding later in communication will see a port that stays open and sends very little data over a time period and might think this is a open chat program and shuts the port down, until more then a few bytes go thru. When power cycling the xPrintServer the communication that goes out to Google contains a large amount of data. All the sign on, password, printers, if online, names of printers, and links for Google to send the data. This allows a new socket to be opened outbound and printing works again; works again until the state-full minding algorithm see the light traffic port again.

            Comment

            Working...
            X