Authoritative DHCP server(s), NACK and “NCB is in use on a remote adapter”
[2026.04.16]
I hate Windows. I mean, I REALLY do. Since I changed shop and got myself entangled with a Windows 11 laptop, not a single day passes without my experiencing an overwhelming death wish, on myself, some Microsoft engineer or the entire universe (let it go back to a frigid state of null entropy… at least, there shall be peace), despite spending most of my time in my beloved WSL-ed Debian.
I could start with Windows SSH Agent not honoring the -t option, with some obscure agent
refused operation message, pretendedly “to be more secure”… WHAT-THE-F…CK!!!
Or with my YubiKey (PIV/PKCS#11) PIN code ending up in the Windows Registry… and persisting across reboot!!!… WHAT-THE-F…CKING-F…CK!!!
Or the fact it is strictly impossible to achieve seamless roaming between Ethernet and WiFi adapters while maintaining established TCP/UDP connections. A thing that comes down, on Linux, on attributing the same IP address to both adapters, although with different metrics. Believe me, I spent days on that topic… in the end, tmux MUST become your best friend.
But what drove me above board is some exquisitely obscure “An error occured while renewing interface Ethernet: The name specified in the NCB is in use on a remote adapter” message when hooking this piece of horse dump of a laptop on my home network and not obtaining network connectivity (even though the fault ended up being mine).
# WTF ?
> ipconfig.exe
Ethernet adapter Ethernet:
IPv4 Address. . . 169.254.12.34
Subnet Mask . . . 255.255.0.0
# WTF !
> ipconfig.exe /renew
An error occured while renewing interface Ethernet: The name specified in the network control block
(NCB) is in use on a remote adapter.
The NCB is the data.
# WTF !!!???!!!...
Now, be my guest. Go ahead. Google it for me!
The most enlighting and highly compentent solutions I found were of the vein “Factory reset your router and try again”. Yeah! Love that level of expertise and professionalism! “Hello? Yes. Are you the Network Manager? Yes. Can you factory reset the company firewall, please?”.
So I took upon myself to discard all those sources of enrichment and reverted to some noobing around:
# On my not-factory-reset router
root@gl-mt6000:~# tcpdump -i br-guest -pn -v udp port 67 or udp port 68
tcpdump: listening on br-guest, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:54:52.485783 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 342)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 11:22:33:44:55:66, length 314, xid 0x79c043a, Flags [none]
Client-Ethernet-Address 11:22:33:44:55:66
Vendor-rfc1048 Extensions
DHCP-Message (53), length 1: Request
Client-ID (61), length 7: ether 11:22:33:44:55:66
Requested-IP (50), length 4: 192.168.4.101
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
MTU (26), BR (28), Lease-Time (51), RN (58)
RB (59), Vendor-Option (43), URL (114), Unknown (108)
17:54:52.486450 IP (tos 0xc0, ttl 64, id 64596, offset 0, flags [none], proto UDP (17), length 328)
192.168.4.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, hops 1, xid 0x79c043a, Flags [Broadcast]
Client-Ethernet-Address 11:22:33:44:55:66
Vendor-rfc1048 Extensions
DHCP-Message (53), length 1: NACK
Server-ID (54), length 4: 192.168.4.1
MSG (56), length 21: "address not available"
17:54:52.492436 IP (tos 0xc0, ttl 64, id 32052, offset 0, flags [none], proto UDP (17), length 354)
192.168.4.1.67 > 192.168.4.101.68: BOOTP/DHCP, Reply, length 326, hops 1, xid 0x79c043a, Flags [none]
Your-IP 192.168.4.101
Gateway-IP 192.168.4.1
Client-Ethernet-Address 11:22:33:44:55:66
Vendor-rfc1048 Extensions
DHCP-Message (53), length 1: ACK
Subnet-Mask (1), length 4: 255.255.254.0
Default-Gateway (3), length 4: 192.168.4.1
Domain-Name-Server (6), length 4: 192.168.1.11
Server-ID (54), length 4: 192.168.1.11
Client-ID (61), length 7: ether 11:22:33:44:55:66
17:54:52.589682 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 338)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 11:22:33:44:55:66, length 310, xid 0x250f825d, Flags [none]
Client-Ethernet-Address 11:22:33:44:55:66
Vendor-rfc1048 Extensions
DHCP-Message (53), length 1: Discover
Client-ID (61), length 7: ether 11:22:33:44:55:66
MSZ (57), length 2: 1500
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
MTU (26), BR (28), Lease-Time (51), RN (58)
RB (59), Vendor-Option (43), URL (114), ...
[[etc. etc. DHCP traffic storm. etc. etc.]]
Now, if you’re as dumb and green as I am, you might notice:
my laptop is obviously keen on having/keeping its
192.168.4.101IP address (as per its DHCP Request)which the DHCP server
192.168.1.11obliges (DHCP ACK), further enlighting us with the255.255.255.254subnet maskwhich the DHCP server
192.168.4.1strictly opposes (DHCP NACK)
Which tells us:
there are obviously (at least) two segments in this network topology
one where the ACK-ing
192.168.1.11DHCP server residesone where the laptop itself and the NACK-ing
192.168.4.1DHCP server (and gateway) resides
Which further tells us:
- the
192.168.4.1gateway (and DHCP server) obviously relays DHCP (broadcast) traffic to the other (subnet’s) DHCP server
But, gloating put aside, what this tells us is that the “The name specified in the network control block (NCB) is in use on a remote adapter” actually means that a DHCP server NACK-s - opposes - the IP address you would expect your host to use.
Now, speaking of DHCP servers, the noobs we are - still, as opposed to the experts who recommend we factory reset our routers - might have heard of authoritative vs non-authoritative servers.
Even though one should not waste time in reading RFCs - aka. piles of crap which even the most incompetent AI can best - HI (Human Intelligence) afficionados might recall:
“Servers SHOULD NOT respond if their information is not guaranteed to be accurate. For example, a server that identifies a request for an expired binding that is owned by another server SHOULD NOT respond with a DHCPNAK unless the servers are using an explicit mechanism to maintain coherency among the servers” (RFC 2131, §3.2)
In layman terms, a DHCP server than can not “maintain coherency among the servers” is not authoritative.
All of which coming down to the take-away which interests us:
an authorative DHCP server is allowed to send DHCP NACK-s to clients
while a non-authoritative DHCP server never should
As per RFC 2131, §4.3.2, an non-authoritative DHCP server is one that complies with “If the DHCP server has no record of this client, then it MUST remain silent, and MAY output a warning to the network administrator. This behavior is necessary for peaceful coexistence of non-communicating DHCP servers on the same wire.”
Coming back the packet-captured DHCP traffic above:
the
192.168.1.11DHCP server is obviously the one we would expect to be authoritativethe
192.168.4.1DHCP server obviously believes it is - since it preposterously sends NACK-s to clients - which it obviously should not
Verification made, my router was effectively, erroneously, configured to be authoritative.
Configuration corrected. ipconfig.exe /renew. And there we were, 192.168.4.101 successfully
attributed to the laptop. Network connectivity restored. Back in business.
But now, I don’t know whether I should hate Windows even more - given Linux, Android, Mac OS and iOS don’t fail so miserably when an erroneously-authoritative DHCP server NACK-s them (reason why it took me so long to discover that misconfiguration) - or a bit less… given the RFC 2131, §3.2 says “If the client receives a DHCPNAK message, it cannot reuse its remembered network address.” (although the RFC says nothing about what to do when a client receives both a DHCPACK and DHCPNAK responses).
I’ll go for hating Windows even more.
Voilà!
 Cédric Dufour (résumé, software, GitHub) |
Created with discount and markdown-rsync |