On Saturday, November 5, 2016 at 10:06:39 PM UTC-4, Brad Tucker wrote: > > Hey Matt, > > This is in syslog when the tcpdump chokes... > > Nov 5 18:58:55 weather weewx[2574]: interceptor: MainThread: parse failed > for > dateutc=now&action=updateraw&realtime=1&id=24C86E06B15C&mt=tower&sensor=00008384&humidity=31&tempf=81.4&baromin=29.28&battery=normal&rssi=2#012dateutc=now&action=updateraw&realtime=1^&id=24C86E06B15C&mt=tower&sensor=00012694^&humidity=48&tempf=71.9^&baromin=29.28&battery=normal&rssi=3^: > > dictionary update sequence element #10 has length 3; 2 is required > >> >>> there is the root cause - the ^ and #012 and double && indicate problems in the cgi string formatting. it is probably due to dangling characters at the end of tcpdump strings (like the p_ r_ and other trailing garbage we saw earlier in this thread).
you'll want to run the tcpdump and stdbuf part of the chain to see what makes tcpdump stick random characters on the end of the strings fwiw, i've been running the interceptor for months using the apache/nginx cgi proxy approach. i've been keen to get the tcpdump/tcpflow/xargs approach to work reliably for systems where you cannot run a proxy (and for another way to test). also, i'm giving some thought to integrating jerome's pcap implementation - as he points out, it is a cleaner approach - but it would still be nice to get the tcpdump/tcpflow approach to work. 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.
