and i can't use it because i use two 5n1 sensors and a rain gauge and a 
about 10 temp/humid sensors i was just playing with it but it worked

On Saturday, October 15, 2016 at 1:54:20 PM UTC-5, Radar wrote:
>
> hi,
> i tested the interceptor driver using tcpdump piped to a perl script to 
> put the packets in one string then send it to weewx interceptor driver 
> using using LWP::UserAgent
> that seamed to work
>
> tcpdump -A -n -p -l -i eth0 -s0 -W tcp dst port 80 | stdbuf -oL strings 
> -n8 | stdbuf -oL grep "&" | to the perl script -> weewx interceptor driver
>
> On Saturday, October 15, 2016 at 11:21:13 AM UTC-5, Jerome Helbert wrote:
>>
>> 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 
>> command. It worked pretty well, but in hindsight its fairly cobbled 
>> together and is losing its usefulness as I add more sensors to the system.
>>
>> About a month ago the system died, being and electrical engineer i 
>> started trying to diagnose a hardware issue and thought that when I saw the 
>> power supply putting out 7.5V instead of 4.5V that that was was killed it. 
>> As I've read around the internet I'm starting to wonder if it was a botched 
>> upgrade to the new SmartHub stuff... Either way I picked up a great deal 
>> for a new bridge + 3 tower sensors off ebay, I fired it up and it did its 
>> FW update - now my hackulink driver no longer works...
>>
>> I went out looking for some information on the new format and came across 
>> the interceptor driver and I've decided to shift over to that. 
>> Unfortunately I am having all kinds of problems getting the sniffing or 
>> redirecting part working. Ive tried all kinds of variants of tcpdump and 
>> ngrep with various sed filters and for the life of me cannot get the 
>> interceptor to parse everything correctly (running it stand alone for now 
>> until I get the whole things working.) I've narrowed it down to the GET 
>> strings coming in as what looks like multiple packets:
>> ngrep -l -q -d eth0 '&' 'src host 10.0.7.1 && dst port 80' | sed -u 
>> '/&/!d'
>> filter: (ip or ip6) and ( src host 10.0.7.1 && dst port 80 )
>> match: &
>>   GET /weatherstation/updateweatherstation?dateutc=now&action=updateraw&
>> realtime=1
>>   &id=24C86E068291&mt=5N1x38&sensor=00000588
>>   &windspeedmph=9&humidity=98
>>   &tempf=63.9
>>   &baromin=30.12&battery=normal&rssi=1
>>   GET /weatherstation/updateweatherstation?dateutc=now&action=updateraw&
>> realtime=1
>>   &id=24C86E068291&mt=tower&sensor=00002029
>>   &humidity=63&tempf=68.9
>>   &baromin=30.12&battery=normal&rssi=2
>> when I pipe this into "nc 10.0.0.1 9999" and run the interceptor at that 
>> port, all the interceptor seems to see is:
>> ngrep -l -q -d eth0 '&' 'src host 10.0.7.1 && dst port 80' | sed -u 
>> '/&/!d' | sed -u -n 3~1p | nc 10.0.0.1 9999
>> { "success": 1, "checkversion": "126" }
>>
>> PYTHONPATH=./ python user/interceptor.py --port 9999 --debug
>> identifiers: dateutc=now&action=updateraw&realtime=1
>> {'bridge_id': None, 'sensor_type': None, 'sensor_id': None}
>> raw data: dateutc=now&action=updateraw&realtime=1
>> raw packet: {'usUnits..': 1, 'dateTime..': 1476547464, 'usUnits': 1, 
>> 'dateTime': 1476547464}
>> mapped packet: {'usUnits': 1, 'dateTime': 1476547464}
>>
>> An interesting note is that if I do a DNS hijack, and kill the apache 
>> server and link ncat up to port 80 directly I see:
>> nc -l -p 80
>> GET /weatherstation/updateweatherstation?dateutc=now&action=updateraw&
>> realtime=1&id=24C86E068291&mt=5N1x31&sensor=00000588&windspeedmph=8&
>> winddir=158&rainin=0.00&dailyrainin=0.00&baromin=30.19&battery=normal&
>> rssi=2 HTTP/1.1
>> Host: hubapi.myacurite.com
>> User-Agent: Hub/224
>> Connection: close
>> and if then hook interceptor up to port 80:
>> PYTHONPATH=./ python user/interceptor.py --port 80 --debug
>> identifiers: dateutc=now&action=updateraw&realtime=1&id=24C86E068291&mt=
>> tower&sensor=00004647&humidity=61&tempf=69.8&baromin=30.19&battery=normal
>> &rssi=3
>> {'bridge_id': '24C86E068291', 'sensor_type': 'tower', 'sensor_id': 
>> '00004647'}
>> raw data: dateutc=now&action=updateraw&realtime=1&id=24C86E068291&mt=
>> tower&sensor=00004647&humidity=61&tempf=69.8&baromin=30.19&battery=normal
>> &rssi=3
>> raw packet: {'barometer.00004647.24C86E068291': 30.19, 
>> 'rssi.00004647.24C86E068291': 0.75, 'sensor_id.00004647.24C86E068291': 
>> '00004647', 'dateTime.00004647.24C86E068291': 1476509500, 'dateTime': 
>> 1476509500, 'humidity.00004647.24C86E068291': 61.0, 
>> 'usUnits.00004647.24C86E068291': 1, 'temperature.00004647.24C86E068291': 
>> 69.8, 'sensor_type.00004647.24C86E068291': 'tower', 
>> 'bridge_id.00004647.24C86E068291': '24C86E068291', 'usUnits': 1, 
>> 'battery.00004647.24C86E068291': 0}
>> mapped packet: {'txBatteryStatus': 0, 'outHumidity': 61.0, 'dateTime': 
>> 1476509500, 'outTemp': 69.8, 'rxCheckPercent': 0.75, 'usUnits': 1}
>> identifiers: id=24C86E068291&mt=firmware&line=0&count=1
>> {'bridge_id': '24C86E068291', 'sensor_type': 'firmware', 'sensor_id': 
>> None}
>> raw data: id=24C86E068291&mt=firmware&line=0&count=1
>> raw packet: {'dateTime..24C86E068291': 1476509501, 
>> 'bridge_id..24C86E068291': '24C86E068291', 'sensor_type..24C86E068291': 
>> 'firmware', 'usUnits..24C86E068291': 17, 'dateTime': 1476509501, 
>> 'usUnits': 17}
>> mapped packet: {'usUnits': 17, 'dateTime': 1476509501}
>> identifiers: id=24C86E068291&mt=firmware&line=0&count=1
>> {'bridge_id': '24C86E068291', 'sensor_type': 'firmware', 'sensor_id': 
>> None}
>> raw data: id=24C86E068291&mt=firmware&line=0&count=1
>> raw packet: {'dateTime..24C86E068291': 1476509545, 
>> 'bridge_id..24C86E068291': '24C86E068291', 'sensor_type..24C86E068291': 
>> 'firmware', 'usUnits..24C86E068291': 17, 'dateTime': 1476509545, 
>> 'usUnits': 17}
>> mapped packet: {'usUnits': 17, 'dateTime': 1476509545}
>> identifiers: id=24C86E068291&mt=firmware&line=0&count=1
>> {'bridge_id': '24C86E068291', 'sensor_type': 'firmware', 'sensor_id': 
>> None}
>> raw data: id=24C86E068291&mt=firmware&line=0&count=1
>> raw packet: {'dateTime..24C86E068291': 1476509588, 
>> 'bridge_id..24C86E068291': '24C86E068291', 'sensor_type..24C86E068291': 
>> 'firmware', 'usUnits..24C86E068291': 17, 'dateTime': 1476509588, 
>> 'usUnits': 17}
>> mapped packet: {'usUnits': 17, 'dateTime': 1476509588}
>> identifiers: id=24C86E068291&mt=firmware&line=0&count=1
>> {'bridge_id': '24C86E068291', 'sensor_type': 'firmware', 'sensor_id': 
>> None}
>> raw data: id=24C86E068291&mt=firmware&line=0&count=1
>> raw packet: {'dateTime..24C86E068291': 1476509632, 
>> 'bridge_id..24C86E068291': '24C86E068291', 'sensor_type..24C86E068291': 
>> 'firmware', 'usUnits..24C86E068291': 17, 'dateTime': 1476509632, 
>> 'usUnits': 17}
>> mapped packet: {'usUnits': 17, 'dateTime': 1476509632}
>>
>> Two things here...
>>
>>    1. I need some way to get ngrep or tcpdump to piece together the http 
>>    stream properly... I tried to use sed, but since sed operates on a line 
>> by 
>>    line basis - it is not very easy (if possible) for it to remove 
>> newlines...
>>    2. I seem to have found a bug with the version reporting... since it 
>>    reported a different version than what was in it the bridge went into 
>>    reprogramming mode and would *not* leave until it updated firmware 
>>    (undid the DNS Hijack, etc and let it re-update to 224 even though it was 
>>    already at that version)
>>
>>
>>

-- 
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.

Reply via email to