jks

Today's v1.337 update adds waterfall filtering (averaging). The filtering methods and adjustments parallel those used for the spectrum filtering, although the range of slider values is slightly different based on practical experience. The waterfall and spectrum filtering are independently adjustable.

Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:

"--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.

"--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.

Sample output. See the Makefile for command line examples.

python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
5.9 meas/sec

Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:

"--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.

"--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.

Sample output. See the Makefile for command line examples.

python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
5.9 meas/sec

Okay, today's v1.336 release now applies the ip blacklist to incoming connections made via the proxy. Because the filtering in done in the Kiwi server instead of iptables a Kiwi log entry is made when the blacklist filter hits. iptables is still used for non-proxy connections for performance reasons.

The "ipt" shell alias now automatically includes the "-v" argument so you can see the packet counter for the iptable filtering rules. I.e. an incrementing packet count means the blacklist filter has been hit. Use "iptz" or "iptc" to clear the counters. These aliases can be used on the admin page console tab.

You're using the proxy? Yeah, I realize now that none of the blacklist stuff will work if you're using the proxy.

This is something I'll have to fix. The reason I used iptables is that it's very efficient at filtering. I can't do nearly as well in the Kiwi code and I didn't want to impose a penalty on everyone since there is currently one default blacklist rule on every single Kiwi.

But when the proxy is in use from the Kiwi's perspective all the connection attempts appear to be coming from the single proxy ip (by definition). The reason you still see the actual user's ip in the log messages is that there is an extra step to uncover the true ip address when the proxy is in use. But this step is not visible to iptables. So for the proxy case I'm going to have to find an efficient way to filter in the Kiwi code..