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.
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.
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.
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.
has successfully booted up with full ssh, ping, arp, and ROS2 dynamic discovery Data Distribution System DDS working
12 out of 12 attempts
since the change of 2.4GHz band WiFi access point
from the xFinity Technicolor CGM4331COM XB7
to my ancient DLink DIR-825 (last firmware released was 2013).
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.
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.
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.
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.
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.
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.