fergus420

Ok, I have had by Pre for about a week and have been fighting trying to get my email to work. I think I finally figured out the problem but I am not sure what I can do about it. Let me explain my situation...

I run my own mail server that sits behind a firewall/router which is connected to the internet. When connected to my wifi at home, mail.mydomain points to an internal private IP address. To everyone else, mail.mydomain points to my router which does destination NAT to my mail server. This setup has worked fine until now.

When the Pre is not in Airplane mode, i.e. EVDO is enabled, and Wifi is disabled all is fine. I can connect to my mail server and perform all tasks successfully. If I then enable Wifi, my email stops working. I can no longer access folders or messages, everything just hangs. If I then enable Airplane mode, i.e. EVDO is disabled, and enable Wifi, my email starts working again.

So I put my Pre in Dev Mode, hooked up the USB cable and lauched novaterm. Using netstat, I was able to observe while in the above failing case, the Pre was attempting to connect to my server with the internal private IP address but from the EVDO interface. Why is it using the EVDO interface when Wifi is enabled? This I can not figure out. All other traffic appears to go through the Wifi interface.

Right now this is preventing me from using my Wifi when at home. Has anyone else experienced this? Have any ideas on what I could to to make it work or fix it?

rich

bhack

That's interesting. I'm assuming Palm did it that way because of how the wifi radio gets shut on/off constantly if the screen is off. I would bet IMAP is specifically set to always use EVDO to make sure the pushes from the server aren't constantly getting interrupted by the user turning on/off the screen.

I would say it's a bug, the Pre is obviously getting routing information from the wifi but attempting to use it on EVDO as well, instead of having a separate routing table.

fergus420

Its not a routing issue, its a DNS issue. They are using a response from the Wifi DNS nameserver and not the EVDO DNS nameserver. I am not sure if I am doing something against the 'dns rules' that breaks this.

vreihen

It sounds to me like:

1) The EVDO link has the "cheaper cost" in the Pre's routing table.

2) The Pre may be caching DNS responses, so that they stick around after you switch interfaces.

I don't know if your router can do it, but I'd recommend using the router's IP address for your mail server both inside and outside the firewall. Mine does it fine, and it saves all kinds of grief with configurations even if it does add an extra hop to your link when you're inside the firewall.....

fergus420

The routing table looks to be correct. The EVDO interface has a much higher metric making it the less favorable interface. They must be doing something specific to make the connection use the EVDO when Wifi is available.

I was able to make it work doing something similar to your suggestion.

davidra

Try this, because I've been having the same problem at work and this is what the IT people suggested....and it's ridiculously simple:
Just start wifi but immediately go to any website, then get out. Then see if you're getting mail. Apparently our wireless system will not locate you as being connected with this phone until you go to the web. Don't understand it, but it worked.

vreihen

Coincidentally, I have now encountered this same exact problem with a different scenario...and I wasn't even trying!

I set up an IMAP server on a test system in my office, behind our firewalls. My Pre has a working OpenVPN link to the server running IMAP, and can load web pages on it just fine. (This test server has no access whatsoever to the Internet, except over the VPN link.) When I configured the IMAP account on the Pre's mail program, it connects to the server via IMAPS (SSL to port 465), and even complained about a certificate problem that contained a typo when I generated it that I had to fix. The account on the Pre is set up correctly, and my server logs show the IMAP connection over the VPN link. That's all she wrote, though. It will not download any messages from the IMAP folder, and I have determined that the reason is because the Pre is trying to connect via the cellular interface instead of over the OpenVPN link.

Long story short, I checked the logs on our production mail server, which has a publicly-visible IMAPS port but is also available over an OpenVPN link. HTTP, ping, and traceroute traffic to the mail server go over the VPN link, but IMAP goes to the same server via the publicly-visible IP address.

My working theory right now is that either Sprint or Palm are operating an intermediate IMAP proxy gateway, and all IMAP/IMAPS traffic is being routed over that gateway via the cellular interface despite what the Linux routing table says. Casting my tin foil hat aside for a few seconds, I'm guessing that they would do something like this to facilitate IMAP push (aka: idle) in such a way that the phone could power down the radio link instead of staying hot the entire time. Knowing how my phone keeps alerting me to new IMAP messages no matter whether I set the poll interval on each account to "as they arrive", "manual", or "24 hours", Sprint or Palm making an intermediate server that's ignoring my preferences could explain everything.....

vreihen

After examining this problem ad naseum, I think the problem is that the IMAP sync code is running as a Java service, and the Java environment isn't honoring the Linux kernel's routing preferences for IP packets.

From a terminal window, I ran the following shell command:

while true
do
netstat | grep imaps
sleep 1
done

Then, I created an IMAP (SSL) account on the Pre, pointing to the server on the other end of my VPN link. When the account editor was verifying my user info (via the HTML/JavaScript half of the mail app?), it sent the requests across the VPN link per the terminal window above. As soon as the e-mail app handed off the connection to the back end sync routine (Java?), it switched to trying to send IMAP packets over the cellular interface's IP address. In my case, the IMAP server is not addressable from anything but the VPN link, so the Java (?) code merely threw 16 SYN packets over the wrong interface and then gave up.

If somebody from Palm is reading this, your sync app has a bug in it because it said that the IMAP sync was successful when in reality it didn't even communicate a single valid packet to the IMAP server!!!

I did manage to "trick" the IMAP client into connecting over the VPN link, by opening an SSH tunnel from the Pre to the remote server and then configuring the Pre's IMAP to connect to 127.0.0.1 (the Pre's localhost address). The script above showed an IMAP connection from the cellular interface's IP address to 127.0.0.1, followed by a second IMAP connection from 127.0.0.1 through the SSH link. This is not a viable workaround though, since the SSH tunnel keeps the EVDO interface active 100% of the time.....