Flic Home

    Community
    • Login
    • Search
    • Popular
    • Users

    Is firmware using DHCPRequest instead of PING by mistake?

    Flic Hub
    flic hub dhcp requests
    5
    16
    2411
    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.
    • yea
      yea last edited by

      I'm still wanting to know why the flic_hub makes DHCPREQUEST every 35-45 seconds?

      My only thought is when someone wrote the code for the HUB did they mistakenly use DHCPREQUEST instead of PING wanting to ascertain if the present connection is still active. I have seen countless devices and apps do this. This is not a unusual event or behavior; however, these devices and apps actually use PING instead.

      Now as I have been asked before back in December, "Have you tried a different router?" Yes, sixteen of them ranging from cheap off the shelf consumer routers, ISP supplied routers, to enterprise grade routers and switches (Cisco, Juniper, Ubiquiti, and HP). The HUB exhibits the same behavior on all of them. Even when DHCP is disabled after the HUB has acquired an IP address.

      Next issue. What type of connection? Wifi or Lan? I have used BOTH or all sixteen network setups. The behavior is the same.

      My next plan of attack is to create a script that floods the flic_hub with DHCPACK packets and watch to see if it still sends DHCPRequests. I'm willing to bet it does.

      In the Log below this router is assigning flic_hub a STATIC address with a DHCP lease of zero(0) which means the client should not make another request unless the connection is reset. I do not know of anything interrupting or resetting this connection every 35-45 seconds. I have also tried setting the DHCP lease length to 9999. This would mean there should be new requests or renewal requests from the client for approximately 4,990+ minutes, but I still get the same behavior.

      Apr 24 18:30:26 ###.###.###.### dnsmasq-dhcp DHCPOFFER(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:30:26 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:30:26 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:34:15 ###.###.###.### dnsmasq-dhcp DHCPOFFER(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:34:15 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:34:15 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:35:20 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:35:20 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:35:23 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:35:23 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:35:31 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:35:31 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:35:47 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:35:47 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:36:05 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:36:05 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:36:59 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:36:59 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:37:03 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:37:03 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:37:12 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:37:12 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:37:29 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:37:29 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:37:44 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:37:44 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:38:38 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:38:38 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:38:43 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:38:43 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:38:51 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:38:51 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:39:07 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:39:07 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:39:23 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:39:23 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:40:17 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:40:17 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:40:21 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:40:21 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:40:29 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:40:29 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:40:45 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:40:45 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:41:02 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:41:02 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:41:58 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:41:58 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:42:01 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:42:01 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:42:09 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:42:09 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:42:26 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:42:26 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:42:43 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:42:43 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:43:38 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:43:38 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:43:42 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:43:42 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:43:50 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:43:50 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:44:07 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:44:07 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:44:23 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:44:23 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:45:17 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:45:17 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:45:22 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:45:22 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:45:29 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:45:29 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:45:46 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:45:46 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub
      Apr 24 18:46:02 ###.###.###.### dnsmasq-dhcp DHCPREQUEST(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7
      Apr 24 18:46:02 ###.###.###.### dnsmasq-dhcp DHCPACK(br0) ###.###.#.29 9a🇦🇫b1:1a:08:a7 flic_hub

      1 Reply Last reply Reply Quote 0
      • Emil
        Emil FlicTeam @Emil last edited by

        @Emil said in Is firmware using DHCPRequest instead of PING by mistake?:

        Hi. I have applied the patch you linked to and built a new firmware for Flic Hub LR.

        @akiraK @yea @Djelibeybi please give me the serial numbers of your hubs so I can assign the new firmware if you want to test it, to see if the patch works.

        1 Reply Last reply Reply Quote 0
        • yea
          yea @Emil last edited by

          @Emil
          I checked the HUB firmware, it showed 3.0.6. I tried the pushing the pin button for 2-5 seconds only to have the HUB completely reset to factory default. After the reset the Firmware version was 2.0.16.

          In the FLIC android app I used the 'Upgrade Hub' button on the settings page. The HUB upgraded and rebooted. The firmware is now version 3.0.8

          I repeated this process several(5) times, only to have firmware version 3.0.6 downloaded again.

          However I did find a method to make the excessive DHCPrequest problem subside for now.
          I set the DHCP lease time to a value equal or greater than 999999
          That seems to bring the rate of DHCPrequests down to 5 or 6 per hour. That's somewhat reasonable.

          Here are my observations of firmware 3.0.6 using ethernet connection:
          (I didn't test 3.0.8 because it wasn't on the HUB long enough to test.)

          If the DHCP lease time is set to zero(static) there is a DHCPrequest every 2 seconds. Basically it sends another request before it receives a reply to the previous.
          If the DHCP lease time is greater than zero, but less than 999999 there is a DHCPrequest roughly every 10-15 seconds.
          If the DHCP lease time is greater than 999999 then there is a DHCP request roughly every 11-12 minutes.
          Using the HUB with WIFI6 access points does not work since the WIFI6 A/P's drop the FlicHub for abusive traffic. At least that's what my Ubiquiti controller is showing.

          1 Reply Last reply Reply Quote 0
          • antoine75
            antoine75 @Emil last edited by

            @Emil hello, I tried the steps to reboot and upgrade to 3.10 but it did not work. How can I get this firmware because I am confirming the same DHCP requests flooding from my server logs?

            1 Reply Last reply Reply Quote 0
            • akiraK
              akiraK @Emil last edited by

              Before test, I configured DHCP and set lease time to 1h.
              Rechecked FW 3.0.9, DHCP REQUEST flood occurs exactly after 30 min, first re-lease timing.
              In FW 3.0.10, after 30 min, only 1 pair of DHCP REQUEST- DHCP ACK is logged... works as expected!
              As far as I watched 3 times re-lease process loop, looks stable.

              Thanks @emil, finally my flic buttons back to network!
              Hope this FW solve @yea's and @Djelibeybi's problem too.

              1 Reply Last reply Reply Quote 0
              • Emil
                Emil FlicTeam @akiraK last edited by

                @akiraK Ok you can now firmware update your hub by either waiting up to 24 h while being connected to internet, or press the pin hole on the hub for exactly somewhere between 2 and 5 seconds, then release. It will then blink during the update and then reboot. In the app you can check that the hub then has firmware 3.0.10.

                akiraK antoine75 yea 3 Replies Last reply Reply Quote 0
                • akiraK
                  akiraK @Emil last edited by akiraK

                  @Emil Wow, you are fast at work!
                  My HUB LR is #[MASKED]. I want to test it by all means. regards!

                  Emil 1 Reply Last reply Reply Quote 0
                  • Emil
                    Emil FlicTeam last edited by

                    Hi. I have applied the patch you linked to and built a new firmware for Flic Hub LR.

                    @akiraK @yea @Djelibeybi please give me the serial numbers of your hubs so I can assign the new firmware if you want to test it, to see if the patch works.

                    akiraK Emil 2 Replies Last reply Reply Quote 0
                    • Emil
                      Emil FlicTeam @akiraK last edited by

                      @akiraK thanks, will take a look.

                      1 Reply Last reply Reply Quote 0
                      • akiraK
                        akiraK @Emil last edited by akiraK

                        @Emil Maybe it is dhcp-8.1.9's bug, occurred on mine too.
                        Please check https://bugs.gentoo.org/766282 as similur situation, and publish FW with patched dhcpd if you could, as "easy way to solve it".
                        Thank you.

                        Emil 1 Reply Last reply Reply Quote 0
                        • yea
                          yea @Emil last edited by

                          @Emil I have combed through the source code of the dhcpd-8.1.9 and there is nothing that indicates that it makes more than ONE request to retrieve an IP address and network parameters, and then remains idle until approximately 1/2 of the lease time expires then it negotiates a lease renewal. YES, there are exceptions in the code to accommodate error handling, but even then the requests are restricted to a total of four(4). This means in order to make multiple requests the operating system(aka firmware) has to call the daemon to initiate each new request.

                          This brings me back to my original statement. The DHCP daemon is being repeatedly called to check for connection status. This only determines if there is a connection to a active network; however, it does not determine if there is a gateway to the internet, nor does it determine if there is any usable resource beyond that gateway.

                          Why not send a ping to connectivitycheck.gstatic.com to determine if there is internet access. Ping is short, distinct, and reliable way that requires very little processing time or resources. Now sending a ping can provide answers to multiple questions. First, if the ping times out it would mean there is not an active network connection of any type. Two, if the PING returns destination unreachable it means there is an active network connection, but lacks a path to the internet. Three, if you receive a response from the target it means you are both connected to an active network and there is a path the internet. Now I'll venture out onto a proverbial limb here and guess that the ping.c library was deliberately left out due to memory constraints.

                          1 Reply Last reply Reply Quote 0
                          • yea
                            yea @Djelibeybi last edited by

                            @Djelibeybi My hub on WiFi makes so many requests it causes other WiFi devices to drop their association with the access point.

                            1 Reply Last reply Reply Quote 0
                            • Emil
                              Emil FlicTeam last edited by

                              As mentioned before, we are using dhcpcd 8.1.9, which should be used in many different products on the market. We use that particular version since it was the only version we could find that passed Apple's Homekit certification tests. You are free to investigate the code to see if you can find any issues with it. Since we are not familiar with this code and currently have other more prioritised work to do, we will unfortunately not take a look at this in the nearest future as it looks right now, unless we find an easy way to solve it.

                              akiraK 1 Reply Last reply Reply Quote 0
                              • Djelibeybi
                                Djelibeybi last edited by Djelibeybi

                                Mine isn't quite as bad as 100 packets per minute, but I am getting a DHCPREQUEST every 45-60 seconds. The lease is for 12 hours.

                                Aug  9 07:35:33 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:35:33 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:36:36 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:36:36 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:37:40 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:37:40 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:38:44 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:38:44 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:39:47 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:39:47 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:40:52 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:40:52 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:41:56 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:41:56 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:43:01 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:43:01 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:44:04 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:44:04 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:45:09 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:45:09 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:46:12 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:46:12 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:47:16 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:47:16 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:48:19 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:48:19 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:49:23 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:49:23 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:50:26 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:50:26 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:51:30 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:51:30 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:52:34 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:52:34 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:53:38 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:53:38 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:54:43 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:54:43 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:55:47 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:55:47 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:56:51 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:56:51 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:57:56 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:57:56 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 07:58:59 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 07:58:59 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:00:03 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:00:03 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:01:08 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:01:08 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:02:13 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:02:13 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:03:16 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:03:16 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:04:19 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:04:19 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:05:24 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:05:24 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:06:28 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:06:28 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:07:33 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:07:33 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub
