I've had a weewx system running for a couple years uses a variant of the
hackulink driver that I had created (used libpcap python libraries to
directly sniff the traffic passing through the router (linux based distro
running on a laptop) without needing to have an external ngrep or tcpdump
comm
Yeah, this is the primary reason I wanted to switch to the interceptor
instead of rewriting my version of the hackulink
On Saturday, October 15, 2016 at 2:45:16 PM UTC-5, Radar wrote:
>
> i thought that it would but i have it working with a put togohter driver i
> made that works and edited some
I didnt get notifications that these messages came in, and just now saw
them. I'll give it a shot in a bit after the kid goes to bed.
On Saturday, October 15, 2016 at 3:04:22 PM UTC-5, mwall wrote:
>
> On Saturday, October 15, 2016 at 12:21:13 PM UTC-4, Jerome Helbert wrote:
>
&
This is also only an issue for someone not sniffing and redirecting, only
if the bridge is talking directly to the driver.
On Saturday, October 15, 2016 at 3:04:22 PM UTC-5, mwall wrote:
>
>
> there is an (untested) fix for this at commit b27acc1 (interceptor driver
> 0.13a)
>
> [Interceptor]
>
libpcap working, is that something we'd be interesting in
bringing into the driver itself?
On Saturday, October 15, 2016 at 3:04:22 PM UTC-5, mwall wrote:
>
> On Saturday, October 15, 2016 at 12:21:13 PM UTC-4, Jerome Helbert wrote:
>
>
>> Two things here...
>>
>
ns dict for the various parameters, now it reads those out of
stn_dict), just an FYI if you try to run it as is - it will probably fail
without some code massaging,
On Sunday, October 16, 2016 at 12:40:14 AM UTC-5, Jerome Helbert wrote:
>
> ok, I see what radar is doing... Most of the "
I forgot to mention, this uses the python-libpcap and libpcap libraries as
dependencies. Both were available via apt-get on ubuntu.
On Saturday, October 22, 2016 at 11:21:22 PM UTC-5, Jerome Helbert wrote:
>
> Finally got some time it port my libpcap based stuff into the driver. I
> f
I posted a modified version of the interceptor a few weeks ago, I used the
libpcap libraries to sniff the data stream directly (no need to run tcpdump
or ngrep or any of that external to the driver. My setup has weewx running
directly on the machine that is routing traffic to myacurite.com. This
varied. I would recommend adding the
specific python module that I called out in my other thread to make
installs easier.
On Sunday, November 6, 2016 at 8:54:14 AM UTC-6, mwall wrote:
>
> On Saturday, November 5, 2016 at 10:24:08 PM UTC-4, Jerome Helbert wrote:
>>
>> I posted a m
I just assumed that when I didn't see anything after I posted this a few
weeks ago that you didn't like the idea :P
On Sunday, November 6, 2016 at 9:16:28 AM UTC-6, mwall wrote:
>
> jerome,
>
> thank you for posting this!
>
> i have incorporated your changes into the interceptor driver at commit
Matt,
How would you prefer bugs be written up? Just posts here, or would it work
better to create an issue in github?
I noticed the wrap-around portion of _delta_rain() could lead to lost data.
When a wrap-around occurs (new_rain < last_rain), you return None. But it's
entirely possible that we
is option b actually something that some of this hardware will produce?
On Sunday, November 6, 2016 at 12:16:00 PM UTC-6, mwall wrote:
>
> On Sunday, November 6, 2016 at 12:12:54 PM UTC-5, Jerome Helbert wrote:
>>
>> Matt,
>> How would you prefer bugs be written up? Just
vember 6, 2016 at 1:17:42 PM UTC-5, Jerome Helbert wrote:
>>
>> is option b actually something that some of this hardware will produce?
>>
>
> i've seen it happen with acurite hardware, but that was with the acurite
> driver and the usb interface. never saw it wit
also should mention that python-libpcap is dependent on the libpcap C
libraries.
On Sunday, November 6, 2016 at 10:11:15 AM UTC-6, Jerome Helbert wrote:
>
> I looked over the commit, looks good. I will try to get a chance to pull
> it down and try it out later today.
>
> W
uesday, November 8, 2016 at 7:07:54 AM UTC-6, Jerome Helbert wrote:
>
> also should mention that python-libpcap is dependent on the libpcap C
> libraries.
>
> On Sunday, November 6, 2016 at 10:11:15 AM UTC-6, Jerome Helbert wrote:
>>
>> I looked over the commit, looks go
On Tuesday, November 8, 2016 at 8:55:31 AM UTC-5, Jerome Helbert wrote:
>>
>> Finally got a chance to check out the driver (latest commit 2ad77b7
>> <https://github.com/matthewwall/weewx-interceptor/commit/2ad77b771db76b46858e04750a9f902f113ecaa8>),
>>
>> had to
This commit looks good! Thanks!
On Tuesday, November 8, 2016 at 4:06:48 PM UTC-6, mwall wrote:
>
> On Tuesday, November 8, 2016 at 3:58:04 PM UTC-5, Jerome Helbert wrote:
>
> Filter was an issue because the class Consumer init function uses
>> pcap_filter:
>>
>
> ri
port 80 basically implies http, so that extra bit ought to be pretty
redundant...
On Wednesday, November 16, 2016 at 8:20:16 PM UTC-6, Radar wrote:
>
> looks like its not going to die again, the only things i can find are
> changed the
>
> pcap_filter = "src 192.168.2.14 and dst port 80"
> to
>
Botched FW upgrades almost never result in "partial" instabilities... It
will almost always result in a bricked device.
On Saturday, November 12, 2016 at 7:11:43 PM UTC-6, Radar wrote:
>
> changed the 3 calls and is running right now
>
> it could be that the bridge didn't take the firmware right
, 2016 at 9:53:38 PM UTC-6, Radar wrote:
>
> thanks every one for the help and this great software
>
>
> On Wednesday, November 16, 2016 at 9:11:48 PM UTC-6, Jerome Helbert wrote:
>>
>> port 80 basically implies http, so that extra bit ought to be pretty
>> redundan
ing the errors
>>
>>
>>
>> On Thursday, November 17, 2016 at 10:26:13 PM UTC-6, Jerome Helbert wrote:
>>>
>>> radar,
>>> What exactly is setup? Are you running the driver as a sniffer on a
>>> device like your router that is sniffin
21 matches
Mail list logo
