It looks like you're new here. If you want to get involved, click one of these buttons!
While logged in via ssh, where do I find the whole log. The one that is partially display on the admin log page
What the system log?
/var/log/messages or syslog
AFAIK the logs are in /var/log/ so I often just
Not what you are asking?
the log of kiwirecorder.py connects that I see in the admin webpage log
I found them... dunno how I had missed them before
so here's the bots nagging me
@WA2ZKD Today's KiwiSDR logs (under root or sudo) cat /var/log/syslog | grep kiwid | more or syslog.1 - yesterday's
cat /var/log/syslog | grep kiwid | more
Only 188.8.131.52 was not already on my Vultr radar, thanks for that one.
If you guys want to help me out you could do a whois of those IPs and figure out the correct CIDR I need to add to the downloadable blacklist.
You have to be extremely careful doing this analysis. The whois will often list multiple IP ranges. You have to use the latter one (most narrow CIDR) specifically allocated to the end user. You also need to check the CIDR isn't already partially or completely covered by an existing blacklist entry. Do curl -s kiwisdr.com/ip_blacklist/ip_blacklist2.cjson to see the current file. Sometimes an existing entry's netmask needs to be enlarged rather than adding a new entry. We need to keep our iptables as efficient as possible.
curl -s kiwisdr.com/ip_blacklist/ip_blacklist2.cjson
Use a website like: https://www.ipaddressguide.com/cidr to check that your CIDR produces the correct IP low-high range.
@jks Hi John, do you have any information about this bot? It appears to be the same software from different IPs and countries using kiwirecorder for frequencies starting at 58.59kHz and ending at 28125.00kHz. Maybe these people contacted with you before the start?
I can't help feeling if this was a legitimate use the source would contact John and declare intention and keep him updated.
I've been banging on about Vultr for at least a year so they surely must know they are being specifically blocked due to "activity not consistent with open and fair use".
I'll go back over my router blocklists but these seem obvious bot sources from recent activity (Jim)
184.108.40.206 [220.127.116.11 - 18.104.22.168, 22.214.171.124/21, The Constant Company, LLC (CHOOP-1), AS20473]
126.96.36.199 [188.8.131.52 - 184.108.40.206, 220.127.116.11/18, The Constant Company, LLC (CHOOP-1), AS20473]
18.104.22.168 [22.214.171.124 - 126.96.36.199, 188.8.131.52/18, The Constant Company, LLC (CHOOP-1), AS20473]
184.108.40.206 [220.127.116.11 - 18.104.22.168, 22.214.171.124/20, The Constant Company, LLC (CHOOP-1), AS20473]
126.96.36.199 [188.8.131.52 - 184.108.40.206, 220.127.116.11/19, The Constant Company, LLC (CHOOP-1), AS20473]
18.104.22.168 [22.214.171.124 - 126.96.36.199, Vultr Holdings LLC Amsterdam, AS20473]
Some of the first ones are a bit more complicated to extract the right CIDR, I'll view after work E.G. https://rdap.apnic.net/ip/188.8.131.52
As my router has IP ranges blocked, it is quite easy to see the logs of IP's active from those ranges. Blocking IP's is a fairly agricultural way to reduce the traffic on a short term basis but it has at least highlighted the problem.
To see what actual IP addresses seem active in these ranges I replaced with a placeholder and counted some log entries since last Sunday 184.108.40.206 seems the most active in this period.
220.127.116.11 AAA =156
18.104.22.168 AAB =82
22.214.171.124 AAC =639
126.96.36.199 AAD = 296
188.8.131.52 AAE = 806
184.108.40.206 AAF = 470
220.127.116.11 AAG = 750
18.104.22.168 AAH = 528
22.214.171.124 AAI = 272
126.96.36.199 AAJ = 542
188.8.131.52 AAK = 414
184.108.40.206 AAL = 475
220.127.116.11 AAM = 466
18.104.22.168 AAN = 236
22.214.171.124 AAO = 258
126.96.36.199 AAP = 182
188.8.131.52 AAQ = 28
@rz3dvp Maybe these people contacted with you before the start?
No, I've never heard from these people. The main problem is that their script/program makes multiple, simultaneous or repeated connections on the same Kiwi, tying up all the receive channels. And seems to sample the same portions of the waterfall while doing this. Like their script has a bug or something. If they behaved better we probably wouldn't even notice them. Just like no one notices the 30 second TDoA sampling connections.
CHOOP (Constant) and VULTR are the same
"CHOOP (Constant) and VULTR are the same"
That is why I mentioned AS20473
Is there a log for kiwirecorder.py or any kiwirecorder.py error messages.
I am running kiwirecorder.py on a Raspberry Pi. All works very well.
I ran kiwirecorder and just nothing happened, then I noticed that my Kiwisdr was not running but no error message from the Kiwirecorder.py or at least I cannot find where is could be.
Thanks for you help.
I think seeing the Kiwi log rather than the recorder would be good, to make sure it really is an issue caused by kiwirecorder.
By "Kiwisdr was not running" I don't understand if you mean the recording did not start, if there were other sessions etc.
As the recorder is using a connection coming in like a normal user, but will present as a data connection, the Kiwi should log pretty well what connected, and why it did not complete (not enough channels allowed for data type connection?)
@Powernumpty OK. Thank you.
Ok, so there is no logging coded into the kiwirecorder.py
I need to check the Kiwisdr log to see if the kiwirecorder.py connected or didn't connect and if there was a delay in connecting to Kiwisdr. The KiwiSDR log will give some info.
Thanks. I shall try that.
I do now see that there is a log switch in the kiwirecorder.py as one of the options.
--log=info or --log=debug or ...
I'll add this to the kiwirecorder.py and play around.
I see that --log=info gives:
2022-05-23 16:53:55,202 pid 17342 started sound recorder 8
2022-05-23 16:53:55,203 pid 17342 Failed to connect, sleeping and reconnecting error='[Errno -2] Name or service not known'
So the kiwirecorder.py can tell you if fails for connect to the kiwisdr.
It just seems to go on trying indefinitely.