thanks for this @robimarko i had had .bin. fixed and complied correctly.
And also AP is showing wifi driver loaded! thank you :). Also huge thanks to @mrnuke for the contstant help with my first device towards openwrt!
Now i have no idea whats next?
Installation to flash ?
yes i have done this now. I do think we are missing something still for 5G to work?
[ 11.159051] ath11k c000000.wifi: ipq6018 hw1.0
[ 11.159087] ath11k c000000.wifi: FW memory mode: 0
[ 12.396373] ath11k c000000.wifi: qmi fail to get qcom,m3-dump-addr, ignore m3 dump mem req
[ 12.399577] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 12.407161] ath11k c000000.wifi: fw_version 0x25008f8e fw_build_timestamp 2024-03-01 03:54 fw_build_id WLAN.HK.2.5.0.1-03982-QCAHKSWPL_SILICONZ-3
[ 12.638911] ath11k c000000.wifi: No regulatory rules available in the event info
[ 12.638974] ath11k c000000.wifi: failed to extract regulatory info
[ 12.647120] ath11k c000000.wifi: No regulatory rules available in the event info
[ 12.651408] ath11k c000000.wifi: failed to extract regulatory info
[ 12.721657] ath11k c000000.wifi: failed to receive default regd during init
[ 12.722560] ath11k c000000.wifi: failed to receive deault regd during init
That sounds like the same issue I had on EAP610-outdoor. Might need to modify the BDF to add a new regdb. See https://github.com/openwrt/openwrt/pull/14922#issuecomment-2050606914
maybe some one can assist here:
the board was extracted with ath11k-bdencoder, to provide "bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=TP-Link-EAP620HD-v2.bin"
i had gotten the regdb.bin from ea610-outdoor and put it in with ath11k_bdf_tool.py
now the question i have is how to create a new board-2.bin based off of this updated "bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=TP-Link-EAP620HD-v2.bin"
@mrnuke did you have eth0 show up for the eap610-outdoor or just this?
root@OpenWrt:~# ifconfig -a
br-lan Link encap:Ethernet HWaddr 34:60:F9:E5:DA:D2
inet addr:192.168.107.71 Bcast:192.168.107.255 Mask:255.255.255.0
inet6 addr: fe80::3660:f9ff:fee5:dad2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:500573 errors:0 dropped:45859 overruns:0 frame:0
TX packets:2427 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:365078682 (348.1 MiB) TX bytes:614725 (600.3 KiB)
lan Link encap:Ethernet HWaddr 34:60:F9:E5:DA:D2
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:507198 errors:0 dropped:1513 overruns:0 frame:0
TX packets:2425 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:375903846 (358.4 MiB) TX bytes:629599 (614.8 KiB)
Base address:0x1800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:383 errors:0 dropped:0 overruns:0 frame:0
TX packets:383 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:56351 (55.0 KiB) TX bytes:56351 (55.0 KiB)
The way I understand the regdb change is that one works on the raw BDF (board.bin), then repackages it with ath11k-bdencoder. lan instead of eth0 is normal.
All is working now 5g + 2g. Happy to push this up for review
one notice on looking at the radio's it seems the noise is almost too good? a neighboring ap (wifi ac non ax), shows about -90 for 5g. is this to be expected or might be a bug?
Possibly the device from your neighbor is Mediatek based?
Mediatek and Qualcomm tend to 'calculate' the noise floor differently.
See also SNR readings in OpenWRT 23.05.5 vary between devices in the same location
just an update after some time..
- re-sumbitted a PR to add device support
- on reboot of AP, MAC's are changed. Its annoying and im not exactly sure how i'd go about resolving it
- Wifi clients (i.e thinkpad amd gen1) disconnect regularly
- wifi roaming towards the AP is not working and results in a disconnect (ive tried with 802.11r and without)
if anyone has ideas to try for the issues im all ears 
another update and plea;
mac's with network config are persisting so this is fixed/fine.
Clients seem to be ok its only roaming events to the AP that are still perplexing me in some weird ways:
heres the ap log debug:
Tue Jul 22 14:11:07 2025 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED c0:3c:59:4d:e8:51
Tue Jul 22 14:11:07 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: event 3 notification
Tue Jul 22 14:11:07 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.1X: unauthorizing port
Tue Jul 22 14:11:07 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.11: deauthenticated
Tue Jul 22 14:11:07 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 MLME: MLME-DEAUTHENTICATE.indication(c0:3c:59:4d:e8:51, 3)
Tue Jul 22 14:11:07 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 MLME: MLME-DELETEKEYS.request(c0:3c:59:4d:e8:51)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.11: start SAE authentication (RX commit, status=126 (SAE_HASH_TO_ELEMENT))
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.11: SAE authentication (RX confirm, status=0 (SUCCESS))
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 MLME: MLME-AUTHENTICATE.indication(c0:3c:59:4d:e8:51, unknown)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 MLME: MLME-DELETEKEYS.request(c0:3c:59:4d:e8:51)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.11: association OK (aid 1)
Tue Jul 22 14:11:23 2025 daemon.info hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.11: associated (aid 1)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 MLME: MLME-ASSOCIATE.indication(c0:3c:59:4d:e8:51)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 MLME: MLME-DELETEKEYS.request(c0:3c:59:4d:e8:51)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.11: binding station to interface 'phy0-ap0'
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: event 1 notification
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: start authentication
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.1X: unauthorizing port
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: sending 1/4 msg of 4-Way Handshake
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: received EAPOL-Key frame (2/4 Pairwise)
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: sending 3/4 msg of 4-Way Handshake
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: received EAPOL-Key frame (4/4 Pairwise)
Tue Jul 22 14:11:23 2025 daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED c0:3c:59:4d:e8:51 auth_alg=sae
Tue Jul 22 14:11:23 2025 daemon.debug hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 IEEE 802.1X: authorizing port
Tue Jul 22 14:11:23 2025 daemon.info hostapd: phy0-ap0: STA c0:3c:59:4d:e8:51 WPA: pairwise key handshake completed (RSN)
Tue Jul 22 14:11:23 2025 daemon.notice hostapd: phy0-ap0: EAPOL-4WAY-HS-COMPLETED c0:3c:59:4d:e8:51
for the client device, it typically keeps the connection to ssid status but all traffic is dropped and eventually the client disconnects. Reconnection takes 1-3mins.
I have tried disabling mac agiging on both ssid bridges but roaming is still broken.
/usr/sbin/brctl setageing br-lan 0
/usr/sbin/brctl setageing br-iot 0
and an identicital config for a nano-hd ap is working with roaming perfectly. So i dont think its my AP config being the issue but something in IPQ6018 device support. Perhaps a patch is required?
update:
Now roaming is fixed for this device with this patch big thanks to @Flole
Hello everyone,
I just received an EAP620 HD V2. However, I can only find a snapshot version for the V1 in the firmware selector. Are the two identical, or is there no snapshot version for V2 yet?
I would like to equip the AP with OpenWrt.
As it is a hardware revision, it’s quite possible they are incompatible, I don’t see an entry for it on the wiki either. It could even be a completely different board, as was the case for the EAP610 v3 (which happens to be the same as an EAP613, other than some minor differences)
It’s also possible that it was a minor change, but it’s impossible to say without taking a good look at the hardware and software, and noting the differences. If it was a recent revision, it is unlikely to be supported yet.
