Member Avatar for Minnino

I have a network that consists of a server running windows 2003 server SP2, which has been dcpromo'ed to a Domain Controller. And 2 workstations both running WinXP Pro SP2. All machines have a static IP address set, and are all on the same subnet.

Both workstations have their windows firewall turned off, and even though they are off there is an exception to allow ICMP echo.

All machines are hard wired to a router. All machines have access to the internet.

From all machines I am able to run a nslookup command and get the proper information back using IP address, and hostname.

From the server I can ping workstation 2 and get a reply but cannot get a reply from workstation 1, I receive 'request timed out'

Workstation 1 is able to ping everything in the network, get to shared drives, and use remote desktop to any machine without a problem.

Workstation 2 can ping the server, get to the server's share, and remote into the server. It cannot ping or access anything on Workstation 2.

Running a 'net view' command on all machines will list all 3 machines.

I Have tried disconnecting all machines from the domain and reconnecting them and get the same error.

If anyone could shed some light on this issue it would be greatly appreciated.

If any other information is needed please let me know.

  • 3 Contributors
  • 5 Replies
  • 387 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Minnino

Dani AI

Generated

Resolution noted: solved the problem by removing and rebuilding the NIC drivers on every machine. That outcome strongly points to a problem in the network adapter/driver layer rather than DNS, shares or basic TCP/IP configuration.

Why driver work often fixes one-way ping symptoms

  • Asymmetric behaviour (one host can initiate connections but does not respond when another host initiates) usually means the packet reached the wire but the local stack or NIC never completed the reply. Corrupt or incompatible NIC drivers, broken NDIS filter drivers installed by third‑party security or VPN software, bad offload/negotiation settings, or flaky firmware can produce exactly that symptom. Reinstalling drivers removes corrupted filter hooks and restores a clean adapter stack, which matches the observed fix.

Practical checklist for future troubleshooting (concise, non-redundant with earlier replies)

  • Verify the physical path first: swap cable and switch port or test with a known-good USB/PCI NIC to isolate hardware.
  • Do a clean driver uninstall and reinstall from the NIC vendor (avoid layered/old drivers left behind).
  • Check for low-level filter drivers (security, VPN, virtualization) and temporarily remove them when isolating the problem.
  • Inspect NIC properties for power-management and offload/duplex settings; if issues persist, force known-good settings rather than auto-negotiation.
  • Review Windows System logs for driver or NIC errors and capture packets on the host or switch to confirm whether ICMP/ARP requests and replies appear on the wire.

Notes tying back to earlier suggestions

  • The antivirus and stack-reset ideas from were valid checks to rule out software filters; the DNS/firewall suggestions from are still good when driver-level causes are excluded. After a driver-level repair, prefer vendor-updated drivers and a controlled reinstall to avoid recurrence.

Recommended Answers

All 5 Replies

Member Avatar for DimaYasny

any additional complex antivirus progs installed? something like norton internet security

any unneeded protocols installed on the stations?

Member Avatar for Minnino

The only security software that is running on all the machines is NOD32 anti virus

Member Avatar for DimaYasny

try resetting winsock on the machines as well

are the pings that do come through timed normally?

Member Avatar for antioed

Sounds like DNS is working, either way you should be testing by IP first to rule out any DNS. But it sounds like there is something going on with a firewall here. When you join a domain it resets your firewall profile...have you checked that again to be safe? Make sure there's no IP/DNS conflicts. Check DNS config and reload the DNS service if you find any conflicts in records. Run ipconfig /flushdns to reset the DNS caches on each workstation. Sometimes you'll get a DNS entry for one host set to another and then one won't be able to talk to the other. DNS in AD plays a huge role. Good luck.

You can also use the telnet command and port numbers to test for ip ports required for services. Sometimes this is a quick way to see if a service is available from a host:

telnet <ip> <port>

telnet 445 would tap the MS DNS port of - you can find common port assignments at IANA: http://iana.org/assignments/port-numbers

Member Avatar for Minnino

Hey guys, thanks for all your input. After removing all the drivers for the NIC on all machine and rebuilding them. All machine are now able to communicate. Thank you for all your help!!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.