Wazuh: Agent with broken tcp connection should update the agent state

[jesusgn90]

As we said here https://documentation.wazuh.com/3.x/user-manual/agents/agent-life-cycle.html#agent-status I understand that an agent using tcp protocol should appear as Disconnected just after it's down but I think we are not looking properly to the broken pipe or something similar, please review it guys!

Best,
Jesús

[jesusgn90]

Hi @gagantous, here is the issue as I said on our last conversation, and here I'm copying your closed issue from the App repository: https://github.com/wazuh/wazuh-kibana-app/issues/349

Best,
Jesús

[gagantous]

Hi @jesusgn90!

I am really looking forward to this, hope the team could solved this cases.

Best regards
Fathin

[gagantous]

Perhaps i have to add some "necessary" info regarding my question. When i disconnected the agent with manager, it took me 20-30 minutes. but when i connected again the agent with manager, it just took about a second to change the status to "active" again. I thought the concept of "disconnected" and "active" are pretty similar, but the "change status immediatley" only works when the agent are in condition "disconnected to active", while the condition "active to disconnected" just didnt work.

[jesusgn90]

Hi again @gagantous , I've copied your closed issue (where you explain all the details) on my second comment so don't worry, also I've explained to the developers your situation and they are researching about it. Thanks one more time.

Best,
Jesús

[vikman90]

Hi @gagantous and @jesusgn90,

Unfortunately, that's an error in the documentation: the manager reports an agent as disconnected when no keep-alive was received from it within the last 30 minutes, no matter if the protocol is UDP or TCP.

When an agent that was disconnected establishes a connection again, it always sends its keep-alive packet (including the agent version, OS information and the version of the shared configuration). That's why the agent appears as connected immediately.

Reporting an agent as disconnected immediately on TCP is possible and it makes much sense. But we have to solve some problems before:

• If the connection is established but the manager is overloaded, there may be a big delay in the delivery of the keep-alive (and the response). Despite the connection is TCP, the agent is not considered itself as connected until it receives an explicit response of the keep-alive. In this case, the agent would appear as connected (due to the TCP connection) but it wouldn't report events until the manager confirms the connection. We have just introduced an input buffer in the manager, this should help improve the response time.

• The keep-alive time is stored as the modification time of the agent's file in /var/ossec/queue/agent-info. The manager may mark agents that have disconnected immediately, but if Remoted is stopped or the manager is restarted, the agents would still appear as connected. I'm thinking in a mechanism to query this data directly to Remoted.

We are working on this. So far we are going to fix the documentation.

Thank you for your feedback!
Best regards.