Local Access Issue [the bot / IP blacklist thread]
edited June 2022 in Configuration and Operation
Recently I've noticed that every time I try to access my SDR from the local IP address, it sends me to the All Channels are busy page regardless of whether they're all full or not. I thought it may have been a software issue so I upgraded to 1.498 this morning but nothing changed. When I access it through my public link, everything appears normal. Attached is a snip of what I get when I try accessing it via the 192.168.XXX.XXX address. You can see that all channels were empty at the time. Any ideas?
What happens when you hit reload, or (Windows) control+F5?
It reloads the page but doesn't drop me into a channel. If I connect to it in another tab using the public link, it updates to show that that particular channel is in use and 3 others are empty but still doesn't drop me in there. This is the same if I hit reload in the Window itself or hit the browser refresh button.
It's happening in Chrome, Edge, and FireFox so it doesn't appear to be a browser issue either.
This just started happening over the last week or so as I typically use the local address to connect to it.
OK and what does the admin log show as the connecting IP when using the using the public link, and then the private?
By public address do you mean the address as would be listed on rx.kiwisdr.com? and private IP as an IPv4 address like 192.168.0.1:8073?
on the client what does "nslookup [public link]" return? - does it return an IPv6 and IPv4 address?
I can only connect to the non waterfall channels on mine. It is in 8CH mode. This is both local and remotely. Once the 6 audio only channels are full, it puts me on the que page for camping.
Update: A beagle reboot from the admin seems to have cleared my issue. Maybe not the same issue, but I did end up on the all channels are busy page, while the two waterfall channels were available. This is with local connection, and two channels set for password protection, which were in use. The reboot fixed my non waterfall channel only problem.
What does the admin log show in the working and non working connection?
Second question is this a public Kiwi, or at least one with a port forward so that is could be found by scanning?
When connecting locally, the log shows my local IP, the 192.168.X.X address.
When connecting via kiwisdr.ku4by.com, the log shows my public IP address.
NSLookup only returns an IPV4 Address for my public address.
One difference I am seeing is that when I login from kiwisdr.ku4by.com, the log shows SND Allowed whereas when I log into it locally, it shows MON Allowed. Is this a Monitor mode?
Yeah, what Stu said: to debug this I need to see the log messages from the admin log tab from when the local user tries to connect. Only then will I know exactly what it is doing. They will look like this (edit out the appearance of your user password, if any):
Also, what happens when you add the URL parameter "nolocal" ? This is a way to make a connection from the local network look like it's not. I use it for debugging.
Nolocal made no difference and should be included in the following:
"When connecting via kiwisdr.ku4by.com, the log shows my public IP address."
That's a little unusual, many router/firewalls won't normally do that by default.
I wonder if your router is dual stack and hijacking the internal v4 traffic, I suppose you could disable IPv6 for a test (from experience you have to disable it on all interfaces or Windows tries the dead links before trying a live working v4).
Another option is that something is tying up the connection but not showing on the logs, to test that (tin foil hat theory) disable port forward on the router then reboot the Beaglebone.
I'm not local, but in this very moment (~20:03 UTC), I see also the busy page, with only one entry (10.000 KHz) and all the others empty.
It's always shown my public IP address.
Something I just noticed in the log is that the SDR does think all channels are busy. I currently have one connection to it but here is the log entry.
No idea why it's only busy for the SNR measurement and local connections but that is where I'm at right now.
Yeah I'm getting that now too but I've been able to get in all day until now.
I just saw a few more connection attempts and they are all saying MON Allowed. The only thing I haven't tried on this end is to actually power down the kiwi and see if letting it sit for a few minutes helps is out. I'm just not sure if I'll be able to get back into it after that.
From that log I can tell all those connection attempts are dropping into monitor mode immediately because all channels are busy (what you just said). We need to figure out who (or what) is tying them up.
Use the "dump" button on the log tab and then cut/paste the log messages here that look like the following:
Also, that log showed your Kiwi up for over 6 hours. How is it after you restart? (use restart button on admin page, control tab)
I X'd out my public IP but have no idea who the 18.104.22.168 (Appears to be Chinanet) is and why they're not showing up in the monitor. I'll wait for your response before I blacklist it to see if anything changes.
Okay, this is super interesting.
First of all, it's clear these are bot connections not using the full Kiwi API. That's why they appear as "waterfall only" connections in the dump information with no corresponding sound connection. Like how Marco and linkfanel poll to get their SNR data.
One bug is that there are never supposed to be blank entries in the connection status panels even for a partial API connection. That's what is misleading us into thinking there are free channels. So I need to do some work there.
Something I'd like to know: If you connect as admin, on the status tab, on the connection entries (RX0 RX1 ...) do you see a round "kick" button at the end of each line? If so, could you try clicking it to free up a channel and then quickly trying to make a local user connection? Do it work then? Depending on how often the bot is hitting you, you might have to try this several times. Or kick a couple of channels instead of just one.
Besides using the dump button, the other easy way to tell which channels are in use is to look at any log message, e.g.
0123after the uptime? That shows the current channel occupancy. It will be
01234567for all channels busy on an 8-channel Kiwi etc. The blank space after it holds an indicator of which channel a log message belongs to (some log messages don't belong to any channel). So for example
means channels 0 & 1 are occupied and the "arrived" log message belongs to channel 1.
I'd still be tempted (as long as it does not break logs jks is looking for) to
"disable port forward on the router then reboot the Beaglebone." as I said before.
My assumption is that it will be fine then get tied up again about ten minutes after port forward re enabled.
The Admin Status Tab only shows my one active connection to the kiwi. No entries or Kick buttons on the other 3 receivers which is what began this confusion for me.
Thanks for the log info, I'm not really proficient in the logs.
So should I just blacklist the bot's IP address and wait for the next one?
Thanks for that. I need to figure out how they are evading the connection detection so I can fix it. No kick button gives me a big clue.
That detail about the logs isn't documented anywhere 🙄 so I though I'd mention it.
Yeah, go ahead and block them. That ip is not in a cloud provider range. So I can't really add the entire 182.150/16 block to the download blacklist because it might deny legit users.
Maybe using "Yes" on "Prevent multiple connections from the same IP address?" on the Network Admin tab will be helpful for prevent full exhaustion of all channels from one bot.
Rgr. I added the IP to the black list and then tried a Beagle Reboot but the reboot didn't work. Nothing happened. I then hit the restart server button and that restarted the server. Now I'm just waiting to see what happens next... 😂
I had that set in the past, not sure why it changed. Also, I noticed after the restart that my local blacklist was empty???
I'm not sure if it is possible to have a stale admin connection so you think you have added to the local blacklist but it has not been successfully appended, if you restarted at that stage it would just show the real situation.
I'd be tempted to open an SSH connection to the local Kiwi so you can use commands directly, would not like to be denied a reboot while there are remote connections.
@rz3dvp Thanks! Kiwi code complex + me getting old = I can't even remember my own stuff, lol
A reboot takes a while. There is a built-in 30 sec delay after Linux reboot before the Kiwi server comes up to allow NTP et al to settle down.
Don't know why your local blacklist would have been cleared. Shouldn't happen..
Yeah, Stu's right once again. May times during development I have restarted the server from an ssh window and then began typing stuff into an open admin page, which it happily accepts, and then wonder why my changes don't seem to do anything. Eventually I figure out I needed to refresh that admin page to reestablish a server connection. I should probably actively detect this situation..
Well it's been about 6 and a half hours since I re-added that IP to the blacklist and so far so good. As far as I can tell, the kiwi never rebooted after I hit the button but it did restart after I hit the restart server button so I'm not sure about the stale Admin tab but I'll try rebooting again in the morning and see what happens.
Thanks for all the help!
@KU4BY The stale admin connection is cleared (most simply) by closing the local browser and reopening it's is just a browser session that needs to be refreshed.
I prefer to make it prompt for a password even if local then I know it really did just reconnect because it challenged for the password if I just Ctrl-F5.
Admin - Security - 'User auto-login from local net even if password set?' set to 'NO'