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

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

[Doug Brewer]

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?
2. would advertising a managed + P2P-client interface combination
    (single channel) be feasible on the current rtw89?
3. is MCC (#channels > 1) on the roadmap, or considered out of scope?

Regards,
Doug

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

[Ping-Ke Shih]

Doug Brewer <brewer.doug@gmail.com> 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.

Ping-Ke

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

[Doug Brewer]

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.

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?

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

Thanks,
Doug

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

[Ping-Ke Shih]

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

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

[Doug Brewer]

On Tue, Jun 30, 2026 at 8:51 AM Ping-Ke Shih wrote:
>
> Doug Brewer  wrote:
> > On Mon, Jun 29, 2026 at 10:10 AM Ping-Ke Shih  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.

Great progress using your test conf and a second RTL8852BE. Results:

Two RTL8852BE peers, no STA — P2P connects fine (GO/client, group formed,
4-way HS completed).

One RTL8852BE with STA on 5GHz ch149, the other RTL8852BE with no STA,
also succeeds. The GO comes up on ch153 while the STA stays on ch149 (so MCC),
group formed, client connected. Both sides confirmed via iw dev
(GO on ch153 + STA on ch149; peer client on ch153).

So STA + P2P coexistence, including MCC, works fine between two 8852BE peers.

p2p_no_group_iface=1 in your conf may have contributed, P2P runs on the main
interface instead of a separate group interface.

Thank you very much for the test conf and guidance.

> 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

Regards,
Doug