Anybody Having Trouble Today?

[Russell]

Glad to see. See, sometimes opening a ticket really does work.

Tim,

Now that you've had the satisfaction of saying, "I told you so" :-), would you be kind enough to let me (and other curious readers) know what kind of "adjustments" were made on my account? As previously mentioned my setup could not be more vanilla: RT31P2 connected directly to the UVerse router (which Brandon has successfully tested with numerous devices). 12Mbps/1.5Mbps service UVerse service.

[VOIPoTim]

Tim,

Now that you've had the satisfaction of saying, "I told you so" :-), would you be kind enough to let me (and other curious readers) know what kind of "adjustments" were made on my account? As previously mentioned my setup could not be more vanilla: RT31P2 connected directly to the UVerse router (which Brandon has successfully tested with numerous devices). 12Mbps/1.5Mbps service UVerse service.

It's not really as simple as saying that a certain router or network setup needs X done to work well. It's more about looking at everything including our logs to see how the traffic is flowing and where errors are.

Every situation is unique. Even a minor firmware version difference in a router/modem can mean that the two versions need complete opposite tweaks applied. Just like we don't have scripts for support, we don't have specific things that are done with different models.

Support reps will simply just look at it, look at the traffic, diagnose, and then change it so that the traffic starts looking valid and problem-free.

For example with audio issues, customers may insist it's a "cheap router", a bad device, etc but one quick look in our logs may show the audio stream stopping when it hits their router. We also see a ton of cases where the traffic is coming through but is being "deformed" by a SIP ALG on the router, etc. These are all cases where we can take a look and between seeing the logs, the network setup, etc diagnose.

Support can determine what needs to be done and do it. That's why we encourage everyone to contact support. Contacting support is the always going to be the fastest and most efficient way to get problems resolved.

[Russell]

I'm not sure if it's coincidence or not but right in the middle of a Skype call the RT31P2 decided to reboot. Obviously, the Skype call got dropped. My setup: computer connected to RT31P2 connected to UVerse box.

[VOIPoTim]

I'm not sure if it's coincidence or not but right in the middle of a Skype call the RT31P2 decided to reboot. Obviously, the Skype call got dropped. My setup: computer connected to RT31P2 connected to UVerse box.

If it's happening frequently, then just contact support to work through it.

A periodic reboot is normal though. How long had it bee since it rebooted?

If the devices aren't rebooted periodically, they will reboot (typically weekly) to download the new provisioning file in case there are updates. We can't really push any changes to them without a reboot so it's important to have them reboot periodically to process changes.

A periodic reboot is also needed just to refresh the device. They will not stay on and work well indefinitely without a reboot. If they are on more than a week or so without a reboot, you'll start having dropped calls, poor voice quality, lost registrations, and just general erratic behavior. There's actually a thread on DSLReports now where people are discussing if Linksys VoIP devices need a reboot periodically and the majority opinion is yes that they get very unstable if not rebooted periodically.

http://www.dslreports.com/forum/r248...est-recreation

Finally, another case where a reboot may sometimes be needed is in a failover scenario on our end where we're re-provisioning the device to another server. In a case like that the system will typically send a reboot signal in the SIP headers to the device.

[Russell]

If it's happening frequently, then just contact support to work through it.

A periodic reboot is normal though. How long had it bee since it rebooted?

If the devices aren't rebooted periodically, they will reboot (typically weekly) to download the new provisioning file in case there are updates. We can't really push any changes to them without a reboot so it's important to have them reboot periodically to process changes.

A periodic reboot is also needed just to refresh the device. They will not stay on and work well indefinitely without a reboot.

Not sure if there's anyway to determine past reboot history. If there is tell me how and I'll look it up. Just checked and it's now been running for 08:21:07 which makes the reboot time when I was in the middle of my Skype call (a little after 10 am local time).

May I suggest that the periodic reboots to refresh the device be done in the middle of the night. Ideally, it'll be a control panel option as to when this should take place with the default being something like 3 am - I'd choose the middle of the night based on our family schedule.

[burris]

Would there be any purpose for the BYOD users who don't have provisioning enabled to do periodic reboots?

[MisterEd]

My ATA has been up for periods of 16 days recently (that I have noticed, there may have been longer periods). Right now it's 9 days 11 hours. When I first got it it would reboot every 45 minutes like clockwork and drove me nuts because all my phone indicator lights all around the house would flash bright red with each reboot but support fixed that.

Maybe once a week would be a good compromise or even every day if it was done at 2 or 3AM and not during the middle of the day.

[Russell]

My ATA has been up for periods of 16 days recently (that I have noticed, there may have been longer periods). Right now it's 9 days 11 hours. When I first got it it would reboot every 45 minutes like clockwork and drove me nuts because all my phone indicator lights all around the house would flash bright red with each reboot but support fixed that.

Maybe once a week would be a good compromise or even every day if it was done at 2 or 3AM and not during the middle of the day.

I couldn't agree more. Looking at the uptime on my ATA it looks like another reboot occurred yesterday afternoon around 2:10 pm.

[tritch]

I couldn't agree more. Looking at the uptime on my ATA it looks like another reboot occurred yesterday afternoon around 2:10 pm.

As a non-provisoned BYOD user, I'm not sure if this applies to your case but it might be wise to take a quick look at the data traffic to the ATA (Wireshark, etc.) using the timestamp of the reboot as a basis of analysis. I say this because you have UDP ports 5004-65000 open (much like myself until recently).

I recently started having strange random reboots on my ATA, sometimes frequently every day. By accident, I just happened to be watching the ATA when suddenly the ATA activity light started to rapidly flash along with the DSL activity light, then the ATA self-rebooted followed by 2 similar events and self-reboots all in about 30 second time span. The activity looked similar to a DoS attack and I suspected somebody was trying to hack the ATA. I installed a debug logger and waited a few hours for another ATA reboot. Sure enough it happened again, and the debug log revealed I was being hit by a "sipvicious" scan tool followed by hundreds of attempts to crack my password using unused open SIP ports. In my case, it was hitting unused ports 5064, 5074 and 5075. The IP address of the hacker was coming from China. Fortunately, I have a fairly complex password, so nothing was compromised. I also have international calling blocked in vPanel as a safeguard. What's amazing is that I released/renewed my public IP on the DSL modem and within a few hours I was hit again!!

Needless to say, I had to close up a lot of the open UDP ports in the router that were not being used by Voipo to stop the attacks. I did leave some ports open that I felt were needed to avoid any potiential dead air issues.

These are the only UDP ports that I have open now:
5004, 5012, 5079 and 35000-65000.

So far so good.....no more reboots and service is working great with no issues.

[Russell]

I tried looking at my router logs but my naive eye didn't catch anything. Another reboot earlier today when there was no one at home and based on the call logs no phone traffic. I do have a ticket open ... lets see if what comes of that.