Meteobridge canot update Weather Underground

[xannor]

I was checking on my setup today and I noticed my Weather Underground data was empty, checking back it seems to have stopped receiving data at around 7pm EDT on june 11th. When I logged into my meteobridge and checked the live data tab it reports this error:

Code: Select all

wget: unable to resolve host address 'rtupdate.wunderground.com' (no more tries)

So I ssh'ed into it and sure enough a ping of that host gets:

Code: Select all

 ping: bad address 'rtupdate.wunderground.com'

but from other computers on the same network a ping resolves, so I ran nslookup on my desktop:

Code: Select all

Non-authoritative answer:
Name:    prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud
Addresses:  169.47.111.60
          52.116.188.162
          169.60.133.174
Aliases:  rtupdate.wunderground.com
          prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud

but nslookup on the meteobridge reports:

Code: Select all

nslookup: can't resolve 'rtupdate.wunderground.com': Name or service not known

I can ping other sites and names perfectly fine from both the meteobridge and desktops. I decided to do a tcpdump comparison to see if there is some sort of issue:

meteobridge:

Code: Select all

12:22:45.859655 IP 192.168.3.162.53072 > 192.168.3.1.53: 2+ AAAA? rtupdate.wunderground.com. (43)
12:22:45.885019 IP 192.168.3.1.53 > 192.168.3.162.53072: 2 1/1/1 CNAME prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. (305)
12:22:45.885579 IP 192.168.3.162.48054 > 192.168.3.1.53: 3+ AAAA? prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. (129)
12:22:45.920563 IP 192.168.3.1.53 > 192.168.3.162.48054: 3 0/1/1 (241)
12:22:45.921203 IP 192.168.3.162.37742 > 192.168.3.1.53: 4+ A? rtupdate.wunderground.com. (43)
12:22:45.974228 IP 192.168.3.1.53 > 192.168.3.162.37742: 4| 0/0/0 (43)
12:22:47.223012 IP 192.168.3.162.36467 > 192.168.3.1.53: 2+ AAAA? rtupdate.wunderground.com. (43)
12:22:47.246846 IP 192.168.3.1.53 > 192.168.3.162.36467: 2 1/1/1 CNAME prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. (305)
12:22:47.257478 IP 192.168.3.162.51699 > 192.168.3.1.53: 3+ AAAA? prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. (129)
12:22:47.293017 IP 192.168.3.1.53 > 192.168.3.162.51699: 3 0/1/1 (241)
12:22:47.293655 IP 192.168.3.162.48714 > 192.168.3.1.53: 4+ A? rtupdate.wunderground.com. (43)
12:22:47.325464 IP 192.168.3.1.53 > 192.168.3.162.48714: 4| 0/0/0 (43)

desktop:

Code: Select all

12:23:43.699862 IP 192.168.3.21.57140 > 192.168.3.1.53: 43578+ A? rtupdate.wunderground.com. (43)
12:23:43.724440 IP 192.168.3.1.53 > 192.168.3.21.57140: 43578| 0/0/0 (43)
12:23:43.727923 IP 192.168.3.21.57140 > 192.168.3.1.53: 43578+ A? rtupdate.wunderground.com. (43)
12:23:43.728015 IP 192.168.3.21.59212 > 192.168.3.1.53: Flags [S], seq 1427135958, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
12:23:43.728117 IP 192.168.3.1.53 > 192.168.3.21.59212: Flags [S.], seq 4147971092, ack 1427135959, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
12:23:43.731061 IP 192.168.3.21.59212 > 192.168.3.1.53: Flags [P.], seq 1:46, ack 1, win 1026, length 45 1+ A? rtupdate.wunderground.com. (43)
12:23:43.731230 IP 192.168.3.1.53 > 192.168.3.21.59212: Flags [.], ack 46, win 457, length 0
12:23:43.731244 IP 192.168.3.21.59212 > 192.168.3.1.53: Flags [.], ack 1, win 1026, length 0
12:23:43.731274 IP 192.168.3.1.53 > 192.168.3.21.59212: Flags [.], ack 46, win 457, length 0
12:23:43.834462 IP 192.168.3.1.53 > 192.168.3.21.57140: 43578| 0/0/0 (43)
12:23:43.841077 IP 192.168.3.1.53 > 192.168.3.21.59212: Flags [P.], seq 1:748, ack 46, win 457, length 747 1 5/0/1 CNAME prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud., CNAME prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud., A 52.116.188.162, A 169.60.133.174, A 169.47.111.60 (745)
12:23:43.844150 IP 192.168.3.21.59212 > 192.168.3.1.53: Flags [F.], seq 46, ack 748, win 1023, length 0
12:23:43.844271 IP 192.168.3.1.53 > 192.168.3.21.59212: Flags [F.], seq 748, ack 47, win 457, length 0
12:23:43.846724 IP 192.168.3.21.59212 > 192.168.3.1.53: Flags [.], ack 749, win 1023, length 0

