I encounter edge cases. It’s not fun.
This particular situation caused OXS Mail.app to crash when using a VPN.
The outline
This particular edge case involved the following:
- OSX 10.11.1 (15B42)
- Tunnelblick 3.5.5 (build 4270.4461)
- Mail.app
When running Mail.app, it would crash within 5-10 seconds. The full dump of the crash has been sent to Apple, multiple times.
Also of note:
- My mail server is not at home… it’s out there on the Internet. Thus, the connection to it does not go over my VPN
- Everything described below occurred while connected to my home WIFI
How did I get here?
This one arose when I moved all my wireless access points onto the same SSID. As an aside, I was running several different SSIDs, mostly silly names for laughs.
After the SSID consolidation, my MacBook Air would work fine, but my MacBook Pro would not. It could get connected to WIFI but could not go anywhere, not Google, not my VPN, nothing.
I noticed the DNS servers on the two MacBooks differed. The Air had 8.8.8.8 & 8.8.4.4 (Google DNS) but my Pro had my internal DNS servers (the ones I run here at home, behind the firewall, and accessible only via VPN). Those servers could not be reached when on WIFI because of the firewall. The Pro should have had the same DNS servers as the Air.
I thought this name server discrepancy was DHCP related because my MacBook Air did worked just fine.
I spent a lot of time experimenting with dhcpd.conf on my DHCPD server.
That was wasted time.
My System Preference | Network | Wi-Fi | Advanced | DNS settings had my internal DNS servers hard coded. After removing those entries, the MacBook Pro started using the name servers (i.e. Google DNS) provided via DHCP. This allowed the MacBook Pro to have a workable WIFI connection. Everything functioned normally.
This DNS problem took about an hour to resolve. During that time, I was connecting into my network via ethernet cable, jumping back onto the WIFI, then back into my network, all in an attempt to fix the DNS issues.
Once the cause was discovered and fixed, I connected to my VPN, via TunnelBlick. And that’s when Mail.app crashed.
I restarted Mail.app. It crashed again.
I concluded Mail.app got messed up / confused while I repeatedly connected to different networks via different ports.
Thunderbird rescue
In the meantime, I got Thunderbird installed and running. It had no problem. I have used Thunderbird in the past, but I prefer the Mail.app interface.
Delete and start again
Don’t do what I outline in this section. It didn’t work for me
I tried various suggestions found while searching for a solution. They involved removing the contents of ~/Library/Mail and ~/Library/Containers/com.apple.mail. That didn’t help.
One suggestion said to disable all your email accounts via System Preferences | Internet Accounts and reboot.
That worked. After rebooting, Mail.app stayed running. Everything downloaded I could read my mail.
Success!
Some time later, I connected to my VPN to work on a issue with one of my servers.
BOOM.
Mail.app was gone. Again.
This was my first inkling that it might be VPN related.
Discovery
I coped with Thunderbird until Saturday morning, when I started hunting around the TunnelBlick options. Under Configurations, the value for Set DNS/WINS was Set Nameserver. I found that if I changed that to Do not set nameserver and restarted my VPN connection, Mail.app would run.
I experimented with various settings and have included the problems encountered with that setting:
- Do not set Nameserver: private DNS servers inaccessible
- Set Nameserver: Mail.app crashes
- Set Nameserver (3.1): only one of the private DNS servers is listed and issues with ssh (see below)
- Set Nameserver (3.0b10): Does not set DNS servers
- Set Nameserver (alterate 1): same DNS issues as Set Nameserver (3.1)
Issues with ssh
When using the Set Nameserver (3.1), this is the type of ssh issue I would encounter:
$ ssh -v zuul.example.org OpenSSH_6.9p1, LibreSSL 2.1.7 debug1: Reading configuration data /Users/dan/.ssh/config debug1: /Users/dan/.ssh/config line 344: Applying options for zuul.example.org debug1: /Users/dan/.ssh/config line 349: Applying options for *.example.org debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug1: /etc/ssh/ssh_config line 102: Applying options for * ssh: Could not resolve hostname zuul.example.org: nodename nor servname provided, or not known
Not perfect, but better
I was asked: what happens if you change the DNS servers manually?
Answer: nothing.
If I select Do not set Nameserver and then set the DNS servers manually via System Preferences, all is good.
The solution
It seems the problem is with Mail.app. Someone contacted me (after reading the crash dump) and said:
I finally looked at the Mail.app crash report, and the problem is that the “length” method is being used on an array (arrays don’t have a “length”, they have a “count”). Perhaps the coder was expecting a string and got back an array of strings or something like that. Perhaps the way that Tunnelblick sets up the DNS servers causes a not-otherwise-taken branch in Mail.app that leads to the bad code.
I’ll wait for the next version of TunnelBlick and see how that goes. In the meantime, I’m using Viscosity on their 30-day trial.
