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

BBAI initial upgrade failure, can't reach internet from bbai

edited September 2022 in BeagleBone AI

I'm attempting to replace my BBG with a BBAI and ran into a problem when following the instructions on page 1 which calls for running the upgrade procedure on beagleboard.org/upgrade. All was going well until I got a request to upgrade security scripts with several options as shown below. I think this is new and unanticipated in the kiwi forum discussion on initial installation of sw. Unfortunately while I copied the text below, the process continued without my input, possibly from the past command. I suspect it took the default N option and did not upgrade the security scripts. Now any time the sudo apt update or upgrade commands are run, or anything that tries to get to the internet fails with destination host unreachable. I'm ssh'd in OK, can reboot etc from the shell. Jim WA2ZKD and I compared the files in /etc/security and they're identical with his. He said he never ran the beagleboard.org/upgrade when he installed his 6 AI's in 2020, so this must have been added recently. We compared os / kernel versions and my OS reads the same, but the kernel here is Linux 4.14.108-ti-r143 and his is Linux 4.14.108-ti-r113.

I've found I can ssh-in OK, then ping devices on my local network, but cannot ping anything outside my local network. It appears that it can find the destination ip address from a dns server, but then gets redirected to a different address that's 192.168.7.2 and then fails. Not sure if this is related to the securetty issue I was given the option to update / replace. Here's what I get when pinging outside the local network:

ping www.cnn.com

PING cnn-tls.map.fastly.net (151.101.195.5) 56(84) bytes of data.

From 192.168.7.2 (192.168.7.2) icmp_seq=1 Destination Host Unreachable

Not sure what's going on here with the 192.168.7.2 address, my ifconfig info is pasted at the bottom.

*************************************************************************

Here's the options I was presented with during the upgrade:


Configuration file '/etc/securetty'

 ==> Modified (by you or by a script) since installation.

 ==> Package distributor has shipped an updated version.

   What would you like to do about it ?  Your options are:

    Y or I  : install the package maintainer's version

    N or O  : keep your currently-installed version

      D     : show the differences between the versions

      Z     : start a shell to examine the situation

 The default action is to keep your current version.

*** securetty (Y/I/N/O/D/Z) [default=N] ?

********** ifconfig **************************************************

debian@beaglebone:/etc$ ifconfig

