OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Packages
  • Assigned To
    Hans Dedecker
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Eric Luehrsen - 17.02.2017
Last edited by Hans Dedecker - 05.08.2017

FS#524 - odhcpd: stateful+stateless sends M flag in RA for prefix that will not DHCPv6

The M-Flag should only be set in RA when DHCPv6 assignment will occur in that prefix. This is related to  FS#402 , but where  FS#402  may be a matter of style to some, this one is a bug. odhcpd sends M-Flag in RA on both prefixes but only DHCPv6 on ULA. This can confuse some client software, they don’t accept only the ULA, and they continue to spam the router with solicits trying to get GA and ULA together. Whether or not debate occurs on DHCPv6 being split in stateful+less mode, if it is split, then the RA need to respect it.

Closed by  Hans Dedecker
05.08.2017 11:33
Reason for closing:  Fixed
Additional comments about closing:  

The odhcpd DHCPv6 server will now by default assign all viable DHCPV6 addresses to the client which fixes the issue reported in this record.

Project Manager
Hans Dedecker commented on 02.08.2017 07:28

Have you observed DHCPv6 clients behave in such way or is this based on a RFC interpretation ?

Eric Luehrsen commented on 03.08.2017 17:19

Yes to both. I have assorted devices with each their various quirks. Windows 10 and Debian derivatives seem to be enhancing robustness to unusual in-spec or out-of-spec behavior. Manufacture controlled devices like smart tv, blu ray player, car smart info-nav, and such seem to be bare minimum main stream. My smart tv is the most noisy about sending dhcpv6 solicit.


Available keyboard shortcuts


Task Details

Task Editing