GoPiGo OS 3.0.1 intermittent access point connection

Greetings!

@cleoqc
While upgrading Charlie running a Raspberry Pi-4 to GPGOS 3.0.1, I ran into an interesting intermittent network issue:

In Access Point mode: (the default)
The access point would randomly fail at about 15-30 second intervals and remain gone for 30 seconds to a minute or so.

I could open my wifi monitor app on my cell phone and watch it go away and come back.

This made it virtually impossible to connect to the access-point connection.  (i.e.  Out of fifteen or twenty attempts, two and only two succeeded, and then were almost immediately dropped. The rest were, “Could not connect to this network” failures.)

The antenna LED was solid green the entire time.

I tried the “ipv6.disable=1” in the cmdline.txt file, no change.

The only thing that seems to work is:
(aside from a hard-wired connection, which is not always possible)

  • Connect directly to the robot with a monitor, keyboard, and mouse.
  • Use the Pi’s browser to connect to localhost.
  • Using the browser interface, switch to networked mode and verify a connection is made to the network.
  • Minimize the browser.
  • Go to wifi settings by right-clicking on the WiFi/network icon in the top right and go to each interface, (not SSID!), in turn and make sure “disable IPv6” is checked, hitting “Apply” after each change.
  • Reboot.

See the important qualifying note at the bottom of this post.

This should be the default setup for new images.

Apparently this can be set by editing /etc/sysctl.conf and adding. . .

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

. . .to the end of the file and rebooting.
 

Update:
Apparently this is Linux version specific.

GPGOS Buster apparently does not see the cmdline flag and needs the sysctrl fix.

Various people on the internet mentioned that later versions of Linux don’t use the sysctrl parameter and need the cmdline flag instead.

Maybe we should set both?
 

Second update:

Why does this happen in the first place?

The result is a very brittle IPv4 network connection.

I do not know this for a fact, but I suspect that somewhere in the grand scheme of things, the Raspberry Pi’s implementation of the IPv6 protocol is not quite ready for prime time and results in a very brittle network.  Supposedly, later updates to Buster seriously broke IPv6 networking.

In any event it is my experience that IPv6 is more trouble than it’s worth at this point and it’s best left disabled.

Important Qualifying Note

In this particular case, I am running a brand-new installation of GoPiGo OS 3.0.1, on a fresh SD card to verify everything’s working correctly with the minimum number of modifications, prior to installing it on my big SD card and completing the configuration there.

Since GoPiGo OS starts up, by default, in access point mode, it’s not possible to make a back-door connection, except, (perhaps), with a hard-wired Ethernet connection.  Even then, with IPv6 trying to ruin everyone’s life, the connection can be “interesting”.

What I ultimately did was to connect using a monitor, keyboard, and mouse directly to the 'bot, (my right-angle micro-HDMI connector to the rescue!), use the browser built into GPGOS to connect back to itself, change the network mode, (you cannot access the WiFi properties in Access Point mode!), and then disable IPv6 everywhere I could.

A reboot demonstrated that things were much better.

2 Likes

Confusion reigns supreme!

Attempting to replicate the results above, I re-flashed, (several times!), 3.0.1 to my SD card and there appears to be nothing I can do to connect to the GoPiGo access point.

I have tried:

  1. Connecting to the local network:
    • This always works.
  2. Reflashing the SD card. (repeatedly)
  3. Adding the various no-IPv6 commands and turning off IPv6 in the wireless settings.
  4. While in access point mode, running raspi-config and setting the WiFi country to “US”, just in case it was preventing WiFi because the WiFi country wasn’t set.
  5. Flashing GPGOS 3.0.0 and trying everything again.
  6. Substituting a different Pi-4 and trying everything again.
    • My next step is a Pi-3.
  7. Trying to connect with different devices.
    • Three computers, two Android telephones.
  8. Trying different operating systems.
    • Aside from Android on the phones, at least one of the computers is a Windows 7 system instead of Windows 10.

I am thoroughly confused.

In the past, I have NEVER had so much trouble connecting to the robot in access-point mode.  It was essentially a sure thing.  Sometimes it would fail or flake-out, but that was relatively rare.

Now, I can’t connect to save my life and I have absolutely no 'naffing clue.

===============================

Update:

I just substituted a Pi-3B. (It says Pi-3B on the PCB, but it has WiFi, does that make it a B+?)

So far, using 3.0.0, I am getting a rock-solid connection every single time, reboot or no.

Next steps:
Reflash back to a virgin 3.0.1 and see what happens.

1 Like

Pi3B has 2.4GHz WiFi on-board and 1.2GHz max processor
Pi3B+ has 2.4GHz/5GHz WiFi on-board and a 1.4GHz max processor.

1 Like

While my latest RPi Networking difficulties were not with the RPi in access mode, the difficulty connecting and trying on a different processor sounds so familiar.

I was seeing a crazy entry for the reserved IP for my bot when I would “arp -a” the net. The bot would boot, the arp would show the reserved IP as incomplete, and I could not get into the bot.

Eventually, I looked at the connected devices on my router and “found” the bot MAC was connected but given a non-reserved IP. I think the solution was to disable IPv6. This was Ubuntu, not R4R or GoPiGoOS.

2 Likes

I am confused as to why things should work so well with the Pi-3 and fail so abysmally with the Pi-4?

I may eventually try back-revving the Pi-4 firmware and see what happens.

As a side note, I am thoroughly peeved at all this - this connection nonsense is taking time away from the research I WANT to be doing!

2 Likes