MiFi 4510L gets stuck in "dormant" state

[nsayer]

Here's an example of what I'm talking about:

System Log> HTML Version 26.

02/01/12 05:43:38pm> Current Time

02/01/12 05:43:24pm> LTE Out of Dormant State

02/01/12 05:43:13pm> LTE in Dormant State

02/01/12 05:42:48pm> LTE Out of Dormant State

02/01/12 05:42:40pm> LTE in Dormant State

02/01/12 05:42:28pm> LTE Out of Dormant State

02/01/12 05:41:36pm> LTE in Dormant State

02/01/12 05:41:11pm> LTE Out of Dormant State

02/01/12 05:41:02pm> LTE in Dormant State

02/01/12 05:40:43pm> LTE Out of Dormant State

02/01/12 05:40:22pm> LTE in Dormant State

02/01/12 05:40:02pm> LTE Out of Dormant State

02/01/12 05:39:51pm> LTE in Dormant State

02/01/12 05:39:22pm> LTE Out of Dormant State

02/01/12 05:39:21pm> LTE in Dormant State

02/01/12 05:39:06pm> LTE Out of Dormant State

02/01/12 05:38:58pm> LTE in Dormant State

02/01/12 05:36:14pm> LTE Out of Dormant State

02/01/12 05:36:08pm> LTE in Dormant State

02/01/12 05:35:56pm> LTE Out of Dormant State

02/01/12 05:35:53pm> LTE in Dormant State

02/01/12 05:35:36pm> LTE Out of Dormant State

02/01/12 05:35:35pm> LTE in Dormant State

02/01/12 05:34:24pm> LTE Out of Dormant State

02/01/12 05:34:23pm> LTE in Dormant State

02/01/12 05:34:05pm> LTE Out of Dormant State

02/01/12 05:34:01pm> LTE in Dormant State

02/01/12 05:33:01pm> First opening Index.html

02/01/12 05:27:18pm> LTE Out of Dormant State

02/01/12 05:27:17pm> LTE in Dormant State

02/01/12 05:26:54pm> LTE Out of Dormant State

02/01/12 05:26:53pm> LTE in Dormant State

At no time during all of that did the problem occur.

I cannot duplicate your assertion that the unit entering the dormant state is abnormal in and of itself. And, for what it's worth, that log represented a CalTrain trip from Redwood City to Santa Clara, so it's not as if I was standing still the entire time.

To be sure, the log is not particularly helpful - when the problem occurs, and I am able to clear it merely by checking for a firmware update, the log looks basically identical.

[wmhjr]

You are totally ASSUMING that the reason the device goes to a dormant state is due to power management.  I would ask you to provide proof.  I say this because I have proof that this is not the case in many instances.  While it may not be happening to you, it clearly happens to both myself and many others.  That is, the device going to a dormant state WHILE TRANSMITTING DATA.  I don't know how much more crystal clear that can be said.  Or perhaps it would be better to say that if power management is causing the device to go dormant, then it is still a defect, as in that case it would mean that power management is setting the device to dormant while the device is actively being used.

As I've said before, the log files are to me pretty much worthless.  There is almost no granularity in them, and AGAIN we must remember that the log files log only that data that the developers predicted use cases for during development, AND it assumes that they properly project the correct system state for the resulting syntax.  In this case where there are gross defects of high severity and there is little/no corresponding log data during those incidents, the best that one can conclude is that they just weren't smart enough to predict the issue and as such there is no corresponding error being written to the log file.  Put more bluntly, that it's even possible that an error condition is being reported by a log entry of "LTE in dormant state".

[nsayer]

At this point, as I believe I've said more than once, it's clear that our experiences differ. I do not believe that entering the dormant state is an error condition in and of itself, because the vast majority of the time my device enters the dormant state, it shows no sign whatsoever of malfunction. Isn't that the pain English definition of "error?" If it is not an error state - which again, I assert because of the lack of any malfunction - then is it not reasonable to say that it is likely a power management strategy?

You accuse me of projecting my experience on everyone else, and at the same time assert that my observations are wrong because they don't match yours. Pot, Kettle, Black.

[nsayer]

This does not work for me. I disabled SSID broadcast yesterday and this afternoon the unit got stuck in the usual way. Checking for software update fixed it, and I've turned SSID back on.

[jnosnih]

Thank you for posting your experience with this problem.

I live in a remote area in central Texas from which I telecommute.

I only use the device from my home.

I also keep it plugged into an A/C outlet, so I cannot imagine why it would be a power management issue.

It worked beautifully until December 2011.

I've been on the phone with Verizon reps numerous times since I began having problems.

Besides the advice to do a hard reset to my device by the initial reps, I've also:

