Try to put Thunderbird in offline mode before you put the laptop to sleep.

Once you're connected to the LAN switch it back to online mode.

http://kb.mozillazine.org/Outbox#Online_and_offline_states

I'll give it a shot, but I have my doubts, because: (a) Thunderbird goes into offline mode automatically when I turn the WiFi off, and comes back online automatically when I plug in the Ethernet cable; and (b) I've manually toggled offline and online before when I have this problem and it still seems to need to go into timeout before connecting. (Sometimes it has to timeout two or three times before it'll connect.)

I'd turn it off rather than use sleep. Sleep and hibernate are just too problematic (generally) in my experience.

My MacBookPro has no problems with sleeping. It's just Thunderbird that has the problem.

Great, but does turning the thing off offer a fix to the timeout? If Thunderbird is getting timeouts following sleeping, then your mac book pro does have a problem. The software can not connect using the MAC hardware.

By changing networks, your changing DNS servers and a whole host of other things required for things to work. Thunderbird does not manage any of that, it simply makes requests to the operating system.

Have you tried opening your browser instead of Thunderbird first up? I would put money on whatever requests an internet address first will have an issue, while OSX wakes up that it's DNS cache is rubbish, the addaptor in use has no valid lease. The DNS servers have changed and it needs to request a new lease from the local DHCP server.

You could be right, although I'll note that Firefox doesn't seem to have a similar problem. Are their queries I could do via Network Utility or System Preferences Network panes I should examine that would help identify the source of the problem? I'll also try other experiments (such as restarting Thunderbird) before resorting to rebooting; that seems like a sledgehammer approach and doesn't really help to root-cause the issue.

I also note that I don't seem to have a similar issue when going in the other direction; that is, disconnecting from the (internal LAN) ethernet connection and going to a WiFi connection.

Re: "Try to put Thunderbird in offline mode before you put the laptop to sleep.

Once you're connected to the LAN switch it back to online mode. "

That didn't help. It still got the timeout. I'll try Quitting Thunderbird and restarting it next time to see if it gets the Timeout on the startup.

It is days since someone suggested you turn it off and on again. Your still talking about doing it "next time".

I know it may be incomprehensible to you, but restarting a problematical device is computer diagnostics point 1. It is the very first thing you do. Not the last. 1 Restart Computer. 2. Restart in Safe mode 3. Check disks for errors 4 Check memory for errors 5. Check for malware. 6 Dust off your copy of wireshark and find out what is going on under the networking hood.

Hi, Matt, my day job intervened.

My experience with doing black box debugging ("black box" because I am not familiar with Thunderbird source code, nor do I have the time or interest to become familiar with it(*)) is that it's important to only change one variable at a time. Rebooting my MBP would change at least two variables: the operating system state (kernel and various daemons), and Thunderbird's state. Hence my approach.

The results: If I Quit Thunderbird and restart it after turning off WiFi and connecting to the internal LAN via ethernet, I don't get the timeout.

I also found that the IP address for company's email server is different outside of the internal network than inside. (It's xx.yy.zz.mm inside, and xx.yy.zz.nn outside, where mm and nn are different but the other octets are the same.) This leads me to wonder if some network stack within Thunderbird is caching the domain name->IP address translation, and only after timeouts or perhaps just elapsed time does it throw away the translation and do a new lookup.

Some more data points: - I also have the same problem going the other way (internal LAN to external WiFi).

- If I don't select Get Mail but leave Thunderbird alone, I notice that after a few minutes after switching to the internal network it will report that I have new mail (if indeed I do), so it must be attempting to make the connection anyway without my asking (and without posting anything to the status bar).

- Sometimes I have a similar problem with Firefox when connecting to the internal company portal. The internal portal's domain name also resolves to different IP addresses depending upon whether you are inside or outside the company network, and an attempt to connect to the internal portal domain name from outside redirects one to the external (public) portal, showing the public portal domain name in the locator bar. (Obviously this problem only occurs when attempting to connect to the internal portal from inside the network. Other than entering the numeric IP address of the internal portal, I haven't figured out how to get Firefox to redo the lookup other than Quitting and restarting it. But I haven't tried doing something else for five minutes before retrying the internal domain name; I'll put that on my list.) I believe that Firefox and Thunderbird share a lot of code, especially the network stack? Since I often have the problem with one program and not the other (that is, Thunderbird will connect correctly but Firefox won't, or vice versa), and only coincidentally at the same time, I speculate that the problem is in a common algorithm both use but not in common state they share, hence above the OS layer.

I'd be interested in any feedback you or any other reader of this thread may have that will help identify the root cause of the problem and perhaps a better (or at least faster) workaround than just waiting or restarting the application. (I want to see how far I can get before I have to download and learn how to use wireshark :-).)

Thanks, --Steve

(*) My expertise is the CPU hardware/software interface, especially related to the correction, diagnosis, and containment of hardware errors by software. See "Injecting Errors for Fun and Profit" at http://queue.acm.org/detail.cfm?id=1839574 for a sample of what I do.

I realize that earlier I said "I'll note that Firefox doesn't seem to have a similar problem" and "I don't seem to have a similar issue when going in the other direction" and my most recent post contradicts both statements. When I made the earlier statements (a) the Firefox problem doesn't happen as often, (b) I hadn't investigated the IP addresses of the sites involved; seeing that both the mail server and the internal portal resolve differently depending upon whether I am inside or outside the corporate network is what made me think they might have a common cause , and (c) when going in the other direction I usually look at my personal email (on a non-company server) before going back to looking at my work email and that probably gives time for the old entry to clear out of whatever cache it's in.

As I said way back, the issue will be around obtaining a DHCP lease and the DNS.

Clear the DNS cache manually in your mac http://support.apple.com/kb/ht5343 and I think you will see improvement.

All operating systems cache DNS

Thanks, Matt, I'll give it a try.

Is there a way to query the cache to see what's in it? I tried sudo killall -INFO mDNSResponder per the mDNSResponder(8) man page and looked at the output it put into /var/log/system.log but that didn't seem to indicate anything useful.

I tried dscacheutil -cachedump but it said Unable to get details from the cache node

and while dscacheutil -q host -a name [mailserver] does produce output, the man page says that if it isn't in the cache it will "go fetch live data"; a plain dscacheutil -q host after that just produces information about localhost and broadcast host.

I gather that the Lookup function of Network Utility bypasses the cache?

I tried "sudo killall -HUP mDNSResponder" per the Apple support article but it didn't seem to have an effect, but perhaps my test wasn't valid? If I recall correctly, this is what I did: 1. (at home) turn off WiFi 2. (at work) switch location from "home" to "work" 3. plug in Ethernet cable. 4. Select Get Mail, got "connecting..." status 5. Ran sudo command; nothing happened. 6. Got Thunderbird timeout alert. 7. Ran sudo command again. 8. Select Get Mail again, got "connecting..." status again. 9. Forced Thunderbird to stop connecting by putting it into Offline mode and selecting my account name. 10. Ran sudo command again. 11. Put Thunderbird back online, selected Inbox, selected Get Mail, and this time it connected.

Next time I'll run the sudo command before the first time I select Get Mail and see if that makes a difference.

Networking is an area of some frustration. Recently, some bug reports are seeing progress. The place to be to test these fixes is in development builds

Note yet fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=939318

 NetworkLinkService should be enabled so Necko can respond to network changes (not offline auto-detection)

https://bugzilla.mozilla.org/show_bug.cgi?id=972262 DNS cache is not flushed/re-initialized when toggling offline/online

fixed in tb30: https://bugzilla.mozilla.org/show_bug.cgi?id=981513

dns cache grace period error busting too aggressive

https://bugzilla.mozilla.org/show_bug.cgi?id=981447

dns cache too sticky!

fixed in tb30

Thanks, Wayne. Does this mean that Thunderbird maintains its own DNS cache?

I note that 939318 says "Platform: All All", but the discussion seems to only be about Windows. Does it apply to MacOS as well?

Do these bugs, especially 972262, apply to Firefox as well as to Thunderbird? I note that sometimes Firefox doesn't recognize network changes either. If toggling it offline/online fixes it, that will be great.

I did rerun Matt's test more carefully yesterday, I just didn't have a chance to report the results before your posting. For Matt's benefit, here's what I did: 1. At home, turned off WiFi, put MBP to sleep. 2. At work, woke up MPB, changed Location to work, plugged in Ethernet cable. 3. When Ethernet Connected, did "sudo killall -HUP mDNSResponder". 4. Clicked Get Mail on Thunderbird. It had "Connecting..." in the status bar and eventually timed out.

I'm willing to test a development build to see if it fixes the problem, but I'm not sure where (or how) to find them. (I just did a cursory look.) Can you tell me how?

Thanks, --Steve