Google calendar - bad synchronization

Questions, comments, and problems with Zimbra on Apple desktops & general CalDAV / CardDAV questions.
Post Reply
FAGORDON
Posts: 15
Joined: Wed Nov 20, 2019 9:03 am

Google calendar - bad synchronization

Post by FAGORDON »

Good afternoon. We set up synchronization with Google calendar, followed all the instructions , and opened access to the desired address on the router. The calendar connects and starts syncing, but then the syncing disappears and in tcp we see a lot of close_wait in the google direction .

Code: Select all

 
 ....
 tcp 345 0 172.10.10.10:47910 64.233.164.132:443 CLOSE_WAIT 25131/java
 tcp 345 0 172.10.10.10:47910 64.233.164.132:443 CLOSE_WAIT 25131/java
 tcp 345 0 172.10.10.10:47910 64.233.164.132:443 CLOSE_WAIT 25131/java
 tcp 345 0 172.10.10.10:47910 64.233.164.132:443 CLOSE_WAIT 25131/java
 ....
 tcp 345 0 172.10.10.10:47910 64.233.164.132:443 CLOSE_WAIT 25131/java
 ...
 
if I kill PID 25131-java is restarted and I get error 502 in the WEB client .
syncing works fine for the first 2 to 3 minutes.
I wrote a script that kills pid-hung sessions every 3 minutes, but then I constantly get a 502 error in the web client.
firewall shows that the tcp_flags: FIN-ACK signal is coming from google,

Code: Select all

Number: 2018021
Date: 20Feb2020
Time: 11:44:36
Interface: eth1-01
Origin: Isec1061
Type: Log
Action: Drop
Service: https (443)
Source Port: 46258
Source: Zimbra_172.10.10.10 (172.10.10.10)
Destination: lq-in-f95.1e100.net (173.194.73.95)
Protocol: tcp
Information: TCP packet out of state: First packet isn't SYN
tcp_flags: FIN-ACK
Product: Security Gateway/Management
Product Family: Network
Policy Info: Policy Name: CorporatePolicy
Created at: Thu Feb 20 09:55:22 2020
Installed from: Isec220
but Zimbra is still waiting for Close_wait
What can I do for normal calendar synchronization ?

PS.

Code: Select all

[zimbra@zimbra ~]$ zmcontrol -v
Release 8.8.15_GA_3829.RHEL6_64_20190718141144 RHEL6_64 FOSS edition, Patch 8.8.15_P3.
FAGORDON
Posts: 15
Joined: Wed Nov 20, 2019 9:03 am

Re: Google calendar - bad synchronization

Post by FAGORDON »

the server is behind the firewall, maybe this is the problem?
.....But the connection to google is happening. and the telnet 443 port is available....
ps.
https://wiki.zimbra.com/wiki/How_to_syn ... _calendars
in the instruction where you need to enter the server name, I specified the name of the local server - is this correct?
Image
Killing the process that close_wait, synchronization works for a while , but after 2-3 minutes I see close_wait PID / java again

Code: Select all

[root@zimbra etc]# netstat -tulpanc | grep ':443 ' | grep "/java"
tcp      251      0 177.10.10.10:45690          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      201      0 177.10.10.10:45846          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      381      0 177.10.10.10:45848          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      230      0 177.10.10.10:45612          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      316      0 177.10.10.10:45616          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      389      0 177.10.10.10:45770          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      233      0 177.10.10.10:45842          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      408      0 177.10.10.10:45766          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      305      0 177.10.10.10:45764          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      332      0 177.10.10.10:45740          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      338      0 177.10.10.10:45610          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      186      0 177.10.10.10:45844          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      389      0 177.10.10.10:45704          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      297      0 177.10.10.10:45692          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      185      0 177.10.10.10:45736          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      325      0 177.10.10.10:45650          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      190      0 177.10.10.10:45706          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      212      0 177.10.10.10:45792          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      280      0 177.10.10.10:45628          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      345      0 177.10.10.10:45748          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      227      0 177.10.10.10:45742          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      402      0 177.10.10.10:45712          173.194.222.132:443         CLOSE_WAIT  25206/java 

my OS

Code: Select all

 [root@zimbra etc]# cat /etc/redhat-release 
CentOS release 6.10 (Final)
после возобновления синхронизации я вижу состояние SYN_SENT, но с другим PID / java
and as a rule the destination IP changes

Code: Select all

tcp      341      0 177.10.10.10:51488          173.194.222.132:443         CLOSE_WAIT  25206/java           
tcp      345      0 177.10.10.10:45748          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      227      0 177.10.10.10:45742          173.194.222.132:443         CLOSE_WAIT  25206/java          
tcp      402      0 177.10.10.10:45712          173.194.222.132:443         CLOSE_WAIT  25206/java         
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0      1 177.10.10.10:36646          52.30.151.10:443            SYN_SENT    6799/java 
then the state changes to ESTABLISHED
and at this point, synchronization works fine , but such actions with killing the process lead to errors in the WEB interface

Code: Select all

tcp        0      1 177.10.10.10:37768          52.30.151.10:443            SYN_SENT    6799/java           
tcp        0    342 177.10.10.10:53642          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      354      0 177.10.10.10:53640          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      376      0 177.10.10.10:53626          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      392      0 177.10.10.10:53632          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      297      0 177.10.10.10:53608          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      255      0 177.10.10.10:53606          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      292      0 177.10.10.10:53604          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      252      0 177.10.10.10:53630          173.194.222.132:443         ESTABLISHED 6799/java           
tcp        0      0 177.10.10.10:37242          173.194.222.95:443          ESTABLISHED 6799/java           
tcp      332      0 177.10.10.10:53636          173.194.222.132:443         ESTABLISHED 6799/java           
tcp      275      0 177.10.10.10:53644          173.194.222.132:443         ESTABLISHED 6799/java
FAGORDON
Posts: 15
Joined: Wed Nov 20, 2019 9:03 am

Re: Google calendar - bad synchronization

Post by FAGORDON »

the solution was on the surface ..... Install Centos 7 and install Zimbra for this OS
Post Reply