| Message ID | 20191120181131.2622-1-uwe@kleine-koenig.org |
|---|---|
| State | Accepted |
| Delegated to: | Hans Dedecker |
| Headers | show |
| Series | [OpenWrt-Devel,netifd] interface: warn if ip6hint is truncated | expand |
On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > > When for example a /60 is assigned to a network the last 4 bits of the > ip6hint are unused. Emit a warning if any of these unused bits is set as > it indicates that someone didn't understand how the hint is used. (As I > did earlier today resulting in spending some time understanding the > code.) Patch applied with some minor tweaks (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); I added your SoB as this was missing in the patch Hans > --- > interface.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/interface.c b/interface.c > index 028dc6ccd5e5..839de0bb88ad 100644 > --- a/interface.c > +++ b/interface.c > @@ -863,9 +863,15 @@ interface_alloc(const char *name, struct blob_attr *config, bool dynamic) > } > > iface->assignment_hint = -1; > - if ((cur = tb[IFACE_ATTR_IP6HINT])) > - iface->assignment_hint = strtol(blobmsg_get_string(cur), NULL, 16) & > - ~((1 << (64 - iface->assignment_length)) - 1); > + if ((cur = tb[IFACE_ATTR_IP6HINT])) { > + int32_t assignment_hint = strtol(blobmsg_get_string(cur), NULL, 16); > + > + iface->assignment_hint = assignment_hint & ~((1 << (64 - iface->assignment_length)) - 1); > + > + if (iface->assignment_hint != assignment_hint) > + netifd_log_message(L_WARNING, "Ignoring set bits of assignment hint for interface '%s'\n", > + iface->name); > + } > > if ((cur = tb[IFACE_ATTR_IP6CLASS])) > interface_add_assignment_classes(iface, cur); > -- > 2.24.0 > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 11/29/19 8:50 PM, Hans Dedecker wrote: > On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >> >> When for example a /60 is assigned to a network the last 4 bits of the >> ip6hint are unused. Emit a warning if any of these unused bits is set as >> it indicates that someone didn't understand how the hint is used. (As I >> did earlier today resulting in spending some time understanding the >> code.) > Patch applied with some minor tweaks > (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); The updated warning message is fine. > I added your SoB as this was missing in the patch I wonder what the significance of the SoB is given that a) it's not documented (at least in the netifd sources) and b) it seems to be ok to "fake" someone else's SoB and c) there are several commits in the newer history of netifd that don't have a SoB of either Author or Committer (or both). Best regards Uwe
Hi, On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > > On 11/29/19 8:50 PM, Hans Dedecker wrote: > > On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >> > >> When for example a /60 is assigned to a network the last 4 bits of the > >> ip6hint are unused. Emit a warning if any of these unused bits is set as > >> it indicates that someone didn't understand how the hint is used. (As I > >> did earlier today resulting in spending some time understanding the > >> code.) > > Patch applied with some minor tweaks > > (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); > > The updated warning message is fine. > > > I added your SoB as this was missing in the patch > > I wonder what the significance of the SoB is given that a) it's not > documented (at least in the netifd sources) and b) it seems to be ok to > "fake" someone else's SoB and c) there are several commits in the newer > history of netifd that don't have a SoB of either Author or Committer > (or both). For details why a SoB is required; see https://openwrt.org/submitting-patches#sign_your_work. If there're any commits in the netifd repo which don't have a SoB this must rather stay an exception than becoming a general rule. Hans > > Best regards > Uwe >
Hello Hans, On 12/3/19 8:50 AM, Hans Dedecker wrote: > On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >> >> On 11/29/19 8:50 PM, Hans Dedecker wrote: >>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >>>> >>>> When for example a /60 is assigned to a network the last 4 bits of the >>>> ip6hint are unused. Emit a warning if any of these unused bits is set as >>>> it indicates that someone didn't understand how the hint is used. (As I >>>> did earlier today resulting in spending some time understanding the >>>> code.) >>> Patch applied with some minor tweaks >>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); >> >> The updated warning message is fine. >> >>> I added your SoB as this was missing in the patch >> >> I wonder what the significance of the SoB is given that a) it's not >> documented (at least in the netifd sources) and b) it seems to be ok to >> "fake" someone else's SoB and c) there are several commits in the newer >> history of netifd that don't have a SoB of either Author or Committer >> (or both). > For details why a SoB is required; see > https://openwrt.org/submitting-patches#sign_your_work. > If there're any commits in the netifd repo which don't have a SoB this > must rather stay an exception than becoming a general rule. ok, so you claim my SoB means that *I* confirmed that my change is compatible to the netifd's license. I didn't do that though. Even if it was me who added that line I doubt is has any relevance for netifd because nothing in the netifd sources explains what an SoB means. And the link you sent applies only to patches for openwrt, not netifd. (Also if this is the only place for openwrt where the significance of an SoB is described I wonder if this is relevant given that from the POV of openwrt.git the wiki is an external resource that can be modified by anyone. What if someone removes item (d) from the wiki or introduces an (e)?) Don't get me wrong, my patch is compatible to netifd's license. But if you want that netifd's license situation stays reasonably safe and clean, it IMHO cannot be that you add a SoB for someone else, and give that SoB a meaning that isn't documented for your project and assumes things about that someone else that you cannot know for sure. So if you require a formalism, please formalize it properly. (Of course INAL, but that's my understanding of how open source licensing works.) Best regards Uwe
On Tue, Dec 03, 2019 at 03:59:18PM +0100, Uwe Kleine-König wrote: <snip> > > ok, so you claim my SoB means that *I* confirmed that my change is > compatible to the netifd's license. I didn't do that though. > > Even if it was me who added that line I doubt is has any relevance for > netifd because nothing in the netifd sources explains what an SoB means. > And the link you sent applies only to patches for openwrt, not netifd. > (Also if this is the only place for openwrt where the significance of an > SoB is described I wonder if this is relevant given that from the POV of > openwrt.git the wiki is an external resource that can be modified by > anyone. What if someone removes item (d) from the wiki or introduces an > (e)?) Hi Uwe, The OpenWrt "Submitting patches" article links to https://www.kernel.org/doc/html/latest/process/submitting-patches.html. There the sign-off (and the reasons for it) is explained a bit more. So it seems OpenWrt is just following kernel.org's example. Which is fine in my opinion. Regarding somebody adding the sign-off _for_ you I share your opinion. It has to be _your_ sign-off, so if a third party adds it for you this is not correct. I didn't really think about this before reading your mail. So thanks for highlighting this. Regards, Seb > Don't get me wrong, my patch is compatible to netifd's license. But if > you want that netifd's license situation stays reasonably safe and > clean, it IMHO cannot be that you add a SoB for someone else, and give > that SoB a meaning that isn't documented for your project and assumes > things about that someone else that you cannot know for sure. So if you > require a formalism, please formalize it properly. (Of course INAL, but > that's my understanding of how open source licensing works.) > > Best regards > Uwe
On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > > Hello Hans, > > On 12/3/19 8:50 AM, Hans Dedecker wrote: > > On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >> > >> On 11/29/19 8:50 PM, Hans Dedecker wrote: > >>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >>>> > >>>> When for example a /60 is assigned to a network the last 4 bits of the > >>>> ip6hint are unused. Emit a warning if any of these unused bits is set as > >>>> it indicates that someone didn't understand how the hint is used. (As I > >>>> did earlier today resulting in spending some time understanding the > >>>> code.) > >>> Patch applied with some minor tweaks > >>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); > >> > >> The updated warning message is fine. > >> > >>> I added your SoB as this was missing in the patch > >> > >> I wonder what the significance of the SoB is given that a) it's not > >> documented (at least in the netifd sources) and b) it seems to be ok to > >> "fake" someone else's SoB and c) there are several commits in the newer > >> history of netifd that don't have a SoB of either Author or Committer > >> (or both). > > For details why a SoB is required; see > > https://openwrt.org/submitting-patches#sign_your_work. > > If there're any commits in the netifd repo which don't have a SoB this > > must rather stay an exception than becoming a general rule. > > ok, so you claim my SoB means that *I* confirmed that my change is > compatible to the netifd's license. I didn't do that though. > > Even if it was me who added that line I doubt is has any relevance for > netifd because nothing in the netifd sources explains what an SoB means. > And the link you sent applies only to patches for openwrt, not netifd. > (Also if this is the only place for openwrt where the significance of an > SoB is described I wonder if this is relevant given that from the POV of > openwrt.git the wiki is an external resource that can be modified by > anyone. What if someone removes item (d) from the wiki or introduces an > (e)?) > > Don't get me wrong, my patch is compatible to netifd's license. But if > you want that netifd's license situation stays reasonably safe and > clean, it IMHO cannot be that you add a SoB for someone else, and give > that SoB a meaning that isn't documented for your project and assumes > things about that someone else that you cannot know for sure. So if you > require a formalism, please formalize it properly. (Of course INAL, but > that's my understanding of how open source licensing works.) I won't waste further my time and energy on this ... I acted in good faith and next time if I find a patch from you without SoB I will just simply reject it to avoid contra productive discussions Patches delivered for all projects (netifd/libubox/ubus/...) maintained by OpenWrt must have a SoB in line what is described on the Wiki; this does not solely apply to the OpenWrt repo This closes the discussion for me Hans > > Best regards > Uwe > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi, On Tue, 3 Dec 2019 at 16:29, Hans Dedecker <dedeckeh@gmail.com> wrote: > > On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > > > > Hello Hans, > > > > On 12/3/19 8:50 AM, Hans Dedecker wrote: > > > On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > > >> > > >> On 11/29/19 8:50 PM, Hans Dedecker wrote: > > >>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > > >>>> > > >>>> When for example a /60 is assigned to a network the last 4 bits of the > > >>>> ip6hint are unused. Emit a warning if any of these unused bits is set as > > >>>> it indicates that someone didn't understand how the hint is used. (As I > > >>>> did earlier today resulting in spending some time understanding the > > >>>> code.) > > >>> Patch applied with some minor tweaks > > >>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); > > >> > > >> The updated warning message is fine. > > >> > > >>> I added your SoB as this was missing in the patch > > >> > > >> I wonder what the significance of the SoB is given that a) it's not > > >> documented (at least in the netifd sources) and b) it seems to be ok to > > >> "fake" someone else's SoB and c) there are several commits in the newer > > >> history of netifd that don't have a SoB of either Author or Committer > > >> (or both). > > > For details why a SoB is required; see > > > https://openwrt.org/submitting-patches#sign_your_work. > > > If there're any commits in the netifd repo which don't have a SoB this > > > must rather stay an exception than becoming a general rule. > > > > ok, so you claim my SoB means that *I* confirmed that my change is > > compatible to the netifd's license. I didn't do that though. > > > > Even if it was me who added that line I doubt is has any relevance for > > netifd because nothing in the netifd sources explains what an SoB means. > > And the link you sent applies only to patches for openwrt, not netifd. > > (Also if this is the only place for openwrt where the significance of an > > SoB is described I wonder if this is relevant given that from the POV of > > openwrt.git the wiki is an external resource that can be modified by > > anyone. What if someone removes item (d) from the wiki or introduces an > > (e)?) > > > > Don't get me wrong, my patch is compatible to netifd's license. But if > > you want that netifd's license situation stays reasonably safe and > > clean, it IMHO cannot be that you add a SoB for someone else, and give > > that SoB a meaning that isn't documented for your project and assumes > > things about that someone else that you cannot know for sure. So if you > > require a formalism, please formalize it properly. (Of course INAL, but > > that's my understanding of how open source licensing works.) > I won't waste further my time and energy on this ... > I acted in good faith and next time if I find a patch from you without > SoB I will just simply reject it to avoid contra productive > discussions I have to agree with everyone, so please don't add SoBs for *anyone* except yourself. This is basically similar to forging a signature (just without the direct legal consequences of that). > Patches delivered for all projects (netifd/libubox/ubus/...) > maintained by OpenWrt must have a SoB in line what is described on the > Wiki; this does not solely apply to the OpenWrt repo Indeed, so patches without one, or a broken one need to be fixed by the submitter/author. This cannot be fixed up by the maintainer (except maybe with an explicit permission of the author). Regards Jonas
On 03/12/19 15:59, Uwe Kleine-König wrote: > Hello Hans, > > On 12/3/19 8:50 AM, Hans Dedecker wrote: >> On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >>> >>> On 11/29/19 8:50 PM, Hans Dedecker wrote: >>>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >>>>> >>>>> When for example a /60 is assigned to a network the last 4 bits of the >>>>> ip6hint are unused. Emit a warning if any of these unused bits is set as >>>>> it indicates that someone didn't understand how the hint is used. (As I >>>>> did earlier today resulting in spending some time understanding the >>>>> code.) >>>> Patch applied with some minor tweaks >>>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); >>> >>> The updated warning message is fine. >>> >>>> I added your SoB as this was missing in the patch >>> >>> I wonder what the significance of the SoB is given that a) it's not >>> documented (at least in the netifd sources) and b) it seems to be ok to >>> "fake" someone else's SoB and c) there are several commits in the newer >>> history of netifd that don't have a SoB of either Author or Committer >>> (or both). >> For details why a SoB is required; see >> https://openwrt.org/submitting-patches#sign_your_work. >> If there're any commits in the netifd repo which don't have a SoB this >> must rather stay an exception than becoming a general rule. > > ok, so you claim my SoB means that *I* confirmed that my change is > compatible to the netifd's license. I didn't do that though. > > Even if it was me who added that line I doubt is has any relevance for > netifd because nothing in the netifd sources explains what an SoB means. > And the link you sent applies only to patches for openwrt, not netifd. > (Also if this is the only place for openwrt where the significance of an > SoB is described I wonder if this is relevant given that from the POV of > openwrt.git the wiki is an external resource that can be modified by > anyone. What if someone removes item (d) from the wiki or introduces an > (e)?) The wiki is not a third party project, the stuff written in the submission rules was decided by or written by core OpenWrt developers. Any change to wiki pages is reviewed and if it is wrong it is reverted by me or tmomas (wiki admins). That said, I thought netifd is a daemon created by OpenWrt project so the submission rules should still apply. -Alberto
On 12/3/19 4:28 PM, Hans Dedecker wrote: > On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >> >> Hello Hans, >> >> On 12/3/19 8:50 AM, Hans Dedecker wrote: >>> On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >>>> >>>> On 11/29/19 8:50 PM, Hans Dedecker wrote: >>>>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >>>>>> >>>>>> When for example a /60 is assigned to a network the last 4 bits of the >>>>>> ip6hint are unused. Emit a warning if any of these unused bits is set as >>>>>> it indicates that someone didn't understand how the hint is used. (As I >>>>>> did earlier today resulting in spending some time understanding the >>>>>> code.) >>>>> Patch applied with some minor tweaks >>>>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); >>>> >>>> The updated warning message is fine. >>>> >>>>> I added your SoB as this was missing in the patch >>>> >>>> I wonder what the significance of the SoB is given that a) it's not >>>> documented (at least in the netifd sources) and b) it seems to be ok to >>>> "fake" someone else's SoB and c) there are several commits in the newer >>>> history of netifd that don't have a SoB of either Author or Committer >>>> (or both). >>> For details why a SoB is required; see >>> https://openwrt.org/submitting-patches#sign_your_work. >>> If there're any commits in the netifd repo which don't have a SoB this >>> must rather stay an exception than becoming a general rule. >> >> ok, so you claim my SoB means that *I* confirmed that my change is >> compatible to the netifd's license. I didn't do that though. >> >> Even if it was me who added that line I doubt is has any relevance for >> netifd because nothing in the netifd sources explains what an SoB means. >> And the link you sent applies only to patches for openwrt, not netifd. >> (Also if this is the only place for openwrt where the significance of an >> SoB is described I wonder if this is relevant given that from the POV of >> openwrt.git the wiki is an external resource that can be modified by >> anyone. What if someone removes item (d) from the wiki or introduces an >> (e)?) >> >> Don't get me wrong, my patch is compatible to netifd's license. But if >> you want that netifd's license situation stays reasonably safe and >> clean, it IMHO cannot be that you add a SoB for someone else, and give >> that SoB a meaning that isn't documented for your project and assumes >> things about that someone else that you cannot know for sure. So if you >> require a formalism, please formalize it properly. (Of course INAL, but >> that's my understanding of how open source licensing works.) > I won't waste further my time and energy on this ... > I acted in good faith and next time if I find a patch from you without > SoB I will just simply reject it to avoid contra productive > discussions I would have expected that the discussion is in your interest because not being strict with licenses is something that really hurts when it goes wrong. My intention is not to drain your energy but to highlight the necessity[1] to be stricter with license stuff than the way my patch was handled. > Patches delivered for all projects (netifd/libubox/ubus/...) > maintained by OpenWrt must have a SoB in line what is described on the > Wiki; this does not solely apply to the OpenWrt repo > > This closes the discussion for me Fine for me, I won't press the matter any further. I wish you that this problem won't backfire. Bye Uwe [1] well, or at least what I consider to be necessary
On Tue, Dec 03, 2019 at 08:56:46PM +0100, Uwe Kleine-König wrote: > On 12/3/19 4:28 PM, Hans Dedecker wrote: > > On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >> > >> Hello Hans, > >> > >> On 12/3/19 8:50 AM, Hans Dedecker wrote: > >>> On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >>>> > >>>> On 11/29/19 8:50 PM, Hans Dedecker wrote: > >>>>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >>>>>> > >>>>>> When for example a /60 is assigned to a network the last 4 bits of the > >>>>>> ip6hint are unused. Emit a warning if any of these unused bits is set as > >>>>>> it indicates that someone didn't understand how the hint is used. (As I > >>>>>> did earlier today resulting in spending some time understanding the > >>>>>> code.) > >>>>> Patch applied with some minor tweaks > >>>>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397); > >>>> > >>>> The updated warning message is fine. > >>>> > >>>>> I added your SoB as this was missing in the patch > >>>> > >>>> I wonder what the significance of the SoB is given that a) it's not > >>>> documented (at least in the netifd sources) and b) it seems to be ok to > >>>> "fake" someone else's SoB and c) there are several commits in the newer > >>>> history of netifd that don't have a SoB of either Author or Committer > >>>> (or both). > >>> For details why a SoB is required; see > >>> https://openwrt.org/submitting-patches#sign_your_work. > >>> If there're any commits in the netifd repo which don't have a SoB this > >>> must rather stay an exception than becoming a general rule. > >> > >> ok, so you claim my SoB means that *I* confirmed that my change is > >> compatible to the netifd's license. I didn't do that though. > >> > >> Even if it was me who added that line I doubt is has any relevance for > >> netifd because nothing in the netifd sources explains what an SoB means. > >> And the link you sent applies only to patches for openwrt, not netifd. > >> (Also if this is the only place for openwrt where the significance of an > >> SoB is described I wonder if this is relevant given that from the POV of > >> openwrt.git the wiki is an external resource that can be modified by > >> anyone. What if someone removes item (d) from the wiki or introduces an > >> (e)?) > >> > >> Don't get me wrong, my patch is compatible to netifd's license. But if > >> you want that netifd's license situation stays reasonably safe and > >> clean, it IMHO cannot be that you add a SoB for someone else, and give > >> that SoB a meaning that isn't documented for your project and assumes > >> things about that someone else that you cannot know for sure. So if you > >> require a formalism, please formalize it properly. (Of course INAL, but > >> that's my understanding of how open source licensing works.) > > I won't waste further my time and energy on this ... > > I acted in good faith and next time if I find a patch from you without > > SoB I will just simply reject it to avoid contra productive > > discussions Yes, and please do so as well for anyone else who doesn't add SoB herself. > > I would have expected that the discussion is in your interest because > not being strict with licenses is something that really hurts when it > goes wrong. My intention is not to drain your energy but to highlight > the necessity[1] to be stricter with license stuff than the way my patch > was handled. I definitely agree, adding SoB on behalf of someone else should not happen and I haven't seen it happening before this occasion. > > > Patches delivered for all projects (netifd/libubox/ubus/...) > > maintained by OpenWrt must have a SoB in line what is described on the > > Wiki; this does not solely apply to the OpenWrt repo > > > > This closes the discussion for me > > Fine for me, I won't press the matter any further. I wish you that this > problem won't backfire. I hope as well... > > Bye > Uwe > > [1] well, or at least what I consider to be necessary >
Hi, > ok, so you claim my SoB means that *I* confirmed that my change is > compatible to the netifd's license. I didn't do that though. as it has been pointed out on this list, adding a S-o-b without consent should not be done, so I reverted the offending commit. Kind regards, Jo
diff --git a/interface.c b/interface.c index 028dc6ccd5e5..839de0bb88ad 100644 --- a/interface.c +++ b/interface.c @@ -863,9 +863,15 @@ interface_alloc(const char *name, struct blob_attr *config, bool dynamic) } iface->assignment_hint = -1; - if ((cur = tb[IFACE_ATTR_IP6HINT])) - iface->assignment_hint = strtol(blobmsg_get_string(cur), NULL, 16) & - ~((1 << (64 - iface->assignment_length)) - 1); + if ((cur = tb[IFACE_ATTR_IP6HINT])) { + int32_t assignment_hint = strtol(blobmsg_get_string(cur), NULL, 16); + + iface->assignment_hint = assignment_hint & ~((1 << (64 - iface->assignment_length)) - 1); + + if (iface->assignment_hint != assignment_hint) + netifd_log_message(L_WARNING, "Ignoring set bits of assignment hint for interface '%s'\n", + iface->name); + } if ((cur = tb[IFACE_ATTR_IP6CLASS])) interface_add_assignment_classes(iface, cur);