DNS lookup

[Bob.ma]

OK, tried using the name and it failed though I can ping using the name in Windows. There is no error in the log from the driver - it just says it is sending messages.

[gopher.ny]

@Bob.ma

There is no error in the log from the driver - it just says it is sending messages.

Can you PM me your hub's id? There may be some error messages in the engineering logs, and I can check those.

[djw1191]

Ok I tested this myself, with the driver and an instance of netcat listening on a separate system using the port in the driver. I'm seeing the command show up on the netcat side when using a DNS entry instead of an IP.

So perhaps some sort of issue with the device or local name resolution as it seems like it should work.

I see the data show up when using both the non-fully qualified hostname and the fully qualified entry.

 nc -u -l 38899
{"method":"setPilot","id":13,"params":{"state":false}}

[ogiewon]

Does Hubitat still force all DNS resolution through 8.8.8.8? If so, that might explain it. I just don’t recall if Hubitat ever changed their DHCP client’s behavior to use the DNS server provided by the DHCP server?

[jlv]

@ogiewon

I just don’t recall if Hubitat ever changed their DHCP client’s behavior to use the DNS server provided by the DHCP server?

Yes, it looks like it still defaults to 8.8.8.8 and ignores DHCP. But, it looks like you can change the DNS server on the network settings page.

[aaiyar]

@Bob.ma

If you haven’t seen this:

DNS bug in 2.2.5.119

2.2.4.120 has two new ways to set a DNS server: In the Networking section: [image] Using a direct endpoint: http://hubs.ip.address.here/hub/advanced/resetResolvConf?nameserver=8.8.8.8 (this works on C4s)

[Bob.ma]

I explicitly made sure it is using my local DNS. I shouldn't have to but want to be sure. I tried using Wireshark to see what is happening but it's not seeing those packets -- probably the switch is not broadcasting them.

In looking at the log I see that it is indeed trying to use the DNS name but nothing is happening and there is no error report. When I change back to the IP address it works again.

This is why I want to know the official status of support for the DNS so I could know if it is simply a bug.

[djw1191]

@Bob.ma

indeed trying to use the DNS name

@Bob.ma

This is why I want to know the official status of support for the DNS

Well I think we have that answer now, via both your wireshark capture and the test I ran. Clearly these calls and the hub itself support DNS.

[Bob.ma]

My Wireshark didn't show anything.

Something is not working. How can we solve this?

[aaiyar]

@Bob.ma

Something is not working

Well, using netcat, @djw1191 clearly demonstrated it wasn’t the driver, or the hub platform.

That narrows it down to something unique about your LAN setup. There was a dnsmasq LISTSERV that was very helpful to me in the past. If it’s still active, you might consider using it as a resource.

[Bob.ma]

Can you provide me with your driver so I can test?

[aaiyar]

???

From what @djw1191 wrote above, they used the Wiz driver pasted above by @jlv. Do you not use the same driver?

[djw1191]

@aaiyar

used the Wiz driver

Yeah, I used the wiz driver, whatever the issue is, it doesn’t appear to be DNS.

[Bob.ma]

I'm wondering about your comments on netcat. Are you saying you saw the IP address on the wire even though you specified a DNS name to the driver? Did this work properly with your Wiz bulbs? Do you also watch the DNS resolution of the name?

[djw1191]

I feel like I already gave a decent explanation?

DNS lookup

Ok I tested this myself, with the driver and an instance of netcat listening on a separate system using the port in the driver. I'm seeing the command show up on the netcat side when using a DNS entry instead of an IP. So perhaps some sort of issue with the device or local name resolution as it seems like it should work. I see the data show up when using both the non-fully qualified hostname and the fully qualified entry. nc -u -l 38899 {"method":"setPilot","id":13,"params":{"state":false}}

I don’t have any wiz bulbs, which is why I did this via nc, to receive the UDP traffic and simulate a device on the network that listens via the port in question. I configured the driver to use a domain and I triggered a command within the created device, and as my post both mentioned and showed, the json blob that is sent showed up in my running nc.

Thus if data shows up on the other end, clearly the hub successfully resolved the hostname and sent data over the wire.

[aaiyar]

@djw1191

Thus if data shows up on the other end, clearly the hub successfully resolved the hostname and sent data over the wire

FWIW, I could reproduce the test you did - also with the Wiz driver and netcat.

[Bob.ma]

I appreciate the interest in showing that name resolution can work. I also know that I'm getting resolution failures. Rather than trying to prove me wrong, it would be more useful to help figure out what is going wrong. I don't see how netcat is relevant since I know names work.

For @aaiyar -- can you provide a screen shot of your IP settings for Wiz? What is your setup?

[aaiyar]

@Bob.ma

What is your setup?

Exactly what @djw1191 described.

@Bob.ma

I also know that I'm getting resolution failures

@djw1191 tests, which I reproduced, indicate the issue is outside of anything with the hub platform. If I were you, I would check your dnsmasq configuration (if I remember correctly, that's what you use)

[Bob.ma]

OK, no point in continuing here.

[Bob.ma]

I will note that I'm using standard Ubiqiuit gear but since the use of names was not well documented (as per my previous efforts) and thus wasn't considered an option, this kind of bug can be lurking for a long time.