Re: Verizon EVDO Issues

["Steven M. Bellovin" <smb () cs columbia edu>]

On Thu, 09 Apr 2009 07:15:44 -0400
"Robert E. Seastrom" <rs () seastrom com> wrote:

> Seth Mattinen <sethm () rollernet us> writes:
>
> > I have a few Sprint EVDO cards. They go into standby when nothing is
> > actively going on and fire up within seconds when there is
> > something to do. I regularly use everything from SSH to streaming
> > video without any issues. I only notice the delay with SSH when I
> > don't type anything for a few minutes and it has to come active
> > again, but I can leave it idle for hours and it never drops.
>
> Interesting.  When I got my Sprint EVDO card (u727) a year and a half
> ago, they were pretty nasty about gunning down (bidirectional spoofed
> RST coming out of the middle of the network somewhere) any TCP
> sessions that were idle for ten minutes or more.  Quite repeatable and
> verified on the downlow by People With Insight that this was in fact
> expected behavior from boxes that were in the middle of the network
> due to "politics" (unlike Verizon, Sprint appears to put no
> restrictions on inbound connections to the evdo-host).  Putting this:
>
> ServerAliveInterval 60
>
> in ~/.ssh/config was an effective work-around.  I have not revisited
> the issue to see if Sprint has corrected this behavior.  Perhaps
> budget constraints or customer complaints have caused Sprint to
> revisit the necessity of having extraneous hardware in their network.
I use a Verizon Wireless u727; before that, I used a PCMCIA card.  I've
never had problems with drops on idle.  *However* -- if there was a
packet from the wrong IP address, the older card would drop the
connection -- apparently, that behavior was required by the spec.  (I
haven't checked if the newer one will do that.)  So, if the
EVDO connection dropped while I had, say, an IMAP or ssh session open,
and I dialed back in, the next TCP packet would cause EVDO to drop
again...  I finally "fixed" it by creating ipfilter rules in my ppp-up
script to block all "bad" packets from going out.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb