0

Devices not checking in, how do I remotely reboot them?

David Johnston

February 06, 2018 16:40

None

Follow

I have some devices at remote locations that were offline for a few weeks during some network changes. The network came back online but the XT devices did not come back up. The network they are attached to is active and the link light is on, but they are not changing status in the BSNEE. I also attempted to send the reboot commands using the BSN, but this failed.

Would I be able to send a UDP remotely via Putty to signal a reboot to these devices? 

Need to know before we send techs to the location to manually restart them.

 

• Facebook
• Twitter
• LinkedIn

20 comments

• 0
  
  Allen H. Porter February 06, 2018 17:59

  This may not help much but we have tested these players extensively and regardless of how long they were off network, when the network came back, the player came back.  That suggest that there is something different on the network.

• 0
  
  David Johnston February 06, 2018 18:26

  That helps, however, I have an XT device right next to me and its not updating its status in the BSN. This device was a test device that I had working fine. Its been off for a few weeks and I thought it would be a good example of what Im seeing. 

  It looks fine as no errors, has an image and is displaying fine video. But it does not update its status in the BSN and I cant remotely manage it. 

  So do you know if its possible to remotely reboot this thing with some method other than with BrightAuthor?

• 0
  
  Allen H. Porter February 06, 2018 19:03

  Only if you know it's IP address and can real its URL.  All players have an internal web server for management.  When you reboot the device next to you it should briefly show the IP assigned to it.  Removing the micro_SD card will cause the player to pause on the diagnostic screen where the IP, MAC, serial, and firmware are listed.

• 0
  
  David Johnston February 06, 2018 19:22

  Thanks Allen,

  These remote devices don't have the diagnostics web server turned on due to security reasons. If it checked into the BSN I could turn it on but these arent checking in. Thats why I need a direct shot to the device over the network. Not being an expert in UDP, I was wondering if anyone was able to restore an un reachable device by hammering it with something over the network.

   

   

• 0
  
  Brandon February 06, 2018 20:18

  Are the player's showing "Last connected (some past date)" in the Advanced tab of their properties? If it's showing Error 403, they are connecting, they just don't have active subscriptions.

  Can you confirm the players' configured time server is still accessible? If they were empowered for weeks they would have lost their click setting, and a reasonably correct clock is necessary for HTTPS communication which BSN uses.

  Players will only respond to inputs specifically listened for in the running person. There isn't a default set of commands.

  If they're on PoE power you may be able to cycle the press from the switch to reboot them.
  Likewise if they've on a controllable power outlet.

  Otherwise without the DWS enabled, there isn't much you can do from the network that wouldn't look like some kind of attack (UDP flood, etc) and be likely to adversely affect the other devices on the network.

  Someone on site would have to power cycle them, though that may not fix the problem.

• 0
  
  David Johnston February 06, 2018 20:29

  The player is showing in the advanced tab: "No connection since 23 Jan 2018 06:29:22 UTC"

  I checked the log on the SD card on one of these devices and it was having a "time sync error and was going to try again in 30 seconds" something like that. Oh and we tried the PoE reset via switch and they still do not check in.

  Im working with my test device now and I did a complete factory reset, formatted the SD card and put on it the files for it to join a test group. Upon reboot, Its icon in the BSN is still showing offline and no check in time since Jan 23rd.

  It like the device object in the BSN is stuck and will not accept any updates even after a factory reset and SD card format. This is affecting about 40 of our 1000 devices. making me a little worried to be honest.

• 0
  
  Brandon February 06, 2018 20:34

  It sounds like the network change is more preventing the player from reading the time server.
  Since the player was not powered for an extended period of time, the internal clock setting was lost.
  If the player can't set its clock, HTTPS won't work and it can't connect to BSN.

  Run the Network Diagnostics on the player you have access to to confirm or can reach the time server.

  The log should also show what server it's trying to connect to.

• 0
  
  David Johnston February 07, 2018 16:06

  I am working on the device that is next to me that does not update in the BSN. I replaced the SD card in the defective device from a working device and the video displays perfect. However, the BSNEE object does not refresh. 

  So I decided to format the card and copy in different config files and then rebooted. With the new Config, the device came up and updated in the BSN.

  That is good information, knowing that the device eventually updates, but Im guessing we will have to have someone actually go to these locations and resolve these devices. 

   

   

• 0
  
  David Johnston February 07, 2018 16:12

  So the original question, is there is some way to reboot these devices over the network that would allow me to force a reboot without using the web controls or a PoE power off. Is there not a way I can send a UDP command to it that will force it to reboot or turn on the web server?

• 0
  
  Allen H. Porter February 07, 2018 16:24

  You can’t swap an SD card from one player to another unless you format it/put new configs on it.  We don’t use BSN but we run our own BSNEE and each player has unique info on it that will not work in another player.  UN and PW for one.

• 0
  
  Allen H. Porter February 07, 2018 16:25

  As Brandon said above (he is BrightSign), there isn't a way to do this unless you had already built a UDP listen function into the current Presentation running.

• 0
  
  David Johnston February 07, 2018 16:29

  Thanks guys, do you think that modifying our presentations to enable UDP would be a good preventive measure? What do you guys use to keep a back door open if one of the devices go offline?

• 0
  
  Allen H. Porter February 07, 2018 16:47

  99% of all issues are client network related.  BrightSign players almost never fail.  If you use BrightSign sold SD/micro-SD cards they almost never fail.  This is the most reliable player I have ever used...only somewhat matched by the Spinetix player.  And that player is 3X the cost with fewer features.

   

  So the answer is, "we don't" keep a backdoor into the players because with 99% of the issues, the network is gone anyway so the backdoor doesn't work.

   

  We do run a few customers with VPN tunnels between us and them and we can get to the player via its onboard DWS.  But mostly that tunnel was left over from a previous project where the player needed that.  Generally cloud management of these players is sufficient.

• 0
  
  David Johnston February 07, 2018 16:54

  Yea, I hear you,

  the devices we have that were setup and have been online have not had a problem. However, if we setup a device and then it was offline for a week or more, these devices don't come back online. It doesnt seem to be a network issue as I have been testing my test devices and two have reproduced the error. They have been offline for a week or two. 

  Im about to confirm this with a third LS device just to be sure. This like the others, have been on a shelf for about two weeks, meaning they were in our BSN and displaying media, then just powered off.

  Lets see what happens with this LS.

• 0
  
  David Johnston February 07, 2018 17:06

  Hmm, LS came up and updated in the BSN just fine. Seems maybe an issue with XT devices? I think I have one to test to see what happens...

  Update: Only had an offline XD device and it seems to have updated without issue as well.

  From what I can tell, its the XT devices that seem to be having this issue. 

• 0
  
  Allen H. Porter February 07, 2018 18:21

  I have very few LS devices and many XT1143s running firmware 6.2.94 and 6.2.147.  I have never seen the behaviour you describe.  And we have had players offline for months at a time in some cases.

• 0
  
  David Johnston February 07, 2018 18:59

  I don't disagree, I am going to test by letting my xt devices set over night plugged in but disconnected from the network. I expect to see them showing Offline tomorrow. I will simply reconnect the network and see what happens. I have two XT and one LS as a control device.

• 0
  
  Brandon February 07, 2018 20:30

  Is this BSN (cloud-based) or BSNEE (local server)?  You mentioned BSNEE earlier, but maybe was just a typo.

  Can you confirm your XT has a valid date/time via the DWS Info tab, Network Diagnostics, or Log?

  Are you using static IP or DHCP-supplied addresses?

  Applying new setup files would've also updated the configured time server, so if the device was configured with a different and now-inaccessible time server, but the time server from the new configuration files is accessible, that would explain why the new setup files fixed it.

  XD3 and XT3 devices use the same firmware, so we really need to figure out what's different between the firmware and/or configuration of the working XD3 and non-working XT3 here.

• 0
  
  David Johnston February 08, 2018 14:30

  Both XT and LS devices came back up and updated themselves in the BSNEE. So I was not able to reproduce the issue with an outage of ~12 hours.

  I am going to power them off as well as disconnect them from the network and see if I can reproduce the issue throughout the day.

   

  But to answer your questions:

  1. BSNEE local server

  2. DWS Info Tab? Not sure where to determine if the time is valid. Should I just compare to local time?

  3. DHCP

  4. Both XT test devices are using the new Config Setup files. 

• 0
  
  David Johnston February 12, 2018 14:26

  So the newly reconfigured devices are not reproducing the error after being offline for a few days. Also, We addressed a one of the original devices in a field location and found a defective CAT 5 cable attached. So the devices seem to be not checking in mainly due to network hardware failures. 

  Will update if needed.