If it's anything like the OS X implementation of using a cellphone as the EVDO connection (I've never tried the expresscard thingy), the fucker thinks it's the 14.4 modem in your mom's basement and so the only logical response to the connection failing is to hang up and dial up AOL again.
Does Verizon have Mac software that might work better than the built in stuff (ha ha)?
2008-01-03 07:52 pm (UTC)
Why do modern operating systems like to kill interfaces when you unplug network cables? Beats me.
What does this thing do? Does the computer see it as a modem and talk PPP over it? Presumably in that case once the PPP connection is terminated you're back at square one, just like with dial-up. You'll probably get a different IP address when you reconnect, so your TCP connections are all going to RST anyway.
Hmm... I just got a Sprint EVDO modem (USB) today... Had the PCMCIA version before I got the MacBookPro. I tried it for a little and noticed the drops after like 10 seconds at first. Then it seemed to stabilize. Haven't had time to use it much more yet to see how stable it is. I *thought* I might have just been accidentally hitting the (default!) Disconnect button.
Assuming it's deliberate, it's one way to limit how much damage a rogue process can do to the bank balance.
I also have a Verizon EVDO Express Card.
I also get disconnected on 10.5, using the built in EVDO Express Card Support from apple.
However, when I used the VZAccess Manager from Verizon, I don't seem to get disconnected as often. As far as I can tell, the Verizon software uses its own kernel module to drive the card, so it likely is doing something, or tolerating network errors more than Apple's Driver.
You can get the Verizon software from:
It kinda sucks in most ways... but it works.
Did it start when you upgraded to 10.5?
I haven't had a problem like this ever in 10.4 using the apple drivers. (Nor the verizon ones)
In airports I often use the 'VZAccess Manager' on XP using my cell phone as a modem and I totally get disconnects. I don't think it's every two hours; sometimes it's less or more time but the disconnects always happen when I run for more than an hour.
This seems to happen to me in areas of questionable signal... like yourself, I'm wondering why it doesn't act a little more tolerant. However, in a good area I can stay online for hours and hours (and I will).
MacBook w/ 10.5, using built-in drivers
Novatel USB720 CDMA modem
I tried Verizon's "VZAccess" software on my other Mac and it was terrible. My connection ran at about a quarter of the speed I get with the native drivers (and the latency was terrible as well). There's some bug with their software; maybe it's just with Leopard or maybe it's a general issue, but forums are full of people talking about 4x speed boosts by switching to the native drivers.
I've found that turning off my airport card makes the connection more stable. No idea why, but sometimes voodoo is that way.
2008-01-04 12:40 am (UTC)
Both the EVDO card and the airport card use RF for communication, sending out a moderately strong signal and listening for a comparatively weak one. While they use different frequencies, a "strong enough" sending signal nearby will still swamp a "weak enough" received signal so that it can't be decoded. So turning off the airport card helping with the EVDO stability doesn't seem like voodoo to me. (Even if, in theory, given adequate signal strength it shouldn't matter due to being a substantially different frequency.)
Brad: a random though to work around the symptoms. If you have somewhere that you can build a VPN to and then route out to the systems you want to reach, then route your ssh (etc) connections through the VPN. When you bring the EVDO back up, restart the VPN (perhaps automatically), and so long as the VPN gave you the same IP (eg, OpenVPN does this by default), your connections should continue working after restarting the VPN.
I have found the same pattern!
2008-01-03 11:43 pm (UTC)
Doesn't happen to me
Wish I could help, but I'm a contrary data point - I often leave mine up for more than 24 hours at a stretch, on both 10.4 and 10.5. Maybe I have a different card rev than you do, though? I don't have it handy, but when I do, I'll try to post it.
I'm using the built-in OS dialing stuff, not Verizon's software, if that matters.
2008-01-04 12:21 am (UTC)
I'm using a borrowed Verizon EVDO card, the same thing just happened to me. I found a setting "Disconnect if idle for  minutes" that was checked, there is also a setting "Connect automatically when needed". I have no idea if these are the cause or solution to the disconnect issue but I thought I'd mention it.
I'm assuming from the comments that you are running Mac OS X, and guessing that you are running 10.5. If so, you can get to these settings by going to System Preferences, then Network, click on the EVDO card, look for the "Advanced..." button on the lower right, click on the PPP tab.
I think the preceding comments, more relevant to your specific situation, are more likely to be more right than mine, but my first thought when I read this was that it sounded reminiscent of having used a SE phone via Bluetooth under Mac OS X 10.3 or so, which I found to be because AT&T Wireless (I'm pretty sure this was before Cingular, which was before AT&T) cheated on DHCP allocations, found itself in a state of IP address conflict (presumably both through valid leases; it happened with a wide variety of their NATed space) and either arbitrarily killed one user or just booted both.
I'd note that I don't have any problems doing the same through an SSH tunnel proxy or two (HTTP/S and SSH is about all I need) on my iPhone (which, for bonus points over Bluetooth, more than one client can use), but that does imply violation of each of Apple's and AT&T's terms of service and, worse, limits one to EDGE speeds, but at least my connections stay up (as long as I don't move around much; haven't tried it in a context where I'd be crossing cell handoffs) with fairly consistent latency...
Edited at 2008-01-04 02:25 am (UTC)
2008-01-05 05:04 am (UTC)
2008-01-17 04:24 am (UTC)