I just realized - reading more of this thread - that you were experiencing the problem even when not running a capture program. Then look at my suggestion below the other way around: start with the state of "stealing" IPs, and remove - one at a time - various programs running, until the process stops (no more ARP responses). You can use pslist and pskill (http://www.sysinternals.com/ntw2k/freeware/pstools.shtml) for that (or task manager?!?), in conjunction with procexp ... a second non-IP bound trace could also help ...
Stef On Tue, 30 Nov 2004 06:49:32 -0600, Stef <[EMAIL PROTECTED]> wrote: > Could you possibly run > http://www.sysinternals.com/ntw2k/freeware/procexp.shtml > then start a trace/capture from your system, and see who's the > "perpetrator"? It would also be nice if you could run a second trace, > from a system with no IP address associated with it (*nix/*BSD?!?), > sniffing traffic on the same switch(es) your Win-based system tends to > "steal" IPs from, to understand what is exactly the process of ARP > response, "seen" from a "neutral" system?!? > > Stef > > On Tue, 30 Nov 2004 10:30:39 +0200, Matthew Tagg <[EMAIL PROTECTED]> wrote: > > > > 1. The refresh period is never generally > 5 minutes, and the problem > > existed much longer than that. > > 2. We cleared ARP tables on the managed switch constantly. > > 3. We also cleared ARP on the windows machine "ARP -D *" > <snip> > ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/winpcap-users@winpcap.polito.it/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