SoftAp0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

    inet 192.168.8.1 netmask 255.255.255.0 broadcast 192.168.8.255

    inet6 fe80::2aec:9aff:fee9:68ae prefixlen 64 scopeid 0x20<link>

    ether 28:ec:9a:e9:68:ae txqueuelen 1000 (Ethernet)

    RX packets 0 bytes 0 (0.0 B)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 37 bytes 6880 (6.7 KiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500

    inet 192.168.1.94 netmask 255.255.255.0 broadcast 192.168.1.255

    inet6 fe80::2aec:9aff:fee9:68ae prefixlen 64 scopeid 0x20<link>

    ether 28:ec:9a:e9:68:ae txqueuelen 1000 (Ethernet)

    RX packets 8000 bytes 1288535 (1.2 MiB)

    RX errors 0 dropped 38 overruns 0 frame 0

    TX packets 1725 bytes 221831 (216.6 KiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    device interrupt 126


lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

    inet 127.0.0.1 netmask 255.0.0.0

    inet6 ::1 prefixlen 128 scopeid 0x10<host>

    loop txqueuelen 1000 (Local Loopback)

    RX packets 571 bytes 50300 (49.1 KiB)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 571 bytes 50300 (49.1 KiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

    inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3

    ether 28:ec:9a:e9:68:b1 txqueuelen 1000 (Ethernet)

    RX packets 0 bytes 0 (0.0 B)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 0 bytes 0 (0.0 B)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

    inet 192.168.6.2 netmask 255.255.255.0 broadcast 192.168.6.255

    ether 28:ec:9a:e9:68:b3 txqueuelen 1000 (Ethernet)

    RX packets 0 bytes 0 (0.0 B)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 0 bytes 0 (0.0 B)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


wlan0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500

    ether 80:91:33:39:b5:87 txqueuelen 1000 (Ethernet)

    RX packets 0 bytes 0 (0.0 B)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 0 bytes 0 (0.0 B)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Comments

  • Your post mentions /etc/security/ (the directory) and /etc/securetty (the file). Those are two entirely separate things.

    Neither of them should have anything to do with your subsequent networking problems. /etc/security seems to be associated with SELinux (secure Linux) and is completely commented out, as I would hope it would be. /etc/securetty limits which ttys the root account can login to and also should not be a problem.

    I had run an upgrade (via the pkup and pkug aliases) some time ago and successfully got Debian 9.13. I just did it again and received a few package updates but no new kernel.

    From the dog alias:

    root@ai:/etc# dog

    Debian 9.13

    BeagleBoard.org Debian Image 2019-08-03

    Linux ai 4.14.108-ti-r143 #1stretch SMP PREEMPT Thu May 27 20:03:25 UTC 2021 armv7l GNU/Linux

    Debian GNU/Linux 9.13 (stretch)

    It's a shame you didn't get a chance to use the D option to show the differences during your upgrade. Probably would have shed some light on who or what made those changes.

  • jksjks
    edited September 2022

    Comment after you updated your post to include some networking information:

    This is almost certainly a default route problem since accesses to your local network still works. DNS works because your router probably publishes a DNS service with a local address via DHCP.

    What's the output of the route command?

    root@ai:~# route

    Kernel IP routing table

    Destination   Gateway     Genmask     Flags Metric Ref  Use Iface

    default     router     0.0.0.0     UG  0   0    0 eth0

    link-local   0.0.0.0     255.255.0.0   U   1000  0    0 eth0

    192.168.1.0   0.0.0.0     255.255.255.0  U   0   0    0 eth0

    router     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

    Also, what's the content of the /etc/network/interfaces file?

  • It's something with the default port that it goes to for internet I think since it redirects to 192.1.7.2, which is shown as usb0. I'm a bit out of my element here, but will keep plugging away...

  • route

    Kernel IP routing table

    Destination   Gateway     Genmask     Flags Metric Ref  Use Iface

    default     192.168.7.1   0.0.0.0     UG  0   0    0 usb0

    192.168.1.0   0.0.0.0     255.255.255.0  U   0   0    0 eth0

    DeviceDHCP.Home 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.252 U   0   0    0 usb0

    192.168.8.0   0.0.0.0     255.255.255.0  U   0   0    0 SoftAp0

  • cat /etc/network/interfaces

    # This file describes the network interfaces available on your system

    # and how to activate them. For more information, see interfaces(5).


    # The loopback network interface

    auto lo

    iface lo inet loopback


    # The primary network interface

    #auto eth0

    #iface eth0 inet dhcp

    # Example to keep MAC address between reboots

    #hwaddress ether DE:AD:BE:EF:CA:FE


    ##connman: ethX static config

    #connmanctl services

    #Using the appropriate ethernet service, tell connman to setup a static IP address for that service:

    #sudo connmanctl config <service> --ipv4 manual <ip_addr> <netmask> <gateway> --nameservers <dns_server>


    ##connman: WiFi

    #

    #connmanctl

    #connmanctl> tether wifi off

    #connmanctl> enable wifi

    #connmanctl> scan wifi

    #connmanctl> services

    #connmanctl> agent on

    #connmanctl> connect wifi_*_managed_psk

    #connmanctl> quit


    # Ethernet/RNDIS gadget (g_ether)

    # Used by: /opt/scripts/boot/autoconfigure_usb0.sh

    iface usb0 inet static

      address 192.168.7.2

      netmask 255.255.255.252

      network 192.168.7.0

      gateway 192.168.7.1

  • Fixed the ip problem by commenting out usb0, uncomment eth0: Thanks. Will get to the rest of this later after honeydo. Thanks John

  • Having usb0 set to a static address is no problem. But not having eth0 set to static or dhcp certainly is. Not sure how that would have happened.

Sign In or Register to comment.