Excellent news, thanks @Emil
I initially intended to migrate my Flic buttons slowly from my RPi to the hub, but after I accidentally corrupted my Sqlite db containing the flic mappings, it was a rush to get them up and running completely via the hub! Have to say the process was quicker than the SDK 😉
Given the connection and responsiveness of Flic is far greater with the hub, even if the hub isn't doing any actions itself, it's a brilliant upgrade for Flic owners. That being said, half my Flics are operating in the hub actions
I'll answer my own question with the email response I got from Daniel:
This is something that we actually have on our to-do list and that we tend to implement. It is really hard for us to give an exact estimate when it will be ready since we have a list of small things we will add in the near future for the hub. We hope to have it released in 2 months from now.
@flic-8 My device is a Moto X4 if it matters to you, activated after I got the Hub setup with another device. I don't think this is a hub issue, just an android app bug I've noticed because of using the hub.
First of all I would like to ask what kind of technique you are using to decide if a UDP port is open or closed?
nmap -sS -sU -T4 -A -v -PE -PP -PS80,443 -PA3389 -PU40125 -PY -g 53 --script "default or (discovery and safe)" flic
UDP is connectionless so by design they don’t really behave like TCP when doing port scans. With TCP you often either get a Connection Reset response or no response at all if you try to connect to a closed port, at which point you can assume that the port is actually closed. With UDP it does not work like that since you are not guaranteed to get a response in either scenario. And even if a port is temporarily open it does not mean that you actually have a service on the other side listening.
I seem to remember that tools like NMAP use ICMP responses to decide if a UDP port is open (correct me if I’m wrong). But this generates a lot of false positives since a lot of ports are not really bound to a permanent service, but rather temporary ports used by both the Linux OS (DNS requests, NTP requests, etc..) and our host application for different features (like action executions etc). This is normal UDP behavior and not an indication of a security flaw.
Hence the question. It is hard to determine why a UDP port is open so I was interested to find out what should be listening and why.
I am not suggesting that I have found a flaw, just the potential to discover one and without some background on what the hub does, it is is guesswork at this point. I usually only work with Open Source and in that case, I can work it out for myself but as far as I know, the flic hub code is hidden so only people on your team can investigate.
The assumption is that most flic hub users are not security experts therefore it is the responsibility of the device supplier to make sure that the user cannot be exploited. Many IoT vendors are also not thinking about security and the overall outcome is an unsafe and unreliable internet and this is what is behind my question.