Still determining local interface address??? What's that mean???

KU4BYKU4BY
in Problems and Issues

I had both kiwis blow out due to a nearby lightning strike, a v1 and a v2. I replaced the beaglebones and reimaged the new ones with images I created last year. They both came up and functioned normally. I now get the message "Still determining local interface address." on the v1 admin page after it's been running for a while and don't quite understand what it means. If I look at eth0, the IP info looks good and I'm obviously going to the correct IP address since I'm seeing that message.

Refreshing the page never seems to help. Restarting the kiwi server via ssh seems to fix it for a while but it always comes back eventually. I never had this issue before so it shouldn't have been anything that got baked into the image I took last year.

This is only affecting the v1 admin page. The user page works just fine and both the user and admin pages work fine on the v2. So where could the disconnect be?

Thanks!

Steve

image.png


Comments

  • jksjks
    edited July 19

    What software version is the v1 running? (shown on the user page control panel, "stat" tab).

    Any idea if your local network use a mix of IPv4 and IPv6 addresses? That is, does eth0 get both IPv4 and IPv6 addresses assigned?

    On some people's networks there seem to be timing related problems with DHCP occasionally preventing a proper IPv4 address from being assigned, and an IPv6 link-local used instead. The latter is useless and leads to the problem you're seeing. I've been unable to debug this problem because I can't replicate it here.

    Lastly, what type of URL are you using to get to the user page when you're not able to get the admin page? (i.e. "kiwisdr.local", IPv4 address, proxy address, domain name, ...)

  • KU4BYKU4BY

    Both are running 1.815 on Linux 11. They were both running 1.815 on the old BBs as well.

    Since I posted this earlier today, I noticed that both of the receivers are doing it now. It may be sporadic.

    I don't have anything purposely running IPV6 but they both have ipv6 link local addresses along with ipv4.

    I access them via their ipv4 addresses. When I tried accessing them through kiwisdr.ku4by.com I got the same message.

    I don't understand what is different between the user and admin side as it doesn't happen on the user side at all. When I am able to get into the admin side, everything looks correct and this issue never happened before. Timing could make sense but then shouldn't the user interface have the same issue?

    They connect directly to an Orbi access point which is the same way they were connected previously. Nothing has changed on my network over the past month with the exception of me adding new IP reservations for the new beaglebones and deleting the old ones. I doubt the access point has anything to do with it as I also have a raspberry pi out there and it's been fine.

  • jksjks

    In order to implement the feature where it bypasses asking you for the admin password when connecting from a local network it needs to, well, know what the local network is. User connections don't have this issue.

    But a change in this behavior should only occur on a restart or reboot. You should never see it not happen after a restart/reboot and then some arbitrary time in the future have it occur (without any restart/reboots in the interim). If this is the case then we're dealing with something completely different.

  • KU4BYKU4BY

    OK, so I may or may not have figured out what was going on with it. My /etc/hosts file on both kiwisdrs had my kiwis pointing to 127.0.0.1. So I changed that to the actual LAN IP of the kiwisdr for each. I also changed the hostnames of both of them to reflect kiwisdr1 and kiwisdr2 from what they were which was just kiwisdr.

    I'm really not sure if this could have caused it or not and I have no idea why this would have worked fine previously but after a couple of reboots the issue hasn't come back yet over the past 24 hours.

    I rebuilt both of these with unique images I made of each one of them last year prior to letting them update automatically.

    My thinking was that this may occur on a reboot, restart, or possibly a lease renewal from my router? Either way, the only thing I did was manipulate the /etc/hosts file so if it works, it works. If not, I'll keep poking around.

    Thanks,

    Steve

  • jksjks
    edited July 22

    If you do a netc (alias for networkctl status eth0) that will show DHCP assignments to eth0 from the syslog with date/time info. You can correlate that to reboot/restarts. It would be interesting to know if DHCPv4 assignment is delayed or not occurring for some reason.

    See below when I tried it on a BBG running Debian 11.11. Note how DHCPv4 was assigned promptly after carrier received on eth0. IPv6LL immediately thereafter.

    root@kiwisdr:~# netc

    ● 3: eth0                                    

               Link File: /lib/systemd/network/99-default.link

              Network File: /etc/systemd/network/eth0.network

                  Type: ether

                 State: routable (configured)

                  Path: platform-4a100000.ethernet

                 Driver: cpsw

               HW Address: 98:5d:ad:43:20:16 (Texas Instruments)

                  MTU: 1500 (min: 68, max: 1500)

                 QDisc: mq

      IPv6 Address Generation Mode: eui64

          Queue Length (Tx/Rx): 8/8

            Auto negotiation: yes

                 Speed: 100Mbps

                 Duplex: full

                  Port: tp

                Address: 192.168.1.103 (DHCP4 via 192.168.1.1)

                     fe80::9a5d:adff:fe43:2016

                Gateway: 192.168.1.1 (HUAWEI TECHNOLOGIES CO.,LTD)

                  DNS: 192.168.1.1

            DHCP4 Client ID: IAID:0xb3129f80/DUID

           DHCP6 Client IAID: 0xb3129f80

           DHCP6 Client DUID: DUID-EN/Vendor:0000ab110acd1e29ffb00d740000


    Jul 11 00:19:21 kiwisdr systemd-networkd[588]: eth0: Gained carrier

    Jul 11 00:19:22 kiwisdr systemd-networkd[588]: eth0: DHCPv4 address 192.168.0.104/24 via 192.168.0.1

    Jul 11 00:19:23 kiwisdr systemd-networkd[588]: eth0: Gained IPv6LL

    Jul 11 00:20:41 kiwisdr systemd-networkd[588]: eth0: DHCP lease lost

    Jul 11 00:20:43 kiwisdr systemd-networkd[588]: eth0: DHCPv4 address 192.168.1.103/24 via 192.168.1.1


  • KU4BYKU4BY

    Yeah changing my /etc/hosts file didn't fix it. Here's what I got from netc. This was from earlier today after a power failure so I'm thinking the Orbi was coming back online at the same time which probably caused the carrier losses.

    Since I'm already using a DHCP reservation in the router, I went ahead and set static IP addresses in the kiwisdrs and disable DHCP altogether. I'm still not sure why everything worked fine previously but if I can get it working consistently for now then I'm good with it. The info below was from prior to making the static changes.

    kiwisdr1:

    ● 3: eth0

               Link File: /lib/systemd/network/99-default.link

             Network File: /etc/systemd/network/eth0.network

                 Type: ether

                 State: routable (configured)

                 Path: platform-4a100000.ethernet

                Driver: cpsw

              HW Address: 88:0c:e0:39:02:a3

                  MTU: 1500 (min: 68, max: 1500)

                 QDisc: mq

     IPv6 Address Generation Mode: eui64

         Queue Length (Tx/Rx): 8/8

           Auto negotiation: yes

                 Speed: 100Mbps

                Duplex: full

                 Port: tp

                Address: 192.168.0.50 (DHCP4 via 192.168.0.1)

                    fe80::8a0c:e0ff:fe39:2a3

                Gateway: 192.168.0.1 (NETGEAR)

                  DNS: 192.168.0.1

            DHCP4 Client ID: IAID:0x3fd1f412/DUID

           DHCP6 Client DUID: DUID-EN/Vendor:0000ab110acd1e29ffb00d740000

             Connected To: n/a on port 9c:3d:cf:f0:91:4b


    Jul 21 17:55:40 kiwisdr1 systemd-networkd[544]: eth0: Gained carrier

    Jul 21 17:55:42 kiwisdr1 systemd-networkd[544]: eth0: Gained IPv6LL

    Jul 21 17:55:47 kiwisdr1 systemd-networkd[544]: eth0: Lost carrier

    Jul 21 17:55:48 kiwisdr1 systemd-networkd[544]: eth0: DHCPv6 lease lost

    Jul 21 17:55:50 kiwisdr1 systemd-networkd[544]: eth0: Gained carrier

    Jul 21 17:56:00 kiwisdr1 systemd-networkd[544]: eth0: Lost carrier

    Jul 21 17:56:00 kiwisdr1 systemd-networkd[544]: eth0: DHCPv6 lease lost

    Jul 21 17:56:11 kiwisdr1 systemd-networkd[544]: eth0: Gained carrier

    Jul 21 17:59:22 kiwisdr1 systemd-networkd[544]: eth0: DHCPv4 address 192.168.0.50/24 via 192.168.0.1


    kiwisdr2:

     3: eth0

               Link File: /lib/systemd/network/99-default.link

             Network File: /etc/systemd/network/eth0.network

                 Type: ether

                 State: routable (configured)

                 Path: platform-4a100000.ethernet

                Driver: cpsw

              HW Address: c0:d6:0a:03:b9:f7

                  MTU: 1500 (min: 68, max: 1500)

                 QDisc: mq

     IPv6 Address Generation Mode: eui64

         Queue Length (Tx/Rx): 8/8

           Auto negotiation: yes

                 Speed: 100Mbps

                Duplex: full

                 Port: tp

                Address: 192.168.0.51 (DHCP4 via 192.168.0.1)

                    fe80::c2d6:aff:fe03:b9f7

                Gateway: 192.168.0.1 (NETGEAR)

                  DNS: 192.168.0.1

            DHCP4 Client ID: IAID:0xe5b6829f/DUID

           DHCP6 Client DUID: DUID-EN/Vendor:0000ab110acd1e29ffb00d740000

             Connected To: n/a on port 9c:3d:cf:f0:91:4b


    Jul 21 17:41:21 kiwisdr2 systemd-networkd[587]: eth0: Lost carrier

    Jul 21 17:41:22 kiwisdr2 systemd-networkd[587]: eth0: DHCPv6 lease lost

    Jul 21 17:41:26 kiwisdr2 systemd-networkd[587]: eth0: Gained carrier

    Jul 21 17:41:34 kiwisdr2 systemd-networkd[587]: eth0: Lost carrier

    Jul 21 17:41:34 kiwisdr2 systemd-networkd[587]: eth0: DHCPv6 lease lost

    Jul 21 17:41:36 kiwisdr2 systemd-networkd[587]: eth0: Gained carrier

    Jul 21 17:41:46 kiwisdr2 systemd-networkd[587]: eth0: Lost carrier

    Jul 21 17:41:46 kiwisdr2 systemd-networkd[587]: eth0: DHCPv6 lease lost

    Jul 21 17:41:56 kiwisdr2 systemd-networkd[587]: eth0: Gained carrier

    Jul 21 17:45:10 kiwisdr2 systemd-networkd[587]: eth0: DHCPv4 address 192.168.0.51/24 via 192.168.0.1

  • jksjks
    edited July 22

    I don't understand why in both those cases there is a 3 minute delay after carrier-up until an DHCPv4 is assigned. The Kiwi code only waits for a little while before it gives up and takes whatever it has. In the first case the IPv6LL. This is because the Kiwi needs to support direct-to-computer/laptop setups where an IPv4/6LL is going to be the only thing available.

    Maybe I need to add a configuration setting that says "keep trying forever to get an IPv4 address and don't accept any IPv4/6LL". But even so you'd still have that 3 minute delay before you could make an admin connection. It just seems like the router is doing the wrong thing in this case.

    This was exactly the symptom with another customer. Only I didn't know about the logging provided by netc which make debugging much easier.

  • KU4BYKU4BY

    Well so far so good this morning after configuring static IP addresses. Those examples were from the point where The Orbi and both kiwisdrs had power restored at the same time so it's likely the issue was the Orbi took longer to come back online as it usually does.

    Here is the same info from when I setup static addresses last night. I can go back to DHCP if you want to dig into it further but I would think my times would be quicker if the Orbi is already online when the kiwisdrs reboot.

    kiwisdr1:

    debian@kiwisdr1:~$ networkctl status eth0

    ● 3: eth0

               Link File: /lib/systemd/network/99-default.link

             Network File: /etc/systemd/network/eth0.network

                 Type: ether

                 State: routable (configured)

                 Path: platform-4a100000.ethernet

                Driver: cpsw

              HW Address: 88:0c:e0:39:02:a3

                  MTU: 1500 (min: 68, max: 1500)

                 QDisc: mq

     IPv6 Address Generation Mode: eui64

         Queue Length (Tx/Rx): 8/8

           Auto negotiation: yes

                 Speed: 100Mbps

                Duplex: full

                 Port: tp

                Address: 192.168.0.50

                    fe80::8a0c:e0ff:fe39:2a3

                Gateway: 192.168.0.1 (NETGEAR)

                  DNS: 192.168.0.1

           DHCP6 Client DUID: DUID-EN/Vendor:0000ab110acd1e29ffb00d740000

             Connected To: n/a on port 9c:3d:cf:f0:91:4b


    Jul 22 02:45:07 kiwisdr1 systemd-networkd[542]: eth0: Link UP

    Jul 22 02:45:09 kiwisdr1 systemd-networkd[542]: eth0: Gained carrier

    Jul 22 02:45:10 kiwisdr1 systemd-networkd[542]: eth0: Gained IPv6LL


    kiwisdr2:

    debian@kiwisdr2:~$ networkctl status eth0

    ● 3: eth0

               Link File: /lib/systemd/network/99-default.link

             Network File: /etc/systemd/network/eth0.network

                 Type: ether

                 State: routable (configured)

                 Path: platform-4a100000.ethernet

                Driver: cpsw

              HW Address: c0:d6:0a:03:b9:f7

                  MTU: 1500 (min: 68, max: 1500)

                 QDisc: mq

     IPv6 Address Generation Mode: eui64

         Queue Length (Tx/Rx): 8/8

           Auto negotiation: yes

                 Speed: 100Mbps

                Duplex: full

                 Port: tp

                Address: 192.168.0.51

                    fe80::c2d6:aff:fe03:b9f7

                Gateway: 192.168.0.1 (NETGEAR)

                  DNS: 192.168.0.1

           DHCP6 Client DUID: DUID-EN/Vendor:0000ab110acd1e29ffb00d740000

             Connected To: n/a on port 9c:3d:cf:f0:91:4b


    Jul 22 02:55:05 kiwisdr2 systemd-networkd[588]: eth0: Link UP

    Jul 22 02:55:07 kiwisdr2 systemd-networkd[588]: eth0: Gained carrier

    Jul 22 02:55:09 kiwisdr2 systemd-networkd[588]: eth0: Gained IPv6LL

  • jksjks
    edited July 22

    So I think the summary here is that there are routers that behave badly and the Kiwi code needs to be changed to accommodate that. Starlink after a power outage is another case. Apparently it takes forever for the terminal to acquire sats and assign an IPv4 address.

    KU4BY
Sign In or Register to comment.