Unnecessary, useless WF connection via Cloudflare VPN (WARP) [fixed in v1.622]
I noticed that users who connect via Cloudflare create additional, absolutely unnecessary WF connections, occupying channels. I checked it myself. It really is. Most likely, part of the problem is in the Cloudflare VPN itself. But, in theory, the limitation on ip should work? (1 ip = 1 connect).
Comments
The correct Zoom is in the WF connection and the correct frequency is in the RX1 connection, when connected via this VPN.
And further. If such a WF connection exists and all channels are busy, no redirect to the next sdr. The "camp" page opens. I remember for sure that, in addition to Cloudflare, there are also problematic VPN / proxy.
VPNs are relevant now, as some countries are blocking everything.
I had free time and I found out what was going on. Since there are a lot of http requests to open a site with kiwisdr (more than 40), VPN Cloudflare opens some of the requests from other ip. It turns out an interesting situation, described above. An unnecessary WF connection causes the redirect to the next kiwisdr to not work.
Since the audio, waterfall and extension all open separate web sockets I have code that "links" them to a single rx channel. The IP address and a millisecond-resolution timestamp from Javascript, which is the same for all web sockets, is used for the link matching. The timestamp is necessary to distinguish multiple connections originating from the same source IP address.
If Cloudflare is really altering the source ip address for the related web sockets then this scheme will obviously not work. I could simply match by timestamp alone, but that raises the risk of timestamp collision since the clocks are not synchronized across browsers/OSs. Although the vulnerability window is probably small.
I could probably add a second match against a session random number or GUID. But being careful to make sure the generator seeding doesn't result in the same pseudo random sequence being produced.
By the way, judging by the log, sometimes such connections are kicked as incomplete. And sometimes not. And then it's a big problem.
Now I have blocked the ip blocks from which such connections come. Otherwise, one user on the first sdr will not allow anyone to go to the next sdrs. Few people will find out that other sdrs are not busy.
Okay. I will work on this when I can. Right now I'm trying to get KiwiSDR 2 prototypes out for manufacture.
Yes. KiwiSDR 2 is more important.
I figured out a relatively easy solution (I think). So give v1.622 a try and see if it fixes the problem for you.
Its OK now. Tnx!
Okay, good. I don't think there should be any side-effects from the change. In particular I made sure legacy connections were not effected (e.g. kiwirecorder).
The way I did it was to make the server-side be the source of the timestamp and communicate that to each client before the web sockets are established. There is such communication already that passes the software version number so the client so they can check the integrity of the javascript files they receive.
The server can guarantee the timestamp is monotonic. So it should be okay now to disregard the source IP address when matching audio, waterfall and extension web sockets to a particular receive channel (i.e. rely on the timestamp alone). That's the theory anyway. Much more than you wanted to know! lol