search

albfan / miraclecast

Connect external monitors to your system via Wifi-Display specification also known as Miracast
Other
3.81k stars 411 forks source link

Handeling P2P-INVITATION-REQUEST, RX-PROBE-REQUEST, STA-OPMODE-SMPS-MODE-CHANGED from Windows 10 (as source) #495

Open AnuragIroh opened 1 year ago

AnuragIroh commented 1 year ago

GroupClientLogs.zip FailedGroupOwnerLogs.zip A valid example of communication is needed to implement it

Originally posted by @albfan in https://github.com/albfan/miraclecast/issues/407#issuecomment-1553722117

I have been trying to get seamless screen casting from Windows PCs as source (trying on Windows 10) to my Debian OS as sink. There are following issues so far :

  1. Connecting successfully but it takes 2 mins -- source sends P2P-INVITATION-REQUEST and after 1min 50s send P2P-PROV-DISC-PBC-REQ. It connects successfully thereafter, but I don't want that 2 min delay. I understand there was a persistent group formed earlier which leads to invitation. Therefore I tried to make sink a GO (set the p2p_go_intent=15), point 2 covers what happens in that case.
  2. Trying to connect with p2p_go_intent=15, I see RX-PROBE-REQUEST and OPMODE-SMPS-MODE-CHANGED which go unhandled. It goes till AP-STA-CONNECTED then I see BSS-REMOVED and things go haywire.
  3. After successful connection, when I try to use vlc -vvv rtp://@7236, it does show the stream (with 0.5 second delay) but it becomes unresponsive intermittently. Also lot of packet drop and errors in the gstreamer run by miraclecast. It could be because I have not set the sink capabilities correctly through .miraclecast config, any comments are welcome here.

I am mainly looking to solve point 1 & 2. As 3 is more about handling the RTP stream but comments are welcome.

Source is looking for some input surely and its critical for it to work. Question is does wpasupplicant do it without any explicit p2p* commands or do we have to handle that through some such command ?

I was analyzing trace logs from wpa_supplicant and I saw this : 

Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: Update WFD IE
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Beacon - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for (Re)Association Request - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for GO Negotiation - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Provision Discovery Request - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Probe Request - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Probe Response - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for P2P Invitation - hexdump(len=0):
Sep 16 13:50:46 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Provision Discovery Response - hexdump(len=0):
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: Update WFD IE
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Beacon - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for (Re)Association Request - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for GO Negotiation - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Provision Discovery Request - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Probe Request - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Probe Response - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for P2P Invitation - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 16 13:50:50 letsving miracle-wifid-wlp0s20f3-3[310799]: WFD: WFD IE for Provision Discovery Response - hexdump(len=15): dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8

If wpasupplicant is going to do it based on above mentioned settings : how do I set these ? Any resources would help. Or if we have to respond with some p2p*, I think it will be p2p_connect [to be figured].

As mentioned in another issue, miracle-dhcp is not doing good job of handling GO groups properly. Does it also affect the joining of GO group ? I am not sure if Go Client has to send some info regarding the persistent group to join it (other than available sa, go_dev_addr and bssid).

PS: I am willing to work on it please guide me a little here. ./test-viewer.sh passes.

albfan commented 1 year ago

If miraclecast is not GO it should just work, but you need to use FAQ: https://github.com/albfan/miraclecast/wiki/FAQ#microsoft-os-support as microsoft needs extra config

AnuragIroh commented 1 year ago

