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 On Sat, 26 Sep 2020 at 03:38, jonnymo <[email protected]> wrote: > 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: > https://variwiki.com/index.php?title=Static_IP_Address > > 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 > > > > On Fri, Sep 25, 2020 at 8:21 AM <[email protected]> wrote: > >> 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 >> >> >> On Tuesday, 14 July 2020 08:54:26 UTC+10, jonnymo wrote: >>> >>> 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 >>> >>> On Mon, Jul 13, 2020 at 3:08 PM Manderson <[email protected]> >>> wrote: >>> >>>> 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 <http://google.com>* >>>>> >>>>> Cheers, >>>>> >>>>> Jon >>>>> >>>>> >>>>> On Thu, Jul 9, 2020 at 4:10 PM Dennis Lee Bieber <[email protected]> >>>>> wrote: >>>>> >>>>>> On Thu, 9 Jul 2020 11:55:02 -0700 (PDT), in >>>>>> gmane.comp.hardware.beagleboard.user Manderson >>>>>> <matthew...> 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 >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/beagleboard/c58fgfp0p35v399encr2d1v1i6han23eov%404ax.com >>>>>> . >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/beagleboard/a4631369-a8b5-40f9-aa53-e05a649029f7o%40googlegroups.com >>>> <https://groups.google.com/d/msgid/beagleboard/a4631369-a8b5-40f9-aa53-e05a649029f7o%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/0fc78342-ee89-401b-9b00-b767f24eeb88o%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/0fc78342-ee89-401b-9b00-b767f24eeb88o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > For more options, visit http://beagleboard.org/discuss > --- > 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 > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAG99bkpeTtDNNmBdtEji1ZP00Zap%2B2ovHaC0Dj_K3St8vvkBiw%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CAG99bkpeTtDNNmBdtEji1ZP00Zap%2B2ovHaC0Dj_K3St8vvkBiw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAD4Xxq_3MVM%2Bf0aXuzwXuZBc2ofqAYo-TLyr510UD4MMOMRf%2BQ%40mail.gmail.com.
