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.