Aug  9 08:08:37 dnsmasq-dhcp[15485]: DHCPREQUEST(eth0) 192.168.9.22 c6:df:61:eb:7d:d2
Aug  9 08:08:37 dnsmasq-dhcp[15485]: DHCPACK(eth0) 192.168.9.22 c6:df:61:eb:7d:d2 flichub

                                This only happens with a wired connection, btw. If I disconnect the cable and configure wifi, the Flic Hub behaves itself.

                                yea 1 Reply Last reply Reply Quote 0
                                • yea
                                  yea last edited by

                                  YES - I am 100% correct. The firmware is using DHCPREQUEST to test network connectivity. This is why the flic hub is sending out almost a 100 DHCPREQUEST packets a minute.

                                  Received a suggestion that I should try increasing the DHCP lease time. Well I first tried Zero(static), , then 1,440 (24 hrs), then I tried 99,999 minutes(That's 69.44375 days). This does not stop or change the rate of DHCPREQUEST traffic. (FYI - Depending on the DHCP or DNSMASQ version you are running the DHCP lease time is generally restricted to five digits.)

                                  When you disable DHCP on the network the FLIC_HUB immediately goes into an offline state.
                                  If you are using ethernet connection the flic hub now shows 'CONNECTED' with the IP address of 169.254.194.195. It knows the NIC is physically connected but refuses to communicate until there is DHCP service. Why do I say this? When you disconnect the ethernet cable the status changes to 'Connect cable.'

                                  If you are using a WiFi connection the flic hub reports 'WiFi disconnected,' but it shows an IP address of 169.254.194.195. Now if the hub has lost it's wlan connection why is it showing an automatic private address? That is because the access point it was communicating with still shows the flic hub as associated and responding to traffic control packets(RTS/CTS).
                                  So that only leaves ONE possible explanation. When the flic hub does not receive a DHCPACK it goes offline under the assumption that there is no active internet connection. This is WRONG!
                                  Maybe you need to implement a Network Connectivity Status Indicator(NCSI) similar to Microsoft has done with windows.

                                  This is not an isolated incident to just a SINGLE flic hub. I have FIVE(5) FLIC hubs sitting here in front of me that all exhibit the exact same behavior. It does not matter which type of connection you use, WiFi or ethernet, the FLIC hub uses DHCPREQUEST to test network connectivity.

                                  Now I was helping a friend troubleshoot their VoIP connection for a remote work setup using WiFi. NO, they cannot use ethernet. This person's landlord does not permit cables or cords of any type to be on the floor, even temporarily. And no taping to the floor isn't acceptable either, we asked. If the landlord finds that condition it is grounds for immediate eviction.
                                  What did I find? Two flic hubs broadcasting nearly 300 DHCPREQUEST a minute across a wireless connection causing congestion on the wireless network. So I unplug the flic hubs and the issue instantly resolves itself. So here is a prime example that this method is poor choice to check for internet connectivity. (Two flichubs? I don't wanna go it that story.)

                                  YES - This causes disastrous latency issues for gaming computers & consoles using WiFi.
                                  I quit counting how many times unplugging a FLIC HUB solved latency issues for gaming.

                                  Here is a list of switch and router manufacturers I can duplicate this behavior with.

                                  • Ubiquiti
                                  • Cisco Systems & Meraki
                                  • Juniper
                                  • HP Pro Curve
                                  • Huawei
                                  • Avaya
                                  • Mikrotik
                                  • Dell
                                  • Netgear
                                  • D-Link
                                  • TP-link
                                  • Zyxel
                                  • Buffalo Technology
                                  • Auruba
                                  • Samsung
                                  • Ruckus Networks
                                  • Linksys/Belkin
                                  • TrendNet
                                  • Motorola
                                  • Arris

                                  Does not matter which brand of router/switch/AP is used in conjunction with the flichub if DHCP is disabled the flichub will go offline without fail - guaranteed.

                                  1 Reply Last reply Reply Quote 0
                                  • Emil
                                    Emil FlicTeam last edited by

                                    Hi. We use dhcpcd-8.1.9 (https://github.com/NetworkConfiguration/dhcpcd/tree/dhcpcd-8.1.9). You are free to investigate the code there to see if you can find any cause of this. Other than that, nothing on the Flic hub sends out dhcp requests.

                                    yea 1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post