Does Aqua Retry Network Errors?

[BigbirdPhila]

Looking at timestamps, the connection was aborted immediately (i.e. there was no delay for a time-out), either from the server's side or by the network between the device and the server:

That's what I was afraid of: the trace doesn't show exactly who closed the connection?  It could be either AT&T's or AOL's fault?

I'd say you could try imap.aol.com + SSL + port 993, but then it might start failing during the "SSL handshake", which would be same thing really.

Yes, I did try that.  That's when I got:

"Incoming mail server (IMAP): Error connecting.  Connection closed by peer.  Please make sure the data is correct."


You're more knowledgeable in this area than I am.  What's your "best guess" as to whose problem it is?  Here's a high-level summary of key observations:

1.  imap.aol.com/143 works 100% of the time over Verizon WiFi
2.  imap.aol.com/143 works 100% of the time over AT&T Wireless (direct, no MVNO)
3.  imap.aol.com/143 fails occasionally (randomly) over AT&T Wireless (TracFone MVNO)
4.  We can see that the (TracFone) connection to imap.aol.com is made (AT&T is not blocking the IP address; AT&T is "getting us there"), but then occasionally (randomly) the connection is immediately terminated.
5.  AT&T Wireless (via TracFone) works 100% of the time to Gmail, Yahoo, and Comcast email servers
6.  AT&T Wireless (via TracFone) works 100% of the time to Amazon, Ebay, YouTube, Wikipedia, etc.

And, here's something I just tried:

7.  If I use a low-level utility (like Telnet) to open port 80 on imap.aol.com (via Tracfone), the port opens successfully and times out in about 15 seconds.  The connection does *not* immediately terminate on port 80!


I am hoping you see something in these observations that I am missing!

[Kostya Vasilyev]

Re: That's what I was afraid of: the trace doesn't show exactly who closed the connection?  It could be either AT&T's or AOL's fault?

I can't tell -- all I know is that it wasn't the app.

Probably the only way to tell is to run a low level network packet capture - but as it's not something I do often, I'm not in a position to provide "5 easy steps" for that. I'd just guess that it's only possible on a rooted Android device.

Re: What's your "best guess" as to whose problem it is?  Here's a high-level summary of key observations:

Looking at those stats - looks like AT&T or TracFone (and I had no idea what TracFone or MVNO are... had to Google it).

And yet:

5.  AT&T Wireless (via TracFone) works 100% of the time to Gmail, Yahoo, and Comcast email servers

AOL could be doing load balancing based on "your" IP address too which may on a different subnet when using TracFone. Or a thousand other factors that I can even begin to imagine.

---

I'm actually a complete ignoramus when it comes to low level networking -- sure I know what IP addresses and just a bit about routing and such to be dangerous as they say, but...

Just to give you an example of things that happen.

