RE: rtw89: RTL8852BE P2P-device iftype and STA+P2P interface combination

[Ping-Ke Shih <pkshih@realtek.com>]

Doug Brewer <brewer.doug@gmail.com> wrote:
> On Mon, Jun 29, 2026 at 10:10 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Doug Brewer wrote:
> > > Hi,
> > >
> > > I'm experimenting with Wi-Fi Display (Miracast sink) concurrent with an
> > > STA connection on an RTL8852BE (PCIe) using the mainline rtw89 driver
> > > (kernel 6.18.37).
> > >
> > > iw phy reports:
> > > Supported interface modes:
> > >    * managed, AP, P2P-client, P2P-GO
> > >    (no P2P-device)
> > > interface combinations are not supported
> > >
> > > In practice this blocks the standard P2P flow: there is no P2P-device
> > > iftype for a dedicated discovery context, and no advertised interface
> > > combination for managed + P2P-client coexistence.
> > >
> > > My questions:
> > > 1. is P2P-device iftype support planned for rtw89 on RTL885x? Is there a
> > >     known technical blocker, or is it simply not yet implemented?
> >
> > We are planning to add P2P-device iftype. It needs to consider the cases of
> > channel context, conditions of power save, and etc. It will take some time.
> >
> > I think it would be okay that you use STA interface to do P2P negotiation,
> > and then create P2P-client or P2P-GO iftype then.
> >
> > > 2. would advertising a managed + P2P-client interface combination
> > >     (single channel) be feasible on the current rtw89?
> >
> > This is a SCC which is supported.
> >
> > > 3. is MCC (#channels > 1) on the roadmap, or considered out of scope?
> >
> > Current support MCC as well. However, we are cooking new firmware to support
> > hw_scan with two operation channels -- which doesn't matter if you don't need
> > to do scan when MCC is operating.
> 
> Thanks for the suggestion. I tried using the STA interface for P2P
> negotiation, and wanted to share what I found.
> 
> With the STA connected (2.4GHz ch11) and an active p2p_connect, a
> wpa_supplicant -dd trace shows GO negotiation getting fairly far:
> 
> Peer's GO-NEG Request is received
> send the GO-NEG Response on ch11, peer ACKs it (TX ack=1)
> State goes GO_NEG -> CONNECT
> then time out waiting for the GO-NEG Confirm, status=-1
> 
> I select ch11 as the P2P operating channel (same as STA, SCC), while
> the peer's operating preference is 5GHz ch149. It looks like after we TX
> the Response, the radio doesn't stay on ch11 to listen for the Confirm,
> so the frame is missed -- presumably because the single radio is serving
> the STA connection.

So, peer doesn't stay ch11 to complete he negotiation, right?

What is the peer device you are using? Can you setup another RTL8852BE?
I suggest running simple scenario first to dig cause.

1. two peers make P2P group without any STA connection
2. RTL8852BE with a STA connection, and peer without connection. 

> 
> Aalso tested with the STA on 5GHz (ch149); the result is the same
> GO-NEG Confirm timeout.
> 
> Is this the channel-context issue that P2P-device iftype will address?
> And with the current driver, is there any way to keep the P2P listen
> context on the operating channel during GO negotiation while STA is up?

Before P2P negotiation completion, there is only one channel context.
The second interface (GC or GO) is created when the P2P role is decided
by P2P negotiation. 

You need to check supplicant log about channels on both peers. I think
remain-on-channel is the method supplicant switch channel to send
negotiation frames and to stay on listen channel. 

> 
> (FWIW, passing an explicit freq= to p2p_connect is rejected with FAIL,
> whether or not it matches the STA channel.)

Not sure why. In our side, it seems work.


I'd share a pair of wpa_supplicant .conf and wpa_cli commands we are testing
for reference.

Peer 1:
ctrl_interface=/var/run/wpa_supplicant
 
network={
        ssid="ap_x"
        key_mgmt=NONE
 
}
 
update_config=1
device_name=my_p2p
manufacturer=Realtek
model_name=RTW_STA
model_number=WLAN_CU
serial_number=12345
device_type=1-0050F204-1
os_version=01020300
config_methods=virtual_display virtual_push_button keypad
p2p_listen_reg_class=81
p2p_listen_channel=1
p2p_oper_reg_class=81
p2p_oper_channel=1
p2p_no_group_iface=1


wpa_supplicant -i wlan0 -c p2p.conf
wpa_cli
> p2p_find
> p2p_connect $SUT_MAC_ADDR pbc (freq=xxxx go_intent=15)


Peer 2:
ctrl_interface=/var/run/wpa_supplicant
update_config=1
device_name=my_p2p
manufacturer=Realtek
model_name=RTW_STA
model_number=WLAN_CU
serial_number=12345
device_type=1-0050F204-1
os_version=01020300
config_methods=virtual_display virtual_push_button keypad
p2p_listen_reg_class=81
p2p_listen_channel=1
p2p_oper_reg_class=81
p2p_oper_channel=1
p2p_no_group_iface=1

wpa_supplicant -i wlan0 -c p2p.conf
wpa_cli
> p2p_find
> p2p_connect $DUT_MAC_ADDR pbc (freq=xxxx go_intent=1)

Regards
Ping-Ke