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 > figure I'd post it here in case you had any interest in incorporating it > into the main driver. I could see it having its advantages over the socket > based approach. > > I'm able to run this on a server already running a webserver or port 80, > the myacurite functionality still works, and (my favorite part) all > functionality is encompassed within the driver and nothing is required > outside of it (ie no ngrep, or tcpdump redirects. > > My formal OOP skills are a bit rusty, and I am sure the pcap stuff could > be incorporated into the architecture of the base driver better than I > have. My intent was to allow for both methods of operation, defaulting to > the socket approach unless a flag was specified. FYI, I didn't resolve the > standalone portion with its current form (initially I passed in the whole > options 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 "magic" is going to happen >> in a perl script that he is piping the stream into. His tcpdump and stdbuf >> all pretty much give the same stuff as the ngrep/sed stuff I have been >> trying to use (spread across multiple lines still) and then he has a perl >> script that glues them all together. >> >> I already wasn't super thrilled about having to run the helper script >> outside the driver to sniff the data, and I really want to avoid a third >> step... >> >> I am brushing up on my iptables... hoping that some combination of a TEE >> and a DNAT or REDIRECT can sniff off the relevant stream and change the >> dest ip/port. That then feeds into the interceptor driver as normal. If I >> cant get that to work, I am thinking about bringing in the libpcap stuff I >> had added to my hackulink driver and eliminating the helper script all >> together. >> >> If I got the 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... >>>> >>>> 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... >>>> >>>> have you tried radar's approach with stdbuf and strings? once the >>> fragments are reassembled, you should be able to send the data along using >>> curl. >>> >>> >>>> >>>> 1. 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) >>>> >>>> there is an (untested) fix for this at commit b27acc1 (interceptor >>> driver 0.13a) >>> >>> [Interceptor] >>> ... >>> firmware_version = 224 >>> >>> 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]. For more options, visit https://groups.google.com/d/optout.
