On Wed, Dec 14, 2022 at 8:59 PM John Lemonovich
<john.lemonov...@foresys.com> wrote:
> Thank you all for the replies so far. I am admittedly an FPGA
> designer/hardware guy, and an embedded software/networking person only enough
> to be able to get the hardware working 😊
>
>
> Here is a the wireshark (via tcpdump) of the solicit msg from my Intel SOC
> device running udhcpc6:
>
> 5 2.848295 :: ff02::1:2 DHCPv6 96
> Solicit XID: 0x286846 CID: 00030001d88039d890a0
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).
> And here is the dhcp.log at the server for the udhcpc6 client:
>
> 2022:12:06-09:29:52 access dhcpd6: Solicit message from :: port 546,
> transaction ID 0x541D1C00
> 2022:12:06-09:29:52 access dhcpd6: Picking pool address
> 2002:189a:af04:40::fb50
> 2022:12:06-09:29:52 access dhcpd6: Advertise NA: address
> 2002:189a:af04:40::fb50 to client with duid 00:03:00:01:d8:80:39:d8:90:a0
> iaid = -1564778168 valid for 300 seconds
> 2022:12:06-09:29:52 access dhcpd6: Sending Advertise to :: port 546
> 2022:12:06-09:29:52 access dhcpd6: send_packet6: Network is unreachable
Tries to send to all-zero IPv6.
I wonder whether we can fool it by having broadcast IPv6 source
address in our solicit :]
> It's possible there might be clients that are working for me here that do
> have the source address set to :: (not certain). I need to get the
> tcpdump for these. I was assuming from the difference in log messages at the
> server that the source is always non-zero when it's working, but I need more
> information to prove that.
Can you instrument d6_read_interface() in networking/udhcp/d6_socket.c
for (ifa = ifap; ifa; ifa = ifa->ifa_next) {
struct sockaddr_in6 *sip6;
getifaddrs(&ifap);
if (!ifa->ifa_addr || (strcmp(ifa->ifa_name, interface) != 0))
continue;
+bb_error_msg("iface:'%s' sa_family:%u", interface, ifa->ifa_addr->sa_family );
if (ifa->ifa_addr->sa_family == AF_PACKET) {
to see whether we do get any address info?
> Section 4.1
> Every IPv6 interface on which DHCPv6 can reasonably be useful has a
> link-local address
Fukushima's emergency manual stated that total loss of power is
so unlikely that this scenario is not considered.
My machine right now has all IPv6 addresses deleted by my firewall script.
Why shouldn't it be able to get a DHCPv6 one?
Anyway.
The code DOES try to find client's own IPv6 address, and use it.
Somehow, this does not work on your machine.
Add debugging to d6_read_interface() to find out why.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
