I can't wait but jot down this piece of story. I woke up this morning and found macOS Mail.app failed to login Gmail. I tried re-login a few times. No success and I left it aside. In a cozy afternoon, I decided to revisit the issue. The first thing I did was inspecting pixelserv-tls log on my Entware (RT-AC56U). So I looked at
/opt/var/log/pixelserv.log  and found repeated log entries like below at a few mins apart since midnight:
Mar 24 03:17:03 Phaeo pixelserv-tls: client 192.168.1.104 ssl error:14094418:lib(20):func(148):reason(1048)
Mar 24 03:19:03 Phaeo pixelserv-tls: client ssl error:14094418:lib(20):func(148):reason(1048)
Mar 24 03:21:04 Phaeo pixelserv-tls: client 192.168.1.104 ssl error:14094418:lib(20):func(148):reason(1048)
Error string "...reason(1048)" is from OpenSSL and added as temporary debug trace in v2.1.0-rc.2. The error code indicated
UNKNOWN_CA. That got me stoned since I'm sure the client has my Pixelserv CA imported. Next, I elevated pixelserv-tls log LEVEL to 4 . Retry login Gmail inside Mail.app. In the log file, now I saw something interesting:
Mar 24 14:09:03 Phaeo pixelserv-tls: 192.168.1.104 www.googleapis.com POST /oauth2/v4/token HTTP/1.1 secure
Mar 24 14:09:03 Phaeo pixelserv-tls: [client_id=77185425430.apps.googleusercontent.com&client_secret=manually sanitized&grant_type=refresh_token&refresh_token=manually sanitized&scope=https://www.googleapis.com/auth/chromesync]
The first line indicates a client attempted to use POST method to upload data to the Google host. The second line indicates the content POST method intends to send. Together the logs show apparently authentication data (note the keywords "oath2" and "token") to host
www.googleapi.com got blocked. So that explains why Mail.app failed to login Gmail since midnight. A little background. My adblock lists get updated at midnight everyday. Somehow the Google host got sneaked in last night and further diagnosis shows it's included by .
For now, I whitelist
www.googleapi.com which is an important host by any measure and shall not have been blocked! Mail.app works again. Also no more errors in pixelserv-tls log. Highlights for new pixelserv-tls users and my take-away:
reason(1048)could happen under scenarios you might not have considered before. This case shows it's not simply without your Pixelserv CA imported on client devices.
- the 2nd chunk of pixelserv-tls logs above demonstrates a client uses HTTP/1.1 POST method to upload content over HTTPS. Note the keyword
secureat the end that indicates HTTPS.
- logging POST content was a new feature added in pixelserv-tls v2.0.
- the logging feature is a helpful facility, not only for charting, but also inspecting and exposing privacy breach by 'rogue' domains.
- in this particular case, not a 'rogue' host but a 'wrongly blocked' host.
 pixelserv-tls log file captured by
syslog-ng and its filters on my Entware setup. Vanilla ASUSWRT will have these logs sent to
 An introduction to using this feature can be found in this HOW-TO.
 The culprit is this gambling-porn list. Update: the issue has been addressed in ticket #547.