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 Wed, Jul 1, 2026 at 2:40 PM Doug Brewer wrote:
> >
> > 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.
> 
> One more update. Two RTL8852BE peers (STA + P2P) work reliably, as
> reported.
> 
> However, with a Samsung phone as the peer, GO negotiation is
> inconsistent — using your conf (including p2p_no_group_iface=1), the same
> setup sometimes completes and sometimes fails with GO-NEG Confirm timeout
> (status=-1).
> 
> Do you have any suggestion for this case with a real phone peer?

I'd suggest the simplest use case which your Samsung phone doesn't connect to
an AP, and remove all STA networks from the phone. That means the phone only
has one interface working on P2P. 

If you need to dig the problems related to P2P channels, I suggest you can
setup RTL8852BE sniffer to capture packets on two channels simultaneously.
One method is to install two RTL8852BE in a computer, and use single one
wireshark to capture two interfaces (setup the two channels manually).
The other is to setup two computers to capture each of two channels,
and then merge the sniffer files (note that you must synchronize the
host time to merge the files properly).

Ping-Ke