> > 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/CAGTinV6TyO8U5_Hsi1aCbzXQ%3D1nhasTPBSW5hME1WYttStBxhA%40mail.gmail.com.
