Flic Home

    Community
    • Login
    • Search
    • Popular
    • Users

    FLICHUB making 500+ DHCP requests a day

    Flic Hub
    network flichub
    3
    8
    1231
    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 recently purchased a FLICHUB LR. It is hooked to my network via ethernet since the FLICHUB does not support WPA3. It has a static IP address assigned with a DHCP lease time of 1440 minutes (24 hrs).

      For that past couple of weeks I have found the flichub is sending a DHCPREQUEST roughly every 62-67 seconds.
      Shortly after 12am the interval is every 62 seconds. At some point that interval increases usually by one second until it reaches 67 seconds 2-3 hours before 11:59pm. I tried power cycling the HUB multiple times with no change. I have tried resetting it to default four times then reconfigure it, but it still does not change.

      How do I make the flichub stop this behavior?

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

        @yea I find your story very strange for a couple of reasons.

        First, the Flic hub uses "locally administered addresses", which is indicated by b1 in the first byte of the MAC address (0x9A = 0b10011010). Such addresses cannot be looked up in an OUI registry. It's not a "fake address". It's just not a "globally administered address". This relates exactly to how "static random addresses" is commonly used nowadays in Bluetooth Low Energy compared to "Public addresses" in order to avoid the hassle with address registration in the production, since nobody believes that a 48-bit randomly generated address could be duplicated on a local network.

        Now, if you have a gateway in your house in front of your LAN that connects to the internet, all internet traffic the ISP will see will contain the MAC address of your gateway, not any MAC address on your local network since that will be rewritten by your gateway.

        Any DHCP traffic should also exist solely on your local network and should not be seen by an ISP.

        The Flic hub runs the firmware from a read only memory, so I've hard to see that an intruder could have added some botnet software on it.

        The Flic hub should only send NTP, DNS, DHCP, and mDNS traffic, as well as communicating with our backend over TLS. (And of course perform the actions you assign flic buttons)

        I'd be glad to get more logs or info on what this "suspicious traffic" might be.

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

          Well I think my initial suspicion was correct. Yesterday, 01/28/2021, I had a visit from my ISP's threat prevention group, and a law enforcement officer who asked that he/she rather not disclose which agency they were with at this time. What ever. Since I personally know both people from the ISP, and the fact one of them is married to my cousin I was not concerned about it being a scam.
          They informed me they had tracked and were monitoring suspicious traffic coming from my residential gateway. Specifically they were looking for a device that was active in a botnet currently under federal investigation.
          I was asked if they could monitor my local network to further identify the actual device that was appeared to be using a fake MAC address. They showed me the MAC address 9A-AF-B1-1A-08-A7. Hmmm? That's the MAC of my FLIC Hub. I handed it over to them to use gather additional surveillance.
          Will I get the device back? Maybe? Probably not, but I really don't care. I still hadn't got it to work. Now I know why.

          Interesting thing I could not find a OUI/OID registry for 9A-AF-B1. I tried 15 different resources including CISCO Systems, Fluke Int'l, and the standards-oui.ieee.org websites. No listing. Not even when searching by company name.

          Now I have to sift through roughly six weeks of internet logs to see if there was any malicious traffic other than just the botnet.
          I can hear my father's word ringing in my ears right now, "Well son, are those modern inconveniences really worth it?"

          Emil 1 Reply Last reply Reply Quote 0
          • flic r
            flic r last edited by flic r

            I observe the same thing with repeated DHCP requests from both flic hubs I am running. I run a regular debian based isc-dhcp daemon on the server, and no issues except for flic hubs. Something is strange with the flic hub implementation.

            @Emil: can you elaborate on what flic hub expects? Is it possible that flic hubs expects an answer from the Wifi router? In my case, and possibly in yea's case, the DHCPD is running on a different machine, so the MAC address could be different.

            Here an example:
            Jan 6 16:31:22 xxx dhcpd[6493]: DHCPREQUEST for 192.168.2.240 from 76🇪🇪2a:9c:c8:38 via enp0s31f6
            Jan 6 16:31:22 xxx dhcpd[6493]: DHCPACK on 192.168.2.240 to 76🇪🇪2a:9c:c8:38 via enp0s31f6
            Jan 6 16:32:26 xxx dhcpd[6493]: DHCPREQUEST for 192.168.2.240 from 76🇪🇪2a:9c:c8:38 via enp0s31f6
            Jan 6 16:32:26 xxx dhcpd[6493]: DHCPACK on 192.168.2.240 to 76🇪🇪2a:9c:c8:38 via enp0s31f6

            The DHCPACK comes right away. Is it possible, that the server is to fast for flic hub to get the message?

            Thanks for any pointer. It is really annoying to see all this internal traffic.

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

              @Emil Well I finally got back to playing around with the FLICHUB again. I have configured the hub to use wifi instead; however, before that I configured the access point nearest the FLICHUB with a new virtual SSID that has both Network and Access Point isolation enabled. Then all DNS traffic for that network is force redirected to OpenDNS preventing access to all known malware and botnet command & control servers. I think that fairly well sandboxes the FLICHUB to a point where I really do not care what the hub does other than send out traffic to other services such as IFTTT.

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

                @yea in that case your router's malware detection is obviously wrong since we don't run malware on the hub.

                We run the dhcpcd software on the hub as dhcp client if you wonder, which is pretty standard.

                For SmartLife, you can use IFTTT to control it from Flic.

                Let me know if you have some more interesting info for this issue, so it can be solved.

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

                  @Emil, Well no, that behavior has now proven to be nothing more than an annoyance, since a new problem has developed when my Ubiquiti Security Gateway received a firmware update today. Now the SG keeps flagging the flichub as infected with malware and denies all access to the flichub.

                  I disconnected the flichub from my network. Besides I have not found a way to integrate my Tuya/SmartLife compatible wifi smart plugs with the FLIC2 buttons yet.

                  I'll revisit this problem after the holiday.

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

                    Hi. This usually means the DHCPACK is not received for some reason, causing it to ask again after a minute. Have you tried another router if it's the same there?
                    Does this behaviour lead to some specific problems for you?

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