I meant DNS hijacking as setting it on my router (precisely, on PiHole's local DNS) - IP of Weewx as rtupdate.wunderground.com.
czwartek, 9 lipca 2026 o 16:08:45 UTC+2 John Smith napisał(a): > Even DNS hijacking didn't worked > > > That assumes they haven't switched to an encrypted DNS protocol. DoT is > trivial to stop, you just filtering packets attempting connections to > TCP/UDP port 853. > > You *may* be able to prevent DoH connections by filtering DNS requests in > a local resolver from this long list of known DoH server hostnames > <https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/doh.txt> > . > > However all Cloudflare IPs tested return DoH packets for any hostname > setup to handle DoH requests. As DoH uses the same port as HTTPS > connections, it would be self defeating to block Cloudflare by IP/ASN due > to the sheer number of websites with their reverse proxy service and > there is a *LOT* of websites using Cloudflare. > > People only realise that a website is proxied by Cloudflare when a server > is down and they see a Cloudflare error page, but this plugin by > Cloudflare > <https://chromewebstore.google.com/detail/cloudflare-optics/mdjgbjnbdnhneejmmaabmccfehigbjbe> > > for Chrome based browsers will more prominently show websites using > Cloudflare. > > A number of countries force ISPs to drop Cloudflare traffic during > prominent sporting matches to limit unauthorised streaming services from > re-broadcasting although this happens with mixed results, and many > legitimate websites become collateral damage because their sites suddenly > stop working then. > > On Thu, 9 Jul 2026 at 22:28, 'Tomasz Lewicki' via weewx-user < > [email protected]> wrote: > >> On my fourth attempt (the first was in March of last year!), I managed to >> get the Garni 1025 to send data to Weewx. I used the interceptor plugin, >> set the address of my own Raspberry Pi running Weewx in the configuration >> panel (by the way, "Custom server" uses the WU protocol - I found it >> analyzing firmware update .bin files), and used port forwarding. I suppose >> the last step was the key. Even DNS hijacking didn't worked. So, after 16 >> months, success - better late than never :) >> >> wtorek, 1 kwietnia 2025 o 06:16:41 UTC+2 Cameron D napisał(a): >> >>> You may have been hoping for that, but TCP/IP does not work that way. >>> There are ways of doing it, but it will be interfering in the normal >>> network traffic flow and, while OK at your home, is probably not suitable >>> for the installation you are describing. >>> >>> I think running a parallel system where you get the RF data directly >>> would be far preferable. It might have the added benefit that it should >>> keep working even if the Garni base station stops. >>> On Tuesday, 1 April 2025 at 5:40:19 am UTC+10 Tomasz Lewicki wrote: >>> >>>> Correct, but I was hoping that by routing the TCP transmission to the >>>> Raspberry with Weewx on board I would cause the packets to be captured by >>>> Weewx. >>>> >>>> poniedziałek, 31 marca 2025 o 06:57:56 UTC+2 Cameron D napisał(a): >>>> >>>>> sorry, I did not read your post thoroughly enough. >>>>> You have told the Garni that you are running a server on the Pi to >>>>> collect the weather data - but you are not running a server. That is why >>>>> the Pi sends the reset packet and closes the connection. >>>>> >>>>> On Monday, 31 March 2025 at 6:10:31 am UTC+10 Tomasz Lewicki wrote: >>>>> >>>>>> Today I had the opportunity to test Garni again and... I am even more >>>>>> confused. >>>>>> >>>>>> After switching to AP mode, I entered an additional user server in >>>>>> the configuration (manual page with screenshot: >>>>>> http://stalker.udl.pl/temp/garni1025.jpeg): >>>>>> >>>>>> URL: 192.168.1.153 (RaspberryPi IP with Weewx installed) >>>>>> Station ID: ABC >>>>>> Station key: abc >>>>>> >>>>>> Then I ran tcpdump on the RPi. It recorded several packets to port 80 >>>>>> coming from Garni (192.168.1.100). I saved them in a .pcap file, >>>>>> unfortunately they don't tell me anything meaningful. I'm sharing two >>>>>> files, maybe someone can find something in them? >>>>>> >>>>>> http://stalker.udl.pl/temp/weewx1.pcap >>>>>> http://stalker.udl.pl/temp/weewx2.pcap >>>>>> >>>>>> The weewx.conf fragment for the interceptor driver looks like this in >>>>>> my case: >>>>>> >>>>>> [Interceptor] >>>>>> driver = user.interceptor >>>>>> device_type = wu-client >>>>>> mode = sniff >>>>>> iface = wlan0 >>>>>> pcap_filter = src 192.168.1.110 and dst port 80 >>>>>> >>>>>> Unfortunately, with these settings I still see an empty queue. >>>>>> >>>>>> So I set about listening in using the SDR dongle. The rtl_433 found >>>>>> several devices in the area transmitting at 868 MHz, including Garni: >>>>>> >>>>>> 2025-03-30T17:42:08.703037+02:00 raspberrypi weewxd[475]: INFO >>>>>> user.sdr: unmapped: {'dateTime': 1743349325, 'usUnits': 17, >>>>>> 'temperature.43967.Bresser7in1Packet': 8.6, >>>>>> 'humidity.43967.Bresser7in1Packet': 51.0, >>>>>> 'wind_gust.43967.Bresser7in1Packet': 1.1, >>>>>> 'wind_speed.43967.Bresser7in1Packet': 1.1, >>>>>> 'wind_dir.43967.Bresser7in1Packet': 90.0, >>>>>> 'rain_total.43967.Bresser7in1Packet': 0.0, >>>>>> 'lux.43967.Bresser7in1Packet': >>>>>> 3849, 'uv.43967.Bresser7in1Packet': 0.0, >>>>>> 'battery.43967.Bresser7in1Packet': >>>>>> 0} >>>>>> >>>>>> And such messages repeat periodically. So I was half-successful. Why >>>>>> only half? Because I can't see the messages from the interior panel - >>>>>> interior temperature and pressure. Does this mean that the panel is not >>>>>> transmitting anything on radio frequencies (868 MHz in my case) like the >>>>>> external module? >>>>>> >>>>>> I already have a starting point in the form of Weewx recognizing the >>>>>> station as a Bresser 7in1. Searching by this designation I came across >>>>>> such >>>>>> a thread on WXforum.net: >>>>>> https://www.wxforum.net/index.php?topic=45249.0 and others. >>>>>> Unfortunately, in neither case did I find information about downloading >>>>>> data from the internal panel. >>>>>> >>>>>> Could someone suggest something? If the panel actually does not send >>>>>> anything that the SDR dongle is able to capture, only the interceptor >>>>>> driver remains. But how do I get it to capture packets from the network, >>>>>> since I think I've set the appropriate section in weewx.conf correctly, >>>>>> but >>>>>> I still see an empty queue? >>>>>> >>>>>> I'm counting on the wisdom of the group :) >>>>>> >>>>>> wtorek, 25 marca 2025 o 02:59:05 UTC+1 Cameron D napisał(a): >>>>>> >>>>>>> yes, I realised my mistake once Vince mentioned the EcoWitt setup. >>>>>>> It is an unfortunate ambiguity of "Access Point" terminology, which >>>>>>> I have only seen used to describe the process I was referring to - >>>>>>> bridging >>>>>>> two network segments. >>>>>>> >>>>>>> From the description Tomasz gave it seems the panel has a single >>>>>>> wifi interface that either sets up an isolated private wlan, or acts as >>>>>>> a >>>>>>> wifi client. >>>>>>> >>>>>>> On Tuesday, 25 March 2025 at 6:24:10 am UTC+10 Rainer Lang wrote: >>>>>>> >>>>>>>> @Cameron D. >>>>>>>> I think you are mistaken here regarding the console WLAN - even if >>>>>>>> that Garni piece is manufactured by CCL, what they do is a commonly >>>>>>>> used >>>>>>>> process. >>>>>>>> E.g. factually all FineOffset (clone) consoles can create their own >>>>>>>> WLAN and a WLAN enabled device (PC, Smartphone etc.) can connect to it >>>>>>>> via >>>>>>>> the SSID the console sends. So that console also becomes an access >>>>>>>> point >>>>>>>> for its own WLAN. It has not yet anything to do with the local WLAN. >>>>>>>> The local WLAN is then selected through the console and the user >>>>>>>> can connect to it via the local SSID and the router password. Now, >>>>>>>> that >>>>>>>> console has two interfaces - through its own WLAN and through the >>>>>>>> local >>>>>>>> WLAN. >>>>>>>> Usually the console WLAN is switched off once the connection to the >>>>>>>> local WLAN is established. >>>>>>>> This process sometimes called "WiFi provisioning" or "pairing" is >>>>>>>> quite common. >>>>>>>> The 2.4 GHz come into play as the console is usually only 2.4 GHz >>>>>>>> enabled. >>>>>>>> Considering this having a minimal value is immaterial - the value >>>>>>>> consists of being able to connect the console to the local WLAN - this >>>>>>>> type >>>>>>>> of setup is quite common and usually works well - provided the user >>>>>>>> takes a >>>>>>>> few precautions like e.g. switching off the mobile data network during >>>>>>>> the >>>>>>>> "pairing" process and avoiding also having a 5 GHz WLAN with the same >>>>>>>> SSID >>>>>>>> active during the pairing. >>>>>>>> On 24.03.2025 05:42, 'Cameron D' via weewx-user wrote: >>>>>>>> >>>>>>>> I don't understand why the Garni would need to be set up as you >>>>>>>> describe - its specification is only 2.4GHz for Wifi, so its value as >>>>>>>> a >>>>>>>> real AP would be minimal. It does not seem to need to use wifi for >>>>>>>> connecting to anything else (that uses 868MHz). >>>>>>>> You wrote that "I managed to connect the laptop to the network >>>>>>>> created by the Garni panel..." but that does not fit - an AP does not >>>>>>>> create a new wifi network, it only extends the existing one created by >>>>>>>> the >>>>>>>> router. >>>>>>>> >>>>>>>> Most likely the router recognises that the upload traffic from the >>>>>>>> panel is not local and does not show it to the laptop/pi, since it >>>>>>>> would >>>>>>>> require retransmitting. A domestic router is unlikely to offer >>>>>>>> traffic >>>>>>>> mirroring/monitoring. >>>>>>>> If all that is correct then I think your options are: >>>>>>>> 1. investigate the option where it says "access data on user's own >>>>>>>> server" >>>>>>>> 2. set up the Pi as another wifi router and pass the traffic >>>>>>>> through it - then use ethernet to the external router >>>>>>>> >>>>>>>> On Sunday, 23 March 2025 at 5:48:59 am UTC+10 Tomasz Lewicki wrote: >>>>>>>> >>>>>>>>> Today I had the opportunity to face the Garni 1025 station. >>>>>>>>> Unfortunately, the issue is much more complex than it might seem at >>>>>>>>> first. >>>>>>>>> The universal driver “interceptor” is powerless in this case. The >>>>>>>>> station >>>>>>>>> communicates with the environment in a strange way. It turns out that >>>>>>>>> the >>>>>>>>> panel with the display does not connect directly to the local network >>>>>>>>> as a >>>>>>>>> device with an IP address in the range given by the DHCP server of >>>>>>>>> the home >>>>>>>>> router, but probably forms a kind of bridge between itself and the >>>>>>>>> router. >>>>>>>>> >>>>>>>>> The way I came to this was that after connecting the Raspberry Pi >>>>>>>>> with Weewx installed, I scanned the local network with my smartphone >>>>>>>>> and >>>>>>>>> found no device in it that could be a Garni panel. From the >>>>>>>>> instructions, I >>>>>>>>> learned that to configure the panel, you need to press the >>>>>>>>> appropriate >>>>>>>>> button on the case and enter AP mode. Then you can enter the default >>>>>>>>> address 192.168.1.1 with a browser and there enter the SSID of your >>>>>>>>> home >>>>>>>>> network and the password for it. I managed to connect the laptop to >>>>>>>>> the >>>>>>>>> network created by the Garni panel and started sniffing on the >>>>>>>>> network >>>>>>>>> traffic. Unfortunately, tcpdump didn't show anything that would give >>>>>>>>> any >>>>>>>>> meaningful clues. The only packets were sent by the Garni panel to my >>>>>>>>> laptop. I couldn't see any packets that Garni was routing to the >>>>>>>>> router, >>>>>>>>> yet it must be transmitting something if data is being sent to the >>>>>>>>> WU, >>>>>>>>> right? >>>>>>>>> >>>>>>>>> Do you see any way that I could still try? >>>>>>>>> >>>>>>>>> PS. Does Weewx allow you to import data from WU in "quasi real >>>>>>>>> time"? What I mean is, can I download data from WU, for example, >>>>>>>>> every 5-10 >>>>>>>>> minutes and feed it to Weewx so that it creates charts locally. >>>>>>>>> >>>>>>>>> niedziela, 16 marca 2025 o 10:02:32 UTC+1 Tomasz Lewicki >>>>>>>>> napisał(a): >>>>>>>>> >>>>>>>>>> Thank you all for the helpful replies. >>>>>>>>>> >>>>>>>>>> As I said, the station is out of my reach so I hoped to prepare >>>>>>>>>> "dry run" and set up Weewx in my home environment and then just >>>>>>>>>> connect in >>>>>>>>>> in target network, changing only necassary things (WiFi network and >>>>>>>>>> so on). >>>>>>>>>> If it is not possible, I have to use tcpdump "in situ", where Garni >>>>>>>>>> works. >>>>>>>>>> But - replying to Reiner Lang's suggestion - Garni sends the data to >>>>>>>>>> WU >>>>>>>>>> instantly; you can check it here -> >>>>>>>>>> https://www.wunderground.com/dashboard/pws/IKOWAL30 >>>>>>>>>> >>>>>>>>>> In the meantime I got a photo of manual page from the owner of >>>>>>>>>> the station (Garni doesn't share the manuals on its website - it's >>>>>>>>>> strange) >>>>>>>>>> and then I was almost sure that Garni uses Weathercloud protocol >>>>>>>>>> because >>>>>>>>>> setup allows setting my own server (if someone is curious, here is a >>>>>>>>>> photo >>>>>>>>>> -> http://stalker.udl.pl/temp/garni1025.jpeg). So I looked into >>>>>>>>>> Weathercloud website and can confirm that Garni 1025 uses >>>>>>>>>> Weathercloud >>>>>>>>>> protocol -> https://weathercloud.net/en/compatible-devices List >>>>>>>>>> contains plenty of manufacturers which I know. Rainer Lang hinted >>>>>>>>>> that >>>>>>>>>> manufacturer is CCL (shame to say it but I did not know this >>>>>>>>>> company). I >>>>>>>>>> found quite old "wcloud" driver from Matthew Wall ( >>>>>>>>>> https://github.com/matthewwall/weewx-wcloud) but if I understand >>>>>>>>>> it good, it allows only for uploading the data from Weewx to >>>>>>>>>> Weathercloud >>>>>>>>>> server, not downloading it from weather station. >>>>>>>>>> >>>>>>>>>> So maybe the clones which Weewx supports are using some >>>>>>>>>> "standard" protocol (whatever means "standard" when talking about >>>>>>>>>> PWS) and >>>>>>>>>> I can use some known driver here...? >>>>>>>>>> >>>>>>>>>> niedziela, 16 marca 2025 o 02:55:59 UTC+1 vince napisał(a): >>>>>>>>>> >>>>>>>>>>> Can you perhaps just listen for all tcp traffic and not specify >>>>>>>>>>> the src address and see what is on your network ? >>>>>>>>>>> >>>>>>>>>>> I’d think you might try to listen for tcp src 192.168.0.0/24 >>>>>>>>>>> dst not 192.168.0.0/24 and not specify any port. >>>>>>>>>>> >>>>>>>>>>> Or listen for all tcp traffic for at least 10 minutes and >>>>>>>>>>> capture to a file, then transfer the pcap file back to your >>>>>>>>>>> computer to >>>>>>>>>>> analyze in the wireshark/ethereal gui later. If you could post a >>>>>>>>>>> pcap file >>>>>>>>>>> somewhere I’m sure folks will see if they can help determine the >>>>>>>>>>> correct >>>>>>>>>>> settings. >>>>>>>>>>> >>>>>>>>>>> On Saturday, March 15, 2025 at 6:15:42 PM UTC-7 matthew wall >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> tomasz, >>>>>>>>>>>> >>>>>>>>>>>> you are correct to first use tcpdump. once you see data using >>>>>>>>>>>> tcpdump, then you can experiment with interceptor to get the data >>>>>>>>>>>> into >>>>>>>>>>>> weewx. if the station can successfully post to wunderground, then >>>>>>>>>>>> the >>>>>>>>>>>> interceptor *should* be able to capture the data. but you should >>>>>>>>>>>> first use >>>>>>>>>>>> tcpdump to figure out the settings necessary to capture data. >>>>>>>>>>>> >>>>>>>>>>>> is it possible to adjust the destination in the weather >>>>>>>>>>>> station? if so, you could tell the station to send to the >>>>>>>>>>>> computer running >>>>>>>>>>>> weewx, instead of wunderground. but still use the wunderground >>>>>>>>>>>> protocol. >>>>>>>>>>>> >>>>>>>>>>>> can you control the dns entries on the network? if so, make >>>>>>>>>>>> weatherstation.wunderground.com resolve to the computer >>>>>>>>>>>> running weewx, then run interceptor in listen mode. if you >>>>>>>>>>>> already run a >>>>>>>>>>>> web server on port 80 then you would have to make interceptor >>>>>>>>>>>> listen on a >>>>>>>>>>>> port other than 80, then adjust the web server configuration to >>>>>>>>>>>> send >>>>>>>>>>>> traffic for /weatherstation/updateweatherstation.php to that port. >>>>>>>>>>>> or do >>>>>>>>>>>> it with firewall rules. >>>>>>>>>>>> >>>>>>>>>>>> does your network switch support port mirroring? if so, mirror >>>>>>>>>>>> the port that the weather station uses and make interceptor listen >>>>>>>>>>>> on the >>>>>>>>>>>> mirrored port. >>>>>>>>>>>> >>>>>>>>>>>> or if the station is wifi, make interceptor listen on an >>>>>>>>>>>> interface that can see the wifi traffic. >>>>>>>>>>>> >>>>>>>>>>>> but first use tcpdump in one of these configurations to ensure >>>>>>>>>>>> that you can see the data from the station. >>>>>>>>>>>> >>>>>>>>>>>> m >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "weewx-user" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/d/msgid/weewx-user/805d8c77-046b-4f35-9d0b-ed090a1536b1n%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/weewx-user/805d8c77-046b-4f35-9d0b-ed090a1536b1n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/d/msgid/weewx-user/80be717f-e5e2-4b17-8921-b44eac7e5b8bn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/80be717f-e5e2-4b17-8921-b44eac7e5b8bn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/4521b35c-31e1-4e3e-80c2-ff6b56b3a905n%40googlegroups.com.
