Fixing Networking and DHCP Issues on Haiku
Diagnose Haiku DHCP failures in order: device and link, Wi-Fi association, lease and routes, DNS, static comparison, logs, and reports.
“No Internet” combines several layers: hardware driver, link or Wi-Fi association, DHCP lease, routes, DNS, and application protocol. DHCP is only responsible for configuration exchange. Confirm the lower layers and inspect the resulting address/route before changing name servers or browsers.
Confirm interface and link
Open Preferences → Network and run ifconfig in Terminal. Save the full output. An interface beyond loopback must exist before DHCP can configure it. If none appears, record listdev/listusb, hardware vendor/device IDs, and syslog; investigate driver support.
For Ethernet, verify cable, switch/router port, and link state. Test a known cable/port. For Wi-Fi, select the intended network and complete association/authentication before expecting a lease. A wrong passphrase or unsupported security mode can look like DHCP timeout because no DHCP frames reach the access point.
Do not infer link solely from the interface being administratively up. Device presence, enabled state, carrier/association, and packet exchange are separate evidence.
Inspect the lease result
Select DHCP for the interface in Network preferences, apply, and wait for completion. Re-run ifconfig and record address, mask, and interface flags. Inspect routes/default gateway with the system’s current network tools and save the output.
An address without a default route may reach only the local subnet. A self-assigned/link-local address is not evidence that the router supplied the intended lease. Compare with another working client on the same network, but never copy its address.
Toggle only the affected interface/configuration once to request a fresh lease. Avoid undocumented net_server kill commands; the supported preferences path preserves service ordering and produces clearer state.
If the machine has Ethernet, Wi-Fi, VPN/TUN, or USB networking active together, record all addresses and default routes. A valid DHCP lease on one interface can coexist with a default route through another. Disable only the unused interface for one comparison, then restore it; do not delete its settings before proving a route-selection problem.
Separate routing from DNS
Test the configured gateway, then a known numeric address appropriate to the network. If numeric connectivity works but hostnames fail, DHCP may have supplied missing/wrong DNS or the configured resolver may be unreachable. Record name-server settings and lookup errors.
If the gateway is unreachable, DNS is premature. Verify mask, route, association/link, and packet counters. If the gateway works but external numeric addresses fail, investigate router upstream routing/firewall rather than replacing the Haiku NIC driver immediately.
A browser failure after DNS and TCP work may be TLS, certificate, proxy, or application behavior. Test another simple client/endpoint and keep that evidence separate from DHCP.
Use static configuration only as a controlled test
Obtain an unused address, mask, gateway, and DNS values from the network administrator/router. Configure them in Network preferences. Never guess an address already inside the DHCP pool; a duplicate can disrupt another device and make results intermittent.
If static configuration reaches the gateway and Internet while DHCP repeatedly fails, the driver and basic packet path work. Capture the DHCP-specific logs/packets and inspect server pool, reservation, relay, VLAN, and filtering. Also test another client requesting a new lease.
Restore DHCP after the comparison unless the network intentionally uses static addressing. Record both configurations and exact timestamps so server logs can be correlated.
Test lease acquisition after cold boot, after disconnect/reconnect, and after sleep only when the first baseline is known. A lease that works at boot but not after resume is a lifecycle defect; a first-boot failure is initialization or network negotiation. Reporting those as separate sequences avoids hiding a driver-resume bug inside generic “DHCP fails.”
When packet capture is available, preserve the DHCP exchange rather than retransmitting indefinitely. The evidence should show whether requests leave the interface and whether replies return. No outbound request implicates local configuration/client state; outbound traffic without replies shifts attention toward link, access point, VLAN, firewall, relay, or server.
Capture a reproducible failure
Save Haiku revision/architecture, interface name, hardware IDs, wired/Wi-Fi details, AP/router model, Network preference screenshots, ifconfig, route and resolver state, and /var/log/syslog around the request. State whether link/association succeeds and whether any offer/lease is observed.
For Wi-Fi, report security type and band without publishing the password. For a regression, compare a previous package state or current live image with the same network and hardware. For USB adapters, test reconnect and cold boot separately.
After a fix, obtain a lease from a clean boot, renew/reconnect, reach gateway and numeric Internet, resolve a hostname, and complete an application request. That sequence validates every layer instead of declaring success when one address appears.
Related:
- Inside Haiku’s Network Stack: Interfaces, Protocol Modules, and Userland Services
- Fixing Display and Graphics Driver Issues in Haiku
Sources: