OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version openwrt-18.06
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Adrian - 15.01.2019
Last edited by Hans Dedecker - 16.01.2019

FS#2060 - Axis IP cameras do not get stateful IPv6 addresses anymore

Same report as in the GitHub issue I created, just opening one here as well in case this tracker is preferred:

Since updating to the latest OpenWRT a few weeks ago, I noticed that my Axis IP cameras do not get a stateful IPv6 anymore, which worked fine before.

Since they receive NOTONLINK responses, I have the feeling that the issue got introduced with commit a2ffc5986cd35bea983b81b28b8a656e3b81fdf1. Might be a shitty dhcpv6 implementation on the camera, I don’t know and I’m not familiar enough with DHCPv6 to see a bad implementation just from looking at the code.

The code of the “mdhcp6” client the camera uses is available in [this git repo]( Not sure if it’s 100% up to date though, but I can reproduce the issue reliably.

Here’s a pcap on my older router running LEDE 17.01.3: [mdhcp6-lede-17.01.3.pcap.gz](
The advertise/request messages don’t contain anything related to the configured IP (via the ‘hostid’ option), but the final reply contains the correct IP.

And here’s a pcap on another router running the latest OpenWRT 18.06.1, coming from the exact same mdhcp6 client (just running on a different machine since they are different networks, hence the different DUID): [mdhcp6-openwrt-18.06.1.pcap.gz](

I’m not sure where the problem is - in the server or the client (more likely, since all other dhcpv6 clients work perfectly fine). But I’d appreciate some help - if it’s a bug in the client (not sending any IA_NA requests in the solicit seems strange to me), I’d like to forward details to the camera vendor. They release firmware updates quite often so I think the chance that they actually fix their dhcpv6 client if it’s broken is quite high.

Closed by  Hans Dedecker
16.01.2019 12:33
Reason for closing:  Fixed
Additional comments about closing:  

The behavior by the mdhcp6 client implementation is quite odd as you would expect it to include an IA_NA option in the solicit message.

RFC3315 states in paragraph 17.1.1 :

The client MUST include a Client Identifier option to identify itself
to the server. The client includes IA options for any IAs to which
it wants the server to assign addresses. The client MAY include
addresses in the IAs as a hint to the server about addresses for
which the client has a preference. The client MUST NOT include any
other options in the Solicit message, except as specifically allowed
in the definition of individual options.

By doing so the DHCPv6 server can create a lease binding when receiving solicit message and include the binding in the advertise message.

Nevertheless RFC3315 does not seem to exclude sending solicit messages without IA_NA options as paragraph 17.2.2 states :

If the Solicit message from the client included one or more IA
options, the server MUST include IA options in the Advertise message
containing any addresses that would be assigned to IAs contained in
the Solicit message from the client.

As a result I've changed the implementation it will not return a "not on link" status if no address or prefix is included in the request message (https://git.op;a=commit ;h=1893905f6a9b699ae0f1813670e93bf4ec340 2e9)


Available keyboard shortcuts


Task Details

Task Editing