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. 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.
