Device layer: the computer has an IP address and still cannot connect

A user calls. The intranet times out. The shared drive is gone. Outlook sits on “Trying to connect.”

You ask them to run ipconfig. They read back an address. Four numbers, three dots. It looks like an address, so the endpoint must be on the network.

It is not. An endpoint can hold a perfectly well-formed IP address and reach nothing at all. The address proves the adapter initialized. It proves nothing about whether the address works.

The device layer is the first stop on the access path. It is also the layer most often waved through, and the reason is right there in the phone call. Somebody read an address out loud and everyone moved on.

State your vantage before you state a finding

Every claim below is made from one place: the endpoint itself, signed in as the user, running local commands. That is the vantage.

Change the vantage and the verdict changes. A ping that fails from the laptop and succeeds from the switch is not the same finding. It is a different one. An engineer who reports “ping fails” without saying where they stood has reported nothing.

Write the vantage down. It is the difference between evidence and an opinion.

What the device layer actually covers

Endpoint health and configuration. A valid IP address, a correct subnet mask, and a reachable default gateway.

That is the whole layer. It is small, and it is the foundation for all seven layers above it. A fault here makes every layer above it lie to you.

The six things that break

1. No address at all

The endpoint shows 169.254.x.x. That is APIPA, a link-local address. Windows and Linux both assign one after DHCP gives up.

The endpoint asked for an address and never got an answer. Look at the DHCP scope first. A Windows Server DHCP scope runs dry. An ISC Kea or Infoblox pool exhausts. A DHCP relay on the switch drops the request. The switch port lands on the wrong VLAN, so the request reaches a scope that does not serve that subnet.

Prove it from the endpoint:

ipconfig /all

Look at three fields. DHCP Enabled: Yes. Autoconfiguration IPv4 Address: 169.254.4.201. DHCP Server is blank. That combination is a DHCP failure and nothing else.

On Linux:

ip addr show
nmcli device show

An address in 169.254.0.0/16 on the active interface says the same thing.

The 169.254 address is the symptom. The fault sits in DHCP, and DHCP sits on the next layer out.

2. An address, and the wrong subnet mask

This one hides for months. The endpoint holds a real address from a real scope. The mask is wrong.

Take 10.4.12.88 with a mask of 255.255.255.0, on a network that is really a /22. The endpoint now believes its local subnet is 10.4.12.0/24. The real subnet runs from 10.4.12.0 to 10.4.15.255.

Traffic to 10.4.12.5 works. The endpoint sees it as local, ARPs for it, gets an answer. Traffic to 10.4.14.30 also gets treated as local. The endpoint ARPs for a host that is not on its wire. Nobody answers. The packet never reaches the gateway, and the gateway is the only thing that could have routed it.

The user reports that some things work and some do not. That report is accurate, and it is the fingerprint of a wrong mask.

ip addr show
ip route show

Read the prefix on the address, then read the route table. A /24 on a /22 network is a wrong mask. On Windows, route print shows the same fault in the on-link routes.

3. No default gateway

The address is right. The mask is right. The gateway field is empty, or it holds an address on a subnet the endpoint cannot reach.

Local traffic works perfectly. Every user on the same wire is reachable. Nothing off-subnet works at all, and the failure is total rather than partial.

ip route show

The first line should read default via 10.4.12.1 dev eth0. No default line means no way off the subnet. On Windows, Get-NetIPConfiguration shows IPv4DefaultGateway as empty.

Then ping the gateway. This is the single most useful command at this layer.

ping 10.4.12.1

A gateway that answers means the endpoint has a working address, a working mask, and a working path to its first hop. That is the device layer cleared.

4. A duplicate address

Two hosts hold 10.4.12.88. A static address was typed onto a machine inside a live DHCP scope. It happens on printers, lab boxes, and a server somebody built in a hurry.

The symptom is the worst kind, which is the intermittent kind. Traffic reaches one host, then the other, depending on which ARP reply arrived last. The user says it works sometimes. Everyone assumes they are wrong. They are not.

