Heads up! Today I was doing some routine maintenance for a customer site on their RUTX11 (7.15.2 firmware), when a banner appeared at the top of the GUI saying “important update for modem firmware available”
“What the hell” I thought, “they’re using the hardwired WAN connection anyway”. So off I went, after about 5 minutes, I got some alerts from my monitoring software that the site was offline. Sure enough, I could no longer access the device, and soon after the office called me to say that the “internet was not working”
I told them to wait (was worried about resetting the device in the middle of what I assumed was a flash operation). But, after 25 more minutes went by, I had no choice—I instructed them to unplug and re-plug.
Thankfully the device booted back up, and appears to be working normally. The modem firmware seems to have updated as well.
Here’s a screenshot I was able to capture before the device went belly up:
I see that your device has updated the modem firmware from EG06ALAR04A01M4G. Could you please let me know which firmware version it was updated to?
Thank you.
Thank you for the information. I have forwarded it to our RnD team, and I will let you know as soon as I receive any feedback from them regarding this.
Our developers haven’t found a direct link between WAN cable connectivity and the modem firmware update. However, there have been occasional cases where the internal switch on RUTX devices may hang, requiring a full device restart.
It seems this was likely just an unfortunate coincidence during the update process.
That is more than unfortunate - Is there any way to detect that switch error condition and self-correct by automatically restarting? This is very disruptive if the device doesn’t have mobile SIM connectivity, as it then requires a truck roll to reboot the device. If there was a way for the software to tell when the WAN link was dead in this way due to the switch being crashed and self-correct it would at least avoid this costly error.
We understand your concern about device disruptions and the need for self-correction.
Without specific logs, we can’t confirm an Ethernet hardware issue; other factors might be at play. If this recurs, detailed logs are crucial for diagnosis and exploring solutions.
