Haloo guyss, I need your hand please, if you have a driver for BBG please reply this email. Thank you so much
Regards, Pada Senin, 28 September 2020 pukul 01.19.27 UTC+7 Fisher Grubb menulis: > 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/33de4dc9-f0fc-4e39-aab9-2a8adf00a2can%40googlegroups.com.
