Second build sold out. Message will appear here when store is ready for third build ordering.

SDR not showing on listing

Hi, my SDR is 'registered', but is not showing on rx.kiwisdr.com
What else do I need to do please?

Thanks

Andy EI2HH

Comments

  • jksjks
    edited August 2020
    The last time kiwisdr.com saw a registration request from http://93.89.254.25:8073 was on August 18. Are you sure this Kiwi is running and has a connection to the Internet? What happens when you use the "check port open" button on the network tab of the admin page?

    Also, is this simply a case of your ISP having changed your public ip address? (since you've taken no measures it seems to guard against that possibility).
  • The IP has changed since then as I moved the location slightly. The new permanent IP is http://185.178.64.39:8073

    Thanks
  • You have severe local networking problems. From your Kiwi I can ping your router, but nothing beyond that. Not even numerically (e.g. ping 8.8.8.8 which should work). Given that fact I don't understand how incoming connections are even working.

    For example, from the Internet you can visit http://185.178.64.39:8073/status and get the correct response. But your Kiwi cannot contact kiwisdr.com at all because it can't even reach its own DNS server!

    So this is not a Kiwi problem and you'll need to find your own solution.
  • OK a routing issue I guess. I will check routes in the router.
    Thanks for checking.
  • Actually can you tell me how to initiate a ping from the Kiwi, so I can check if its working?
    -Thanks.
  • Admin page, console tab, click "connect" button.
    In "enter shell command" below type "ping 8.8.8.8" or "ping kiwisdr.com" (or google.com or something).
    Type control-C to stop command if no response.
  • I get "only available to local admin connections". And I'm not local to it!
  • Did you mean to write "am local to it" instead of "am not"?

    Is your device running the browser on the same 192.168.10.xxx subnet as the Kiwi? That's what it is checking for.
  • This stuff is so complicated now that even I forget how it works.

    If you are connecting to the admin page of a remote Kiwi over the Internet (i.e. not from the same local network as the Kiwi) then the "console" tab functionality is disabled as a security measure. The rationale was that if your Kiwi admin password was leaked or guessed then it would be better if all the bad guy could do was change your Kiwi configuration rather than also have Beagle root shell access.

    The better solution is to use ssh as the transport mechanism for the admin console tab. I worked on that for a while but had implementation problems and never finished the work..
  • Hi, yes I am NOT on the same subnet as the Kiwi. The Kiwi is in a field a mile from my house!
    Is there anyway I can do a ping, or see if the outgoing route is working remotely?
    How is the Kiwi registering if it cannot see the outside world?

    Thanks.
  • Going back to my very first post in this thread: Try the "check port open" button on the admin page network tab. If after a while you get an error (e.g. "Error checking port status") then you know the Kiwi cannot communicate with kiwisdr.com due to the issue.

    How is the Kiwi registering if it cannot see the outside world?
    It's not registering. Isn't the whole point of this?
  • Has this Kiwi ever registered since it's been at its remote location? I.e. since August 18th when kiwisdr.com last saw it? Or was Aug 18th the last time it was at your local location hooked up to your local network?
  • 18th was the last time the unit was at my home QTH. The admin control panel shows that it IS registered! (see screenshot attached).

    I will try to check the routing in the router today.

    Thanks for your help.

    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/ab/e1f363ae6ffca51f9aa1edf17b66d2.png
  • The admin control panel shows that it IS registered!
    That seems to be a bug. I switched registration off, then on again. It sat there for many minutes (like it wasn't able to connect to kiwisdr.com) then finally said the registration was successful. But there was this error message in the log:
    Thu Aug 20 17:26:29 10:14:12.510 0... _reg_kiwisdr_com: sp == NULL?
    So this particular error condition is not being reported properly on the admin page. The logs on kiwisdr.com show absolutely no incoming connections from this Kiwi's ip address (from the new remote location).
  • jksjks
    edited September 2020
    This is one of the craziest things I've ever seen. From kiwisdr.com I can do a: curl http://185.178.64.39:8073/status And it will connect and return the expected data.

    But if you initiate even the simplest connection from the Kiwi (TCP SYN) it will stop dead on the second hop. I don't see that 10.x.x.x local network in the reverse (incoming) direction if I do a traceroute from the outside. This is definitely some horrible network misconfiguration. Is this site on the end of a wireless link or something? Who is airwire.ie? Is this their fault?

    Traceroute to a well-known DNS server from Kiwi:
    root@kiwisdr:~/Beagle_SDR_GPS# tr -n 8.8.8.8
    traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
     1  192.168.10.1  0.289 ms  0.138 ms  0.091 ms
     2  10.0.5.24  38.615 ms  45.488 ms  45.495 ms
     3  * * *
     4  * * *
     5  * * *
     6  * * *
     7  * * *
     8  * * *
     9  * * *
    10  * * *
    11  * * *
    12  * * *
    13  * *^C

    Traceroute from kiwisdr.com to Kiwi:
    root@proxy:~# tr 185.178.64.39
    traceroute to 185.178.64.39 (185.178.64.39), 30 hops max, 60 byte packets
     1  23.92.24.2 (23.92.24.2)  0.619 ms 23.92.24.3 (23.92.24.3)  0.590 ms 23.92.24.2 (23.92.24.2)  0.828 ms
     2  173.230.159.64 (173.230.159.64)  0.400 ms 173.230.159.70 (173.230.159.70)  0.384 ms 173.230.159.68 (173.230.159.68)  0.446 ms
     3  38.142.11.153 (38.142.11.153)  1.727 ms  1.854 ms  1.882 ms
     4  38.142.11.153 (38.142.11.153)  3.432 ms be2063.ccr21.sjc01.atlas.cogentco.com (154.54.1.161)  1.881 ms  2.293 ms
     5  be3179.ccr22.sfo01.atlas.cogentco.com (154.54.43.149)  3.412 ms be3178.ccr21.sfo01.atlas.cogentco.com (154.54.43.69)  2.897 ms be2095.ccr22.sjc01.atlas.cogentco.com (154.54.3.137)  2.526 ms
     6  be3110.ccr32.slc01.atlas.cogentco.com (154.54.44.142)  18.755 ms  18.873 ms be3179.ccr22.sfo01.atlas.cogentco.com (154.54.43.149)  3.363 ms
     7  be3038.ccr22.den01.atlas.cogentco.com (154.54.42.98)  29.012 ms be3110.ccr32.slc01.atlas.cogentco.com (154.54.44.142)  19.029 ms  19.092 ms
     8  be3037.ccr21.den01.atlas.cogentco.com (154.54.41.146)  29.065 ms be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90)  40.411 ms be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90)  40.173 ms
     9  be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90)  40.526 ms be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90)  40.500 ms  40.500 ms
    10  be2718.ccr22.cle04.atlas.cogentco.com (154.54.7.130)  60.203 ms be2832.ccr42.ord01.atlas.cogentco.com (154.54.44.170)  52.424 ms be2718.ccr22.cle04.atlas.cogentco.com (154.54.7.130)  59.545 ms
    11  be2717.ccr21.cle04.atlas.cogentco.com (154.54.6.222)  58.563 ms be2718.ccr22.cle04.atlas.cogentco.com (154.54.7.130)  59.454 ms  59.529 ms
    12  be2993.ccr31.yyz02.atlas.cogentco.com (154.54.31.226)  66.400 ms be3259.ccr21.ymq01.atlas.cogentco.com (154.54.41.206)  73.043 ms be3260.ccr22.ymq01.atlas.cogentco.com (154.54.42.90)  73.576 ms
    13  be3042.ccr21.lpl01.atlas.cogentco.com (154.54.44.161)  142.258 ms  142.419 ms be3259.ccr21.ymq01.atlas.cogentco.com (154.54.41.206)  73.710 ms
    14  be2590.rcr21.dub01.atlas.cogentco.com (154.54.39.154)  148.775 ms be3042.ccr21.lpl01.atlas.cogentco.com (154.54.44.161)  142.375 ms be2529.rcr21.dub01.atlas.cogentco.com (154.54.37.226)  150.014 ms
    15  be2529.rcr21.dub01.atlas.cogentco.com (154.54.37.226)  150.000 ms be2590.rcr21.dub01.atlas.cogentco.com (154.54.39.154)  148.640 ms  148.662 ms
    16  be2003.nr51.b020478-0.dub02.atlas.cogentco.com (154.25.5.98)  149.505 ms be2530.rcr21.dub02.atlas.cogentco.com (130.117.2.230)  150.230 ms  149.426 ms
    17  be2003.nr51.b020478-0.dub02.atlas.cogentco.com (154.25.5.98)  149.848 ms vl210.nsw01.b020478-0.dub01.hades.cogentco.com (149.6.4.50)  150.121 ms  149.952 ms
    18  vl210.nsw01.b020478-0.dub01.hades.cogentco.com (149.6.4.50)  150.682 ms ptr-93-89-255-195.ip.airwire.ie (93.89.255.195)  149.320 ms  154.713 ms
    19  195.43.155.121 (195.43.155.121)  150.321 ms ptr-93-89-255-195.ip.airwire.ie (93.89.255.195)  150.036 ms 195.43.155.121 (195.43.155.121)  150.093 ms
    20  195.43.155.121 (195.43.155.121)  150.729 ms  150.112 ms ptr-185-178-64-39.ip.tuxbox.ie (185.178.64.39)  150.377 ms
    21  185.178.64.39  150.951 ms  150.349 ms  150.321 ms
    
  • Another case of missing default gateway?
  • Another case of missing default gateway?
    Doesn't seem to be?
    root@kiwisdr:~/Beagle_SDR_GPS# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
    192.168.7.0     0.0.0.0         255.255.255.252 U     0      0        0 usb0
    192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
    
    root@kiwisdr:~/Beagle_SDR_GPS# ifconfig -a eth0
    eth0      Link encap:Ethernet  HWaddr 40:bd:32:e5:40:4b  
              inet addr:192.168.10.254  Bcast:192.168.10.255  Mask:255.255.255.0
              inet6 addr: fe80::42bd:32ff:fee5:404b/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:2434885 errors:0 dropped:0 overruns:0 frame:0
              TX packets:2667825 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:170826774 (162.9 MiB)  TX bytes:1951438253 (1.8 GiB)
              Interrupt:175 
  • Airwire.ie are the ultimate internet connection. But the connection is actually like this:
    Kiwi connected to a Mikrotik LT AP (192.168.10.1), which has a cellular SIM. Because the cell company do not give a static IP, I have a VPN set up so the Mikrotik uses the cell connection to tunnel to the VPN server (at Airwire), which gives me a static public IP.
  • It seems as if there is a problem with an outgoing route in the Mikrotik. Its hard for me to check as I'm not local to it, I will ask the admin of the VPN (who is a friend) to check it from his end. He may be able to see where the route is missing. I will report later!
Sign In or Register to comment.