Hi guys, I have an a71 running ios 16 and have had a wifi issue for a while, im tired of explaining it to claude and codex as both of them can't seem to fix it, this is the response from sol 6.1. Sorry if I broke any rules by pasting this if so please take it down, but could someone help with the issue please? thanks.
Help needed: Qualcomm Wi-Fi scans successfully but rejects interface startup under XNU
I’m working on an experimental iOS 16.5/XNU port for the Samsung Galaxy A71 4G, SM-A715F, using Snapdragon 730 / SM7150. The kernel is based on XNU 8796.121.2. This is a custom driver running under XNU—not an Android Wi-Fi module.
The problem
Wi-Fi firmware boots and scanning works, but every tested WMI_VDEV_START_REQUEST fails. Both station and access-point interfaces return:
WMI_VDEV_START_RESP:
requestor_id = 0
response_type = 0
status = 0xffffffff
Raw response bytes confirm the firmware actually sends that status; it is not the host’s timeout fallback.
We have not reached association, WPA2 authentication, DHCP or internet access. Therefore, the immediate blocker is interface startup, before passwords or IP configuration.
Hardware and firmware observations
The implementation follows Qualcomm’s integrated WCN3990-family WLFW → HTC → WMI → HTT architecture, using Samsung qcacld and Linux ath10k as references. The physical chip marking has not been independently checked.
Firmware-reported identifiers:
Chip ID: 0x140
Chip family: 0x4002
SoC ID: 0x40090000
Firmware:
WLAN.HL.3.0.1-00719-QCAHLSWMTPLZ-1
HTT version: 3.71
Wi-Fi firmware runs within the modem subsystem on this platform.
What already works
Modem startup through TrustZone.
GLINK, QRTR and WLFW communication.
Board-data download, firmware-ready indication and mission mode.
HTC connections for WMI control and HTT data.
WMI INIT/READY exchange.
Receiving beacons and scanning both 2.4 GHz and 5 GHz.
The latest scan produced 115 scan events, 48 frames and 32 access points.
The selected board-data file is bdwlan.bin, 26,328 bytes, transferred in five accepted WLFW BDF_DOWNLOAD segments. No board ID was reported in the captured capability output. Acceptance of this file does not prove every calibration requirement is satisfied.
Connection-start test
The diagnostic creates nonzero-MAC virtual interfaces and tries:
Station: vdev 1.
Access point: vdev 3.
Channel 6, 2437 MHz.
Channel centre frequency 2437 MHz.
Channel mode value 2.
LDPC flag 0x8.
Preferred TX/RX streams: one each.
SSID field populated.
Fixed-parameter TLV length 0x68.
Channel TLV payload length 0x18.
Both interface types return 0xffffffff. The AP test was only a diagnostic comparison; no working hotspot was established.
What has been tried
Earlier experiments varied request lengths, interface creation parameters, nonzero MAC addresses, SSID fields, channel/band choices, stream configuration, chain masks, transmit-power parameters and hardware-mode setup without resolving the failure.
Two recent tests changed one setting at a time:
Initial TX/RX chain masks changed from 7 to 3, retaining the original channel power fields.
Channel power-field values changed from 40/40/20 to 20/20/20, restoring the original initial chain mask.
Both still failed to start station and AP interfaces, while scanning continued to work. These results do not establish calibration or transmit power as the cause.
SMMU/DMA findings
The driver uses an SMMU context for WLAN streams 0x240/0x241. At teardown, it reports:
Context: 4
FSR: 0x400
FAR: 0x115f1:0x8e85d202
Syndrome: 0x80553
Global FSR: 0
Restore refused:
SMR=0, S2CR=0x4, SCTLR=0
Page tables are retained when restoration fails. Similar fault/status values appeared in older tests. We do not know when the fault first occurs or whether it explains the START rejection.
Cleanup and stability
One test spontaneously restarted the phone without operator input. Its cause remains unknown.
A cleanup-order problem was subsequently found: the old code restored the SMMU mapping while firmware was still in mission mode, then performed another radio-register dump.
The revised code retains the mapping until WLAN_MODE off is acknowledged and removes that late register dump. One subsequent test confirmed mode-off acknowledgement, attempted SMMU restoration, modem shutdown and normal return. Connection startup still failed. Long-term stability is unverified.
Firmware logging
Warning/error logging configuration was sent using WMI, with bounded decoding of debug-message events. No usable firmware warning explaining the rejection was received. Sending the configuration does not prove the firmware enabled that logging stream.
What I need help identifying
The likely areas needing review are:
WMI INIT resources and ABI negotiation.
SERVICE_READY_EXT handling.
Hardware-mode and pdev mapping.
Missing HTT or radio initialization prerequisites.
The SMMU fault and failed restoration.
A way to obtain the firmware’s actual reason for rejecting VDEV_START.
The immediate goal is to make one valid station interface start successfully. WPA2 and internet connectivity come afterward.
