Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Kea DHCPv6 and clients with unstable IAID

    Scheduled Pinned Locked Moved DHCP and DNS
    3 Posts 2 Posters 487 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      rolfl
      last edited by rolfl

      Using pfsense 25.07.1

      I have 30 problematic client devices that:

      1. Have unstable IAID that changes on every request
      2. Request new lease every 10 minute regardless of lease time set on server.

      Without changing the server lease time to 10 minutes this causes a problem with new leases filling up the server with defunct leases.

      The devices are TAPO/TP-link matter wifi light switches.
      I reported the issue to TP-link in July but not have any updates.

      I was trying two possible options.

      Option 1: Use hw-address for client ID in in reservation
      add a custom configuration to the reservation:

      {
       "duid": "",
       "hw-address": "3c:52:a1:39:f1:fe"
      }
      

      This works in that the IP is assigned correctly on first lease.
      Unfortunately, it appears the server still looks at UID/IAID in the lease db and assigns a new IP address on subsequent releases.

      Option 2: Set kea to ignore IAID using hooks library
      This could be set in the Dhcp6 server custom configuration by adding /usr/local/lib/libdhcp_flex_id.so to the hooks-libraries section and setting a iaid-ignore flag true.

      However, /usr/local/lib/libdhcp_flex_id.so does not seem to exist in pfSense distribution.

      Any suggestions of how to address the client with unstable IAIDs issue?
      Other than living with a bunch of extra leases 😉

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG Offline
        Gertjan @rolfl
        last edited by

        @rolfl said in Kea DHCPv6 and clients with unstable IAID:

        by adding /usr/local/lib/libdhcp_flex_id.so to

        ... wouldn't that be :

        /usr/local/lib/kea/hooks/

        for pfSense ? I found some kea libraries there.

        I you could find a pre build "libdhcp_flex_id.so" (build against FreeBSD 15.x - light up a candle, and copy it in place) it might just work.

        Btw : just to be sure : these devices use Wifi, right ? So it could be the wifi that 'breaks' every 10 minutes, so a DHCP initial 'boot' request will get emitted every time ? That stull doesn't expmlain why the IAID is randomized like that.
        If this isn't the case, why not mentioning the device by type, serial number, brand etc ?
        So we will all know what device not to chose at any cost, as it is known that every constructor out there wants to break IPv6, and some of them are doing a great job.

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        R 1 Reply Last reply Reply Quote 0
        • R Offline
          rolfl @Gertjan
          last edited by rolfl

          @Gertjan said in Kea DHCPv6 and clients with unstable IAID:

          @rolfl said in Kea DHCPv6 and clients with unstable IAID:

          by adding /usr/local/lib/libdhcp_flex_id.so to

          ... wouldn't that be :

          /usr/local/lib/kea/hooks/
          for pfSense ? I found some kea libraries there.

          Correct, I must have been copying from a google search.
          Regardless, the file isn't there.

          I you could find a pre build "libdhcp_flex_id.so" (build against FreeBSD 15.x - light up a candle, and copy it in place) it might just work.

          PfSense is using Kea 2.6.2. Apparently pre 3.0 Kea had this library as a premium feature and requires a token to enable it.

          Btw : just to be sure : these devices use Wifi, right ? So it could be the wifi that 'breaks' every 10 minutes, so a DHCP initial 'boot' request will get emitted every time ? That stull doesn't expmlain why the IAID is randomized like that.

          I have checked unifi logs for the devices and there is no evidence of disconnect/connect behavior for wifi.

          If this isn't the case, why not mentioning the device by type, serial number, brand etc ?
          So we will all know what device not to chose at any cost, as it is known that every constructor out there wants to break IPv6, and some of them are doing a great job.

          I did mention that the brand was TAPO / TP-link, particularly the matter compatible wifi light switches.
          The model numbers are: S505, S505D, S515, P125M.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.