[PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Carl Quist]

Allow 8723d to operate a station and an AP interface concurrently, using
the combination already enabled for 8822c: one station plus one AP on the
same channel.

Without it, the AP interface cannot be brought up while the station is
active (hostapd: "Could not set interface ap0 flags (UP): Device or
resource busy"), so an RTL8723DE laptop cannot share its Wi-Fi
connection.

Tested on RTL8723DE [10ec:d723], firmware 48.0.0, kernel 7.2.5, with
hostapd 2.12 on a second (AP) interface with its own MAC address:

- the AP ran beside the associated station on 2.4 GHz channel 1 (HT20)
  for about four hours and served a smartphone client;
- the AP was started and stopped repeatedly without affecting the
  station;
- with the AP running, the station was disconnected and reconnected
  four times; it re-associated within one second each time and the AP
  stayed up.

Assisted-by: LLM
Signed-off-by: Carl Quist <equalizerjr@gmail.com>
---

Notes:
    An AI coding assistant (Claude Opus 5.5) helped investigate this, write the
    change and run the tests above; I reviewed the change and tested it on my
    own RTL8723DE laptop.

 drivers/net/wireless/realtek/rtw88/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 0f23498..c64a3ba 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -2299,7 +2299,8 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
 	hw->wiphy->max_scan_ssids = RTW_SCAN_MAX_SSIDS;
 	hw->wiphy->max_scan_ie_len = rtw_get_max_scan_ie_len(rtwdev);
 
-	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C) {
+	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C ||
+	    rtwdev->chip->id == RTW_CHIP_TYPE_8723D) {
 		hw->wiphy->iface_combinations = rtw_iface_combs;
 		hw->wiphy->n_iface_combinations = ARRAY_SIZE(rtw_iface_combs);
 	}
-- 
2.55.0

Re: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Luka Gejak]

Hi Carl,

On Fri Oct 16, 2026 at 11:41 PM CEST, Carl Quist wrote:
> Allow 8723d to operate a station and an AP interface concurrently, using
> the combination already enabled for 8822c: one station plus one AP on the
> same channel.
>
> Without it, the AP interface cannot be brought up while the station is
> active (hostapd: "Could not set interface ap0 flags (UP): Device or
> resource busy"), so an RTL8723DE laptop cannot share its Wi-Fi
> connection.
>
> Tested on RTL8723DE [10ec:d723], firmware 48.0.0, kernel 7.2.5, with
> hostapd 2.12 on a second (AP) interface with its own MAC address:
>
> - the AP ran beside the associated station on 2.4 GHz channel 1 (HT20)
>   for about four hours and served a smartphone client;
> - the AP was started and stopped repeatedly without affecting the
>   station;
> - with the AP running, the station was disconnected and reconnected
>   four times; it re-associated within one second each time and the AP
>   stayed up.
>
> Assisted-by: LLM
> Signed-off-by: Carl Quist <equalizerjr@gmail.com>
> ---
>
> Notes:
>     An AI coding assistant (Claude Opus 5.5) helped investigate this, write the
>     change and run the tests above; I reviewed the change and tested it on my
>     own RTL8723DE laptop.
>
>  drivers/net/wireless/realtek/rtw88/main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index 0f23498..c64a3ba 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -2299,7 +2299,8 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
>  	hw->wiphy->max_scan_ssids = RTW_SCAN_MAX_SSIDS;
>  	hw->wiphy->max_scan_ie_len = rtw_get_max_scan_ie_len(rtwdev);
>  
> -	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C) {
> +	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C ||
> +	    rtwdev->chip->id == RTW_CHIP_TYPE_8723D) {
>  		hw->wiphy->iface_combinations = rtw_iface_combs;
>  		hw->wiphy->n_iface_combinations = ARRAY_SIZE(rtw_iface_combs);
>  	}

Where does the AP beacon fit in the reserved pages?

This chip has 8 pages of 128 bytes, while rtl8822c has 16, so the 8822c
never had to squeeze a beacon in next to the station pages.

A station vif always adds five reserved packets in
rtw_add_rsvd_page_sta() and each one is counted after
rtw_fill_rsvd_page_desc() adds the 40 byte tx descriptor. Four of them
take one page, rtw_lps_pg_dpk_hdr is 169 bytes and takes two, so 6 of
the 8 pages are gone before the beacon is even considered. The beacon is
first in the list and its descriptor counts too:

		total_page += rtw_len_to_page(iter->len + tx_desc_sz,
		                              page_size);

That leaves 2 pages, so the beacon has to stay <= 216 bytes. Past that
rtw_build_rsvd_page() fails with "rsvd page over size" and
rtw_fw_download_rsvd_page() returns before rtw_download_beacon() runs.
rtw_ops_bss_info_changed() ignores the error, so hostapd thinks the AP is
up but no beacon ever reaches the firmware.

I ran this on an RTL8723DU with your patch applied. A stock hostapd WPA2
beacon came to 188 bytes and 28 bytes of extra IE still fit. At 29 bytes
the driver logged "rsvd page over size: 9" and "failed to build rsvd page
pkt" while hostapd still reported the AP as enabled. Scans still list the
SSID because probe responses go out over the normal path, so the failure
is easy to miss.

A longer SSID, WPS or a vendor IE all add bytes to the beacon, so this is
easy to reach in everyday usage.

Can the station pages be trimmed while an AP is present, or maybe this
combination should only be used on the chips with the bigger page budget?

