MiFi 4510L gets stuck in "dormant" state

[nsayer]

Firmware v2.23 is far and away better than the older firmware, but still, once or twice a week, the device will fail. The symptoms:

1. WiFi is still connected, but any data I/O simply hangs.

2. vz.hotspot responds, and shows the connection state correctly, except that it is "dormant."

Hitting "Disconnect" waiting and then hitting "connect" works around the problem and brings the connection back up.

The "dormant" state is not sufficient to identify this problem - the mifi connection is often dormant, but when you start doing something, it typically "un-dormants" itself and operates normally. Only sometimes - once or twice a week for me - does it wind up in a state of semi-permanent dormancy.

[nsayer]

I must be luckier than you, then. I've not had it not listen to me when I tell it to stick with either CDMA or LTE (at least since upgrading to 2.23). During the last LTE outage, forcing it to CDMA only was necessary to avoid disruptions while it attempted to upgrade the connection periodically, in fact. I've also been satisfied with the speeds - rarely do they dip below 5 mb/sec, and most of the time, they're 10mb+. The only problem I have is the dormancy issue.

Either you're experiencing something different from me, or I have lower expectations. It's unclear to me which is the case.

[wmhjr]

Yeah, I'm actually a little surprised myself.  It's really only been relatively recently that the device has routinely ignored setting to "LTE Only" for example.  Previously it would at least follow those instructions - though clearly it would still go "dormant" on a very routine basis.  I'd say in an 8 hour day, it would happens at least 50 times that I notice.  Probably far more.  In some cases, the issue only lasts for a few minutes.  Sometimes it requires bouncing the 4150.  For the record, it is CLEARLY not a WiFi issue.  I have never had a single instance where I lost the Wifi connection. 

For speeds, they vary significantly.  That being said, for the record I am now connected on the 4150 via LTE.  I have full signal strength.  Just did a speed test.  2932 down, 600kb up.  72ms latency.  Did another one at a different site.  2302 down, 698 up, 66ms latency.  Yet a 3rd one on yet another system was 3245 down, 810 up, 167ms latency.  Frankly, these aren't terrible.  Also, admittedly, any of the online speed tests are only decent "guides".  They're really not all that accurate - meaning you may well actually have better - or worse - actual performance than what is reported.  The upload is obviously pretty weak.  The latency isn't great all things considered.  But it would be OK, just not "awesome".  You typically don't see me complaining about the speed so much.  You do see me complaining about the total lack of reliability. 

[nsayer]

That the connection goes dormant is routine. The devices do that to save battery. Mine goes dormant all the time. Only once in every, say, 100 times does it fail to come *out* of dormancy when I try to do something. Every time so far that it has gotten stuck and I've tried to go do a firmware update check to shake it loose, it has worked.

I'm going to try disabling the SSID broadcast this evening, though frankly, leaving it like that is going to be quite inconvenient, as it means that connecting to it will require typing all the details again.

[wmhjr]

Um, sorry but I have to disagree VERY strongly with the statement "That the connection goes dormant is routine. The devices do that to save battery".  I would strongly encourage you to read the feedback of the symptoms being experienced by so many others.  Mine often goes dormant within 90 seconds of booting up.  Sometimes it doesn't go dormant for an hour.  Though I have no scientific measurement, I would say that perhaps 35% of the time it "comes out of dormancy" when "I try to do something".  Of the remaining approximate 65% of the time, I'd say that half of the time if I just wait long enough (which can be several minutes) it comes back on its own.  The other half requires taking more serious action.

In any case, it is ABSOLUTELY NOT THE RESULT OF POWER CONSERVATION.  Period.  As a matter of pure fact, more than 90% of the time I have the device plugged into AC power when I'm using it.  And beyond that, the fact that it goes dormant kills it's effectiveness when using applications that require the maintenance of session state.  I have not tried the "firmware update check" but I can say that approximately zero percent of the time, a "disconnect" and then "connect" works.  In every instance, the "disconnect" works, but then attempting to "connect" results in a constant cycling of connect/disconnect/connect/disconnect.......  but it never actually reconnects.  This has been reported elsewhere, is not unique to me, and is consistent across multiple hardware 4150s. 

[nsayer]

Go look at the system log of your MiFi. It goes dormant within seconds of the last active transmission whenever you stop sending data.

That it does so is not indicative of any problem whatsoever. As I said, it's a battery preservation strategy.

Of all of the times mine goes dormant, only one out of every hundred times or so does it fail to immediately reconnect once there's network activity. That's the nature of the problem here.

For me, of late, when I have had it get stuck, a firmware update check has resolved it every time. Before then, I was using disconnect reconnect, and that worked almost every time.

Once in a while, when I check on what the MiFi's state is when it gets stuck, it's "disconnected" or "connecting" or some such. A quick glance at the system log in those cases shows something else is going on. Perhaps that happens once or twice a month, but it's not frequent enough to be bothersome, and it's not the same thing as when the unit gets stuck dormant.

[wmhjr]

I'm sorry but you are in fact quite wrong.  The fact that you're trying to represent an idea that dormancy due to inactivity following an active transmission is not indicative of a problem but is representative of a battery strategy tells me that you're either totally unfamiliar with the technology or you just don't want to admit the failings. 

For the record, the problem can (and has) occured even when streaming data, where there is no inactivity to trigger a "power conservation" mode. I've even had consoles up watching how many actual connections are active when the device has gone dormant.  It's very interesting to see some of the use cases of the failure when you have network engineering tools at your disposal.  I've watched an active 443 connection with data transfer going on at the very instant that on another browser screen the device pops to "dormant".

The problem here is that you are apparently (and very fortunately in your case) not experiencing the problems that so many others are.  My very strong suggestion is that you don't ascribe your particular use case to describe the "nature of the problem here", as it is absolutely not accurate.  BTW, the 39 POC devices we tested in 3 major metro areas all experienced the same issue.  The issue did not manifest itself on competing 3G devices.  We are not moving forward on the POC, but the data is the data.  I would further suggest that just maybe the system log of the 4150 is certainly not the end all of data sources.  Far from it.  Looking at it, it's only providing the barest surface data with no granularity whatsoever.  Though IJMHO, I find almost no value in it.  Now, if there were more detailed logging, then......

[nsayer]

"Two men say they're Jesus. One of them must be wrong."

I can only report what I experience.

My 4510L has a problem.

I have described it in great detail. I, in fact, was the one who started this thread. If you suspect you're having problems different from mine, then perhaps you should start a thread of your own.

I think we're done here.

[wmhjr]

Thanks.  Just remember that what YOU experience is not necessarily what OTHERS experience.  I don't experience all the issues that others have.  For example, I never experienced the 2 hour disconnect that has been reported by some users - though clearly they have.  Hopefully, the idea that it's related to competing towers, etc, has helped to diagnose root cause.  Who knows. 

But also clearly, it is totally ridiculous to say that the random dormancy issue which for many many people does NOT reconnect when required is NOT the proper result of power conservation, and to try and defend that only gives more leverage to VZ to continue and ignore and obvious and very real issue.  VZ needs no assistance in demonstrating poor support.

Also, for those that perhaps don't realize it, the "System Log" is not "God".  It's a landing zone for system generated messages with pre-determined syntax which are generated upon specific conditions being met.  The very very important point is that it's all instrumentation, built in by the SW team for the device/firmware.  If an error condition occurs that they did not anticipate, then nothing may write to the log file.  Or, if the error is incorrectly interpreted by the logic to resemble another condition, that's what it will represent.  Just in case people are not familiar with how instrumentation is built into applications, it's important to understand that those logs are crated, the syntax designed and the logic built - by the same folks who write the firmware.  It is not magic.  Instead of a log entry reading "Dormant" when data transmission ends, I (assuming my group would have been responsible for instrumentation for this firmware) have made it log something like "VZ Users are idiots" every time the device made a connection.

[nsayer]

I didn't say that a failure to come out of dormancy was proper power management. I said that the device routinely entering the dormant state was power management. I have also stated more than once that for me, the device is often dormant, and that does not indicate a problem. The problem is that it sometimes does not exit the dormant state.

This is a recording.

[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.

[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.

[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.

[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.

[tim_lightfoot]

Thanks John.  We are using a Wilson signal booster already and we constantly have full bars on 3G (we are in a fringe area for 4G according to Verizon, but never have been able to pull that in even with the biggest signal booster we could buy).  I'm going to look at the PepWave Surf...that looks interesting...

Thanks again - and thanks for your continued advocacy in this area.  I know that your posts have been tremendously helpful....Cheers!  Tim

[PebbleBill]

Just got my new MiFi a couple of weeks ago. Have an important use for it today. But, it has been dormant all day. 4 bars. Good connection. Every time I reconnect, it goes back to dormant in a few seconds.

Does anyone know of a reliable data connection via cell? Does AT&T have a model that works? I am a professional and not a hobbyist. Need a device that is consistent.

Thanks

[John_Getzke]

Pebble,

What you are describing is normal behavior for the MiFi 4510L.  Dormancy is not a problem, it is a status message that regards the activity of your MiFi.  The MiFi will go in and out of dormancy as is needed.

If you havent read through the solutions on this thread then I suggest starting with the resets to try and correct the actual problem, which is most likely a disconnection event from the VZW network.

Level 1 Reset:

1. Power down the MiFi
2. Let the MiFi sit for 30 seconds
3. Power on the MiFi
4. Test the connection

Level 2 Reset:

1. Power down the MiFi
2. Remove the back cover
3. Remove the battery
4. Remove the SIM card
5. Allow the MiFi to sit for 30 seconds
6. Reassemble the MiFi
7. Test the Connection

Level 3 Reset

1. Power on the MiFi
2. Remove the back cover
3. Press and hold the Reset button next to the battery for 10 seconds
4. Watch the MiFi E-Ink display to see if all the icons are displayed
5. Release the Reset button
6. Reassemble the MiFi
7. Test your connection

MiFi's come with a 14 day trial.  If the resets do not correct your problem before your trial is up then return it and try something else.  All the major wireless providers have a mobile broadband device similar to the MiFi 4510L.  If you want to stick with VZW then the upgraded MiFi 4620L should perform better.