Re: udhcpc6 missing source address
On Wed, Dec 14, 2022 at 11:23 PM David Laight wrote: > From: Denys Vlasenko > > Sent: 14 December 2022 21:17 > 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) Shouldn't be doing that. After the lease is acquired and before renew time is reached, dhcp client just sleeps. It does not receive any packets. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: udhcpc6 missing source address
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
Re: udhcpc6 missing source address
On Wed, Dec 14, 2022 at 8:59 PM John Lemonovich
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();
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
RE: udhcpc6 missing source address
From: Denys Vlasenko > Sent: 14 December 2022 10:04 > > On Wed, Dec 14, 2022 at 10:52 AM David Laight wrote: ... > If it's the code from the above, then no, kernel will not fill in > any IPv6 source addresses, as it does not even know it's > an IPv6/UDP packet - we use raw sockets here, > and we format UDP packet "by hand": Not enough coffee this morning to quickly interpret the strace output :-( I'm pretty sure there is a way of sending UDP multicast packets and that dhcpc6 could use it. (It is harder for IPv4 because there isn't a valid source IP.) We've got some code that sends UDP from RAWIP sockets. That allows the sender to change the source port for every message. For IPv6 the kernel can calculate the UDP checksum after doing the packet routing - so we don't have to build the IPv6 header. 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
Re: udhcpc6 missing source address
On Wed, Dec 14, 2022 at 10:52 AM David Laight wrote:
>
> From: John Lemonovich
> > Sent: 13 December 2022 20:35
> >
> > How are you getting a solicit message through with :: as the source
> > address, which I've found no
> > server likes as I've tested 3 of them? Or is mine not using the link local
> > address because I'm not
> > doing anything with the default.script?
> >
> > The kernel is 5.4.13
>
> I've just run a quick test.
>
> strace of uhdcpc6 shows it doing something with a routing socket,
> creating an IPv6 UDP socket, binding (probably to the interface)
> and then doing s sendto() that specifies the multicast MAC.
> (It puts the mcast address in the bind as well - probably ignored?)
This code?
int FAST_FUNC d6_send_raw_packet_from_client_data_ifindex(
struct d6_packet *d6_pkt, unsigned d6_pkt_size,
struct in6_addr *src_ipv6, int source_port,
struct in6_addr *dst_ipv6, int dest_port, const
uint8_t *dest_arp)
{
struct sockaddr_ll dest_sll;
struct ip6_udp_d6_packet packet;
int fd;
int result = -1;
const char *msg;
fd = socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IPV6));
if (fd < 0) {
msg = "socket(%s)";
goto ret_msg;
}
memset(_sll, 0, sizeof(dest_sll));
memset(, 0, offsetof(struct ip6_udp_d6_packet, data));
packet.data = *d6_pkt; /* struct copy */
dest_sll.sll_family = AF_PACKET;
dest_sll.sll_protocol = htons(ETH_P_IPV6);
dest_sll.sll_ifindex = client_data.ifindex;
/*dest_sll.sll_hatype = ARPHRD_???;*/
/*dest_sll.sll_pkttype = PACKET_???;*/
dest_sll.sll_halen = 6;
memcpy(dest_sll.sll_addr, dest_arp, 6);
if (bind(fd, (struct sockaddr *)_sll, sizeof(dest_sll)) < 0) {
msg = "bind(%s)";
goto ret_close;
}
> The kernel is providing the source IPv6 address as part of its
> normal UDP routing operations - the same as it does for any
> other outbound packet.
If it's the code from the above, then no, kernel will not fill in
any IPv6 source addresses, as it does not even know it's
an IPv6/UDP packet - we use raw sockets here,
and we format UDP packet "by hand":
packet.ip6.ip6_vfc = (6 << 4); /* 4 bits version, top 4 bits
of tclass */
if (src_ipv6)
packet.ip6.ip6_src = *src_ipv6; /* struct copy */
^ this is where source IPv6 address filled in
packet.ip6.ip6_dst = *dst_ipv6; /* struct copy */
packet.udp.source = htons(source_port);
packet.udp.dest = htons(dest_port);
/* size, excluding IP header: */
packet.udp.len = htons(sizeof(struct udphdr) + d6_pkt_size);
packet.ip6.ip6_plen = packet.udp.len;
/*
* Someone was smoking weed (at least) while inventing UDP checksumming:
* UDP checksum skips first four bytes of IPv6 header.
* 'next header' field should be summed as if it is one more byte
* to the right, therefore we write its value (IPPROTO_UDP)
* into ip6_hlim, and its 'real' location remains zero-filled for now.
*/
packet.ip6.ip6_hlim = IPPROTO_UDP;
packet.udp.check = inet_cksum(
(uint8_t *) + 4,
offsetof(struct ip6_udp_d6_packet, data) - 4 +
d6_pkt_size
);
/* fix 'hop limit' and 'next header' after UDP checksumming */
packet.ip6.ip6_hlim = 1; /* observed Windows machines to use hlim=1 */
packet.ip6.ip6_nxt = IPPROTO_UDP;
d6_dump_packet(d6_pkt);
result = sendto(fd, , offsetof(struct
ip6_udp_d6_packet, data) + d6_pkt_size,
/*flags:*/ 0,
(struct sockaddr *) _sll, sizeof(dest_sll)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: udhcpc6 missing source address
On Wed, Dec 14, 2022 at 8:55 AM Nicolas Cavallari
wrote:
>
> On 14/12/2022 00:47, Denys Vlasenko wrote:
> > On Tue, Dec 13, 2022 at 4:58 PM John Lemonovich
> > wrote:
> >>
> >> Thanks for the replies. Yes David, it's also my understanding per the
> >> spec, that the client's link-local address must be included for the
> >> solicit message.
> >
> > Where does it say that in https://www.rfc-editor.org/rfc/rfc3315 ?
>
> 1.1. Protocols and Addressing
>
> Clients and servers exchange DHCP messages using UDP [15]. The
> client uses a link-local address or addresses determined through
> other mechanisms for transmitting and receiving DHCP messages.
>
> Also, RFC 3315 is obsoleted by RFC 8415, but the wording is the same in
> section 5.
Looking at the code.
d6_send_raw_packet_from_client_data_ifindex() fills in
source address like this:
d6_send_raw_packet_from_client_data_ifindex(
packet, (end - (uint8_t*) packet),
/*src*/ _data.ll_ip6, CLIENT_PORT6,
... _data.ll_ip6 is passed as "src_ipv6" parameter into it, and...
if (src_ipv6)
packet.ip6.ip6_src = *src_ipv6; /* struct copy */
it is used as above.
client6_data.ll_ip6 is populated by periodic calls to
d6_read_interface(..._data.ll_ip6,...)
which looks at all addresses and should be finding
our link-local address, if it exists:
int FAST_FUNC d6_read_interface(
const char *interface,
int *ifindex,
struct in6_addr *nip6,
uint8_t *mac)
...
getifaddrs();
for (ifa = ifap; ifa; ifa = ifa->ifa_next) {
struct sockaddr_in6 *sip6;
if (!ifa->ifa_addr || (strcmp(ifa->ifa_name, interface) != 0))
continue;
...
sip6 = (void*)(ifa->ifa_addr);
if (ifa->ifa_addr->sa_family == AF_INET6
&& IN6_IS_ADDR_LINKLOCAL(>sin6_addr)
) {
*nip6 = sip6->sin6_addr; /* struct copy */
log1(
"IPv6
%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x",
nip6->s6_addr[0], nip6->s6_addr[1],
nip6->s6_addr[2], nip6->s6_addr[3],
nip6->s6_addr[4], nip6->s6_addr[5],
nip6->s6_addr[6], nip6->s6_addr[7],
nip6->s6_addr[8], nip6->s6_addr[9],
nip6->s6_addr[10], nip6->s6_addr[11],
nip6->s6_addr[12], nip6->s6_addr[13],
nip6->s6_addr[14], nip6->s6_addr[15]
);
retval &= (3 - (1<<1));
}
Do you reach this code? You can know it if you
enabled logging at least to level 1 (udhcpc6 -v) and you see
"IPv6 xx:xx:xx:...:xx" message.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
RE: udhcpc6 missing source address
From: John Lemonovich > Sent: 13 December 2022 20:35 > > How are you getting a solicit message through with :: as the source > address, which I've found no > server likes as I've tested 3 of them? Or is mine not using the link local > address because I'm not > doing anything with the default.script? > > The kernel is 5.4.13 I've just run a quick test. strace of uhdcpc6 shows it doing something with a routing socket, creating an IPv6 UDP socket, binding (probably to the interface) and then doing s sendto() that specifies the multicast MAC. (It puts the mcast address in the bind as well - probably ignored?) The kernel is providing the source IPv6 address as part of its normal UDP routing operations - the same as it does for any other outbound packet. tcpdump then shows the packet being sent from the link-local address - as expected. Three messages are sent, no reply received (I don't have a server here and there is absolutely nothing else on that network segment). The script is run 'leasefail' and it all retries a short time later. On a network with a server it gets a response. 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
Re: udhcpc6 missing source address
On 14/12/2022 00:47, Denys Vlasenko wrote: On Tue, Dec 13, 2022 at 4:58 PM John Lemonovich wrote: Thanks for the replies. Yes David, it's also my understanding per the spec, that the client's link-local address must be included for the solicit message. Where does it say that in https://www.rfc-editor.org/rfc/rfc3315 ? 1.1. Protocols and Addressing Clients and servers exchange DHCP messages using UDP [15]. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. Also, RFC 3315 is obsoleted by RFC 8415, but the wording is the same in section 5. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: udhcpc6 missing source address
On Tue, Dec 13, 2022 at 4:58 PM John Lemonovich wrote: > > Thanks for the replies. Yes David, it's also my understanding per the spec, > that the client's link-local address must be included for the solicit message. Where does it say that in https://www.rfc-editor.org/rfc/rfc3315 ? > The reply from the server is unicast. What do you mean by the proper IPv6 > version of the script...to which script are you referring to? Can you > possibly show an example? > > Just out of curiosity, has it ever been tested or known to work with a DHCPv6 > server then? I wrote the code based on IPv4. Couldn't test it. Surprisingly, people reported that it did work on the first try (with a number of bugs quickly discovered and hopefully fixed). I have no doubt it still has obvious bugs due to limited exposure. > I've tried with 3 different DHCP servers and they all seem to NOT want to > reply with a broadcast and are expecting to receive an address (e.g.: the > link local address) for a reply. My windows machines and my Ubuntu/Cent-OS > machines are doing it this way - they are not sending all 0's for the source > address for their requests. Here you mean "source address of the IPv6 packet", or some DHCPv6 option? Can you tcpdump clients which do acquire a lease from these servers? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: udhcpc6 missing source address
From: John Lemonovich > Sent: 13 December 2022 15:59 > > Thanks for the replies. Yes David, it's also my understanding per the spec, > that the client's link- > local address must be included for the solicit message. The reply from the > server is unicast. What > do you mean by the proper IPv6 version of the script...to which script are > you referring to? Can you > possibly show an example? The one that probably ends up in /usr/share/udhcpc/default.script and is passed to udhcpc6 with the -s option. Not the least of the problems is that you need to explicitly delete the old IPv6 address (in deconfig). I think the script I started from deleted the IPv4 address! There is also the issue that you need to do a 'mark and scan' pass over the routes (even in IPv4) to ensure the system isn't left with an invalid routing table during renew processing. > Just out of curiosity, has it ever been tested or known to work with a DHCPv6 > server then? Works for us (in testing anyway). There has also been a bug to do with release renewal. Might have been fixed. If any of our customers decide to use IPv6 I'll need to check - they clearly haven't on the previous product! (The lack of bugs is a pretty good hint.) I presume you are running a reasonably recent kernel. Anything really archaic might be buggy - but you should have a few years. Are you actually running Linux on a nios2? I can't actually imagine that being fast enough for anything useful. (Or does the arria10 contain an arm core?) We do use nios cpu - but only running a few kb of code. 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
RE: udhcpc6 missing source address
From: Denys Vlasenko > Sent: 13 December 2022 15:22 > > On Fri, Dec 9, 2022 at 5:09 PM John Lemonovich > wrote: > > Hello Denys, > > > > I am working on an embedded Linux project using an intel Arria 10 FPGA and > > have been using IPv4 for > a long time, and now need IPv6. I found your email online searching for > help. I have many things > working with IPv6, but the one thing I can’t get to work is udhcpc6 – it will > not acquire an IP > address via DHCPv6 (tried with multiple servers). I’m really stuck and > looking for any help – even a > pointer to documentation maybe I’m missing? > > Sorry, I myself have no DHPCv6 server to test against... > > > If I look at the tcpdump output – the solicit packets go out with a null > > source address (all 0’s - > just as :: ) > > Which kind of makes sense, if you think about it. DHCP client does not > _have_ an IP address yet, > this is the whole point of DHCP: to obtain an address... They do need to go out from the link-local address. Whatever starts udhcp6 needs to wait for it to be created. I don't remember any issues getting the initial response though. You will need to write a proper IPv6 version of the script that actually does the work. Also dhcp6 only gives you an address, the 'router advertise' stuff also has to be enabled (autoconf can be left disabled, but you need to be on a network where it would work). David > > > and the server doesn’t know how to reply (unreachable). > > I would imagine server can/should reply with a broadcast, right? > > > My link local address is set to: > > inet6 fe80::da80:39ff:fed8:90a0 prefixlen 64 scopeid 0x20 > > but yet udhcpc6 seems to put just :: in for the source address. > > But what if the iface has no link-local address either? > Then udhcpc6 would have no choice but leave it not filled. > And a good server implementation should deal with such incoming packets. > > > If there’s a better place to post this - please let me know. > > CCed to busybox ML. > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox - 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
Re: udhcpc6 missing source address
On Fri, Dec 9, 2022 at 5:09 PM John Lemonovich wrote: > Hello Denys, > > I am working on an embedded Linux project using an intel Arria 10 FPGA and > have been using IPv4 for a long time, and now need IPv6. I found your email > online searching for help. I have many things working with IPv6, but the one > thing I can’t get to work is udhcpc6 – it will not acquire an IP address via > DHCPv6 (tried with multiple servers). I’m really stuck and looking for any > help – even a pointer to documentation maybe I’m missing? Sorry, I myself have no DHPCv6 server to test against... > If I look at the tcpdump output – the solicit packets go out with a null > source address (all 0’s - just as :: ) Which kind of makes sense, if you think about it. DHCP client does not _have_ an IP address yet, this is the whole point of DHCP: to obtain an address... > and the server doesn’t know how to reply (unreachable). I would imagine server can/should reply with a broadcast, right? > My link local address is set to: > inet6 fe80::da80:39ff:fed8:90a0 prefixlen 64 scopeid 0x20 > but yet udhcpc6 seems to put just :: in for the source address. But what if the iface has no link-local address either? Then udhcpc6 would have no choice but leave it not filled. And a good server implementation should deal with such incoming packets. > If there’s a better place to post this - please let me know. CCed to busybox ML. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
