HT 802 stops and requires cycling power every day

#1

I’m seeing others with similar issues but no resolution.

I have a site that has had an HT802 providing dial tone to two FAX machines for nearly 4 years without issues.
In the past month, the user has had to restart the HT802 each morning to get it to work.

I replaced the HT802 yesterday with a new one. I also moved its network connection from the back of a phone (should be for a PC) and connected it to another wall jack that’s directly patched to the network switch.

I got word this morning that the HT802 had to be restarted again.

I can understand the old one being OLD and needing to be replaced. But having a 2nd one doing the same thing.
When I replaced the unit, I used the NEW power supply that came with the new unit along with a NEW patch cable that also came with the new HT802.

I have opened a ticket with support, but figured I’d also ask here to see if anyone has resolved this on the HT802’s.

Both units have the latest firmware available. I don’t see any BETA versions or any notes referring to this issue on the firmware notes.

#2

So how is the HT setup with regard to the NAT of the site? How does it keep responses flowing to and from the SIP provider such that the firewall does not close?

#3

the PBX and device are on the same LAN infrastructure. The PBX is 172.16.31.20 and the device is 172.16.71.52.

there’s a L3 switch that provides unblocked routing between the two VLAN’s.

The device had been running since 2019 without issues. And the user started complaining that she has started to have to reset it every morning for about 3 weeks now.

#4

Are keep alives enabled? If not, you might give that a shot. Normally, I would not advocate it, but perhaps the lack of data being generated causes the port switch to go green.

#5

which options need to be enabled?

I see something on the Advanced Settings - the Keep Alive Interval is set to 20 seconds.

In the FSX ports, I see:
NAT Traversal = NO - the options are: Keep Alive, STUN, UPnP and VPN

Enable SIP Options/Notify Keep Alive = currently set to NO. the other options are OPTIONS and NOTIFY.
SIP OPTIONS/NOTIFY keep alive interval = 30 seconds
SIP OPTIONS/NOTIFY Keep alive Max Lost = 3

#6

There is no NAT traversal so leave as No.

In the SIP section, enable the keep alive and use Options with a frequency of 30 sec. Max lost at 3 is OK as well.

#7

We ended up replacing it with an HT812. The issue cleared and the user hasn’t had to restart the device since.

#8

Interesting, that perhaps points to a firmware bug in the HT802 software, which is not there in the (slightly different) HT812 software?

Thanks for coming back to update us!

#9

Having the same problem with my HT802!

For me the problems started on 29 March, after months of running fine.

I think I’m running firmware 1.0.45.2, as that’s the version numbers showing for Base & Prog. Though Boot & Core are only 1.0.45.1, and CPE is 1.0.4.54.

The device requires power cycling at least every day (today it needed rebooting within 20 hours). When the devices freezes, I can still ping the HT802 and get replies - so it’s still alive and running in some way. But it has disconnected from the SIP provider, and the HT802 does not respond to trying to log in via SSH or via web interface. Handset has no “dialtone” and so I can’t access menu options that way either.

I tried enabling Keep Alive in the SIP section, using Options with a frequency of 30 seconds & Max Lost = 3. No luck, the device still keeps falling into this “frozen” state every day. Since the device seems to be crashing, I expect Keep Alive isn’t the problem in this case anyway.

#10

I don’t have this problem with the latest fw,
try setting the keep alive to 10 seconds, and disabling the SIP ALG on the router/firewall,
NAT and other settings to review,
if the problem persists, you can contact Grandstream Support

#11

Thanks for the fast reply. I tried setting Keep Alive at 10 seconds (and already had the device set to reboot every day at 4am), but the problem is continuing.

I don’t think the issue is related to firewall & NAT. The issue is not so much that the device loses connection, it’s that the HT802 device gets itself into a frozen state. (Obviously, when the HT802 freezes / crashes, the connection is also lost.) When in that state, it won’t even respond to a handset plugged physically into the device (ie can’t even press *** to get to “Enter A Menu Option”). That’s something that would normally work even when the HT802 is physically unplugged from the network.

I’ll try the help desk, and will try to report back if I identify what triggers the issue and/or a fix.

#12

To follow up - while none of the suggestions above helped me, I seem to have found a workaround. My HT802 has now been running successfully for 2 weeks without needing a reboot, due to one surprising setting change I made:

I switched Automatic Upgrade to No.

I previously had Automatic Upgrade turned on and set to Daily. This could account for why my device required power cycling daily, if something in the Automatic Upgrade process was causing the unit to hang. My unit shouldn’t have required any firmware upgrades as it was already on the latest firmware, but I note that the Grandstream HTTPS certificate changed on the same day (March 29th) that I first started having problems.

This isn’t a very satisfactory solution, but at least I have inbound calls again, and I don’t have people contacting me out-of-band to say that my phone system is down yet again.

So for anyone else having this issue, consider changing that setting and testing if it fixes things for you. But if you do, obviously, you’ll need to keep monitoring the Firmware page manually for updates instead.

#13

I was experiencing multiple HT802 units becoming unresponsive almost daily, requiring power cycling to recover.

5 days ago, I downgraded to the previously available firmware (1.0.43.11).
I also had an automatic upgrade (on boot) and configured a power cycle every morning. I have kept the power cycle schedule but turned off automatic firmware update.

With this change, I haven’t had an issue so far so it looks like there is a bug with the latest firmware (1.0.45.2). What this bug is, I don’t know. It didn’t appear to be the auto-upgrade process that caused the issue since the issue would appear at different times.
I also noticed there was a naming change to the HTTPS certificate between the 2 versions but I’m not sure if that’s related.