Oops, I meant to comment on the debug thing. The most reliable way to get the ossec-agentd process into debug mode is to run it with the "-d" flag.
On Mon, Apr 4, 2011 at 4:07 PM, Valentin Avram <[email protected]> wrote: > See below. > > On Mon, Apr 4, 2011 at 10:18 PM, dan (ddp) <[email protected]> wrote: >> >> Does this mean you ran tcpdump on the server and saw no packets going >> to the agent? Or did you only run tcpdump on the agent? >> Either way, if packets are going from the server to the agent there's >> a problem. Find out where those packets are going. > > Running tcpdump on a good agent, on a service restart i saw packets going > from the agent towards the server (as expected), and a few reply packets > from the server to the agent (also as expected). > > Running tcpdump on the broken agent, also on a service restart i only saw > packets from the agent towards the server, NO reply packets from the server. > > Running tcpdump on the server, there were NO packets towards the broken > agents, but there were a few reply packets towards the other agents. > Try running remoted in debug as well ("-d" flag). > The only theory i have so far is the following: > - the server binds only to the 10.5.x.y IP > - any new packets towards the agent would use the 172.16.a.b IP, however > that should NOT happen, as only reply packets should be sent (if any), which > should use as source IP the IP for the UDP "connection" the agent created. > > Somewhere in the middle it seems to be a problem generating those reply > packets.. or so it seems. > >> >> > I believe those are the counters to help prevent replay attacks. If >> > the agent isn't communicating properly with the server, the counter >> > won't get updated. >> > > That makes sense, and it confirms that the communication between the server > and the agent does not work as expected. > > It still doesn't make sense why there are no errors in any logs (server's or > agent's) and why agentd.debug does not work. >