@albfan Thanks for the reply! Connection did get established and I was using the config already (my bad I didn't mention that).

Point 1 (Solved)

Problem here was the time it was taking to connect (which was 2 mins except when connecting for first time). There was a PROV_DISC_PBC_REQ but after around 1min 40 secs (after which connection used to get established). I was getting P2P-INVITATION-REQUEST to which wpa_supplicant was sending an IE packet (IE1).

I managed to eliminate this delay by adding persistent_reconnect=1, p2p_cli_probe=1, disable_scan_offload=1 in config of wpa_supplicant. I checked the logs to see what is different, now it was sending IE packet (IE2)

Following are IE1 and IE2 respectively : 

Sep 16 17:51:12 letsving miracle-wifid-wlp0s20f3-3[31948]: Pending TX frame - hexdump(len=38): 04 09 50 6f 9a 09 04 01 dd 0d 50 6f 9a 09 00 01 00 01 05 02 00 00 00 dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8
Sep 18 16:40:59 letsving miracle-wifid-wlp0s20f3-3[67536]: Pending TX frame - hexdump(len=38): 04 09 50 6f 9a 09 04 34 dd 0d 50 6f 9a 09 00 01 00 08 05 02 00 00 00 dd 0d 50 6f 9a 0a 00 00 06 00 11 1c 44 00 c8

One octet are different (i.e 01 34)

In the case of sending IE2 I immediately got 

Sep 18 16:40:59 letsving miracle-wifid-wlp0s20f3-3[67536]: P2P: Invitation from peer 2c:XX:XX:XX:XX:e9 was rejected (status 8)

So I am guessing windows didn't fret much about persistent group and made new one after that.

Point 2 (Unsolved)

Around using it as GO (it still doesn't work), I checked that DHCP(DISCOVER, OFFER, REQUEST, ACK) seemed fine, but then I got WLAN_FC_STYPE_DEAUTH which I think means the GC (windows 10 here) want to drop off.

Can you can share what is probably wrong with current implementation that we face issues with Miraclecast as GO ?

Point 3 (Solved)

Earlier I had copy pasted the example configuration, when I removed the parameters were weren't sure of it works much better.

Thanks a ton for your amazing work! I would love to contribute, maybe I can help with the GO issue.

albfan commented 1 year ago

Remove delay on Windows connection is really interesting, feel free to edit wiki with your parameter findings, we can dig on that

albfan commented 1 year ago

About GO, I think the miracle-dhcp implementación is wrong, but I cannot find a way to test implementation

AnuragIroh commented 1 year ago

I have removed the delay to a great extent now (2-3 secs). There were couple of more flags which were useful namely :

  1. update_config=1 -- after this the network information of the p2p_group we join are appended to the config and if the same config is used the p2p group re-invocation works successfully and I get P2P_INVITATION_ACCEPTED. I had to copy the wpa_supplicant configuration file before killing miracle-wifid and then use that configuration file in sink. This fork has the changes.

  2. p2p_device_random_mac_addr=2 more on that here

Following is my config 

disable_scan_offload=1
driver_param=p2p_device=1
update_config=1
device_name="Tamada Media_Return"
device_type=1-0050F204-1
config_methods=pbc
p2p_go_intent=0
persistent_reconnect=1
p2p_cli_probe=1
p2p_device_random_mac_addr=2

network={
        ssid="narendra-modem_5GHz"
        psk=0f5c44d0f7e067f840dcb29408fbe3f4efc1afde6e00914b48819b28adb9351b
}

network={
        ssid="narendra-modem_5GHz"
        psk=0f5c44d0f7e067f840dcb29408fbe3f4efc1afde6e00914b48819b28adb9351b
}

#Below p2p persistent group entry was added by the wpa_supplicant itself
network={
        ssid="DIRECT-NEJAYDEEP-LETSVINSHCM"
        bssid=dc:21:5c:8b:99:86
        psk=3a1cd81b58181f94c31a788c38408115bb3bbecc77cb27e7c33c7bbcfa9fbc16
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP
        auth_alg=OPEN
        disabled=2
}
AnuragIroh commented 1 year ago

About GO, I think the miracle-dhcp implementación is wrong, but I cannot find a way to test implementation

I was monitoring the GO failure with Wireshark on Windows (source) and I think dhcp was successful (as I saw lot DNS request going from assigned IP of windows to the IP of sink). As sink must initiate the RTSP connection, I saw TCP SYN but from source port 59520 to 7236 which seems wrong to me. Quoting the specification :

Note that the WFD Source can choose any value other than default 7236, and it should be within 49152 to 65535

Above seems to imply the source cannot choose 7236, and also as source didn't reply back to those TCP SYN we are doing something wrong.

@albfan am I making any sense here ?

chengpings commented 11 months ago

I have removed the delay to a great extent now (2-3 secs). There were couple of more flags which were useful namely :

  1. update_config=1 -- after this the network information of the p2p_group we join are appended to the config and if the same config is used the p2p group re-invocation works successfully and I get . I had to copy the configuration file before killing and then use that configuration file in sink. This fork has the changes.P2P_INVITATION_ACCEPTED``wpa_supplicant``miracle-wifid
  2. p2p_device_random_mac_addr=2 more on that here

Following is my config

disable_scan_offload=1
driver_param=p2p_device=1
update_config=1
device_name="Tamada Media_Return"
device_type=1-0050F204-1
config_methods=pbc
p2p_go_intent=0
persistent_reconnect=1
p2p_cli_probe=1
p2p_device_random_mac_addr=2

network={
        ssid="narendra-modem_5GHz"
        psk=0f5c44d0f7e067f840dcb29408fbe3f4efc1afde6e00914b48819b28adb9351b
}

network={
        ssid="narendra-modem_5GHz"
        psk=0f5c44d0f7e067f840dcb29408fbe3f4efc1afde6e00914b48819b28adb9351b
}

#Below p2p persistent group entry was added by the wpa_supplicant itself
network={
        ssid="DIRECT-NEJAYDEEP-LETSVINSHCM"
        bssid=dc:21:5c:8b:99:86
        psk=3a1cd81b58181f94c31a788c38408115bb3bbecc77cb27e7c33c7bbcfa9fbc16
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP
        auth_alg=OPEN
        disabled=2
}

What is the path to the configuration file? I tried the /etc/dbus-1/system.d/wpa_supplicant.conf path and it didn't work

AnuragIroh commented 11 months ago

@chengpings config file is in /run/miracle/wifi/