•      had the SIMM card replaced; 
•      had the device replaced;
•      followed the the rep's advice to logon & change the device settings;
•      had the rep push down updates to the device...
•      attached an external antenna to the device.

None of these have corrected the problem.

The Verizon rep has now told me that a 'ticket' would be created on this issue & I'd be contacted by another Verzon support person. That was on Jan 30th, 2012 - I'm waiting for that contact.

[wmhjr]

nsayer, you refuse to acknowledge the point.  This is not a pot calling the kettle black.  I do not, and have never, indicated that you are experiencing the same issues.  Nor do I state that your "observations are wrong". I DO state that your CONCLUSIONS are wrong.  However, when you made the statement "That the connection goes dormant is routine. The devices do that to save battery"  and "If you have dormancy issues where vz.hotspot is always responsive, but not Internet sites generally, AND if either the mac filter or disabling SSID broadcast makes that not happen, then I'd be quite surprised." you totally disregard so many others experiences.

As said before, I don't experience (and never have) the 2 hr disconnect issue.  However, factually it is a known, real, issue.  Similarly, your statements above as written indicate no issues could possibly exist where devices go dormant when they should not.  That it's "normal" behavior resulting from power management.  There is absolutely no possible way on this planet that you can make that argument.  I'm very happy for you that you aren't experiencing those symptoms.  Others are.  Furthermore, when those issues occur, you have absolutely not the slightest knowledge (nor do we for that matter) as to whether power management has a single, solitary thing to do with it.  You are making vast, unsupported assumptions.  That's the problem.  And it results in clouding the issue with misinformation

There is already too much misinformation, so much of it created deliberately by Verizon.  We don't need others making the issue worse by stating "assumptions" as fact.  So, unless you're a firmware developer, having direct access to the uncompiled code and direct knowledge of this issue, I'd suggest refraining from defending this situation (going "dormant") as just a normal behavior resulting from power management.

[John_Getzke]

Has anyone ever found a true definition for Dormancy?  I dont believe we have one, especially in the 4510L manual or from any of the other threads that I have read on the subject.  A quote from a VZW engineer or rep would go along ways to confirm how this feature works or what it is intended to represent.

Here are my observations with my own device:

- Dormancy is not an error state, but a network status message

- Dormancy is logged on the device when there is no network traffic sent to/from VZW for a period of time

- Local traffic does not effect Dormancy (moving files between computers)

- Dormancy can apply after as little as 2 or 3 seconds

- The MiFi can be non-Dormant for hours at a time when streaming content (ex youtube, netflix, radio)

- Dormancy is not effected by wall/car chargers or the USB cable

- Dormancy cannot be configured on or off, it is automatic

- The MiFi will move in and out of Dormancy many times a day

[wmhjr]

John, I would agree with your statements with a couple more of my own...

-Dormancy can occur during traffic through the external interface.  Meaning, I have experienced the device going "dormant" in the middle of internet data transfer - not just moving files between two computers connectved via MiFi.

To be honest, I almost never ever use the device for anything other than internet access by devices.  I only move files between devices via the device for testing purposes.

[tim_lightfoot]

Much like several folks - our MIFI was bullet-proof until December.  Then, dormancy issues, connection issues, etc. caused us to do most things listed in these forums (including new SIMs, a replacement device, etc.).  We currently have a MIFI (it is stationary b/c it is one of the few ways we can get any type of Internet connection where we live) that constantly drops connection and/or freezes in the dormant state.

In rereading through these posts again, I found:

1) That when it is stuck in dormancy, querying for new software will pull it out;

2) If I turn off SSID, it becomes stable and doesn't drop out like clubtech5 suggested.

Solution 2 seems to work best - however, with SSID off, my other devices can't find the network, or if I put the computer to sleep, it can't find the network at that point.

So, I tend to agree that there is a firmware issue and am willing to entertain any solutions to help my devices find the network without the SSID on (and I've tried manually entering the network name in the Find Network dialogs).

BTW:  On a Mac Leopard system and the Mifi is 2.23 (and yes, I successfully bricked one mifi trying to upgrade to 2.23).

Thanks for any insights from those of you that know more about this system...

Cheers!

Tim

[John_Getzke]

@tim_lightfoot

Chances are if you have read this thread then you have already tried all known solutions and work arounds for dormancy issues.  The only other areas that you can play around in are the external devices and accessories.  Some examples include external antennas and wireless repeaters like the PepWave Surf. 

An antenna/booster combo would ensure you have the best possible connection to the local towers incase signal strength or overloaded towers are an issue.  Since repeaters can create thier own SSID's they would allow your devices to connect to a visible SSID while the MiFi retains its hidden SSID.