Thread Info
  • State Not Answered
  • Replies 17 replies
  • Subscribers 0 subscribers
  • Views 10991 views
  • Users 0 members are here
Options
Suggested

[2.830][BUG] Device lost connection to ACC

quasar3c279
Hi,
I have one out of 48 devices which lost the connection to my ACC. In the ACC it's shown as offline.

In the device agent logfile I get the following lines repeated: 

2011:06:17-08:47:43 firewall-1 device-agent[7891]: 1 is not connected. Trying to connect

2011:06:17-08:47:43 firewall-1 device-agent[7891]: [1] Connecting to ACC socket (ip=212.*.*.*, port=4433).

2011:06:17-08:47:48 firewall-1 device-agent[7891]: [1] ACC connection failure, retrying (ip=212.*.*.*, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'

2011:06:17-08:47:54 firewall-1 device-agent[7891]: [1] ACC connection failure, retrying (ip=212.*.*.*, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'

2011:06:17-08:47:55 firewall-1 device-agent[7891]: [1] Connection failed (ip=212.*.*.*, port=4433).

2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 1 not executing: denied by role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 2 not executing: denied by role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 3 not executing: denied by role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 4 not executing: denied by role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 5 not executing: denied by role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 6 not executing: denied by role

2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 7 not executing: denied by role 


The ASG runs firmware 8.103.

Mario
Parents
  • 0
    In my Beta 3 Gateway manager I have 31 devices registered.  Of these there is a mixture of 7.5 and 8.1 gateways.  I did not import my previous setup but created a new ACC environment.
    Since commencing 19 of these devices now show that they do not connect (majority are v8 devices).  These 19 machines are contactable via normal web admin.   It appears that when a connection fails, the ACC or the device has trouble reestablishing the connection.  I had hoped that this issue which was prevalent with 2.2 would have been addressed in this 3 beta release.
    If a login or provision of logs would help, I am happy to provide.
  • 0 in reply to BangkokBob
    Hi Mario, hi Bob,

    do you have an ASG in front of your ACC? If so it is possible that this ASG blocks the packets from the remote ASGs.

    See here.

    Regards, Hakan
  • 0 in reply to Hakan Yueksel
    Hi Hakan,

    Yes, we do have an Astaro in front of our ACC.  I will go through checking the logs, however I notice that the primary problem is for 8.1 gateways, not for 7.5

    Of the 21 8.1 gateways, 17 have connection problems (of the balance, 2 are internal and two I've reconnected today).  Of the 10 7.5 gateways, 9 are up and one is actually down.  

    Unless there are different strings in the connections being made between the 8.1 and 7.5 gateways to the ACC, I would have expected that all would suffer equally if an IPS problem?
Reply
  • 0 in reply to Hakan Yueksel
    Hi Hakan,

    Yes, we do have an Astaro in front of our ACC.  I will go through checking the logs, however I notice that the primary problem is for 8.1 gateways, not for 7.5

    Of the 21 8.1 gateways, 17 have connection problems (of the balance, 2 are internal and two I've reconnected today).  Of the 10 7.5 gateways, 9 are up and one is actually down.  

    Unless there are different strings in the connections being made between the 8.1 and 7.5 gateways to the ACC, I would have expected that all would suffer equally if an IPS problem?
Children
  • 0 in reply to BangkokBob
    Hi Bob,


    Unless there are different strings in the connections being made between the 8.1 and 7.5 gateways to the ACC, I would have expected that all would suffer equally if an IPS problem?


    IMHO not necessarily.

    You could also check whether you had that problem by searching for the string "SSL handshake timeout, closing connection" in your accd log files, i.e. /var/log/accd.log or the archived logs under /var/log/accd.

    If you find it then it is a strong indicator that you had the blocking problem.

    Regards, Hakan
  • 0 in reply to Hakan Yueksel
    Hi Hakan,

    Sorry for the travel caused delay in responding.

    We've checked our logs and cannot find the string "SSL handshake timeout" in our accd.log. 
    The size of accd.log in remote ASG is 0 since May. All files in archive are 0. 
    I also cannot find the blocking in packetfilter.log for our ip 192.168.200.48 in our ASG 

    It strikes me a strange as when I restart the accd through web admin of the remote gateway, it will connect, and then stay up for sometimes up to a day before failing, and then at that point it is unsuccessful at reconnecting.

    Also as previously mentioned, the problems are with 8.1 gateways, not 7.5
    regards

    Robert
  • 0 in reply to BangkokBob
    Hi Robert,

    it seems that you have encountered another problem. I think it would be the most helpful if you could provide us with ssh access to the ACC when the issue happens again. I'm going to send you a pm.

    Regards, Hakan
Unfiltered HTML