Member Avatar for jcmmartin

I work in a mixed Mac and PC environment, majority PC, and I have DHCP running on 2 servers with different scopes both are Win 2003 Server. The issue that I am having is with the client name in the address lease of the DHCP server.
Some of them come up with a BAD_ADDRESS which is very frequent. The bigger problem is the complete lack of name in the lease. I have noticed the problem because of some monitoring and the IP errors in the Mac’s that have a MAC OS X 10.3.9. For this reason the MAC machines doesn’t have communication to the internet. What I have to do in order to solve this issue.

Thanks in advance.

Juan C. Martínez

  • 2 Contributors
  • 1 Reply
  • 344 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by yellow

Dani AI

Generated

A short, practical diagnosis and checklist for (building on ’s note about name/ID issues):

BAD_ADDRESS entries on a Microsoft DHCP server mean the server detected that an IP appears to be already in use and therefore marked it unusable instead of leasing it. This is a server-side conflict detection behaviour (the server will ping/check before assigning) and is the usual reason scopes fill with BAD_ADDRESS. (learn.microsoft.com)

Quick things to check first

  • Look for static IPs or devices accidentally configured inside the DHCP pool, and confirm the two Windows DHCP servers’ scopes do not overlap.
  • Search for any rogue DHCP service (consumer routers, VM/virtualbox hosts, wireless controllers) by stopping the DHCP service briefly and seeing whether clients still obtain addresses.
  • If BAD_ADDRESS recurs for the same IPs, reconcile the DHCP database and inspect recent migrations or restores (database corruption/migration issues can produce persistent BAD_ADDRESS entries). (support.microsoft.com)

Troubleshooting steps (practical)

  1. In the DHCP console note the IP, Unique ID and timestamp for BAD_ADDRESS entries.
  2. On the router/server run arp -a and check the switch CAM/MAC table to find the physical port for that MAC, then isolate the device.
  3. Capture DHCP traffic (Wireshark) on the subnet to see DHCPDISCOVER/REQUEST packets and the client-identifier/hostname sent. That will show whether a client or rogue server is causing the conflict.
  4. After fixing the root cause, remove BAD_ADDRESS entries (or wait for expiry) and, if needed for troubleshooting, temporarily enable a small number of conflict-detection pings on the DHCP server (1–2 attempts) to avoid handing out conflicting addresses while you hunt the culprit. (learn.microsoft.com)

Mac-specific checks and name visibility

  • Make sure each Mac is actually getting an address via DHCP and renew the lease on a test Mac (System Preferences > Network > Advanced > TCP/IP > Renew DHCP Lease). If the Mac never sends a hostname or the DHCP server is not configured to register names, the Name column will be blank even when the lease is good. (support.apple.com)

If BAD_ADDRESS entries keep returning, use DHCP snooping / port security on your switches to block unauthorized DHCPOFFERs and speed locating the offending port. (juniper.net)

If more details from your lease table (sample BAD_ADDRESS rows, Unique IDs) or a short packet capture are available, a focused next step can be suggested.

Member Avatar for yellow

In order for the name service to work properly, the DHCP client ID and the "Sharing name" should be the same on the Macs. And naturally they should not include spaces or non-alphanumeric characters.

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.