jkp: The router is a linksys “Velop” system which is running the latest firmware from them and that hasn’t changed since it started doing this.
vreihen and erktrk: I get the same result from 2 different macs on the network here, one of which is my development machine which has all the security updates, and one another test box that I have not run any updates on in the last few months at least since long before this changed.
If I do a ping from the macs it knows the IP address and starts pinging instantly. Curl is having a problem, and also my app which connects via the python requests library shows the same issue. To get detailed output on the timing of various parts of the process from curl I used this script:
#!/bin/bash
curl -w @- -o /dev/null -s "$@" <<'EOF'
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
----------\n
time_total: %{time_total}\n
EOF
When I run it on either of my 3 test macs here I get really long timings for the resolution like this:
./curltime.bash "http://hubitat.local/"
time_namelookup: 5.072900
time_connect: 5.073906
time_appconnect: 0.000000
time_pretransfer: 5.073959
time_redirect: 0.000000
time_starttransfer: 5.557005
----------
time_total: 5.608930
when I run it with the IP address instead the output looks like this:
./curltime.bash "http://192.168.0.whatever/"
time_namelookup: 0.053673
time_connect: 0.054804
time_appconnect: 0.000000
time_pretransfer: 0.054854
time_redirect: 0.000000
time_starttransfer: 0.531687
And I get a similar timing if I run the same script from a raspberry pi here. So it’s definitely something in the implementation of the local lookup on the Mac but even there it doesn’t affect everything. I have restarted both macs and the router while trying to narrow this down and none of that made any difference that I could tell.
It has not always been this way though. I developed the interface and ran it for a year without any delay in this at all using the hubitat.local address. Then in the last couple of weeks or even more recently I started to see significant delays in anything that was controlled from the software. I would walk out to the garage and it would take 10 seconds or more to turn on the lights for me sometimes. I did a lot of other debugging before I figured out this was the problem. I’ve told my users to setup either a DHCP reservation or try to use the static IP address stuff on the hubitat that is available now and use the IP address instead and that has solved everyones problems, but not everyone is having the problem so I don’t know exactly when it happened or what accompanied it as far as software updates but something definitely changed and it wasn’t the latest security update from Apple as it does it on my machine that hasn’t had that installed yet.
If anyone can think of anything else I can do to gather more info let me know and I will! I would be happy to just blame the Mac’s failure to cache the lookups or something if it hadn’t worked perfectly for so long and then broken without a clear correlation to a software update or something.
This also affects the python3 requests library which does not use curl on the backend.