arping -D -I eth0 10.4.12.88

-D runs duplicate address detection. Two different MAC addresses answering for one IP is proof, and it is the only clean proof of this fault.

On Windows, arp -a on a neighbor and the switch MAC address table tell the same story from the other side.

5. The wrong adapter is active

A laptop has a Wi-Fi adapter, a dock with an Ethernet port, a VPN adapter, and two virtual adapters from Docker or VMware. Five interfaces. One of them is answering.

The endpoint chose an interface by route metric, and it chose wrong. Traffic leaves on the Wi-Fi adapter and never touches the corporate wire the user is plugged into.

Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix 0.0.0.0/0

Two default routes with different metrics is the tell. On Linux, ip route show lists them in order, and the lowest metric wins.

The user is plugged in and connected. The endpoint disagrees.

6. Half an IPv6 stack

The endpoint holds an IPv6 link-local address, fe80::/10, and no usable global address. SLAAC never completed, or DHCPv6 never answered.

Modern operating systems prefer IPv6 over IPv4. The endpoint tries IPv6 first, waits for the timeout, then falls back. Nothing is broken. Everything is slow, and the user reports that the network “hangs.”

ip -6 addr show

A link-local address with no global address, on a network that runs IPv6, is a half-configured stack.

What this is not

The most useful thing this layer can do is hand the ticket to the right neighbor. Three faults look like a device problem and are not.

The gateway does not answer, and the address is correct. The endpoint is configured properly. Nothing is wrong on the device. The fault is the first hop out, which is the local network layer. Look at the switch port, the VLAN, the tunnel, and the wireless association. Start at the Local network module.

The gateway answers, and a name does not resolve. The device layer is clear and proven clear. A resolver address is configured on the device, and that misleads people. A resolver failure is still not a device failure. Go to the DNS module.

Everything routes, and one app is blocked for one user. The device is fine. The device is fine for everyone. A block that follows the user rather than the machine is an identity and policy question, and it lives at the rights layer. Go to the Check Point module.

A device that reaches its own gateway has cleared this layer. Stop working it.

Adjacent layers

The device layer is first, so it has one neighbor.

Next: local network. The first hop out. LAN, Wi-Fi, the local gateway, and the VPN tunnel. Every fault that survives a clean device check belongs there until proven otherwise. See the Local network module and how the full path fits together.

How PathWise walks the device layer in one pass

PathWise reads this layer with the IP Addressing module, which ships in the box and declares the device layer as the one thing it reads. You can see it at the IP Addressing module page, alongside the other modules.

It reads seven things in one pass. The IPv4 address, the subnet mask, and the default gateway. DHCP against static addressing, and the lease state, and scope exhaustion. A 169.254 link-local address as a DHCP failure signal. A duplicate address, using the artifacts an ARP probe leaves behind. A wrong mask or gateway producing the partial reachability described above. Multiple adapters, and the risk that the wrong one is active. IPv6 link-local, SLAAC, and DHCPv6 address state.

It gathers that evidence, states which of the six faults it found, and cites the output it read. It attaches a confidence level. It says what it could not verify. Then it stops.

PathWise does not fix the mask. It has no path to change your systems, and that limit lives in the code rather than in a prompt. It hands back a fix for a person to perform, and a person performs it.

Two honest notes on the boundary of this layer.

PathWise does not check endpoint posture, and it is not going to. Compliance checks, a Cisco ISE posture verdict, an Intune compliance state, all of that is real work and none of it ships in the box. It is a deliberate scope line, not a gap we are hurrying to close. Dedicated compliance tools already do that job. If you want posture folded into the access path anyway, the Open Module Standard is free and public, and somebody can write it.

The probes that produce device-layer evidence are not filed under the device layer. The ARP probe that proves a duplicate address is filed at the local network layer. That is a dispatch detail inside the engine, and it is not a claim about networking. A probe is a tool. A layer is where the failure is proven. The two are different things, and confusing them is how a troubleshooting session goes sideways for an afternoon.