[riot-notifications] [RIOT-OS/RIOT] Add MUD URL option to DHCPv6 client (#15508)

Jan Romann notifications at github.com
Sat Nov 28 15:52:40 CET 2020

@JKRhb commented on this pull request.

> @@ -247,6 +247,17 @@ static inline size_t _compose_elapsed_time_opt(dhcpv6_opt_elapsed_time_t *time)
     return len + sizeof(dhcpv6_opt_t);
+static inline size_t _compose_mud_url_opt(dhcpv6_opt_mud_url_t *mud_url_opt,
+                                          char mud_url[])
+    uint16_t len = strlen(mud_url);
+    mud_url_opt->type = byteorder_htons(DHCPV6_OPT_MUD_URL);
+    mud_url_opt->len = byteorder_htons(len);
+    strcpy(mud_url_opt->mudString, mud_url);

> > Would using `strncpy` instead of `strcpy` solve this problem?
> Only if truncated URLs are still of any value

Hmm, probably not. The enlarged buffer should, however, minimize the risk of truncation. Or is there maybe a more robust and/or elegant way to prevent such a scenario?

> > I assume the length of the send buffer should be increased by 255 Bytes (or in accordance to the total length of the MUD option) if the `gnrc_dhcpv6_client_mud_url` pseudo-module is used?
> Yea something like
> ```c
> #define DHCPV6_CLIENT_BUFLEN        (512)
> #else 
> #define DHCPV6_CLIENT_BUFLEN        (256)
> #endif
> ```
> although it would probably be enough to only enlarge the send buffer

Would the addition of something like


in `client.c` be a good solution?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20201128/3ecdd152/attachment-0001.htm>

More information about the notifications mailing list