Wired PCs Down While the Wi-Fi Manager Keeps Working

Read the results as a ladder - each successful step clears everything below it:

Test	Result	What it proves
ping 192.168.1.1	1 ms	NIC, cable, switch, IP address, local subnet all fine
ping 8.8.8.8	24 ms	Default gateway, NAT, routing and the ISP link all fine
nslookup www.irctc.co.in	timeout	Name resolution is failing
Wi-Fi laptop works	OK	The line is not the problem; the fault is in the wired path's configuration

So the failing layer is DNS, not "the internet". The office can reach any address it already knows and cannot translate names into addresses.

Confirm before changing anything:

• nslookup www.irctc.co.in 8.8.8.8 - if that resolves, the public resolvers are fine and the local resolver is the broken part.
• ipconfig /all on a faulty PC: which DNS server is listed? If the wired DHCP scope hands out a stale or wrong DNS address while the Wi-Fi scope hands out a working one, that single difference explains why Wi-Fi works and wired does not.
• Browse to a site by IP (or ping the IP of a known site then open http://<ip>). Success confirms the browser path is intact.
• Check proxy settings (netsh winhttp show proxy, and Settings > Proxy) and the hosts file - a rogue proxy entry produces exactly this "pings work, browsing fails" picture.

Fix with the widest blast radius: correct the DNS option in the router's DHCP settings (or the router's DNS relay) so every wired PC gets a working resolver on lease renewal; if the relay itself is dead, hand out 1.1.1.1 and 8.8.8.8. Then ipconfig /release + /renew and ipconfig /flushdns per PC, and reboot the switch if leases are stale. Fallback for a single urgent machine: set static DNS to 1.1.1.1 / 8.8.8.8 in the adapter properties.

No - it is a second, independent fault, and fixing DNS will not fix it.

169.254.x.x is an APIPA address (Automatic Private IP Addressing). Windows assigns it to itself when it asks for a DHCP lease and gets no answer, so the machine has no gateway and can reach nothing beyond its own link. It is a symptom of a broken DHCP conversation, not of DNS.

Causes to work through, cheapest first:

1. Physical: cable unseated, a dead switch port, or a faulty patch lead - check link lights at both ends and swap the cable and port.
2. DHCP server side: pool exhausted (a 12-person office often has a tiny default pool plus a guest Wi-Fi range), the server/DHCP service disabled on the router after a firmware update, or a reservation conflict.
3. The PC's adapter set to a wrong static address, or DHCP disabled in adapter properties.

Repair: ipconfig /release then ipconfig /renew; if the lease still fails, set the adapter back to "Obtain an IP address automatically"; log into 192.168.1.1 and check the DHCP client list and pool size. If a static address is genuinely needed, choose one outside the DHCP pool (for example 192.168.1.240) rather than picking a random address inside it - otherwise two machines will eventually collide and produce an intermittent fault that is far harder to diagnose.

Verify success with ipconfig /all showing "DHCP Enabled: Yes" and a lease obtained, then ping the gateway. Treat it as a separate ticket from the DNS fault and record both, because the 11 a.m. bookings need both closed.

The browser is failing to validate the certificate chain. Three PCs failing on every site, including banks, points to a shared local cause rather than three coincidentally expired certificates.

Plausible causes, check in this order:

1. Wrong system date/time - a flat CMOS battery or a clock set years off is the most common and the cheapest to fix. A certificate that is valid from 1 Jan 2025 looks "not yet valid" to a PC that thinks it is 2019.
2. An intercepting proxy or SSL-inspecting antivirus web shield using a self-signed root, or a malicious proxy configured by adware. Check Settings > Proxy and netsh winhttp show proxy.
3. A captive portal or DNS hijack - plausible here, since name resolution is already broken.
4. Missing root certificate updates on an old Windows install, which breaks only newer chains, not literally every site.

Correct response: click the padlock/error details and read the certificate - issuer, validity dates, and whether the name matches the site. Fix the clock (set automatic time sync), remove any unknown proxy, run a malware scan, install pending Windows updates, and if the agency deliberately runs an inspection proxy, deploy its root certificate properly through policy and record that decision.

What staff must not do: click "Proceed anyway" / "Advanced > Continue", and above all must not do so on a bank portal. That click accepts an unverified identity on a machine that may be intercepted, and it also trains users to ignore the one warning that matters. Those three machines should not be used for any online payment until the certificate panel shows VALID. Keep the urgency honest: fixing DNS restores browsing, but the certificate warning is a separate stop-work item for banking.