WiFi connectivity and possible external power supplies for BBAI

274 views
Skip to first unread message

Manderson

unread,
Jul 9, 2020, 2:55:03 PM7/9/20
to BeagleBoard
Hi all,

I typically take the wired approach when connecting to my Beaglebone (plug in USB-C power to a port on my laptop and ssh with the 192.168.6.2 IP). I've noticed, however, in the past several days that my BBAI loses wlan connectivity if my host computer goes to sleep (e.g. overnight). Pinging google.com after this happens results in 
debian ~ $ ping google.com
ping: google.com: Temporary failure in name resolution
debian ~ $ ping 8.8.8.8
connect: Network is unreachable


My question is twofold:

1) It would seem that this is a DNS issue, and the only remedy I have come up with for this is to reboot the BBAI. Is there a Linux command that restores or resets this without having to reboot?

2) If my board's wlan is dependent on my computer also being connected to wifi, then would it be detrimental to power my BBAI off a wall outlet and USB-C wall charger instead of plugging into my computer? Or would I not even be able to ssh into it?


Thanks,
Matt

Dennis Lee Bieber

unread,
Jul 9, 2020, 7:10:55 PM7/9/20
to Beagleboard
On Thu, 9 Jul 2020 11:55:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Manderson
<matthewdanderson23-R...@public.gmane.org> wrote:

>Hi all,
>
>I typically take the wired approach when connecting to my Beaglebone (plug
>in USB-C power to a port on my laptop and ssh with the 192.168.6.2 IP).

What type of computer are you using (OS)? I ask as Windows normally
uses 192.168.7.x, Mac the 192.168.6.x, and Linux apparently works with both
(they are, I believe, slightly different USB<>Ethernet protocols).

>I've noticed, however, in the past several days that my BBAI loses wlan
>connectivity if my host computer goes to sleep (e.g. overnight). Pinging

Odds are very good that the USB port powers off when the host sleeps.
That means the BBAI is getting a very rude power drop -- risking file
system corruption, and who knows what may happen when the host wakes up and
the BB AI reboots.

Also, it may be that you aren't even using the WiFi connection -- if
the host is performing the equivalent of "Internet Connection Sharing" your
...

>google.com after this happens results in
>debian ~ $ ping google.com
>ping: google.com: Temporary failure in name resolution
>debian ~ $ ping 8.8.8.8
>connect: Network is unreachable

would be trying to go through the USB gadget (though I'd think if that was
active before the sleep, it would reactivate after the sleep also).

>
>2) If my board's wlan is dependent on my computer also being connected to
>wifi, then would it be detrimental to power my BBAI off a wall outlet and
>USB-C wall charger instead of plugging into my computer? Or would I not
>even be able to ssh into it?

