Have you tried testing traffic on a test port to make certain traffic is getting there and coming from the direction you expect? For instance:
on the good server: tcpdump -n 'port 55512' on the bad agent machine: echo "hello?" | netcat goodserverip 55512 See if the traffic gets to the good server, and if so whether it comes from the IP you expected it to. On Apr 4, 2: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. > > 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.
