From: Denys Vlasenko > Sent: 14 December 2022 21:17 ... > For comparison, this is how DHCPv4 looks on the wire: > > 28:df:eb:11:48:92 > Broadcast, ethertype IPv4 (0x0800), length 342: > (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length > 328) > 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from > 28:df:eb:11:48:92, length 300, xid 0x158e8233, Flags [none] > Client-Ethernet-Address 28:df:eb:11:48:92 > ... > 40:3f:8c:7c:7a:2d > 28:df:eb:11:48:92, ethertype IPv4 (0x0800), length > 342: (tos 0xc0, ttl 64, id 41793, offset 0, flags [none], proto UDP > (17), length 328) > 192.168.1.1.bootps > 192.168.1.193.bootpc: BOOTP/DHCP, Reply, > length 300, xid 0x158e8233, Flags [none] > Your-IP 192.168.1.193 > Server-IP 192.168.1.1 > > Not only the server is unfazed by source IP of 0.0.0.0, it > nevertheless sends _unicast_ reply, > because it saw client's MAC address. (It even filled our would-be IP > in the destination IP field, > to be extra nice).
The 0.0.0.0 source IP is just a fudge, there is nothing else that can be put in the field. And you'll probably find the both the dchp client and server side are using the raw packet interface (with a BPF filter) to receive the packets. A Linux system that runs the dhcp client never reports any received ethernet packets as 'discarded by software' because they all get passed to dhcp! (At least one time I looked anyway) The IPv6 broadcast UDP packet (from the link-local address) is much more of a standard UDP packet than anything dhcp4 uses. Quite why the system in failing to allocate/return it's link-local address is another matter entirely. I think there is a standard wrapped that waits for the link-local address to appear before starting udhcpc6, we use this shell code: wait_link_local() { # Wait for the ipv6 link local address to appear. # Probably needed for dhcp6 to work at all. eth=$1 shift while ip_addr=$(ip "$@" address show dev "$eth" scope link 2>/dev/null) || return 1 [ "${ip_addr#*inet6 fe80}" = "$ip_addr" ] do sleep 0.5 done return 0 } We do have the full 'ip' command, not just the busybox version. I'm not sure what happens if you try to start udhcpc6 too soon. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox