Has anyone seen WiFi networking issues with the Raspberry Pi 3B+ ?
I am wondering if the dual band WiFi might be confusing Ubuntu 20.04 64-bit Server OS.
PROBLEM: ssh and ping sometimes report “host down” for many repeated cold boots
Have you disabled IPv6 on all network interfaces, including those not being used?
Is there a way to completely kill the IPv6 protocol altogether at the system level?
I have heard mention that later versions of Raspbian/Raspberry Pi OS, especially the 64 bit versions, have problems with WiFi.
I have a strong suspicion that this is not limited to the Pi-3 as I, using a Pi-4, have had networking issues with later versions of Raspbian.
I do not know enough about this to really be of help but I remember that there were problems like this. Since Raspbian and Ubuntu come from the same upstream source, it makes sense.
I would suggest lurking the Ubuntu Raspberry Pi forums and/or searching the web.
You may also want to lurk the Raspberry Pi forums too.
Is there a way to test a relatively un-modified version with as few changes as possible to exclude changes you have made and/or ROS changes from causing the problem?
When I was investigating my own weird wifi issues I saw a number of posts along those lines. It wasn’t relevant to what I was checking on, so I didn’t pursue. But apparently dual-band can be an issue.
/K
yes current stategy.
I fired up the latest PiOS (only 32-bit available for Pi3s) have not seen the issue, but interestingly, my suspect OS booted just fine after PiOS but issue returned on next boot. Could be coincidence, haven’t found any patterns yet.
Next to fire up a “clean Ubuntu 64-bit Server”
Also going to set my old dlink router up again to see if xFinity wiz-bang TV,telephone, dual-band, and a bucket of hidden access things router is playing with my sanity as well.
. . . . And how old might this router be?
You appear to have a whole bunch of other things attached to the router too.
As I mentioned in a QA Tech Tips blog article way back in December of 2009:
If any device on your network has IPv6 enabled, it can play havoc with everything.
You should check anything and everything that uses your network, both wired and WiFi, and verify that IPv6 is disabled on every available interface. This includes the router too.
This might not solve all your problems but it will get a lot of the pesky stuff out of the way.
OK, I’ll push back a little on this one. I can easily believe this was a problem 12 years ago. But surely by now the software/firmware has evolved. I’ve got 16 devices connected to my home wifi right now. Besides my robot Finmark only 3 of them are computers where I could even hypothetically disable IPV6. The rest are smart devices. Since they’re newer, I’m guessing they have an IPV6 address. But my wifi router interface doesn’t even show me which ones do or don’t. So this advice is essentially a non-starter. The only way to manage it might be to set up a separate network using a router on which you could turn off IPV6, and then only attach computers/robots onto that network if they’ve had IPV6 disabled.
Turns out that’s not even that easy. As an experiment I’ve been trying to disable IPV6 on Finmark. After doing steps taken from several websites, when I reboot wlan0 still has an IPV6 address. Oh well. 
/K
Yo, try this - worked for me:
======= DISABLE IPv6
Reference: https://itsfoss.com/disable-ipv6-ubuntu-linux/
* Add to bottom of /etc/sysctl.conf
############ Added by Alan: DISABLE IPv6 #########################
# Reference: https://itsfoss.com/disable-ipv6-ubuntu-linux/
# Don't forget to sudo sysctl -p
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
* sudo sysctl -p
* check with "ip a" should not see:
inet6 xxxx::xxxx:xxxx:xxxx:xxx/64 scope link
valid_lft forever preferred_lft forever
(did so continue..)
* create /etc/rc.local
#!/bin/bash
# FILE: /etc/rc.local
#
# PURPOSE: DISABLE IPv6
# Reference: https://itsfoss.com/disable-ipv6-ubuntu-linux/
/etc/sysctl.d
/etc/init.d/procps restart
exit 0
* sudo chmod 755 /etc/rc.local
* shutdown, reboot
* check with "ip a" should not see:
inet6 xxxx::xxxx:xxxx:xxxx:xxx/64 scope link
valid_lft forever preferred_lft forever
**Looking Good**
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.0.0.11/24 brd 10.0.0.255 scope global dynamic wlan0
valid_lft 172107sec preferred_lft 172107sec
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
Yes and no - yes more devices and software are IPv6 aware, but “have the IPv6 compatibility issues gone away?” - no.
Case in point - we all like to type “sudo apt-get update && sudo apt-get upgrade” ( and some like to “-y” it). Sometimes unknowingly, we are accessing mirrors around the world where IPv6 is really needed but only half works. Files will stat, but not copy without packet errors. Nothing in the error msgs will lead you to understand IPv6 has anything to do with your problem, but if you add “ipv6.disable=1” to the end of cmdline.txt in PiOS or R4R, and reboot - magic! the errors are gone and your upgrade works like a charm.
This is no longer possible @jimrh, and now with service provider owned routers that run on IPv6 and offer IPv4 translations for us old folk with old devices, no only can you not administer their router, the dials they give you to twist amount to “bar that kid from the net for x minutes” and not much more.
Even if you turn off a WiFi band, their router may still be broadcasting hidden SSIDs in the band for all the service provider “home appliances” they offer like security systems, mobile phone service, MOCA and mesh net connections, and fricken public access points to their subscribers from my house. (They keep hiding that public WiFi service in different places. First I found where to turn it off, then they moved router management to the cloud, and now it seems you have to call them and beg to turn the thing off.)
I’m opening myself up to the devil in hopes of quickly learning if this is not going to solve the problem - so far every boot after setting up my “SKYNET” to provide 2.4Ghz to Carl, and Dave, and DeskPi, no computer has changed colors or cause me to start hyperventilating again.
Currently, ROSbot Dave
While I can say Carl and DeskPi have had fitful connections with the xFinity router(s), neither has shown the “cannot remote in” (ssh) issue that Dave exhibited, nor did I attempt distributed data messaging across the network when Carl was trying out ROS (1).
Carl has always been a Raspberry Pi 3B based GoPiGo3, but DeskPi was in fact using the exact Raspberry Pi 3B+ (plus) board that GoPiGo3 ROSbot Dave is running, except DeskPi has always run Raspbian/PiOS.
All these tests seem to point the finger at Ubuntu 20.04.2 on RaspberryPi 3B+ (or at least this particular 3B+) having unreliable ICMP, ARP, or UDP handling during the DHCP link establishment phase with the xFinity router configured with a reserved IPv4 address for the board’s WiFi MAC address.
I don’t know enough to be able to diagnose this deeper, and having found a solution that enables me to progress with my ROS2 learning (through migrating the “Hands On ROS for Robotic Programming” exercises), I am leaving this mystery of the universe unsolved.
I do have a new WiFi 6 router on order, (that has ongoing firmware update support), to minimize the chance my network will become a crypto-bot or participant in the next distributed denial of service attack on internet democracy.
OK - I can see that. But that’s different than connecting/disconnecting from the local network.
I run my own router. Although to be fair it’s a Google router, so it’s possible Google is doing things I don’t know of. I used to run a Linksys WRT54G with open source firmware, but eventually wanted to run a mesh at home and decided keeping up with all of the security issues wasn’t worth it.
Good plan.
/K
Thanks. I thought that’s what I had done, but I just retried it. It seems to work fine until I reboot, but after I reboot is still have an IPV6 address associated with wlan0. I’ve tried adding a line specifically for wlan0 to sysctl.conf based on another post. And I had seen site saying that for ubuntu 18.04 specifically, you had to modify the grub file, but that didn’t work either.
Since I don’t seem to be having trouble, I’ve also just decided to press on.
/K
Mine acted like that until I did:
Now I’m trying to figure out how to “permanently” turn off powermanagment:
sudo iwconfig wlan0 power off
is session only.
I had done that as well. So really not sure what’s going on.
I’ve never looked at the power management.
/K
Not necessarily true.
Unless you live in Japan, (and possibly Brazil), IPv6 support is not something I would take for granted.
Even if we “assume” that the ISP’s have IPv6 knocked cold, (
), I doubt that’s true for client-side software. Virtually every operating system I’ve seen still has IPv6 issues to this day.
This is why I avoid:
“Whole-house mesh” type appliances.
Anything other than a basic modem interface that connects to a router (by ASUS) that I supply and that I configure. (i.e. No fancy ISP-supplied routers and such.) I absolutely insist on absolute and total control over my network. That is the only way I can guarantee my network behaves in a consistent and reliable way.
I also avoid “smart” appliances like the plague they are. The providers are not working in your best interest. They do whatever they darn well please.
I have a basic cable modem (in the US) and a basic fiber-modem (in Moscow). I have total and absolute control of my network.
If your providers don’t offer that, it’s time for some serious push-back on them.
If you have an Android based smartphone, Kwelsoft has a WiFi monitor app you can download.
There are commercial versions of WiFi monitor software for both bands that will show hidden channels. (It may not show the name, but you will see what channels exist.)
You need to do the research, you need to know, and you need to hold these companies accountable.
Thanks - I’ll check that out.
/K
Another thing:
There are a lot of appliances that operate in the 2.4GHz range, the most notorious being the common microwave. At between 600 watts and 2kw+, it’s a powerful source of interference.
Even if you have a “microwave leakage detector” the most miniscule amount of leakage will be orders of magnitude larger than the most, (legally), powerful router.
When I was doing my computer business, I spent $100+ on a broad-band spectrum analyzer dongle to help pinpoint interference.
99% of the interference was from “non-network” RFI.
Another tip:
An app like the kewlsoft WiFi analyzer will help you visualize what frequencies are being used by what networks.
Point of information:
WiFi channels are not like TV or CB radio channels. They all overlap. The only, (2.4GHz), channels that don’t overlap are channels 1, 6, and 11. (and 14 if not in the US)
A dozen-or-so wifi channels that are superimposed is better than three that overlap. Superimposed channels cooperate by definition. Overlapping channels cannot cooperate and you end up with incredible amounts of collisions and piss-poor performance.
I don’t know what your living arrangements are - crowded condo or 20 miles to the nearest neighbor.
I would investigate the radio environment surrounding yourself as a primary part in tracking down the issues.
BTW:
AFAIK, WiFi shares power management with USB on the Pi. (You may wish to verify this.)
You may wish to disable USB power management too and see if that helps.
I was not aware this is possible in Pi3B or Pi3B+. Do you have a link to read up on this?
The PiB+ (not to be confused with 3B+) does allow setting max_usb_current=1 in cmdline.txt to allow up to 1.2A total (instead of the default 600mA) across all USB ports if your power supply has sufficient oompf. I have not heard of any “cut/limit power if not used in a while” management.
AFAIK, only the WiFi has power management that will suspend or lower tx power (which I posted two ways to disable here ).
FWIW: Schematic for Pi3B+
A very limited schematic and virtually useless for anything more technically serious than a wall poster. (IMHO)
I remember reading about it somewhere.
Where? I don’t know. I read a lot of things and sometimes I even remember what I read! 