KiwiSDR networking -- firewall??? issue

N8URN8UR
in Configuration and Operation

I have a maybe arcane networking issue and I wonder if anyone has any clues.

Our two KiwiSDRs are on a LAN at a remote site using a Unifi gateway/firewall for access to the outside world. The gateway forwards ports 8073 and 8074 to them. That works fine.

The Unifi gateway runs OpenVPN and I have a VPN client configured on my machine at home. That also works fine for all the machines on the remote network *except* the two Kiwis. They do not respond to any traffic over the VPN. No ping, no ssh, no http. Traceroute from the VPN client to either Kiwi goes off into space. The client can ping, ssh, http all the other machines on the network with no problems, so there must be something different about the Kiwi networking configuration that prevents routing via the VPN. Does anyone know what that might be?

Thanks,

John

Comments

  • jksjks

    It would be interesting to run tcpdump (or equivalent) from a non-Kiwi host on the LAN and see what comes out of the gateway for Kiwi vs non-Kiwi traffic.

  • N8URN8UR

    There is something very weird in the KiwiSDR networking. In addition to the eth0 ethernet interface, there are two interfaces "usb0" and "usb1" each with a /24 route -- one of them to the VPN subnet, the other to a different subnet that as far as I can tell isn't being used.

    Deleting those two routes makes things work normally. I don't know what caused them to be created, so I'm not sure what a permanent cure might be.

  • N8URN8UR
    edited November 2023

    Might have found it... apparently BeagleBone creates those interfaces at boot via scripts in /opt/script. I haven't made the changes yet, but this link talks about it. It looks like there are two "autoconfigure" scripts in /opt/scripts/boot that cause these interfaces to be created with IP addresses that are getting in the way. I'm not sure yet the best way to disable them.

    https://superuser.com/questions/1609818/beaglebone-black-debian-10-where-does-the-ip-addresses-on-usb0-and-usb1-come-fro


  • N8URN8UR
    edited November 2023

    Found the fix. It sure wasn't easy to find via Google, but after lots of searches plus grepping through lots of config files, the answer is simple and blindingly obvious once you know what and where it is :-)

    Just go into /etc/default/bb-boot and uncomment "USB_NETWORKING_DISABLED=YES" then reboot. After that the routing table looks normal and I can access the systems via the vpn.

  • jksjks

    The only BBG I have here running Deb 10 looks like this:

    root@kiwisdr:~# dog

    Debian 10.11

    BeagleBoard.org Debian Buster IoT Image 2020-04-06

    Linux kiwisdr 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

    Debian GNU/Linux 10 (buster)

    root@kiwisdr:~# route

    Kernel IP routing table

    Destination   Gateway     Genmask     Flags Metric Ref  Use Iface

    default     192.168.1.1   0.0.0.0     UG  0   0    0 eth0

    192.168.1.0   0.0.0.0     255.255.255.0  U   0   0    0 eth0

    192.168.1.1   0.0.0.0     255.255.255.255 UH  0   0    0 eth0

    192.168.6.0   0.0.0.0     255.255.255.0  U   0   0    0 usb1

    192.168.7.0   0.0.0.0     255.255.255.0  U   0   0    0 usb0

    Don't know why having two inactive USB .[67].0/24 subnets would mess up the routing of .1.0/24, but it obviously solved your problem. Good catch!

  • N8URN8UR

    I think the problem is that 192.168.7.0 is also the subnet being used by the VPN endpoints. Just bad luck that they chose the same network as our VPN did. If it weren't for that it probably wouldn't have been an issue.

Sign In or Register to comment.