Weird issues with WiFi and Bluetooth

Since I updated to 23.05.3 my phone can't use both WiFi and Bluetooth.

This is not a problem with the phone, the phone works as expected on any other WiFi network. I only updated the router's firmware and now my phone only works normally when connected to WiFi normally, with Bluetooth off, but if I switch Bluetooth on and connect a headset the phone loses Internet connectivity (it works normally with Bluetooth on and no connected devices). If I try to place a VoIP call (with a BT headset connected) sometimes WiFi disconnects completely, sometimes it stays on but it's as if there was no Internet connectivity, but if I switch Bluetooth off then connectivity is restored.

I also run a VPN on the router, if I connect to the VPN from another WiFi network everything works as expected, so I think it's not related to any other thing than wireless.

I restored a backup made just before the upgrade, so the configuration was working on 23.05.2, the issue persists.

It happened in the past that after an upgrade some parameters were changed in the default wireless config file, so I had to set everything up from scratch, because restoring a previous backup wasn't working, but I think this was when upgrading to a major version, like from 22.03 to 23.05, I really wish to avoid doing that again because I changed a lot of settings, so it would be a pain to do everything once again. Should I simply delete the wireless config file and reboot to have the OS create it again and then only edit those settings? Would that work?

The router in question is a Linksys WRT series if that matters, they have a some issues with wireless.

resetting the network config on the phone is often not a big deal, I would try it. Maybe its some cached outdated config on the phone side.

I tried everything on the phone, even safe mode. As I said it's not a phone problem

The router in question is a Linksys WRT series if that matters, they have a some issues with wireless.

The backup you made is a gzip archive that can be directly opened in tools like 7zip. If you have not already done that, I would compare the wireless config (and maybe all other configs) from your backup versus the ones on the router in /etc/config (with ssh session). There might be a subtle difference in there that could explain the problem.

Is the phone wifi connected on 2.4 or 5 GHz? If you must use 2.4 I think that lower channels are preferred as they don't overlap with Bluetooth.

2.4 GHz, changing to channel 1 (20 MHz) doesn't solve the issue

Yeah. Since you have a backup of the config, I would give it a try, if default wifi config works.

23.05.3 was said to add wpa3 for wrt1900, not sure if this changes something on you previous working config.
(On the other hand you said that going back to 23.05.2 did not help)

I did what @papagirafe said, compared the files, found nothing out of order. After factory reset I found the issue is present on 23.05.3 even at factory settings, so it's not config related. I switched back to 23.05.2 for the time being. Should I report this issue in the forum or wherever else?

Since I updated to 23.05.3 my phone can't use both WiFi (2.4 GHz) and Bluetooth.
This is not a problem with the phone, the phone works as expected on any other WiFi network. I only updated the router's firmware and now my phone only works normally when connected to WiFi normally, with Bluetooth off, but if I switch Bluetooth on and connect a headset the phone loses Internet connectivity (it works normally with Bluetooth on and no connected devices). If I try to place a VoIP call (with a BT headset connected) sometimes WiFi disconnects completely, sometimes it stays on but it's as if there was no Internet connectivity, but if I switch Bluetooth off then connectivity is restored.

I tried all channels to no avail.

I tried factory reset and I found the issue is present on 23.05.3 even at factory settings, so it's not config related.

23.05.2 works as expected.

I have a WRT1900ACS v1 and do not have this issue.

While Bluetooth and Wifi use the same 2.4G band, they are unrelated to each other so it does suggest something is happening with your phone that is unique. Do you have other devices (phones/tablets/computers) that you can check to see if the BT issue happens on anything else?

What is the specific issue that you are experiencing? Do you see an error or some other indication that BT and wifi cannot be used at the same time?

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

And please make sure that you're actually comparing apples with apples here, modern OpenWrt versions allow enabling WPA3 or 802.11w, which is known problematic on mwlwifi (yes, there have been some fixes for that recently, but not necessarily enough). Make sure to use WPA2PSK/ CCMP, no mixed mode, no WPA3, no 802.11w, no 802.11r.

There is this coming of age moment where a grown-up will try to explain the bee and flower thing.
And the other moment, where an grown-up will try to explain the Linksys WRT thing.

Sit down, this talk might be hard to swallow.
Linksys WRT is a dead platform with terrible Wifi closed source „FULLMAC“ blob driver (meaning non disclosed Wifi code and doc) and therefore no reasonable chance to get most of the issues fixed.

On top Linksys as a company no longer exists. „Linksys“ nowadays is just a product logo. The company that had formerly produced the Wifi chip also no longer exists. The company that bought the former chip intellectual property does not opensource any of this old stuff and has no people working on that old stuff either.

