3cxsbc not reconnecting after a network failure

[Gaëtan]

Hi,
I'm using sbc on a debian server internally and when the server is not reachable for some time, for example because of a network outage or 3cx restarting for ssl certificate renewable the sbc did not reconnect and stay with message saying tunnel is not connected. After restarting the service, it's going great.

Messages in the logs are the following:

err:3CXTunnel[18967]::2018-12-31T03:16:40.433859+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:644 | Socket error (6): secure read at secure read (Tu
nnelTcp::process)
err:3CXTunnel[18967]::2018-12-31T03:16:40.435512+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:268 | Bridge [3CX Session Border Controller 02] failur
e 'error:00000006:lib(0):func(0):EVP lib' on TCP connection: secure read
warning:3CXTunnel[18967]::2018-12-31T03:16:40.437041+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/Bridge.cpp:261 | Tunnel disconnected. Terminating all active cal
ls.
err:3CXTunnel[18967]::2018-12-31T03:16:40.547188+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:210 | Failover timeout has been reached
warning:3CXTunnel[18967]::2018-12-31T03:16:40.558369+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/Dns.cpp:80 | [DNS] Failed to retrieve SRV records for _3cxtunnel._tcp.; errcode=4
err:3CXTunnel[18967]::2018-12-31T03:16:40.559986+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:165 | Failed to resolved DNS SRV record for tunnel connection to
warning:3CXTunnel[18967]::2018-12-31T03:16:40.658427+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/Dns.cpp:128 | [DNS] Failed to resolve host name ; errcode=1
err:3CXTunnel[18967]::2018-12-31T03:16:40.660069+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:184 | Failed to resolve host name
err:3CXTunnel[18967]::2018-12-31T03:16:40.661422+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:224 | Can not resolve any of specified connection FQDNs
err:3CXTunnel[18967]::2018-12-31T03:16:40.961946+01:00: TUNL | 139903658727616 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/Bridge.cpp:773 | Tunnel is not connected! SIP message is not sent: SipReq:  REGISTER XXXXX.3cx.fr:5060 tid=3tjuu2fvpooz50pvxfp cseq=83518 REGISTER [email protected] / 83518 from(wire)

 

[eddv123]

I used to get similar issues with the Raspberry Pi variant. It would not connect unless you restart the tunnel service (or if you do not want to effect the entire PBX tunnel service) login to the device and issue the command "service 3cxsbc start".

If you want to gather logging from the device (for a 3CX support ticket for example) you could log from the SBC. This can be done in the 3cxsbc.conf which can be found in the "etc" folder in Linux.

Change the DEBUG to VERBOSE then run the below commands:

1) Edit file /etc/3cxsbc.config and uncomment the # File section.
2) Stop the 3cxsbc service (service 3cxsbc stop)
3) Stop the rsyslog service (service rsyslog stop)
4) Delete file ls -l /var/log/ (rm /var/log/3cxsbc.log)
5) Recreate /var/log/3cxsbc.log (touch /var/log/3cxsbc.log)
6) Start the rsyslog service (service rsyslog start)
7) Start the 3cxsbc service (service 3cxsbc start

You can also tail -f the logs so that it saves to a txt file.

 

[DSXVOICE]

We use a cron script that watches a number of SBC pulses - the most effective part of the script watches to see if the tunnel is up and if not - it restarts the service.

X=$( netstat | grep -c 5090 )

if [ $X -eq 0 ]; then
sudo service 3cxsbc stop
sleep 10
sudo service 3cxsbc start
fi

If you use a different tunnel port - change 5090 to whatever that is...