Disabling IPv6 to fix name resolution issues on LAN

Question

I have a conventional LAN configuration. It consists of a router/firewall/gateway running OPNsense, and a variety of hosts - mostly Macs, RPis, Ubuntus, my WiFi APs and the usual phones and video gadgets.

In preparation for a move, I recently removed the Ethernet connection to my RPi 3B (hostname raspberrypi3b), and created the following wpa_supplicant.conf in /etc/wpa_supplicant:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=GB
network={
        ssid="MyMeshyWiFi"
        psk="**********"
}

Here's the ifconfig output for wlan0:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.144  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2605:a601:a82d:f500::1e11  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::fb12:4c3f:73b0:2394  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:AB:CD:EF  txqueuelen 1000  (Ethernet)
        RX packets 932046  bytes 55887017 (53.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1736798  bytes 2654807130 (2.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This worked fine initially. I simply un-plugged the Ethernet cable & now connect via WiFi. Since then however, I am having SSH connect failures for raspberrypi3b. Following are some details:

After a few hours (but inevitably) my attempted SSH connections fail:

% ssh pi@raspberrypi3b.local
AND ...
% ssh pi@192.168.1.144

Hours may pass with no response. Yet, raspberrypi3b's power light is illuminated, and the green light can be observed to flash occasionally. A reboot of raspberrypi3b always resolves the issue - but only for a while. This has started since using wlan0 exclusively. If this ever failed while using eth0 on raspberrypi3b, I do not recall it.

I checked the DHCP Leases in the DHCP server (OPNsense firewall) while raspberrypi3b was missing in action, and found no active lease for it. After re-booting, ssh pi@raspberrypi3b.local was successful, and then an active lease was shown for raspberrypi3b. Perhaps even more oddly: While engaged in an active & responsive SSH session with raspberrypi3b, I attempted to make a second SSH connection by opening another terminal window on my Mac. I was unable to connect (as described previously) using raspberrypi3b.local, but was able to connect using the IP address I got from the active session?!

I have configured OPNsense to "Prefer to use IPv4 even if IPv6 is available". There is a separate DHCP server for IPv6, but it has never been enabled.

I have also checked man avahi & found nothing useful. man 5 avahi.service lists an XML fragment that looks interesting: <service protocol="ipv4|ipv6|any">, but as the default is any, I did not change anything.

This has turned into a much longer question than I wanted, and I've still omitted some details. Any solutions for resolving this are appreciated. In the meantime, I am going to disable IPv6 on raspberrypi3b to see if that has any effect.

ADDENDUM:

I disabled IPv6 without any noticeable effect; i.e. raspberrypi3b.local & 192.168.1.144 continued to suffer connection failures.

I reviewed my network configuration: I am using 3 AmpliFi WiFi routers for my APs. They are configured as a "mesh" (Ethernet backhaul), and set in "Bridge Mode" (DHCP is passed through the WiFi APs to my DHCP server/OPNsense firewall. The AmpliFi HD units were added to replace older APs early last year, but otherwise this configuration has served numerous WiFi clients flawlessly for years. This issue with raspberrypi3b.local is the first persistent issue I've had with a WiFi client. The unfortunate thing about the AmpliFi HD units is that their admin interface is non-existent (the web GUI has been replaced by an iPhone app designed for 15 year-olds). Yeah - they are crap in this regard, and I do not recommend them.

I discovered a related question here. The syslog for raspberrypi3b also showed a flurry of bpf_send: No buffer space available messages attributed to dhcpcd. Unfortunately, the answers provided there didn't fix my issue.

I made a few changes to my default /etc/dhcpcd.conf file in an effort to get more relevant data. The following lines were added:

# My Experiments:
ipv4only
debug
logfile /home/pi/mydhcpcdlog.txt

Another change I made was moving raspberrypi3b closer to one of the AmpliFiHD APs; from approx. 12 meters to 1 meter. Maybe, instead of a "mesh" configuration, Ubiquiti has designed a "quagmire" configuration? :)

As mentioned above, the ipv4only change did not cure the connection failures for raspberrypi3b. However, since physically moving raspberrypi3b closer to one of the APs, and adding the debug & logfile changes, the connection failures have disappeared :/ I hate it when that happens! Any ideas for a troubleshooting approach would be most welcome.

Answer 1

You can use ipv4only or noipv6 to avoid IPv6.

I experience occasional resolution failures (only resolved by restarting routers etc).
I reserve IP in my routers, so I (usually) have predictable IP.

I "avoid" the occasional problem with scripts like the following

#!/bin/bash
# script to start ssh connection to Pi
# If not found use default ADDRESS
# Ian Binnie 2019-07-30
# 2021-01-17 ip4
TARGET="MilliwaysPi4.local"
ADDRESS="10.1.2.84"     # WiFi
ADDRESS2="10.1.2.74"    # Ethernet
ping -c1 $TARGET > /dev/null 2>&1
rc1=$?
if [ $rc1 -gt 0 ]; then
    echo "Can't ping $TARGET"
    TARGET=$ADDRESS
    ping -c1 $TARGET > /dev/null 2>&1
    rc2=$?
    if [ $rc2 -gt 0 ]; then
        TARGET=$ADDRESS2
    fi
fi
if [ $# -eq 0 ] ; then
    USR='pi'
else
    USR=$1
fi
ssh $USR@$TARGET
PS1='\h:\W \u$ '