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
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox