Admin access hosed after power outage

For almost a year I've been running a KiwiSDR/BBAI which is devoted to supporting WsprDaemon. From my laptop using wifi on the same network, I could connect as admin at, and also connect to the single unallocated radio receiver (used for testing purposes) at

Today we had a power outage for a couple of hours. When power came back up, I restarted the wsprdaemon Linux host, and soon found that wspr spots were being posted normally on the external public archive site.

I also find that I can still connect to the KiwiSDR normally as a user at

However, if I try to connect as admin at, I see an error from the KiwiSDR:

"No admin password set. Can only connect from same local network as Kiwi.Client ip ="

I think that when I was initially setting up and testing the KiwiSDR/BBAI it may have had a local ip address of, but for a long time since then it's been In any event, I'd think it would recognize me as being on the same local network, as I can access the KiwiSDR as a user at

Any suggestion on how I can restore admin access to the KiwiSDR when I need to access it from my local laptop via wifi?


  • Try power cycling the Kiwi. If after a power failure the Kiwi comes up before a slow router that serves ip addresses via DHCP there can be synchronization problems.

  • Frank's Kiwi is at address but it requires admin access from a browser at So it appears the Kiwi thinks it admin LAN is not in

    Similarly, I can't ssh to his kiwi because no password is set and I don't know the serial number of his Kiwi, which I think is the backup password

    I have one of six Kiwis at KPH which rejects logins with a similar message, except at KPH there is an admin password set so I can log in to it.

    So it appears that Frank's Kiwi has identified a different network interface as its LAN. What is the algorithm used by the Kiwi to determine its admin LAN?

  • jksjks
    edited February 2023

    I've never been able to replicate the failure here. But there is some evidence that what's happening is this: The Kiwi is set for DHCP mode. After a power failure the Kiwi comes up long before the DHCP server of the router. The Debian Ethernet interface code times out and assigns a "self-assigned" ip address (e.g. 169.254.x.x). The Kiwi code uses this as the "local" ip address.

    Presumably, when the DHCP server comes up, the Debian code gets the DHCP assignment and assigns a second ip address to the Ethernet interface (it's perfectly legal for network interfaces to have multiple ip addresses and subnets). That's why you can subsequently connect to e.g. 192.168.x.x even though the Kiwi thinks its official local ip is 169.254.x.x

    But this is just a guess as I can't replicate the behavior. And explains why a Kiwi power cycle (not simply a Kiwi server restart) will clear the problem. The Kiwi code deliberately delays startup for 30 seconds after a Beagle power up to let things like DHCP and NTPd settle. But apparently this is insufficient in some cases.

  • edited February 2023

    Try power cycling the Kiwi. If after a power failure the Kiwi comes up before a slow router that serves ip addresses via DHCP there can be synchronization problems.

    Thanks, that makes sense, and that fixed it.

  • I think John is spot on. In my experience,. once Debian/Ubuntu distros self-assign an IIP address to an interface, they never run DHCP to try to get a different address. Even cycling its interface from the ethernet switch doesn't seem to stimulate a Debian/Ubuntu computer to look for a new address. Only a reboot/power cycle seems to run the DHCP client service to get an address from a server.

    This is unfortunate and I think unnecessary behavior by Debian. Perhaps it could be avoided by having Kiwi SW down/up the LAN interface periodically when the only IP address of that LAN interface is one self-assigned 169.254.x.y address

Sign In or Register to comment.