Some time ago I was having issues accessing certain web sites from home. Anything Yahoo and AOL (IIRC), but no issues with any other web sites (that I've tried).

The packets would apparently not get through.

The ISP's technical support said everything was fine for them (from the call center).

The ISP's customer support said everything was fine for them too (from their office).

Two techs came into my apartment, connected their laptop to my network cable, everything was fine again.

And then - only when they used my account on their laptop, they started seeing the issue themselves.

The "bad" web sites had nothing in common, in seemed - their IP addresses varied a lot, from the first byte.

And yet...

Anyway, they were able to fix it, but "the moral of the story" is - networking issues can be weird.

[BigbirdPhila]

Looking at those stats - looks like AT&T or TracFone (and I had no idea what TracFone or MVNO are... had to Google it).

And yet:

5.  AT&T Wireless (via TracFone) works 100% of the time to Gmail, Yahoo, and Comcast email servers

And also #7 -- changing to port 80 the connection to imap.aol.com works!  To me, that smells like it's not AT&T, but rather AOL (disliking something on port 143).

A collection of conflicting observations.  Nasty!

This has still been more progress than 6 weeks of vendor turmoil.  I'm going to try to get this trace sent to AOL.  If you or anyone else thinks of something I would be most appreciative. 

[BigbirdPhila]

And also #7 -- changing to port 80 the connection to imap.aol.com works!  To me, that smells like it's not AT&T, but rather AOL (disliking something on port 143).

Am I correct in saying that AT&T would have no knowledge/sensitivity to what port the user (me) was trying to open?  That is, to AT&T the important thing is the destination IP address.  It's oblivious to the fact that, in the packet's data, port 80 is being opened rather than 143?

The destination machine (imap.aol.com) would be the only one sensitive to the port #, extract it from the packet, and take "appropriate" action?

[Kostya Vasilyev]

Re: And also #7 -- changing to port 80 the connection to imap.aol.com works!

It would be very unusual for an IMAP server to listen on a port # that's used for HTTP.

And personally I can't get a connection to imap.aol.com : 80 here (using telnet).

Am I correct in saying that AT&T would have no knowledge/sensitivity to what port the user (me) was trying to open?  That is, to AT&T the important thing is the destination IP address.  It's oblivious to the fact that, in the packet's data, port 80 is being opened rather than 143?

In theory, no difference. In practice ... there could be anything anything at all going on in the intermediate network (as there was something in my story above).

[StR]

ISPs can easily see/distinguish which port you are connecting to.
It is a frequent practice these days for some home and mobile ISPs to close access to certain ports from their networks (e.g. port 25 for outgoing connections, port 80 for incoming, etc.).
I haven't heard any ISPs that would block port 143 for outgoing connections.
Still, if you have problems with that, - I'd consider using port 993 (+SSL).


Regarding specifically AOL, imap.aol.com does not seem to accept connections on port 80. (And why would it? It is not a webserver, and it is a huge organization, so their server functionality (IMAP and Web-servers) is separated.
And I checked that port 80 on amapl.aol.com doesn't accept connections, the same way as for Kostya. Port 143 responds without any problem.

[BigbirdPhila]

Re: And also #7 -- changing to port 80 the connection to imap.aol.com works!

It would be very unusual for an IMAP server to listen on a port # that's used for HTTP.

And personally I can't get a connection to imap.aol.com : 80 here (using telnet).

Thanks, guys.  I agree: I couldn't understand why port 80 would be open on a mail server, but I didn't want to argue with what my testing tools were telling me.   After your input, I went back and did more testing.  The plot thickens ...

I have a tool on my Android phone called PingTools.  It has a PortsScanner utility which scans 1000 of the "most common" ports on a server to check if they're open.  I just ran it for imap.aol.com and it shows 21, 80, 110, 143, 993, 995, and 8080 as being open.  I have another tool on my iPhone (something like Telnet) which tries to open a specified port on a specified server.  I tried all those ports on imap.aol.com and *they all opened*.  Some closed immediately, and some timed out in 15 seconds or so, but they all opened.  Specifically, port 80 timed out in 15 seconds.  This was done over wireless AT&T (TracFone).

So, I wondered, why was I seeing something different from you two?  I enabled my (Verizon) WiFi and disabled wireless (I had been doing all my testing on my wireless connection since that was how my email had been failing).  PortsScanner now reports only *4* ports open: 110, 143, 993, and 995.  The iPhone tool successfully opens them all.  The tool now (over WiFi) *can't* open 21, 80, and 8080.

Million dollar question: What the heck is going on?  How could two different tools, on two different phones, agree that they see 3 more ports open (for FTP, HTTP, and HTTP) on the AT&T (TracFone) wireless connection than on the Verizon WiFi connection?

StR: Just so I follow you, what server did you mean by "amapl.aol.com"?

[StR]

Sorry, that was the work of the automatic  spelling corrector. IMAP.aol.com.

On different networks you have different DNS servers. If you cam, find out what IP addresss you are connecting to while on Tracfone/att network. It sounds like tracfone SMS redirects your connection to a different server.
BTW, what prompts/server responses  are you getting  for that suspicious host while opening ports in telnet?

In the mean time,in Aquq.Sol, you can try configuring the server manually, using its IP address.

[BigbirdPhila]

If you cam, find out what IP addresss you are connecting to while on Tracfone/att network. It sounds like tracfone SMS redirects your connection to a different server.
BTW, what prompts/server responses  are you getting  for that suspicious host while opening ports in telnet?

It looks like imap.aol.com can translate into 12 (or possibly more)  IP addresses due to load balancing.  Here are the ones I've found so far:

64.12.88.129 - 4,7
64.12.88.130 - 4
64.12.88.161 - 4
64.12.88.162 - 4,7
64.12.91.193 - 4,7
64.12.91.194 - 4,5,7

152.163.0.65 - 4,6
152.163.0.66 - 4,7
152.163.0.97 - 4,7
152.163.0.98 - 4,7
152.163.3.65 - 4
152.163.3.66 - 4,7


The numbers following the IP addresses are the # of ports the PortScanner found open on that machine when accessing it over WiFi (first number) and AT&T (TracFone) Wireless (second number(s)).

Note that both WiFi and Wireless could translate to addresses in either the 64.12.x.x or 152.163.x.x range.  It's not like one always translated to 64.12.x.x and the other to 152.163.x.x.  I think if I tested long enough, I could have gotten each connection method to access all the servers (it just got too tedious & time consuming for me).

Note that, over WiFi, only 4 ports are consistently found open: 110, 143, 993, and 995.  Over cellular I always get them and possibly more -- usually 7 but sometimes (rarely -- it could be a bug in the app) only 5 or 6.  The extra ports are always 21, 80, or 8080.

And, with my TCP client, I can open those bogus (21, 80, or 8080) ports on that machine.  The app thinks the "open" is succeeding (and then the server times out and closes the port).  But only when using AT&T (TracFone) wireless.  When using WiFi, the app hangs trying to open the port and I have to cancel the "open" manually.

OK, assuming we *know* that ports 21, 80, and 8080 are not really open on a real imap.aol.com machine, how is AT&T (TracFone) making it look like the ports really are there??

BTW, what prompts/server responses  are you getting  for that suspicious host while opening ports in telnet?

I don't use Telnet; I use a utility that only knows how to open a specified port on a specified server.  It doesn't know any protocol.  It displays anything the server sends.  If I want to send anything, I have to key it in (which I never do -- I'm only using this tool to see if I can open a port on a specific machine).  For example, when I open port 143 on imap.aol.com, I get "OK IMAP4 ready" and then I manually close the connection.

I just tried to open ports 21, 80, and 8080 on imap.aol.com using AT&T (TracFone) wireless.  I get "Connection Success" from the app, but nothing from the server.  Strange.  Do you know what I should I get from a "real" server for each of those ports?

[BigbirdPhila]

More interesting info for this nasty problem:

I just installed a VPN app.  I haven't seen a failure since I started it.  As soon as I stop it, the intermittent errors return.  Does this tell us anything about where the "fault" may lie?

A very interesting observation is that as I watch the app (TunnelBear) start up, if I have WiFi enabled it seems to connect to its server pretty quickly.  If I have wireless enabled, it churns for a while, says "Can't connect.  Trying another way.", and then successfully connects.  It doesn't say what the "other way" is that it's trying, but it does successfully connect.  If I switch back to WiFi while it is connected via wireless, it complains again, tries "another way", and successfully connects.  It doesn't matter for the purpose of solving this problem, but I figured I'd document it for anyone who may read this thread in the future.

So, knowing that using a VPN gets around this problem, does that cast more suspicion on AT&T or on AOL?

[Kostya Vasilyev]

Based on what you wrote - seems that a TracFone issue is more likely.

Especially with your data points re: VPN and "extra" port numbers (weird! port 21 is FTP!) - those ports must be a side effect of "something" they're doing (proxying all connections?).

I'd also try to replace imap.aol.com with one of those IP addresses above - maybe the issue only happens for 64.* and not for 152.* or vice versa?

[BigbirdPhila]

I'd also try to replace imap.aol.com with one of those IP addresses above - maybe the issue only happens for 64.* and not for 152.* or vice versa?

Thanks, will try.  How do I do that?  Directly on the Account Setup screen?  StR mentioned "Aquq.Sol" in a previous post, but I don't know how to access that.

[BigbirdPhila]

I have 2 accounts configured in Aqua.  Tried a 64.* address in one account and a 152.* address in the other.  Both failed on the first try (at least I didn't have to retry them many times!).  Picked two more addresses and tried them.  Again, failed on first try. 

I'm leaning towards that it's an AT&T problem, too.  Not TracFone, but AT&T.  TracFone is just a "front-end" billing service.  They have no technical expertise or technical responsibilities to speak of (and basically no detailed technical support, unfortunately).  They just pre-buy time from AT&T and enable the account with AT&T.  AT&T, however, does know who is an MVNO customer.  They read my APN file, which must have an "APN name" field of "reseller".  I know that if I change it to anything else I get no internet access at all.  So, they know who is a reseller (MVNO) customer and who is a direct AT&T customer.  The confusing part is why it happens only with AOL servers (Gmail and Yahoo servers work fine) and why it's intermittent.  I've concentrated on imap.aol.com to keep things simple in this thread, but it also happens (more frequently) with pop.aol.com and pop.verizon.net. 

When we saw the connection close immediately in Aqua's debug trace, I'm not sure we were really talking to an imap.aol.com machine.  We might have been talking to some kind of "bogus" machine with those phantom 7 ports open.  Some kind of DNS/routing error on the part of AT&T?  Confusing part there: Aqua never had the chance to log in.  Some machine definitely allowed Aqua to open the port but then the connection evaporated before the login.

I have never seen PortScanner report only 4 imap.aol.com ports open over Wireless.  It's always 7.  And, yet, Aqua does successfully fetch email (intermittently).  That would indicate it really is imap.aol.com we're talking to.

What a nasty, nasty problem.

[BigbirdPhila]

More testing:

I have Alto loaded on my phone.  That's  AOL's "slimmed down" email app.  Their email app does news, too.  I just want email.

Alto does not make visible to what servers & ports it's connecting and what authentication methods it's using.  It uses PUSH, but everything after that is a mystery (at least to me).

I hit an extended period of failures tonight and decided to check how long it would take an email to get to Alto.  Sending it from my computer, it was immediate.  I then enabled PUSH in Aqua on one of my accounts and sent another email.  Immediate to both Aqua and Alto.  I then tried polling for email on both accounts (to try to verify that they were still stalled) and both failed.  So, PUSHed email has no trouble coming down even when polling in the other direction fails.


I then tried to send two emails out of my phone.  Alto sent its out, but Aqua couldn't.  There is a window there -- betweeen the time Alto tried it and when Aqua tried it.  Alto could have gotten "lucky" with its connection attempt.  Does anyone happen to know how Alto (or probably the email app, too) configures its outbound email?  I could try that in Aqua if I knew.

Two questions:

1.  I see Aqua has a "Push mail session duration" parameter.  It defaults to 1 hour.  What benefit would I get if I set it to 2 hours?

2.  How much more does PUSH drain the battery compared to a 10-minute polling cycle?  Should I keep polling enabled, too?  If I used it, I would use it only on one account.  The other account would stay exclusively polled.
 

[StR]

As I wrote in my previous post, "Aquq.Sol" was a typo... it was meant to be "Aquamail".
Well, you've tried configuring IP address directly, as I (and then Kostya) was suggesting.

So, it doesn't look like Tracfone modifies DNS resolution of the addresses. However, it appears that it (or AT&T for Tracfone users) might be using some type of proxy (and a weird one). And that proxy is what likely creates the problem.