Best regards,
Luka Gejak

Re: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Carl Quist]

Hi Luka,

Thanks for the review, and for testing it on an RTL8723DU.

On Sat Oct 17, 2026 at 10:41 AM, Luka Gejak wrote:
> Where does the AP beacon fit in the reserved pages?
>
> This chip has 8 pages of 128 bytes, while rtl8822c has 16, so the 8822c
> never had to squeeze a beacon in next to the station pages.

You are right, I missed this. I went through rtw_build_rsvd_page() and
get the same numbers: the five station packets take 6 of the 8 pages,
which leaves 2 pages, so the beacon must stay at or below 216 bytes.

> Can the station pages be trimmed while an AP is present, or maybe this
> combination should only be used on the chips with the bigger page budget?

I think they can be trimmed for every station, not only while an AP is
present. Two of the five packets, RSVD_LPS_PG_DPK and RSVD_LPS_PG_INFO,
take 3 pages, but their locations are only read by rtw_fw_set_pg_info(),
which only runs in LPS_DEEP_MODE_PG. rtw_update_lps_deep_mode() never
picks that mode unless the chip sets BIT(LPS_DEEP_MODE_PG) in
lps_deep_mode_supported, and only 8822c does; 8723d has 0.

So for v2 I plan to add a patch before this one that only reserves those
two pages on chips with LPS PG. That leaves 5 pages for the beacon next
to a station on 8723d, i.e. up to 600 bytes, and changes nothing for
8822c.

Before sending v2 I will repeat your check on my RTL8723DE: grow the
beacon past 216 bytes with vendor_elements in hostapd and confirm there
is no "rsvd page over size" and the beacon is actually transmitted.

Ping-Ke, does that approach look acceptable to you, or would you prefer
to keep the combination limited to 8822c?

Best regards,
Carl

RE: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Ping-Ke Shih]

Carl Quist <equalizerjr@gmail.com> wrote:
> Ping-Ke, does that approach look acceptable to you, or would you prefer
> to keep the combination limited to 8822c?

As you confirmed RTL8723DE work well, it is okay to me. 

Did you setup an air sniffer to capture packets? I suggest you can have one
to check AP behavior including:
1. The beacon is sending on time. (100TU)
2. Is the behavior expected with DTIM=3 ?
3. When connected station goes sleep and AP send a packet to the station, 
   the corresponding TIM bit is set?
4. broadcast/multicast is sent right after beacon (by ATIM window register)
5. Combine 2 and 4, checking corresponding TIM bit is set?

Ping-Ke

Re: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Carl Quist]

Hi Ping-Ke,

Thanks for the review.

Ping-Ke Shih wrote:
> As you confirmed RTL8723DE work well, it is okay to me.
>
> Did you setup an air sniffer to capture packets? I suggest you can have
> one to check AP behavior including:

No, I have not. I only have this one RTL8723DE laptop and no second
Wi-Fi adapter that can capture in monitor mode, so I cannot check the
five points you listed over the air (beacon interval, DTIM behavior, the
TIM bit for a sleeping station, and broadcast/multicast after the
beacon).

What I did test on the RTL8723DE (kernel 7.2.5, hostapd 2.12, station
and AP on 2.4 GHz channel 1):

- With v1, the AP served a phone beside the station for about four
  hours, and the station re-associated within one second each of four
  times I disconnected it with the AP running.
- With the LPS PG patch, beacons of 192, 312 and 592 bytes were built
  and downloaded without any "rsvd page over size" error (a 312 byte
  beacon failed without it), and a 639 byte beacon was still rejected,
  as calculated.

That last test only shows that the driver builds and downloads the
beacon. It does not show what is transmitted over the air.

Would you be fine with sending v2 as it is, with the commit message
stating exactly what was and was not tested? Or would you rather wait
until someone with a sniffer can run your checks? If there is a way to
check any of those points with a single adapter, I am happy to try it.

Best regards,
Carl

RE: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Ping-Ke Shih]

Carl Quist <equalizerjr@gmail.com> wrote:
> Would you be fine with sending v2 as it is, with the commit message
> stating exactly what was and was not tested? Or would you rather wait
> until someone with a sniffer can run your checks? 

With your tests from user point of view, I think it is okay. That'd be
good if someone can capture a sniffer and analyze it, but that isn't
a blocking item to merge this patch. Please follow Luka's suggestions
to spin v2. 

> If there is a way to
> check any of those points with a single adapter, I am happy to try it.

I think no. Driver isn't aware that packets sent by firmware/hardware.

Ping-Ke

Re: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Luka Gejak]

October 25, 2026 at 3:38 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:


> 
> Carl Quist <equalizerjr@gmail.com> wrote:
> 
> > 
> > Would you be fine with sending v2 as it is, with the commit message
> >  stating exactly what was and was not tested? Or would you rather wait
> >  until someone with a sniffer can run your checks?
> > 
> With your tests from user point of view, I think it is okay. That'd be
> good if someone can capture a sniffer and analyze it, but that isn't
> a blocking item to merge this patch. Please follow Luka's suggestions
> to spin v2. 

I can test v2 on rtl8723du and another card as a sniffer if that helps :)

> 
> > 
> > If there is a way to
> >  check any of those points with a single adapter, I am happy to try it.
> > 
> I think no. Driver isn't aware that packets sent by firmware/hardware.
> 
> Ping-Ke
>