Re: MQTT connection for IoT device not working

Posts: 15

Thanks: 12

@bobpullen, the device is now setup to use 212.159.6.9 for DNS

@chrisking, you can move it back to the router

Aaaand.... it's green.

Posts: 16,887

Thanks: 4,979

Fixes: 316

Thanks guys. Seems we can squarely point the finger at the DNS proxying then.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Posts: 15

Thanks: 12

It will be interesting to know how the vendor responds.

Posts: 14,773

Thanks: 5,539

Fixes: 395

I would imagine that almost all routers use a version of dnsmasq to provide the DNS cache/forwarding.

According to the faq here http://www.thekelleys.org.uk/dnsmasq/docs/FAQ

Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify

that?

A: Update: from version 2.10, it does. There are a few limitations:

data obtained via TCP is not cached, and source-address

or query-port specifications are ignored for TCP.

I can't find when v 2.10 was released but it's up to about 2.78 now

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

Posts: 15

Thanks: 12

Good find!

Looks like it dates from 2004, so if the routers are using that, they need to update.

Edit: thanks autocorrect

Posts: 15

Thanks: 12

Pleased to say that Monitor-IO have now pushed an update that fixes the problem.

Good job, everyone.

Chris

Posts: 16,887

Thanks: 4,979

Fixes: 316

@monitor-io, care to share the specifics of your fix? Was it to hard code the DNS resolvers, and thus bypass the router proxy? Or have you approached things another way?

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Posts: 15

Thanks: 12

Well, because our device is looking to validate the customer's connectivity we didn't want to always bypass whatever DNS they normally receive via DHCP from their router. So for us, the best option was to specify a set of backup public DNS servers via a "append domain-name-servers x.x.x.x, y.y.y.y;" in our dhclient.conf file. We used an "append" instead of a "prepend" so that they are only utilized if the first choice (whatever they normally get from DHCP) is unresponsive or failing - like the issue we saw in this case. We're very happy with this fix as there is no significant change to our normal functionality.

And I'd like to once again express our sincere appreciation for all your help and assistance - we couldn't have asked for more. It seems that Plusnet customers are very well served by the support they receive. Thank you...

Posts: 15

Thanks: 12

For my part, I would like to add that customers of both Plusnet AND Monitor-IO are very well served by their respective support teams. Very impressed with both.

Chris