Log location to find log of bots... <FOUND>
While logged in via ssh, where do I find the whole log. The one that is partially display on the admin log page
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
Comments
What the system log?
/var/log/messages or syslog
AFAIK the logs are in /var/log/ so I often just
"tail-f /var/log/messages"
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
139.180.147.173
158.247.235.18
167.179.65.161
208.85.22.113
216.238.81.138
66.42.119.248
67.219.111.113
70.34.214.223
95.179.191.34
@WA2ZKD Today's KiwiSDR logs (under root or sudo)
cat /var/log/syslog | grep kiwid | moreor syslog.1 - yesterday'sOnly 67.219.111.113 was not already on my Vultr radar, thanks for that one.
67.219.96.0/20 added
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.cjsonto 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.Use a website like: https://www.ipaddressguide.com/cidr to check that your CIDR produces the correct IP low-high range.
Thanks
@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)
208.85.22.113 [208.85.16.0 - 208.85.23.255, 208.85.16.0/21, The Constant Company, LLC (CHOOP-1), AS20473]
216.238.81.138 [216.238.64.0 - 216.238.127.255, 216.238.64.0/18, The Constant Company, LLC (CHOOP-1), AS20473]
66.42.119.248 [66.42.64.0 - 66.42.127.255, 66.42.64.0/18, The Constant Company, LLC (CHOOP-1), AS20473]
67.219.111.113 [67.219.96.0 - 67.219.111.255, 67.219.96.0/20, The Constant Company, LLC (CHOOP-1), AS20473]
70.34.214.223 [70.34.192.0 - 70.34.223.255, 70.34.192.0/19, The Constant Company, LLC (CHOOP-1), AS20473]
95.179.191.34 [95.179.190.0 - 95.179.191.255, 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/139.180.147.173
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 158.247.235.18 seems the most active in this period.
173.199.70.39 AAA =156
45.32.124.96 AAB =82
144.202.76.200 AAC =639
155.138.156.239 AAD = 296
158.247.235.18 AAE = 806
149.28.38.97 AAF = 470
140.82.23.11 AAG = 750
70.34.214.223 AAH = 528
45.77.186.242 AAI = 272
167.179.65.161 AAJ = 542
216.238.81.138 AAK = 414
66.42.119.248 AAL = 475
139.180.147.173 AAM = 466
208.85.22.113 AAN = 236
95.179.191.34 AAO = 258
67.219.111.113 AAP = 182
149.248.7.185 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.
140.82.23.11
167.179.65.161
216.238.81.138
66.42.119.248
67.219.111.113
CHOOP (Constant) and VULTR are the same
"CHOOP (Constant) and VULTR are the same"
That is why I mentioned AS20473
https://ipinfo.io/AS20473
@Powernumpy
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.
Jimo
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.
Jimo.
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.