LAN is OFF KIWI needs restart after last update

ic8pofic8pof
edited May 2017 in Problems and Issues
HI All.
Does it happen only to me ?
It happens that after a switched OFF state being daily or after some days on starting the KIWI_RX it goes ON ,
the LAN revives with the socket leds blinking then the first blu led on the KIWI's left blinks and the LAN is OFF.
Need to restart OFF-ON it manually.
That is happening after the last updates (last is 1.77)
For the long period without updates , during the 1.64 or 65 the KIWI started always OK, but happened also some time ago after an update
 Is this a normal operation mode or some problem in my unit ?

That means that I have to integrate a KIWI_Restart plus a webcam to see what is going on in the remote site.

73
Phil IC8POF

Comments

  • KA7UKA7U
    Phil,
    I've had a similar issue since the recent updates. A unit with a static IP does as you say, but a unit with DHCP reboots itself over and over. I find it necessary to pull the power, wait a minute, and plug the power back in to restart the KiwiSDR. That wouldn't be practical at a remote site. If you login with SSH to the KiwiSDR and run the following commands:
    $: cd /var/log
    $: cat messages |grep remoteproc1
    $: cat messages |grep "Apr 23 00:23:52"   # Where "Apr 23 00:23:52" is replaced with a date from the repeating listings.

    You can see the boot sequence and the errors leading up to a stall or reboot. 

    I think this caused by a power supply voltage drop, but I'm not certain about that. I'm currently using 5vdc @ 2.1amps and I get these results on reboots/restarts since version 1.77
    Ron

  • WA2ZKDWA2ZKD
    One option if you can it to lock your router to use the same IP# to the kiwi MAC and then the kiwi can dhcp and get the same address
  • ic8pofic8pof
    HI tnx for the suggestions, I will try to ssh asap.
    My modem-router is an old Netgear DG834 and has the DHCP ON and I think it is stil working fine....
    >ZKD: not sure about your suggestion. I use already a fixed IP for the KIWI, I have red somewhere the option to set the MAC into the router instead of the IP but not jet used.
    As written before: when the LAN is OFF no connection is possible to the KIWI-rx.

    >JKS: my PSU is a 22Vdc/1.5Amp and I reduce to +5 via a lm317 plus a fan to get the heather cooler.
             It is a waste of energy I know (I have dozens of little trafo-psu but nothing with a steady +5 or +9),
             it was my only choice from the KIWI start and am waiting (QRL is more important) to build a
             psu with a new 8Vac/1.8Amp trafo.
    73
    Phil


  • WA2ZKDWA2ZKD
    Phil..

    I let the Kiwi/BB use DHCP as that is the default. Then in my router, I set it such the router "locks" the relationship of the Kiwi/BB's MAC address to IP#n.  That way, the Kiwi/BBwill do a DHCP request and always get the same number.

    -Jim
  • jksjks
    edited April 2017
    Phil, I looked at the Debian /var/log/messages file you sent me in email. Except for ONE case where Debian started the Kiwi process too early everything looked fine. In that one case starting the Kiwi server early caused the Kiwi code to think the Ethernet was down because it hadn't been initialized yet. But I only saw this ONCE in the log. Everything else looked perfectly normal. I don't know why Debian would start it early in that one case. That is definitely a problem. But it is not related to anything that has changed in any of the recent releases.

    Ron, if you have a situation where your Debian reboots or Kiwi server restarts (important distinction for me) over and over when running DHCP I definitely want to understand that. Please send me a complete /var/log/messages file or allow me to ssh in to your Kiwi and have a look.

  • WA2ZKDWA2ZKD
    doesn't Debian have a wait for network option at boot?
  • KA7UKA7U
    John,
    I have sent you a message containing the link to a tar.gz containing all the logs. If you need to log into one of these KiwiSDR units, let me know and I'll setup a port forward for you.
    Ron - KA7U
  • ic8pofic8pof
    OK John abt the messages file.
    Jim ZKD makes a strong observation abt Debian waiting\or-not for the LAN connection.
    Let us see what the further development will bring in such small super box.
    73
    Phil
  • jksjks
    "doesn't Debian have a wait for network option at boot?"
    It does and it is:

    [Unit]
    Description=kiwi daemon
    After=network-online.target time-sync.target

    But I'm looking at what I can do to improve this. Maybe I should be waiting for multi-user.target and then delaying 10 seconds or something to let things settle down further.

  • jksjks
    edited April 2017
    Looks like I have this already unless I'm doing something wrong. The complete kiwid.service file. See multi-user.target at bottom:

    [Unit]
    Description=kiwi daemon
    After=network-online.target time-sync.target

    [Service]
    Type=forking
    ExecStart=/etc/init.d/kiwid start
    ExecStop=/etc/init.d/kiwid stop
    Restart=always
    RestartSec=10

    [Install]
    WantedBy=multi-user.target

  • KA7UKA7U
    I have worked with this for a time now and all is quiet and operating as it should here. So a review of the problems. The KiwiSDR has operated here for quite some time without any boot problems, and then it seemed after version 1.77 or 1.76 it started having a problem starting. It would boot and then reboot. If the KiwiSDR was set for static IP it would boot and seem to lock up and not be network accessible. I have 2 KiwiSDR units and both behaved the same way. So I changed the 5vdc power source to use a battery with 5vdc @2.1amp outputs and I still had some problems with reliable cold boots. If a unit went into a reboot situation, it would stay in that loop until I removed the power, waited for a time and then reapplied the power. Looking at the logs, I wondered if I had another problem, so I checked the network connections. I found that the transmit side of the network connection was intermittent and many errors. It was a bad connection in the RJ-45 connector that fed a switch that served the equipment in the radio shack. After that RJ-45 connector was replaced the performance of all the network equipment was greatly improved on the transmit side. The KiwiSDR units both now start from a cold boot as they should. Additionally a DSL speed report improved from 0.15Kb to 1.9Kb on the upload.

    So what is the conclusion? Coincidence concerning the version numbers and the faulty RJ-45? Or does the new versions after 1.76 require more current on a cold boot? Or did the power supplies fail to provide adequate current due to some internal change on the power supplies? Or is it some combination of the above? 

    I'm going to venture that it is very important to have a 5vdc supply that holds 5vdc up to 2.1 amps without a voltage drop. It is very important to have a good network connection from the KiwiSDR to the router. As the months go by, the condition of the system and the network can change due to mechanical motion and corrosion. So the first thing I'm going to check is the power, and then the Network. Last thing I'll check is the KiwiSDR, because as near as I can tell the little unit is nearly "bullet proof".
    Ron - KA7U
  • jksjks
    edited April 2017
    Closer analysis of Phil's message log and some experiments have revealed a few things.

    1) In the kiwid.service file above the "After=time-sync.target" is NOT waiting for NTPd to start and sync the TOD. In fact it doesn't seem to be doing anything.
    2) I may have been making a mistake by not using "Requires=" or "Wants=" before using "After=". The systemctl documentation is not 100% clear about this. But it does recommend this convention as best practice. Any expert advice is welcome.
    3) It is still unknown why in the one case in Phil's log kiwid was started early. I did find documentation that waiting on "After=network-online.target" doesn't necessarily mean after the network interfaces are fully up and configured. You'd really have to invent a custom target that waits for the specific interface, eth0 in our case. Although this is complicated by people wanting to use WiFI dongles. A different solution discussed below.

    The next release will have this kiwid.service file:

    [Unit]
    Description=kiwi daemon
    Wants=network-online.target
    After=network-online.target
    Wants=ntp.service
    After=ntp.service
    Wants=capemgr.service
    After=capemgr.service

    [Service]
    Type=forking
    ExecStart=/etc/init.d/kiwid start
    ExecStop=/etc/init.d/kiwid stop
    Restart=always
    RestartSec=10

    [Install]
    WantedBy=multi-user.target

    So NTPd and the cape manager are being waited for explicitly. Although the use of "Wants=" instead of "Requires=" means that if NTPd has trouble starting, for whatever reason, the Kiwi server won't fail to start. Also, when started in background mode, the server will wait 30 seconds before doing anything. This will give time for the rest of Linux/Debian to settle in case the Kiwi server is started early. This should help with the case of network interfaces being slow to become ready.

    In Phil's one case the eth0 link never came ready. This was much more of a problem with Beagles several years ago. It was generally fixed with improvements to the PHY code. But it is possible that occasionally after a power-on reboot that the Ethernet may fail to establish a link. I think the best strategy is to avoid switching the power off to the Beagle on a regular basis. If you're in a power-limited environment then this is a consideration (e.g. solar powered). But hopefully you have a large float battery. If you're powering off due to nearby transmitter operation then you should really be solving the problem another way. Like proper switching of antennas and grounding of inputs.

  • jksjks
    edited April 2017
    Analysis of Phil's log:

    Normal reboot. Ethernet (eth0) found at 7 seconds, initially not ready.
    Apr 19 18:37:25 kiwisdr kernel: [    7.562009] net eth0: initializing cpsw version 1.12 (0)
    Apr 19 18:37:25 kiwisdr kernel: [    7.564357] net eth0: phy found : id is : 0x7c0f1
    Apr 19 18:37:25 kiwisdr kernel: [    7.575096] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    ...
    eth0 goes ready at 10 seconds.
    Apr 19 18:37:25 kiwisdr kernel: [   10.577864] cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
    Apr 19 18:37:25 kiwisdr kernel: [   10.577958] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    ...
    Kiwi server properly started AFTER eth0 is up and cape manager has run:
    Apr 19 18:37:26 kiwisdr kernel: [   16.456317] bone_capemgr bone_capemgr: slot #6: dtbo 'cape-bone-kiwi-P-00A0.dtbo' loaded; overlay id #2
    Apr 19 18:37:27 kiwisdr kiwid: 0:00:00 ....      KiwiSDR v1.74 --------------------------------------------------------------------

    ==============

    Abnormal reboot. Kiwi server started at 1.6 seconds into boot!!! Why did Debian do this?
    Apr 19 18:38:11 kiwisdr kernel: [    1.631758] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
    Apr 19 18:38:11 kiwisdr kiwid: 0:00:00 ....      KiwiSDR v1.74 --------------------------------------------------------------------
    ...
    eth0 found at the usual 7 seconds, but link is not ready. 
    Apr 19 18:38:11 kiwisdr kernel: [    7.186237] net eth0: initializing cpsw version 1.12 (0)
    Apr 19 18:38:11 kiwisdr kernel: [    7.188604] net eth0: phy found : id is : 0x7c0f1
    Apr 19 18:38:11 kiwisdr kernel: [    7.199275] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    ...
    Cape manager finishes.
    Apr 19 18:38:11 kiwisdr kernel: [   22.044267] bone_capemgr bone_capemgr: slot #6: dtbo 'cape-bone-kiwi-P-00A0.dtbo' loaded; overlay id #2
    ...
    Kiwi server correctly decides Ethernet is not there, which is isn't. Eth0 link has never gone ready.
    Apr 19 18:38:16 kiwisdr kiwid: 0:00:43 ....      DDNS: no Internet access?

    =================


Sign In or Register to comment.