Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 40 replies
  • Subscribers 1 subscriber
  • Views 57086 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cannot Login to Gateway Manager

BangkokBob
Using VM 2.201 I cannot log into the gateway manager.  Either no response or error message "cannot connect to backend process".  Same admin account has no problem in accessing Webadmin.

Many errors in the ACC Core Daemon :

2010:10:01-11:39:02 acc accd: 466055991 [0xae17cba0] ERROR server.device.ReportingItem null - Error extracting binary reporting data (Error creating temporary director for file extraction: boost::filesystem::create_directory: Too many links: "/var/tmp/09af8f03-dd5a-4fa1-bbca-3c124874767b")
2010:10:01-11:39:02 acc accd: 466055991 [0xae17cba0] WARN server.device.ReportingItem null - reporting item will not be updated as binary part is erroneous: [5EAC4E9A-802D-11DF-BFD5-87DB1C65302B;reporting.security]
2010:10:01-11:39:18 acc accd: 466071837 [0xaa174ba0] ERROR server.main.PerlHashDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.ph'
2010:10:01-11:39:18 acc accd: 466071837 [0xaa174ba0] ERROR server.main.JsonDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.json'
2010:10:01-11:39:48 acc accd: 466101835 [0xae17cba0] ERROR server.main.PerlHashDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.ph'
2010:10:01-11:39:48 acc accd: 466101835 [0xae17cba0] ERROR server.main.JsonDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.json'
2010:10:01-11:40:18 acc accd: 466131833 [0xb4989ba0] ERROR server.main.PerlHashDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.ph'
2010:10:01-11:40:18 acc accd: 466131833 [0xb4989ba0] ERROR server.main.JsonDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.json'
2010:10:01-11:40:48 acc accd: 466161837 [0xa3967ba0] ERROR server.main.PerlHashDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.ph'
2010:10:01-11:40:48 acc accd: 466161838 [0xa3967ba0] ERROR server.main.JsonDumpStrategy null - Caught exception 'basic_ios::clear' processing '/var/diag/accd.json'
2010:10:01-11:40:57 acc accd: 466171539 [0xaf17eba0] ERROR libs.util.TarExtractor null - error extracting tarball: Error creating temporary director for file extraction: boost::filesystem::create_directory: Too many links: "/var/tmp/de5725ce-0ef6-4ec5-a840-840bc754ac5c"
2010:10:01-11:40:57 acc accd: 466171540 [0xaf17eba0] ERROR server.device.ReportingItem null - Error extracting binary reporting data (Error creating temporary director for file extraction: boost::filesystem::create_directory: Too many links: "/var/tmp/de5725ce-0ef6-4ec5-a840-840bc754ac5c")
2010:10:01-11:40:57 acc accd: 466171540 [0xaf17eba0] WARN server.device.ReportingItem null - reporting item will not be updated as binary part is erroneous: [90082066-9F9C-11DF-83A2-B576659BB770;reporting.security] 

Any suggestions how to fix?


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to stkfor
    Hi stkfor,

    I assume you are using version 2.202, right?

    Could you please login per ssh and call: 
    lsof -n -p `pidof accd`


    and check the number of TCP connections? Are there multiple connections to certain hosts?

    Please also call: 
    grep 'device is already connected'  /var/log/accd


    Please also check the content of the folder /var/chroot-accd/var/tmp. Are there any subfolders, and if so how many are there?

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

    I assume you are using version 2.202, right?


    Hi Hakan, yes 2.202 version


    Could you please login per ssh and call: 
    lsof -n -p `pidof accd`


    and check the number of TCP connections? Are there multiple connections to certain hosts?

    Yes one IP in particular


    Please also call: 
    grep 'device is already connected'  /var/log/accd


    No output with this command...



    Please also check the content of the folder /var/chroot-accd/var/tmp. Are there any subfolders, and if so how many are there?

    Regards, Hakan


    A huge amount (32000)...
  • 0 in reply to stkfor
    Hi,

    we have found the reason for this issue. We have found it on a setup where an ASG was in front of the ACC. On that ASG the "Astaro Flow Classifier" sometimes false-positively classified the payload of some ASGs as ICQ/OSCAR traffic and blocked it as there was an appropriate rule set under "Web Security -> IM/P2P -> IM".

    So everyone who has this problem should check whether he has also an ASG in front of the ACC and also check on that ASG whether there is a similar blocking of traffic which is going from the remote ASGs to the ACCs port 4433. This can be checked by inspecting the afc.log or ips.log. When the issue is happening live it can also be checked via tcpdump whether the payload arrives but isn't forwarded to the ACC. For this just listen with tcpdump whether the remote ASG sends P(ush) packets. Then listen whether these push packets are sent to the ACC.

    The solution is to set an exception for the remote ASGs.

    Nevertheless we have implemented a fix for the ACC such that it can now handle this situation without keeping the connections open. So now only the blocked ASGs appear offline and the accd doesn't get out of its limit. This is much better as the user now can check why those certain ASGs can't connect to the ACC and find the reason.

    The fix is available in the ACC V3.000 Beta.

    Regards, Hakan
  • 0 in reply to Hakan Yueksel
    Well, sorry to raise this issue again, however after waiting for the new ACC and installing and configuring, the connections seem to be ok until I have an interruption to service on my ACC then the majority of ASGs don't reconnect.  The ones that are OK are generally 7.5 branch, the ones that don't are generally 8.2 branch.

    My ACC is behind our ASG with a NATted public address routing 4430 to the ACC

    If I go to the remote ASGs and delete the old connection and renew, they reconnect fine.

    In my IPS log I find no trace of blocking.
    There doesn't seem to be in AFC.log in 8.2 but application control log is empty.

    Perhaps if my ACC never restarts I won't have an issue but realistically I can't expect this.  This is exactly the same issue I have reported on this topic, but now with the new version.  I have over 30 ASGs linked to the ACC and I find it tedious to go and restart the central management on them all.  I am happy to provide logs of this ACC or any ASGs connecting.
  • 0 in reply to BangkokBob
    Hi Bob,

    did the ip address of your ACC change after the interruption?
    If so you probably have the same problem as described here
    and here for which we will provide a solution within the next
    ASG release.

    Regards, Hakan
Unfiltered HTML