Mathew,
Matthew Tagg wrote:
This is a remote possibility of course, but unlikely at least in my thinking. I considered this and could come up with no reasonable scenario and it would be a major bug in the network code. One would *expect* the bug to have been found on other machines, by other users, so I would assign a low probability to this. Typically the drivers for a card are more suspect and changing the card type did fix your problem so perhaps there is some wierd interaction, but again I think this scenario is unlikely. If the other causes don't pan out then I would definitely try an experiment and see if the problem reoccurs when installed with a different driver.Hi Terry
My replies below.
A couple of things as I read this thread- based on speculation as I try to understand what is going on.
- some process must intercepting ARP replies and sending out incorrect
ARP reply packets
By this it take it you mean some application process? Can in not be the
windows networking subsystem?
Sorry, I was unclear, I meant to say "changing the card type" rather than "removing the card". My thought is that a service would not be able to find the card/type/driver and would not be able to start successfully.
- winpcap being installed around the time the problem started makes one
wonder if there was some sequence like (based on the fact that winpcap
by itself does nothing)
-- program X installed
-- X intercepts ARP requests and replies to them but works OK in
non-promiscuous mode (why? I don't know)
-- install winpcap, some programs sets the card in promiscuous mode
-- X now gets all ARP requests for all machines and sends replies- or
it has been sending ARP replies all along and in promiscuous mode they
actually get sent
-- the uninstall doesn't work (because it wasn't run or had errors or
the wrong install or ...)
-- some service fires up on reboot and sets card in reboot mode (this
explains why removing the card fixed the problem- the service could not
find it?)
Actually removing the card and replacing it with a different one (diff mac
address) though exact same model, did NOT solve the problem. It was only
when I added a second card (DIFFERENT model - 1000GBps this time) and
disabled the first one did the problem go away.
Since Winpcap.dll was not found when arp packets, the only role I can imagine winpcap playing is that putting the card in promiscous mode contributed to the problem. As someone pointed out early in the discussion, some monitor programs will try to do poison arp so that they can see all frames, perhaps even if you are only monitoring one address,- so perhaps there is some interaction between the monitor program and the card being put in promiscuous mode. Having no experience with the programs involved I don't know if this is possible or not. If I was having the problem the other thing I would try is checking for malware.
Where X could be netlimiter, trafficstatisic or something else
Things to do and questions
-- which uninstall was run? (winpcap or trafstatistics)
Both and netlimiter uninstall
-- after uninstall if you searched the machine for the winpcap DLLs,
were they found?
No..
-- if winpcap and tra..statistics were installed and netlimiter was not
installed, did the problem still occur?
I never tried that - this was a very urgent situation - my may concern was
to stop the DOS on the other machines while maintaining uptime on the rogue
machine.
-- did you run an anti-virus/spyware program?
No
I am going to run WinPCap and TrafficStatisic installs through a reg and file sniffer to see exactly what gets modified.
Good luck, It would be interesting to know the resolution .. Terry
================================================================== 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]
==================================================================
