Miracast over Infrastructure

[TrololoManPL]

A very useful feature would be Miracast over Infrastructure, which is supported under Windows 10 1703 and later. In companion with Chromecast-like GUI this feature would make lazycast a very useful solution even in semi-corporate networks. Please consider adding it in future releases.

[homeworkc]

I will look into it. It does seem like a attractive feature and may solve the issue of unreliable a/v transmission, but I want to figure out a way so we don't have to modify the existing codes too much.

[pczekalski]

It would be great to have it. I'm thinking on converting our university DLPs into wireless ones using RPI3, but it would be easier to have them in common, infrastructure network, because if you use a laptop to connect to the DLP via WiFi, then you cannot connect parallel to another network i.e. to present on-line content.

[homeworkc]

I actually tried to implement it some time ago. It seems like it should be as simple as adding a few WPS IE to Beacon and Probe Response frame. I tried wpa_cli VENDOR_ELEM_ADD but it seems that this has no effects on the frames. Please let me know if anyone has figured out this problem.
(After that I discovered that Raspbian started to randomized MAC address of the P2P interface on every reboot so I shifted my focus to that issue. Again, let me know if anyone has any ideas.)
On the side note, wifi direct should allow concurrent connections. (That is, the laptop should be able to connect to the Internet on one interface while doing Miracast (on another "virtual" interface) simultaneously.) Even in this extension, wifi direct is still mandatory for device discovery.

[pczekalski]

I was thinking as temporary solution, to connect RPI using Ethernet to the infrastructure and configure routing /Nat for WiFi AP. Then connect to the WiFi both Miscast and regular. I just wonder, if it works, however.

…

On Tue, 5 Mar 2019, 08:47 homeworkc, ***@***.***> wrote: I actually tried to implement it some time ago. It seems like it should be as simple as adding a few WPS IE to Beacon and Probe Response frame. I tried wpa_cli VENDOR_ELEM_ADD but it seems that this has no effects on the frames. Please let me know if anyone has figured out this problem. (After that I discovered that Raspbian started to randomized MAC address of the P2P interface on every reboot so I shifted my focus to that issue. Again, let me know if anyone has any ideas.) On the side note, wifi direct should allow concurrent connections. (That is, the laptop should be able to connect to the Internet on one interface while doing Miracast (on another "virtual" interface) simultaneously.) Even in this extension, wifi direct is still mandatory for device discovery. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWoKxme0BePdyuL-zB79F8pZkmdarI92ks5vTiEugaJpZM4ZNUs-> .

[mirh]

https://git.codelinaro.org/clo/la/platform/frameworks/base/-/commit/18c58345bef2980d4c40eda3a626e6dbf4649e79
https://git.codelinaro.org/clo/la/platform/external/wpa_supplicant_8/-/commit/b32930059beef9965877dbbd53c227648b87c3c3

Qualcomm should have already implemented it.

[visbs]

any updates on this @homeworkc !

[homeworkc]

Not at the moment. The main issue here is to embed the information elements (IE) in beacon frames.

[ghost]

Hello homeworkc, I like the home work you are doing!
I would als like to have Miracast over Infrastructure. We have wired Infrastructure in our school and I tried Airserver and ScreenBeam for projection. They work as I expected, but what I figured out is:
You need the Beacon to establish the wired connection. Desktop PC works with WLAN Stick, but not without. You can remove the Stick when the connection is established.
But there is no other transfer over the WLAN Interface than the Beacon.
So what we would need to get this running is: lazycast with Support for Miracast over Infrastructure and something, that injects the Beacon Frame to the wired PC (do not know if npcap can do the trick).
What I can support is a captured on Air Packet (they differ for both products)

[homeworkc]

Thanks.
I've updated the README file and you can find more details in the spec. You're right about the overall transfer. In MICE, wifi direct is only used for device discovery while the negotiation and the actual screen data are transferred over ethernet or conventional wifi. So yes, a wifi stick is required even though it does very little in MICE. In the future, we might be able to emulate a wifi stick (either in software or using hardware like an ATmega32U4 or ATSAMD21) and eliminate wifi requirement completely.
I have figured out a way to embed the information elements (IE) in beacon frames. I also have been comparing Wireshark traces I collected when a PC is connected to another PC via MICE versus trying to connect to Pi. I found that without a proper mDNS configuration, a PC will not try to connect over Ethernet. Therefore, what we need to figure out now is the mDNS setting, which I think is mandatory ('MUST') according to the spec. If someone can figure out the mDNS setting, we will be closer to having a complete MICE function.

[ghost]

As I said I can send files to you, that you can analyze with wireshark. I made a trace with Airserver and one with ScreenBeam. I have been sitting on one end of our school with 2 PCs. One sending Beacons generated with python and the other making the connection to Airserver situated on the other end of the building. I used scapy and was able to send the beacon. You can have of course have my sources but I think here is not the place to share files.
And yes, i had a CNAME in our dhcp and you have to be on the same subnet.

[homeworkc]

Cool. Thanks for your help. I will send a private email to you if you want to send files or links. Currently I am able to send the beacon with all the required information so my focus right now is on the DNS part. According to the spec, we have to publish additional information (registering ._display._tcp.local and a TXT key-value pair) by DNS/mDNS on the sink (i.e., Pi). This information is exchanged on Ethernet and I think I have a rough idea of how to implement it.

[homeworkc]

The MICE feature works in the latest commit. It still has lots of rough edges and more tests may be needed but it does provide better experience especially using Ethernet.
This feature requires installing NetworkManager. Specifically, it requires controlling the wifi card using DBus and the easiest way to do it is using NetworkManager. DBus is needed since it is the only method to add WPS vendor extension without recompiling wpa_supplicant.
For those who are interested, the major pitfall I encountered was that the WPS vendor extensions have to be append immediately after the existing WPS information elements and it does not work if those information are contained in a separate information element.

[shayne]

You mention using specific IPs on both sides. I can get the mice.py to successfully register. When I connect it negotiates and then cannot bind right after printing out sourceip.

Any specifics on this setup not mentioned in readme?

[shayne]

Ended up getting it to work. Modified d2.py and set payer_select = 2 to use the h264 player. Working well!

[matham]

I'm following the mice guide, but it isn't clear to me whether I need to connect my desktop to pi via ethernet directly or pi to router via ethernet?

I connected the pi to router via ethernet, assigned pi static IP and added it to newmice.py. Windows is connect to router via wifi. But Windows doesn't see the pi when doing "connect". Is that incorrect and is there a way to do this via a router?

[homeworkc]

For mice, it should work if the desktop and pi are connected. (Basically it should work as long as the desktop can successfully ping pi.) It can be a direct ethernet connection, or both connecting to the same router. (Ethernet or WiFi should not matter, although I think I read somewhere that mice will not try to use an open WiFi network.)

[CaptainDaVinci]

Hi @homeworkc, any reason for using the WPSVendorExtensions property instead of P2PDeviceConfig.VendorExtension for setting the IEs? I'm trying to accomplish MICE but without sink acting as the GO group owner.

[homeworkc]

If I remember correctly, the reason is that specifically for MICE, the IE has to be one of the WPS IEs. I think setting VendorExtension will make it a separate IE, which did not work with Windows.

[CaptainDaVinci]

Thanks for the response @homeworkc, that helps. I was trying to map the WFDIEs set in newmice.py file to the WFD IE Device information subelements as defined in Wi-Fi display technical specifications, but they both don't seem to be co-related. Am I missing something here or do the WFDIEs set here map to something else entirely?