One thing I’ve found is that some devices only query dns and especially ntp when they power up, so it is easy to miss those if you run tcpdump after the console is already running. You might have more luck if you start tcpdump then power the console down/up.
SDR should likely see something if you can figure out the frequency settings, but decoding it might be difficult initially. If it is similar to other stations already known by weewx-sdr then extending that driver by adding a new definition is pretty straightforward. SDR will not have any data from sensors in the console itself (typically pressure and inside temperature) I do not recall anything that imports realtime from WU. Interceptor intercepts traffic ‘to’ WU. WU does not send data anywhere. On Sunday, March 23, 2025 at 12:10:55 AM UTC-7 Tomasz Lewicki wrote: > I don't know if this makes sense or not, I simply described my attempts. > tcpdump is unlikely to lie. But fine. Let's assume I don't have the ability > (or skill) to use the interceptor driver. Are there other options for > getting data from the station? > > It seems to me that I have two ways - direct and indirect. > > 1. Direct > > I found information about the weewx-sdr controller. From the description > it seems to me that it can help me in my situation. It works well, because > I have an SDR dongle that I use to receive ADS-B signals. > > 2 Indirect > > Downloading the data sent by the station to the WU and uploading it to > Weewx. I repeat the question from the previous message - does Weewx allow > import on the fly from WU, or only from manually fed files? > > niedziela, 23 marca 2025 o 02:35:36 UTC+1 vince napisał(a): > >> Not sure your description makes much sense. There has to be some traffic >> from the station to an ip off network. I’d expect ntp and dns traffic as >> well. >> On Saturday, March 22, 2025 at 12:48:59 PM UTC-7 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/b2292465-67d7-4475-8e7d-3ba7cb4a4972n%40googlegroups.com.
