jks

HTTPS on the Kiwi is not happening. Too many implementation/performance problems. We had the barroom-brawl about this years ago. Nothing has changed. Except that I'm less inclined than ever to work on stuff I don't perceive as important/interesting.

Maybe someone else will do this and deliver a 100% tested, validated patch. But history says otherwise.

Yep. Currently the ITU region setting only has effect for defining the NDB band bar and the 80/75m band overlap (which has problems of its own). It is not used for 160m (Fstart), 40/41m, 30m (Fstop) etc.

Is this Kiwi available from the Internet so I could connect (I don't need any passwords) and take a look?
"Being available" doesn't mean it has to be a publicly listed Kiwi. Only that port 8073 on your router is set to map to the Kiwi and that you can tell me your public ip address.

Oh yes, and based on recent experience I guess we now have to ask you: is your ISP Comcast?

Also, is there WiFi involved anywhere in the path between your Kiwi and the machine running the browser? Does the same thing happen on some other device like a tablet, cellphone etc?

I know this sounds like entry-level tech support, but seriously, try power cycling all your network equipment. I used to have a WiFi bridge connection between my development Kiwis and my laptop due to the physical setup here. About twice a year my Internet router or the TP-Link bridge would lose its mind and the ping times randomly go to several seconds for no apparent reason. Power cycle fixed it, but only after half my hair had already been pulled out trying to find out what was wrong with my code. Needless to say I found a way to run an Ethernet cable.

Wow that's a clean VLF/LF/MW spectrum from that 60m dipole. You must have ditched/upgraded all the SMPSs at your place. It's funny to see Jim Creek sitting +20 dB over a flat spectrum. Did you see that you have a beeper with a little bit of frequency wander on 176.65 kHz? I've always wondered if these were leftover LoJack systems before they moved to VHF. Maybe just NFC/ISM stuff? Will never know I suppose.

Thanks Brendan and everyone who contributed. Documenting these investigations is so important because now when someone reports a vaguely similar problem far in the future a little alarm bell will go off in the back of our heads and we'll ask "Oh, does your ISP happen to be Comcast? ".

but it still doesn't show up on the map

Which map? rx.linkfanel.net (aka map.kiwisdr.com)? Or the map section of sdr.hu?
If your Kiwi is listed on kiwisdr.com/public (aka rx.kiwisdr.com) then it should appear on the rx.linkfanel.net map since the kiwisdr.com listing site is where linkfanel.net gets its data from currently.

As you point out sdr.hu is an entirely independent (and now optional) registration path. It is quite possible that there might be an intermittent connection issue with sdr.hu, yet people are still finding your Kiwi via {rx,map}.kiwisdr.com rather than saved browser history.

What exact error message is sdr.hu returning in the log when the registration attempts from your Kiwi fail?

Update: I'll answer my own question. Your Kiwi is reporting this:

Wed Apr  1 01:57:01 00:49:07.685 ....      sdr.hu registration: DOWN

So that's a problem we've seen from sdr.hu before. And it's something Andras will have to fix since we have no control over his site.

At the moment I can't connect to http://71.197.249.8:8073
It just times out. If you hover over your purple icon on rx.linkfanel.net it says "Last online: 7 hours ago".

So I think you've got incoming connectivity problems. Now I was able to get in fine an hour ago to check your log messages. So it hasn't been completely down. On the admin "network" tab if you click the "check open port" button do you get a status of "YES" to either of those paths? That button makes a request to kiwisdr.com to check connectivity to your Kiwi (in the incoming direction) using both the DNS-based and IP-based paths.

Re: links on kiwisdr.com pages to forum for more info about password changes. You're absolutely right -- these links are totally broken. Were they ever set correctly in the first place? I don't know. It almost looks like I had set a placeholder link and then forgot to go back and edit the content. I'm always pretty good about checking links in hand-edited html because they are so easy to get wrong. Anyway, should be good now.

If you haven't already started making customizations to your Kiwi configuration and you want to try the regular install procedure then just do this: Re-flash to v1.2 using your sd card (with the Ethernet disconnected just for good measure). Then after the re-flash powers down remove the sd card, reconnect Ethernet and power up.

You should be able to ssh in using the root account and a blank password since the v1.2 image will be running for the hour it will take for v1.384 to be installed. Upgrading from v1.2 doesn't have a nice log file you can follow to see the process. But you could do a successive "ps ax" (or your favorite variant) and get a rough idea of what's going on. There will be an initial period of apt-get activity as many Debian packages are installed, the largest being the Clang compiler suite. Eventually clang will get invoked on the Kiwi sources and that will take the balance of the time. Things will be very slow during the compilation of the DRM sources as they are written using true, extensive C++ constructs which cause the compiler no end of heartburn (me too as I was trying to wade through that stuff, lol). At the very end a bunch of time is spent coalescing all the data files (.js, .html, .jpeg et al) into the in-memory image file which is done via a pearl script that generates these huge inline C data files. After that the usual "make install" behavior that moves all the binary files into place.

Then a reboot to (hopefully) v1.384 when the one-time password changes will be applied where the root password will be set to the Kiwi serial number since there was never a point in this whole sequence where a Kiwi admin password was set manually. Same for the "debian" user account password.

I have done this procedure a number of times now and it's always worked. So I'd be keen to understand any case where it doesn't.

Cheers,
John

Re: links on kiwisdr.com pages to forum for more info about password changes. You're absolutely right -- these links are totally broken. Were they ever set correctly in the first place? I don't know. It almost looks like I had set a placeholder link and then forgot to go back and edit the content. I'm always pretty good about checking links in hand-edited html because they are so easy to get wrong. Anyway, should be good now.

If you haven't already started making customizations to your Kiwi configuration and you want to try the regular install procedure then just do this: Re-flash to v1.2 using your sd card (with the Ethernet disconnected just for good measure). Then after the re-flash powers down remove the sd card, reconnect Ethernet and power up.

You should be able to ssh in using the root account and a blank password since the v1.2 image will be running for the hour it will take for v1.384 to be installed. Upgrading from v1.2 doesn't have a nice log file you can follow to see the process. But you could do a successive "ps ax" (or your favorite variant) and get a rough idea of what's going on. There will be an initial period of apt-get activity as many Debian packages are installed, the largest being the Clang compiler suite. Eventually clang will get invoked on the Kiwi sources and that will take the balance of the time. Things will be very slow during the compilation of the DRM sources as they are written using true, extensive C++ constructs which cause the compiler no end of heartburn (me too as I was trying to wade through that stuff, lol). At the very end a bunch of time is spent coalescing all the data files (.js, .html, .jpeg et al) into the in-memory image file which is done via a pearl script that generates these huge inline C data files. After that the usual "make install" behavior that moves all the binary files into place.

Then a reboot to (hopefully) v1.384 when the one-time password changes will be applied where the root password will be set to the Kiwi serial number since there was never a point in this whole sequence where a Kiwi admin password was set manually. Same for the "debian" user account password.

I have done this procedure a number of times now and it's always worked. So I'd be keen to understand any case where it doesn't.

Cheers,
John

Okay, there seems to be a couple of issues going on here.

1) I got screwed over by dropbox. The v1.383 img.xz file has the correct filename, contents and SHA on my laptop dropbox directory. But even after a dropbox sync a fetch of that file from dropbox returns the contents of the previous v1.46 img.xz file (as pointed out by Yuri) for reasons I don't understand. I used the usual procedure to get a dropbox file URL to insert into various places (e.g. Kiwi website, kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh script, etc.) But I didn't actually check it because it's never failed before. I think it's okay everywhere now with one exception: The file Beagle_SDR_GPS/tools/kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh in the distro on your Kiwi will have to wait for an update to a v1.384 release to be corrected.

2) Jeff mentions he had to manually install a github commit (e90f87d) which is one commit (91cbe70) before the full v1.383 release. But that last commit has to do with the changes to the flasher script and I can't see how it would influence the normal running of the system in any way. But I also have one other complaint in email of an update to v1.383 failing (no details known yet). So more investigation is needed. [update: it was just filesystem corruption that prevented an update from v1.374 to v1.383, and after a manual rebuild it now works fine]. I always test the full release on a bunch of beta Kiwis of different configurations to try and reduce the chances of bricking the world.

The password changes are bit subtle. You have to read the explanation topic on the forum carefully to decide if the password has been changed to the Kiwi admin password (if you have configured one) or the serial number of the Kiwi (written in black marker pen in the white box on the Kiwi PCB, also in the "network" tab of the admin page if you can get there).