Nothing in your post confirms that you even had a WiFi connection to
some shared router (if you had, you wouldn't be using 192.168.6.x to
connect to the BB AI, but instead be using an IP number -- or hostname:
beaglebone or beaglebone.local -- to connect using a path through the
router. Does your router even show the BBAI as a Wireless client?

Even if the USB port remains powered while the host sleeps, if you were
going via ICS (BBAI<>USB gadget<>host WiFi [or cable]<>router<>ISP), the
host WiFI may go down when the host sleeps, and possibly it gets a
different DHCP assignment on wake-up which is not being reflected in
routing tables for the USB gadget.



--
Dennis L Bieber

jonnymo

unread,
Jul 9, 2020, 8:02:44 PM7/9/20
to Beagle Board
I suspect your resolv.conf got set back to the default with no nameservers listed when the USB ethernet port went offline. 

How do you have your wlan0 configured?
If you used connman, you can add the following to your connman settings:
 Ex:
   IPv4.gateway=192.168.2.1
   Nameservers=8.8.8.8;8.8.4.4;4.4.4.4;


Typing 'route' should show your which network device the traffic is going down.

Also, you can test this by using ping and specifying the ethernet port to use:
Ex:
    ping -I wlan0 google.com

Cheers,

Jon


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c58fgfp0p35v399encr2d1v1i6han23eov%404ax.com.

Manderson

unread,
Jul 13, 2020, 5:52:43 PM7/13/20
to BeagleBoard
Hi Dennis,



On Thursday, July 9, 2020 at 4:10:55 PM UTC-7, Dennis Bieber wrote:
On Thu, 9 Jul 2020 11:55:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Manderson
wrote:

>Hi all,
>
>I typically take the wired approach when connecting to my Beaglebone (plug
>in USB-C power to a port on my laptop and ssh with the 192.168.6.2 IP).

        What type of computer are you using (OS)? I ask as Windows normally
uses 192.168.7.x, Mac the 192.168.6.x, and Linux apparently works with both
(they are, I believe, slightly different USB<>Ethernet protocols).


I am on a Mac running 10.14.6 Mojave. I have been interchangeably using 192.168.6.2 and whichever IP `ifconfig` says that wlan0 is using. In my original post I had been using 192.168.6.2 to use the cloud9 IDE, and it would not give me any problems wrt interacting with the BBAI, but any commands or tasks that required an internet connection would hang or fail.

Manderson

unread,
Jul 13, 2020, 6:08:13 PM7/13/20
to BeagleBoard
Hi Jon - thanks for your input.

This is a snapshot of my working wlan0 

wlan0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
        inet 192.168.1.50  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::8291:33ff:fe4a:4223  prefixlen 64  scopeid 0x20<link>
        ether 80:91:33:4a:42:23  txqueuelen 1000  (Ethernet)
        RX packets 20004  bytes 4482231 (4.2 MiB)
        RX errors 0  dropped 375  overruns 0  frame 0
        TX packets 2130  bytes 245657 (239.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I am indeed using connman -- what do those two additional settings do?

Output of `route`:
debian ~ $ 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 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 wlan0
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
192.168.8.0     0.0.0.0         255.255.255.0   U     0      0        0 SoftAp0


Best,
Matt


On Thursday, July 9, 2020 at 5:02:44 PM UTC-7, jonnymo wrote:
I suspect your resolv.conf got set back to the default with no nameservers listed when the USB ethernet port went offline. 

How do you have your wlan0 configured?
If you used connman, you can add the following to your connman settings:
 Ex:
   IPv4.gateway=192.168.2.1
   Nameservers=8.8.8.8;8.8.4.4;4.4.4.4;


Typing 'route' should show your which network device the traffic is going down.

Also, you can test this by using ping and specifying the ethernet port to use:
Ex:
    ping -I wlan0 google.com

Cheers,

Jon


On Thu, Jul 9, 2020 at 4:10 PM Dennis Lee Bieber <dennis...@gmail.com> wrote:
On Thu, 9 Jul 2020 11:55:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Manderson
To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.

jonnymo

unread,
Jul 13, 2020, 6:54:26 PM7/13/20
to Beagle Board
The values I provided should set the /etc/resolv.conf for the wlan0 interface. The gateway you would want to set for your config.  I typically run with a static ip on my wlan0 so I edit the connman settings manually for my environment.  The other option is to do it manually or with some script that detects the loss of your usb network connection and then set resolv.conf accordingly.  This does take root access, so I find it best to just add it to the connman settings. 

You could check your /etc/resolv.conf on your BBAI after you experience the USB sleep mode on your laptop to see if there are any settings still in there. If not, then that might explain why you can not reach google.com when the usb interface is offline.

Cheers,

Jon 

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a4631369-a8b5-40f9-aa53-e05a649029f7o%40googlegroups.com.

fisher...@gmail.com

unread,
Sep 25, 2020, 11:21:14 AM9/25/20
to BeagleBoard
Hi all,

I'm also having issues with getting internet via WiFi on this BB-AI board.

It connects to my WiFi network, gets a DHCP address, the routing table shows the default route is 192.168.1.1, through wlan0 interface etc, exactly the same top line of Matt's table.
The WiFi LED goes green (right next to the Ethernet port).

I've connected through Ethernet and upgraded the software, but same issue with WiFi connected but no network through it.

It automatically sets the routing interface to Eth0 when I plug the Ethernet in, then sets its back to wlan0 when I unplug it so that's great but still no signs of life.

There are a bunch of scripts in /opt/scripts, and configs in /etc/default.
In /etc/default, there's a settings file bb-wl18xx with "TETHER_ENABLED=yes", I've changed it to "no".  That caused connman to not connect the WiFi automatically, so I used connmancltl to set the agent back on for it to connect again.

What else can I check and change?  I've put my connman settings and route command output are below, to me they show everything set up for this to work.
My assumption is that either its a separate setting relating to boot scripts etc, or its a driver/firmware issue.

I've had this issue previously, but it worked once on the original board image, but after updating to the latest image, it just doesn't work at all.

My connman settings file in /var/lib/connman/

[global]
OfflineMode=false

[Wired]
Enable=true
Tethering=false

[WiFi]
Enable=true
Tethering=false

[Gadget]
Enable=false
Tethering=false

[P2P]
Enable=false
Tethering=false

[Bluetooth]
Enable=true
Tethering=false


fisher@beaglebone:~$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 wlan0
192.168.1.0     0.0.0.0        255.255.255.0   U    0      0        0 wlan0
192.168.1.1     0.0.0.0        255.255.255.255 UH   0      0        0 wlan0
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
192.168.8.0     0.0.0.0        255.255.255.0   U    0      0        0 SoftAp0


fisher@beaglebone:~$ ping -I wlan0 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.175 wlan0: 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 178ms

 
Fisher

Dennis Lee Bieber

unread,
Sep 25, 2020, 12:12:37 PM9/25/20
to Beagleboard
On Fri, 25 Sep 2020 08:19:06 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
fisher.grubb-Re5J...@public.gmane.org wrote:



>*fisher@beaglebone*:*~*$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 wlan0
>192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
>192.168.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 wlan0

If I read this correctly, your gateway is pointing right back at the
BBAI, not to the next node in the route. OR -- if 192.168.1.1 IS supposed
to be the router, you appear to mask it with a local definition for the
same IP.

This is from a Raspberry-Pi...
pi-star@pi-star-3b(ro):~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
default dsldevice.attlo 0.0.0.0 UG 303 0 0
wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0
wlan0
pi-star@pi-star-3b(ro):~$
pi-star@pi-star-3b(ro):~$ ifconfig
<SNIP>
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.79 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:4b:0b:d5 txqueuelen 1000 (Ethernet)
RX packets 60790023 bytes 1410944400 (1.3 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12658944 bytes 2726884208 (2.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

pi-star@pi-star-3b(ro):~$



--
Dennis L Bieber

jonnymo

unread,
Sep 25, 2020, 1:38:56 PM9/25/20
to Beagle Board
In your /var/lib/connman folder you should have a file associated with your wlan0 config.

ex:
 $  sudo ls  /var/lib/connman/wifi_8091334a1523_4d6f4e6574494f54_managed_psk/
data  settings

In the psk settings file, I tend to set this manually as such:
Name=MySSID
SSID=pk2-passwd
Frequency=2462
Favorite=true
AutoConnect=true
Modified=2020-09-24T07:36:19.092924Z
Passphrase=mypasswd
IPv4.method=manual
IPv4.netmask_prefixlen=21
IPv6.method=off
IPv6.privacy=disabled
Hidden=true
IPv4.local_address=192.168.2.210
IPv4.gateway=192.168.2.1
Nameservers=8.8.8.8;8.8.4.4;4.4.4.4;

The "Nameservers" setting wll set the /etc/resolv.conf with the nameserver associated with wlan0 and the same is so for  IPv4.gateway if you are running IPv4.

This can be done manually as such:
# connmanctl config <service> --ipv4 manual <ip address> <netmask> <gateway>
# connmanctl config <service> --nameservers <dns-addr>
Ref:

If your eth0 is not defined with nameservers and gateway, it is possible it will overwrite the /etc/resolv.conf when you plug in an ethernet cable and not set it when it is disconnected.  One test would be to reboot the board and see if the wlan0 connection recovers. Another is to  check /etc/resolv.conf when you plug in the ethernet cable and then when you disconnect it.

You can also use 'dmesg' to see if there are any networking errors being reported when you are changing network connects. 


Cheers,

Jon



To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/0fc78342-ee89-401b-9b00-b767f24eeb88o%40googlegroups.com.

Fisher Grubb

unread,
Sep 27, 2020, 2:19:27 PM9/27/20
to beagl...@googlegroups.com
Hi all,

Thanks for your input, its very strange.  I got it working, by pinging the IP address from my laptop.

They are both connected to the same WiFi network.  The routing table hasn't changed at all, but I noticed that it took like 5 seconds to generate.  I assumed that might have been normal for this board, but now its instantaneous.

This device was given 192.168.1.175 via DHCP by my WiFi modem, so, I could ping it from my laptop through the WiFi network.

I've rebooted, and it connects as normal, and internet via WiFi works immediately.

Very strange, any ideas?

I'll reply here if anything changes.
Fisher

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/D0kLUD-zwHY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAG99bkpeTtDNNmBdtEji1ZP00Zap%2B2ovHaC0Dj_K3St8vvkBiw%40mail.gmail.com.

willy simangunsong

unread,
Feb 2, 2021, 9:57:49 AM2/2/21
to BeagleBoard
Haloo guyss, I need your hand please, if you have a driver for BBG please reply this email. Thank you so much


Regards,

Reply all
Reply to author
Forward
0 new messages