1.84 - DUC Needs Restart?

edited May 2017 in KiwiSDR Discussion
I couldn't connect to my KiwiSDR (remote), and noticed when I connected locally that 1.84 was running. I wonder if there could be a correlation here  - is it necessary to manually restart the DUC for the DDNS to work after an update?

Bjarne Mjelde


  • The DUC should be (re)started on a Kiwi server restart when the "enable" switch on the DUC section of the network tab is set to "yes". You can verify this by logging into the Beagle after a restart, doing a "ps ax" and looking for a process that says: /usr/local/bin/noip2 -c /root/kiwi.config/noip2.conf

    Since I don't use DDNS here I can't really test this 100% although I'm certain the DUC does start each time (I just checked with v1.84 again). But if there is a problem I'd of course like to know. Thanks.

  • I had to unplug the +Vdc from the KIWI and restart to let the LAN function again to see that
    the new version is 1.84.
    A cut of the messages file for the 1.84 part will follow asap.

  • We'll see when 1.85 comes along!

    Bjarne Mjelde
  • Tested again today - with the PC having been disconnected for several hours I tried to connect from remote - no cigar. Connected the PC to the Kiwi's network and a few minutes later I could connect.

    Bjarne Mjelde
  • jksjks
    edited May 2017
    Bjarne, help me to understand your network setup again please? You have this PC that can be connected to the same local network as the Kiwi OR connected to the outside world (Internet) via a different path so you can test actual incoming connections to the Kiwi. Is that right? I do something similar here by dropping my laptop off the local wifi/fiber network and teathering it to my cell, which I've in-turn taken off the local wifi and forced to use 3G/4G. So to my Kiwi connections from my laptop now look like ordinary outside Internet connections.

    One thing to remember is that the DUC sends an update of the Kiwis current public ip to the noip.com DDNS server on a fixed schedule. The default is 30 mins, but in v1.84 there is a menu option to reduce this to as little as 5 minutes. So when the Internet provider changes your public ip there is the possibility for a "dead" period until the next DUC update. This presumes your Internet provider is changing the public ip infrequently. Because this is a 3G/4G connection it is possible they are doing something weird. Like if there is no traffic for a while they drop the ip assignment and re-assign when traffic is active again. This would increase the probability of dead times. You'd have to keep track of the public ip addresses being assigned to see what's really going on.

  • I have just changed the DUC update to 5 minutes, and will do a server restart as well, so to replicate the situation and monitor over the next several hours. My setup is a 4G modem/router to which the KiwiSDR and a laptop is connected (via ethernet, the router's wifi is turned off). I use other PCs in the house, connected to another broadband solution, to access the Kiwi.
  • Here's what I did and found. Unconclusive. Log files attached.

    SERVER RESTART 00:50:49, see kiwisdr_log_210517_0130_1st_server_restart

    5 minutes
    DUC update enabled. I restarted with laptop disconnected from the 4G router. External
    units could not connect to the Kiwi from this point, up until 01:26:47 when I
    connected the laptop to the 4G router (local connection 10 seconds later and
    external connection 01:32.29).

    REBOOT 01:41:15, see kiwisdr_log_210517_0146_beagle_reboot

    I rebooted
    with laptop disconnected from the 4G router. External connection made at
    01:44:56, so all well.

    RESTART 01:53:27, see kiwisdr_log_210517_0158_2nd_server_restart

    I restarted
    with laptop disconnected from the 4G router. External connection made at
    01:53:27. Laptop connected to 4G router at 01:57:09.

    somewhat puzzled that the two server restarts produced such different logs. The
    entries are additions to the log created by the reboot.

  • The second restart shown in the second log doesn't have a message from the Kiwi server indicating what the public ip address is. This is not right. The Kiwi has to ask a service on the Internet for this information. That means this process didn't respond. It's unfortunate because I wanted to see if the public ip changed from what was obtained in the first restart.

    Another variable here is DNS propagation time. If your ip address has changed, even though the DUC has reported this fact to noip.com that doesn't mean a connection from your PC to the Kiwi using the DNS name (e.g. kiwixxx.ddns.net) will have the updated ip address immediately. There will be some delay for the DNS change to filter out from noip.com to whatever DNS server your PC is getting its DNS information from (most likely the 3G/4G provider).

    So this all gets back to how often the Kiwi's ip address is being changed by the upstream Internet provider. This will determine what ip the PC is trying to use and may explain why the Kiwi looks like it isn't responding. This information is outside the scope of what's in the Kiwi logs. We'd need to know what ip the PC is trying to use when a connection is attempted (e.g. use a "ping kiwixxx.ddns.net" on the PC). And also reliably know what ip the Kiwi has been assigned.

  • Thanks John. I'll have a word with my ISP about that. The strange thing though, was that after I reconnected the PC to the router's network (and assumingly its DUC sent an update), I could access the Kiwi. There are a few variables here I need to sort out.
  • Well, it would be better to have some real evidence of the ip assignment behavior before talking to your ISP. Although I guess you could ask them the general question about ip assignment policy. Do they say up-front that they'll assign you a static address but for more money? That used to be pretty standard in days past. You don't really need that necessarily unless their dynamic assignment policy is unworkable.

Sign In or Register to comment.