The only real difference I can see is that the meteobridge is doing AAAA (ipv6) and A (ipv4) queries and the desktop is only doing A,as I have no IPV6 from my ISP.

If I "dig" from another system on my network I get for A:

Code: Select all

;; QUESTION SECTION:
;rtupdate.wunderground.com.     IN      A

;; ANSWER SECTION:
rtupdate.wunderground.com. 10   IN      CNAME   prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud.
prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. 10 IN CNAME prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud.
prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. 10 IN A 169.47.111.60
prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. 10 IN A 52.116.188.162
prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud. 10 IN A 169.60.133.174

and for AAAA:

Code: Select all

;; QUESTION SECTION:
;rtupdate.wunderground.com.     IN      AAAA

;; ANSWER SECTION:
rtupdate.wunderground.com. 10   IN      CNAME   prod-pws-ng-ingest.prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-0001.us-south.containers.appdomain.cloud.

;; AUTHORITY SECTION:
containers.appdomain.cloud. 10  IN      SOA     ada.ns.cloudflare.com. dns.cloudflare.com. 2034373254 10000 2400 604800 3600

so the only thing I an figure is that when it resolves, since it is getting a response for the AAAA records it is trying to do an IPV6 lookup which does not resolve, and ignoring the A queries. I would think this is a error on weather undergrounds part, but all of my other systems do not have a problem with this, just the meteobridge. (also it seems that weather undergorund is the only service having this problem as I publish to 4 other services without an issue.)

[galfert]

On the Meteobridge, how is your Network tab IP Address configured? DHCP or Set Manually?
Looks like a DNS issue.

I recommend using DHCP and then going to your router's DHCP service and setting an IP address reservation for the Meteobridge.

[xannor]

Weirdly enough, while I was researching and building this post, one single blip of data came through, so I tried restarting my meteobridge again but no luck, this is just a really weird problem that must be unique to me because I see no other posts about WU issues recently.

it is set to DHCP, with a static assignment from my router, but DNS resolves fine for other systems on the same physical network.

[xannor]

I had an AHA moment while making my lunch, and I found the cause but not a solution.

I remembered around the time it stopped working I had turned on DoT (DNS-over-TLS) on my router and enabled a function that disabled client auto DoH (DNS-over-HTTPS) (so firefox doesnt ignore my custom/local dns entries). The default for DoT is strict mode, so I tried changing that to oppertunistic (will allow unverifiably record through) and that didnt work, then I tried disabling the DoH bocker and still nothing changed. Then I decided to turn off DoT and sure enough I could ping from the meteobridge. When i turned it back on I could not.

So I checked my server list and I am trying a bunch of difference servers to see if it is an endpoint issue, or if the meteobridge just cannot handle the responses from DoT.

[xannor]

I went through my preset list and none made a difference so it looks like for now, if I want WU updates, I have to leave DoT off. it is definately some issue between their DNS and the meteobridge when DoT is enabled.

[galfert]

You could set the IP address of the Meteobridge manually and use the reservation address you configured for it on your router. Then you'll be able to manually specify a DNS server for the Meteobridge, and use 8.8.8.8 or 1.1.1.1. This will allow you to enable DoT for your other DHCP devices... I think. Unless the router is smart enough to recognize DNS query to external DNS server and block it.