Skip to content

Raspberry Pi 3 B+: Wi-Fi latency regression on 6.18.39+rpt-rpi-v8; 6.18.33 works #7568

Description

@cinghialino

Describe the bug

After upgrading a Raspberry Pi 3 Model B+ from 6.18.33+rpt-rpi-v8 to 6.18.39+rpt-rpi-v8, onboard Wi-Fi exhibits a repeating latency pattern: most gateway pings take approximately 105–113 ms, interspersed with normal 4–8 ms responses.

There is no packet loss, signal strength is excellent, the system is idle, and Wi-Fi power saving is disabled.

Booting the same system into the retained 6.18.33+rpt-rpi-v8 kernel restores normal latency. No firmware, userspace, NetworkManager, access-point, or Wi-Fi profile changes were made between the decisive tests.

Results

6.18.39+rpt-rpi-v8, Wi-Fi only:

10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 5.360/78.668/112.640/47.331 ms

Representative responses:

107 ms
110 ms
5.36 ms
111 ms
112 ms
8.63 ms
105 ms
113 ms
5.40 ms
110 ms

6.18.33+rpt-rpi-v8, Wi-Fi only:

20 packets transmitted, 20 received, 0% packet loss
rtt min/avg/max/mdev = 2.110/6.990/39.653/7.566 ms

Apart from one 39.7 ms response, replies were normally 4–6 ms.

The working 6.18.33 test was performed on the same 5 GHz AP radio and frequency (5500 MHz) used when the problem was initially observed.

Steps to reproduce the behaviour

  1. Use a Raspberry Pi 3 Model B+ running 64-bit Debian 13 / Raspberry Pi OS Lite.
  2. Install and boot linux-image-6.18.39+rpt-rpi-v8.
  3. Connect using the onboard BCM4345/6 Wi-Fi adapter.
  4. Disable Wi-Fi power saving.
  5. Disconnect Ethernet.
  6. Run ping -c 20 <LAN gateway>.
  7. Observe repeating responses around 105–113 ms with periodic normal responses.
  8. Boot the same system into linux-image-6.18.33+rpt-rpi-v8, without changing the Wi-Fi firmware or configuration.
  9. Repeat the ping test.
  10. Observe normal latency around 4–6 ms.

Device(s)

Raspberry Pi 3 Mod. B+

System

Raspberry Pi reference 2026-04-21
Generated using pi-gen:
4ad56cc850fa60adcc7f07dc15879bc95cc1d281
stage2

Debian GNU/Linux 13.6 (trixie)
aarch64

Affected kernel:

Linux 6.18.39+rpt-rpi-v8
#1 SMP PREEMPT Debian 1:6.18.39-1+rpt1 (2026-07-29)

Working kernel:

Linux 6.18.33+rpt-rpi-v8
#1 SMP PREEMPT Debian 1:6.18.33-1+rpt1 (2026-06-01)

Firmware:

May 21 2026 11:21:57
version 288930ab4712b99596f32732664aaaeb881ef1e0

Relevant packages:

firmware-brcm80211 1:20260519-1~bpo13+1+rpt1
linux-image-6.18.33+rpt-rpi-v8 1:6.18.33-1+rpt1
linux-image-6.18.39+rpt-rpi-v8 1:6.18.39-1+rpt1
network-manager 1.52.1-1+rpt4
wireless-regdb 2026.05.30-1~deb13u1
wpasupplicant 2:2.10-24

Wi-Fi chipset and firmware:

brcmfmac: using brcm/brcmfmac43455-sdio for chip BCM4345/6
brcmfmac: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08
version 7.45.265 (28bca26 CY)
FWID 01-b677b91b

Logs

On the working kernel, NetworkManager briefly enables power saving during initialization and then disables it as configured:

brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled

Both the global NetworkManager setting and active connection profile specify disabled power saving:

[connection]
wifi.powersave = 2

802-11-wireless.powersave: 2 (disable)

No brcmfmac errors, disconnects, thermal throttling, or packet loss were observed.

Additional context

The upgrade that introduced the problem changed the kernel from 6.18.33 to 6.18.39. It also updated firmware-brcm80211, but the controlled old/new kernel comparison used the same currently installed firmware package, isolating the kernel version as the changed variable.

The latency was reproduced on two different 5 GHz AP radios/channels. Signal strength was reported between 69% and 97%, including approximately -22 dBm near the access point.

This may be related generally to recent Pi 3 brcmfmac regressions, although the symptoms differ from #7337:

#7337

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions