Issue: Treo 300's (and probably 600's as well) sometimes have a very long delay (over 30 seconds) prior to connections to private servers using certain services, like pop3 or telnet, due to some of the Sprint IP addresses completely ignoring reverse DNS requests.

The problem is NOT that the addresses don't reverse resolve, it's fine to have them NOT reverse resolve, but when you set up IP address ranges to reverse resolve and then ignore the world's attempts to reverse resolve them, it causes the world's servers to attempt to resolve them for 30 seconds or more before timing out. This is the problem.

According to my experience, my Treo 300 is assigned IP addresses in any of the following 7 IP ranges (at least in the Pittsburgh area):

68.24.0.0/16
68.25.0.0/16
68.26.0.0/16
68.27.0.0/16
68.28.0.0/16
68.29.0.0/16
NEW: 68.244.0.0/16

Three of these ranges have problems with the reverse DNS:

68.27.X.X
68.29.X.X
68.244.X.X (just started showing up yesterday, 1/7/04)

This is incredibly ironic because I just posted a reply to someone a few days ago who was having problems with Snappermail and Sprint, and suggested it might be related to this problem that Sprint has had for the last year. And, just yesterday Sprint added a new range that my Treo grabbed which started the same delay problem for me all over again. The symptom is that when I use any TCP-based service on any of my 6 Linux boxes, it takes 30 full seconds for any service to start when I just happen to get assigned an address from one of the three problematic ranges. For example, checking email with pop3 Snappermail takes a full 30 seconds before the email even starts downloading. Telnetting takes a full 30 seconds before a prompt pops up. (Don't use telnet for production servers, it's risky. This is just an example).

I've capped the data with a sniffer many times. The sequence of events is this for pop3: Treo request for port 110 comes in and is acknowledged and held, while the Linux tries to reverse resolve the source IP address. One of two things should happen: The reverse attempt should succeed and get a name, or the reverse attempt should fail or be blocked. INSTEAD it is simply ignored (firewalled?) by Sprint, which causes the Linux boxes to continue to try for 30 seconds. Once the timeout happens, the connection continues normally. Note that only 3 ranges of Sprint addresses have this problem, the remaining ones work fine.

I realize that this is because my Linux is configured to reverse resolve IP addresses prior to letting them connect to it, but this is how most servers are configured, and it's required for some of the features on my Linux, so I cannot disable it. It actually irritates me that I need to make such special concessions for Sprint because their techs are idiots. This server is used for many people located all around the country and none of them see this symptom because all of their DNS maps are configured correctly. It's only the few of us who use our Treos on them.

Yes, tried to talk to Sprint about it. No surprise that they had no desire to do anything about it, and I doubt they actually understood anything I was telling them. I offered to send my sniffer caps as proof, no interest.

SOLUTION: My solution is a bandaid, because we don't use the Treo's in a production environment and I can't spend any real time or make any major modifications to the servers. So, I simply made my DNS servers think that they are authoritive for the reverse resolution of these addresses. I made three fake REV Zone files, and this makes all equipment using this DNS server instantly fail on any reverse DNS request to these addresses. This makes pop3 fly.

I have no idea of the above ranges cover every Treo user, I do know that even when I travel I have never gotten an IP address that wasn't in the above ranges. If you wish to reply to this thread and append any IP addresses that I've missed I'd appreciate it.

Also note that there might be many more new ranges coming that I haven't seen yet. Will try to append them as I see them.

IF YOU KNOW SOMEONE HIGH IN THE TECH CLICK AT SPRINT, PASS THIS MESSAGE TO THEM. IF YOU KNOW SOMEONE HIGH IN THE MANAGEMENT OF SPRINT, TELL THEM THAT THEIR TECHS ARE UNMOTIVATED IDIOTS AND HAVE AT THE VERY LEAST COST THEM CORPORATE DEPLOYMENT OF SPRINT DEVICES AT MY COMPANY. I was actually approached about rolling out my Treo solution to our entire team (certainly dozens, potentially hundreds) and I outright told them that the SUPPORT FOR SPRINT SUCKS AND I DO NOT RECOMMEND THEM FOR CORPORATE USE. My advice was taken, and although I now carry a Sprint phone and a Nextel phone, I feel confident that the support for the Nextel will at least get us through the day. The Treo device itself is great. The Functionality is great when it works. The potential is there for Sprint to be a clear industry leader, but their idiotic support and 30 minute hold times and lack of customer caring is killing them, and has AT LEAST cost them this large account. I know that when there's a problem with the Treo, don't ever count on Sprint support for any knowledgable answer whatsoever. And, that's a real shame.

mk3cn4 at yahoodotcom