I haven't tried that, but others have mentioned turning on the MAC address filter and I see you have that on as well. Are you sure it's the lack of SSID instead of the mac filter?
In any event, are you also sure that the problem you're seeing is the same? I could imagine a bug where the WiFi connection could go bad that would cause similar symptoms. Are you able to go to vz.hotspot and refresh the page and see that the connection really is "Dormant" and in another window going to a real website hangs? I'd expect any problem that the mac filter or SSID hiding would fix would cause vz.hotspot to hang AS WELL as the Internet in general.
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.
When i only enabled mac filtering, it didn't solve the problem.
My Mifi would still get stuck in dormant mode. I could access the mifi homepage but nothing on the internet.
I really don't know why but as soon as i disabled SSID broadcast the problem went away and i can confirm that i use the mifi all day long for two weeks now and not single dormancy issue.
I am running the latest firmware as well.
Give it a try and see if this solved your issue as well. nothing to lose here!
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.
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.
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.
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.
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......
"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.
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.
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.