Your options:

  • either one of the following open source community links has unlikely miracle intel, to fix your issue. Outside of that, the Linksys WRT dev reality has practically stopped to exist.
  • you also have the option to accept to live with any Linksys Wifi flaws as is. Linksys WRT Wifi from OpenWRT perspective had alwas sucked a lot and will forever continue to suck in many cases (and on top it sadly had accumulated a long history of additional OpenWRT issues for Linksys WRT - e.g. v21 being rather instable for many users, v22 switch security issues)
  • or consider it now being a right time to move on to a different access point device (Qualcom or Mediatek chip based).

But be aware that waiting and hoping for things to get fixed is not an option for Linksys WRT. This platform is a dead platform, where waiting that things happen does not help.
And be aware that therefore investing time into reporting Wifi issues for this particular Linksys WRT practically does not help either. This platform does not have any comparable progress or options that other platforms have.

If you can’t let go yet, there are the following remaining locations, where reading the most recent posts might give you an idea of how low chance are for getting Linksys WRT Wifi issues fixed and how few Wifi development is actually happening for Linksys WRT.

  1. the one long thread where remaining OpenWRT Linksys WRT Wifi remaining users occasionally post
    Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02 - #1098 by mmortal03

  2. the mostly dead github repo of mwlwifi
    https://github.com/kaloz/mwlwifi/issues

  3. the „divest“ fork for Linksys WRT (which does not develop additional code, but tries to cherry-pick good commits)
    Divested-WRT: No-nonsense hardened builds for Linksys WRT series - #1464 by anomeome

(If you want my personal advice: get a new AP for every day use)

1 Like

So, 23.05.2 works for you? What phone model do you have?

1 Like
root@OpenWrt:~# ubus call system board
{
	"kernel": "5.15.150",
	"hostname": "OpenWrt",
	"system": "ARMv7 Processor rev 1 (v7l)",
	"model": "Linksys WRT1900ACS",
	"board_name": "linksys,wrt1900acs",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.3",
		"revision": "r23809-234f1a2efa",
		"target": "mvebu/cortexa9",
		"description": "OpenWrt 23.05.3 r23809-234f1a2efa"
	}
}

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'XXXX:XXXX:XXXX::/XX'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'wan'
	option macaddr 'XX:XX:XX:XX:XX:XX'

config interface 'wan'
	option device 'wan'
	option proto 'pppoe'
	option username 'XXXXX'
	option password 'XXXXX'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'


root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option disabled '1'
	option country 'FR'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option macaddr 'XX:XX:XX:XX:XX:XX'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option disabled '0'
	option country 'FR'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option macaddr 'XX:XX:XX:XX:XX:XX'


root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'


root@OpenWrt:~# cat /etc/config/firewall
config defaults
	option syn_flood	1
	option input		REJECT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

config zone
	option name		lan
	list   network		'lan'
	option input		ACCEPT
	option output		ACCEPT
	option forward		ACCEPT

config zone
	option name		wan
	list   network		'wan'
	list   network		'wan6'
	option input		REJECT
	option output		ACCEPT
	option forward		REJECT
	option masq		1
	option mtu_fix		1

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
config rule
	option name		Allow-Ping
	option src		wan
	option proto		icmp
	option icmp_type	echo-request
	option family		ipv4
	option target		ACCEPT

config rule
	option name		Allow-IGMP
	option src		wan
	option proto		igmp
	option family		ipv4
	option target		ACCEPT

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
	option name		Allow-DHCPv6
	option src		wan
	option proto		udp
	option dest_port	546
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-MLD
	option src		wan
	option proto		icmp
	option src_ip		fe80::/10
	list icmp_type		'130/0'
	list icmp_type		'131/0'
	list icmp_type		'132/0'
	list icmp_type		'143/0'
	option family		ipv6
	option target		ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Input
	option src		wan
	option proto	icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	list icmp_type		router-solicitation
	list icmp_type		neighbour-solicitation
	list icmp_type		router-advertisement
	list icmp_type		neighbour-advertisement
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Forward
	option src		wan
	option dest		*
	option proto		icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-IPSec-ESP
	option src		wan
	option dest		lan
	option proto		esp
	option target		ACCEPT

config rule
	option name		Allow-ISAKMP
	option src		wan
	option dest		lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT

The issue is present even with no WiFi encryption

That's a shame, but at least keep what's working intact?

Nothing apparently wrong with your configuration.

I honestly suspect that the issue is with your phone... do you have other phones to test?

Agreed.
Sadly the past releases of v21 and v22 have shown that even this expectation had turned out quite difficult for the mvebu target.
New bugs unexpectedly entered the ring and remained longer than expected on mvebu.
As is, the target simply misses developers, testers and manufacturer support and manufacturer input even for keeping the status quo, while toolchain and kernel move on (but according to the threads still has a huge base of loyal device owners)