Second build sold out. Message will appear here when store is ready for third build ordering.

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

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?

  • edited March 2022

    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 | more or syslog.1 - yesterday's

  • Only 67.219.111.113 was not already on my Vultr radar, thanks for that one.

    67.219.96.0/20 added

  • jksjks
    edited March 2022

    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.

    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

  • edited May 2022

    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.

Sign In or Register to comment.