IoT Devices Not Using DNS from DCHP
-
When I try to just use the system name for MQTT on the ESP32, it won't find it with mDNS. Never. That's what got me going on the whole thing - why isn't it doing that? I've had one or two other systems with similar issues: They either don't allow me to enter a system name or don't work with one and need an address instead of a system name. The short version is trying to keep track of, look up, or remember numbers is a pain. Sometimes I have to use paper with a hole in it and read one quad at a time because of reading issues. So being able to use a name instead of an address makes things a lot easier for me. (Which is pretty close to why DNS was invented in the first place, isn't it? To make it easier to remember how to get to a specific system on the net?)
@johnpoz said in IoT Devices Not Using DNS from DCHP:
As to showing - well for starters where did you get the idea that was happening in the first place - where did you see it?
I didn't see anything in packets. But what I did see is that when the ESP was using mDNS, it would always end up with the bogon as its DNS server. I would think that's why it would not be able to find my system on the LAN - because, for some reason, even though it's supposedly using mDNS, it still gets a DNS server.
That leads to the issue I've brought up several times: Doesn't the ESP have to be asking for a DNS server to get one, even if it's a bad one (the bogon address)? The only thing on my LAN that should be handing out a DNS server address is my DHCP server, which should be using my pfSense firewall/DHCP server/DNS server.
I'm trying to figure out how this device ends up with a bogon DNS server instead of getting the DNS info through mDNS or from my DHCP server. It seems to me, if mDNS isn't working to get the broker system from the system name, AND that it's getting a bogon DNS server, something on the ESP is wrong.
Here's my logic: If it's using mDNS, it should be getting the needed information to contact my broker from the system name AND it shouldn't be using a normal DNS server. BUT - it's using a DNS server, even if it's a bogon, so it's somehow bypassing mDNS, even when it's enabled. With mDNS on, it's doing something it should NOT do.
Added to that, when I disable mDNS, it still gets that bogon DNS server somewhere around 10% of the time. It's not behaving reliably when it gets the right DNS server 90% of the time, and a bogon 10% of the time.
-
@TangoOversway said in IoT Devices Not Using DNS from DCHP:
My switches are unmanaged and I have never set them up to do anything special. I'm not even sure I can configure them.
What switches are you actually using? Are they able to be managed to create VLANs?
Doing so enables you to track and control the interactions you are trying and failing to do without VLANs.
I strongly recommend you configure VLANs to segregate and control your network.
-
@TangoOversway said in IoT Devices Not Using DNS from DCHP:
it would always end up with the bogon as its DNS server
Where did you see this?? In its resolv.conf? Where exactly are you seeing this 253 address?
Your esp doesn't even need dns to talk to the broker - be it normal dns or mdns.. Tell it what the broker Ip IS.. Does it now work? Or not?
We are going down some rabbit hole that you keep saying its using this 253.x address for dns - but have yet to show us where your seeing this dns being used?
If you show us where your seeing this - maybe we can figure out where its coming from.. But as you correctly pointed out if pfsense was handing it out via dhcp - then every dhcp client would get it, and your dns wouldn't work.
Unless you setup specific dhcp reservation for a specific client that is different than your normal dhcp settings.
-
The ESP system itself reports this:
That's what I've been saying - that somehow the ESP system is getting this bogon as a DNS server.
@johnpoz said in IoT Devices Not Using DNS from DCHP:
Your esp doesn't even need dns to talk to the broker - be it normal dns or mdns.. Tell it what the broker Ip IS.. Does it now work? Or not?
Yes, but, again, IP addresses (as opposed to names) are quite confusing to me and sometimes I have to use paper with a cutout for the numbers so I can read them one at a time to be sure I have the right address. I am also doing work on my network and have changed the broker from one machine to another and will probably be doing so 2-3 more times as I make other changes - so if I could use just the name, it would make this process a lot easier.
Also, since this ESP32 is getting this bogon as a DNS server (according to the ESP32 itself), where is that coming from?
-
@TangoOversway that is from a wifi connection.. You sure your wifi is not handing that out? Or it could be set on device itself.. Just because you use dhcp to get an IP doesn't mean you can't set a dns locally.
Have already gone over this - if pfsense was handing out that for dns in its dhcp server then every single client on your network would be getting it. Every one..
Unless you have setup a reservation for that device - and changed the settings.
On your pfsense do you have a dhcp reservation set for that mac?
Here look - here is my normal dhcp scope for my 192.168.3.0/24 network... I hand out all clients on this network dns of 192.168.3.10, by default it would hand out pfsense IP on that interface.
But in a reservation for a specific client, my pihole in this case I hand out a different dns server.. Pfsense IP 192.168.3.253
Do you have any such reservations (static mappings) setup for your esp box?
Lets see your dhcp server settings on pfsense, and if you show any static mappings at the bottom of the page
Also we already went over how to validate with a packet capture on pfsense - what IP it offers to the dhcp client.
You should see pfsense see the discover from the esp the offer and ack, etc.
-
@johnpoz Okay - just realized that even though I've assigned it an address. I have not, specifically, told it what to use for the DNS and gateway. It's getting the proper gateway. I think I forgot I have to specifically set the DNS in each DHCP entry. (I thought it was automatic.)
I'll test that out when I get back to that computer this afternoon.
-
@TangoOversway if you leave the dns blank - it will provide the IP address of pfsense interface.
See when I delete - it shows the default which is pfsense IP on that interface
See how its a gray color.
-
@johnpoz I thought that was how it worked - leave the DNS, search domain, or gateway blank, and it should use the default - and I have set them, in the DHCP server page, to the pfSense system. So, by transitive property, it should be getting the proper DNS server from the pfSense DHCP server. Otherwise, as we've agreed, other systems would be having this kind of issue.
-
@TangoOversway the only way this one client could be different is if you set a reservation for it and changed what it points to, or it is set locally on the device..
Any os can set the dns locally and still get IP from dhcp.. Even windows allows you to do that.
You can even do that on your phone, etc.
Or its not using pfsense dhcp and you some other dhcp handing out the same IP range, etc. Like dhcp on your wifi or something.
But yes if no reservation setup in pfsense for this mac address or every other mac address on your network having their own reservations.. And pfsense was handing out that IP for dns - everyone would get it.
That doesn't seem to show the IP it got dhcp from - but a simple sniff on pfsense would validate it handed out the info that client, or you could just look in pfsense leases table, etc.
And if you want to for sure validate pfsense is not handing out that IP you could do the packet capture of the dhcp transaction and look for yourself what pfsense offered.
-
@johnpoz You're going to find this extremely interesting. I have double checked all of this to be sure.
I know about the defaults and they're well labelled. If you don't set the DNS and gateway in the DHCP page, then it'll use the pfSense/DHCP/DNS address as a default. So if I've got it at 172.16.7.1, the DHCP server will provide that as the DNS server and gateway by default, even if I don't specify it.
I had not specified it in the DHCP configuration page, and had not specified it in the entry page for the ESP chip. (If I'm using a default, I don't explicitly specify it again "downline," since that just means I have to change it later if I ever change from the default.) So here's the DHCP Server configuration page:
Note that while it states that the pfSense unit acting as DHCP server will be used for the DNS and gateway, that it does not fill them in, ghosted. (It could be I need to update to the latest version for that.)And here's the DHCP page for the ESP32. Same thing. The default is not showing in gray:
So I went through and set the DNS and gateway in both pages and saved them, then restarted the DHCP for it to take effect. Then I rebooted the ESP32. I checked the info to get the new DNS info after the reboot:
FINALLY - it has the correct DNS server! I even waited a couple minutes to check to be sure it wasn't just something that had not been set yet after reboot and it was still correct, so I took a screenshot.
BUT - and this is the part that's just weird and interesting - I took that screenshot, was so glad it showed the right DNS, that I wrote up this post. Then, just to be sure I read it right, I went back and looked at that page again, and it's back to the bogon:
Somehow, between about 1-2 minutes after boot, and in the time it took to post the screen caps, it changed from the right DNS to the bogon.
-
This is interesting........
I may be wrong , but your subnet mask shoud be 255.255.255.0 and your available range should go from 172.16.4.1 to 172. 16.4 254 not 172.16.7 254.
So if your IOT device is on the 172.16.4. 1 network. Your gateway and DNS should be the same, 172.16.4.1.
-
@Uglybrian said in IoT Devices Not Using DNS from DCHP:
I may be wrong , but your subnet mask shoud be 255.255.255.0 and your available range should go from 172.16.4.1 to 172. 16.4 254 not 172.16.7 254.
That's the range for unassigned addresses. I use them in blocks throughout the range specified by the subnet mask.
-
@Uglybrian he is on purpose using a /22 nothing wrong with that.
Yeah @TangoOversway that is odd.. hmmmm - I have been out drinking with a buddy so let me take a look at this in the morning when not just back from multiple beers. But good screen grabs.. Odd for sure.
Off the top - not sure what could be going on.. a dhcp inform maybe? but what would be handing that out - I still lean towards something local on the esp device.
What specific version of pfsense are you running - might be the beers, but pretty sure the ghosted IP in the dhcp setting isn't something new. Be it shows ghosted IP that would be handed out our not.. There is no way that 253 should be handed out..
A packet capture - you could look for informs. You could download your config and then do a search in the xml to see if that 253 address is anywhere in your xml.
-
Didn’t find 253 in the xml file.
Realized I have not updated in over a year! (It’s hard to keep track of all the devices that I have to update!) So I upgraded to the next version and started the upgrade to the version after that - and it’s not rebooting. So I have to deal with that for now. Yes, I have my config backed up - did that when I downloaded it to my desktop to search for 253.
-
Well, spent the last 15 hours trying to get my SG1100 working again. Ran into trouble at every step of the way. I need an offline installer, since the install program can't connect to the Netgate servers. (I suspect that has to do with the Starlink router using the same address space on the WAN side that pfSense defaults to use on the LAN side.)
So I don't know if I'll ever be able to get back to this. Lost 15 hours of time, plus income, plus wife's income (can't work remotely after a snow storm), and I'm wondering if my device is ever going to work again - or if I have to wait for a paycheck so I can get a new one and then just sit around and wait for it to arrive.
