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
would also work in any of the scenarios where you have a router redirecyt
https://groups.google.com/d/msg/weewx-user/3ak8y8h83c0/oKP7QaHeAAAJ
Since we aren't running an HTTP server ourselves, the version response
becomes a non-issue. The way my system is set up the entire thing actually
still operates with myacurite.com and will still receive all firmware
updates as they show up.
On Thursday, November 3, 2016 at 5:08:51 PM UTC-5, Radar wrote:
>
> the perl script was made to work with tcpdump it won't work with the new
> tcpflow that puts out every thing on one line
>
> On Wednesday, November 2, 2016 at 7:21:17 PM UTC-5, Brad Tucker wrote:
>>
>> Only thing I noticed is you are running it off the bridge device. I can't
>> get any data off my bridge device. only eth0. I also see a stream similar
>> to yours when its communicating with weatherunderground. Is it possible you
>> didn't let it run long enough? Im assuming you let it run for a min or two
>> and had the same results?
>>
>> Past that I have no more ideas :( sorry...
>> B
>>
>> On Wednesday, November 2, 2016 at 5:06:51 PM UTC-7, Pat Hayes wrote:
>>>
>>> Looks like yours minus the good stuff.
>>>
>>> [root@weewx ~]# tcpdump -A -n -p -l -i bridge0 -s0 -W tcp dst port 80 |
>>> stdbuf -oL strings -n8 | stdbuf -oL grep "&"
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> decode
>>> listening on bridge0, link-type EN10MB (Ethernet), capture size 65535
>>> bytes
>>> E..4l.@.1..+b..7...*...P.&........9.R...............
>>> E..(l.@.1..6b..7...*...P.&...v.PP...3.........
>>> E...l.@.1...b..7...*...P.&...v.PP...{4..GET / HTTP/1.0
>>> E..4l.@.1..(b..7...*...P.&...v.P.....{.....
>>> E..4l.@.1..'b..7...*...P.&...v...."8.......
>>> E..4l.@.1..&b..7...*...P.&...v....'........
>>> E..4l.@.1..%b..7...*...P.&...v.l..-..C.....
>>> E..4l.@.1..$b..7...*...P.&...v.l..-..?.....
>>> E..(..@.1.Y.b..7...*...P.&......P.............
>>> E..(..@.1.Y.b..7...*...P.&......P.............
>>> E..(..@.1.Y.b..7...*...P.&......P.............
>>> E..(..@.1.Y.b..7...*...P.&......P.............
>>> E..(..@.1.Y.b..7...*...P.&......P.............
>>> E.....@.5.&.F,4....*...PX~4..;.......*.....
>>> E....&@.5...F,4....*...P..-..X.R.....$.....
>>> E..4.&@.5.+.F,4....*...PX~6M.<.w...........
>>> f.6.&,.....[.....
>>> f.6.&,...........
>>> f.6.&-.....5.....
>>> ^C62 packets captured
>>> 62 packets received by filter
>>> 0 packets dropped by kernel
>>>
>>>
>>>
>>>
>>> On Wednesday, November 2, 2016 at 7:38:41 PM UTC-4, Brad Tucker wrote:
>>>>
>>>> what does you output look like on tcpdump w/o the perl script? mine
>>>> always looked strange but it worked... Also don't do it off the bridge but
>>>> use eth0 or your main ethernet to the router.
>>>> sudo tcpdump -A -n -p -l -i eth0 -s0 -W tcp dst port 80 | stdbuf -oL
>>>> strings -n8 | stdbuf -oL grep "&"
>>>>
>>>> output always looks strange but it works well with the perl script:
>>>> pi@weather:~ $ sudo tcpdump -A -n -p -l -i eth0 -s0 -W tcp dst port 80
>>>> | stdbuf -oL strings -n8 | stdbuf -oL grep "&"
>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>> decode
>>>> listening on eth0, link-type EN10MB (Ethernet), capture size 262144
>>>> bytes
>>>> E..xfd..d.=.....4....}.P.. B...cP...D...GET
>>>> /weatherstation/updateweatherstation?dateutc=now&action=updateraw&realtime=1
>>>> E..Qfe..d.=.....4....}.P..
>>>> ....cP....g..&id=24C86E06B15C&mt=tower&sensor=00012694
>>>> ....4....}.P.. ....cP...OD..&humidity=53&tempf=73.0
>>>> E..Lfg..d.=.....4....}.P..
>>>> ....cP....|..&baromin=29.31&battery=normal&rssi=3
>>>> E..xfs..d.......4....~.P..0....jP.......GET
>>>> /weatherstation/updateweatherstation?dateutc=now&action=updateraw&realtime=1
>>>>
>>>> E..Qft..d.......4....~.P..0....jP...UH..&id=24C86E06B15C&mt=tower&sensor=00008384
>>>> E..?fu..d.......4....~.P..1....jP....$..&humidity=37&tempf=82.3
>>>>
>>>> E..Lfv..d.......4....~.P..1/...jP..._c..&baromin=29.31&battery=normal&rssi=2
>>>> E..xf...d.^.....46._...P/.......P...3...GET
>>>> /weatherstation/updateweatherstation?dateutc=now&action=updateraw&realtime=1
>>>>
>>>> E..Rf...d.^.....46._...P/..L....P....5..&id=24C86E06B15C&mt=5N1x38&sensor=00002179
>>>> E..Cf...d.^.....46._...P/..v....P....6..&windspeedmph=3&humidity=15
>>>> E..3f...d.^.....46._...P/.......P...Rg..&tempf=78.4
>>>>
>>>> E..Lf...d.^.....46._...P/.......P.......&baromin=29.31&battery=normal&rssi=3
>>>>
>>>> GLUCK!
>>>> B
>>>>
>>>>
>>>> On Wednesday, November 2, 2016 at 4:30:08 PM UTC-7, Pat Hayes wrote:
>>>>>
>>>>> With just the tcpflow command, it shows this.
>>>>>
>>>>> [root@weewx ~]# tcpflow -C -0 -s tcp dst port 80
>>>>> tcpflow: listening on bridge0
>>>>> GET
>>>>> /weatherstation/updateweatherstation?dateutc=now&action=updateraw&realtime=1&id=24C86E08150D&mt=5N1x38&sensor=00002701&windspeedmph=0&humidity=86&tempf=58.8&baromin=30.34&battery=normal&rssi=3
>>>>>
>>>>> HTTP/1.1
>>>>> Host: hubapi.myacurite.com
>>>>> User-Agent: Hub/224
>>>>> Connection: close
>>>>>
>>>>> GET
>>>>> /weatherstation/updateweatherstation?dateutc=now&action=updateraw&realtime=1&id=24C86E08150D&mt=5N1x31&sensor=00002701&windspeedmph=0&winddir=158&rainin=0.00&dailyrainin=0.00&humidity=86&tempf=58.8&dewptf=54&baromin=30.34&battery=normal&rssi=3
>>>>>
>>>>> HTTP/1.1
>>>>> Host: hubapi.myacurite.com
>>>>> User-Agent: Hub/224
>>>>> Connection: close
>>>>>
>>>>> GET
>>>>> /weatherstation/updateweatherstation.php?ID=KNJNEWJE4&PASSWORD=pat6854&dateutc=now&action=updateraw&realtime=1&rtfreq=36&id=24C86E08150D&mt=5N1x31&sensor=00002701&windspeedmph=0&winddir=158&rainin=0.00&dailyrainin=0.00&humidity=86&tempf=58.8&dewptf=54&baromin=30.34&battery=normal&rssi=3
>>>>>
>>>>> HTTP/1.1
>>>>> Host: rtupdate.wunderground.com
>>>>> Connection: close
>>>>>
>>>>>
>>>>>
>>>>> Brad, I tryed your combination, but nothing gets sent to weewx and
>>>>> nothing gets shown in console either.
>>>>>
>>>>> [root@weewx ~]# tcpdump -A -n -p -l -i bridge0 -s0 -W tcp dst port 80
>>>>> | stdbuf -oL strings -n8 | stdbuf -oL grep "&" | ./acurite-lwp.pl
>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>> decode
>>>>> listening on bridge0, link-type EN10MB (Ethernet), capture size 65535
>>>>> bytes
>>>>> ^C42 packets captured
>>>>> 42 packets received by filter
>>>>> 0 packets dropped by kernel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, November 2, 2016 at 7:17:42 PM UTC-4, mwall wrote:
>>>>>>
>>>>>> On Wednesday, November 2, 2016 at 6:53:13 PM UTC-4, Pat Hayes wrote:
>>>>>>>
>>>>>>> I've been following this thread thanks to Brad letting me know of
>>>>>>> it. It seems I ran into a snag. It seems the interceptor driver doesn't
>>>>>>> like the input.
>>>>>>>
>>>>>>
>>>>>> pat,
>>>>>>
>>>>>> it looks like your tcpflow/acurite-lwp.pl combination is butchering
>>>>>> the string that it is posting to the interceptor.
>>>>>>
>>>>>> what do you see when you just do the tcpflow command?
>>>>>>
>>>>>> 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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
