Closed dingo35 closed 4 years ago
benzea
commented
5 years ago What is the gnome-screencast/gnome-network-displays output?
It sounds like there is a codec support issue. The set of supported h264 encoders between miraclecast and gnome-screencast might be slightly different.
Please try making sure you have the openh264 gstreamer package installed (openh264 plugin and openh264enc element in gst-inspect-1.0). I'll be adding a UI to automatically prompt for installation.
dingo35
commented
5 years ago I didn't have openh264 installed, I understood that x264 was possible too, and x264 is packaged on Ubuntu.
It took me a long time to find my way through gstreamer/plugins/openh264, so for other readers here is how I installed the open264 and open264enc plugin: -first you have to install the openh264 package from openh264.org, BUT NOT the master; install the latest release from git, because the master will make that the gstream plugin will not compile! -enable source packages on Ubuntu -apt-get source gstreamer1.0-plugins-bad -cd gst-plugins-bad1.0-1.15.90 -mkdir builddir -cd builddir -ninja -ninja install Now this should install openh264 plugin, but it doesn't, so: -cd /usr/lib/x86_64-linux-gnu/gstreamer-1.0 Here is where all my gstreamer .so files reside... -cp -a /tmp/gst-plugins-bad1.0-1.15.90/builddir/ext/openh264/libgstopenh264.so .
So now that works: `root@laptop-hans:/usr/lib/x86_64-linux-gnu/gstreamer-1.0# G_MESSAGES_DEBUG=all gnome-network-displays (gnome-network-displays:13924): GLib-GIO-DEBUG: 13:28:21.500: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’ ** (gnome-network-displays:13924): DEBUG: 13:28:21.618: NdScreencastPortal: Aquired Portal proxy
(gnome-network-displays:13924): WARNING : 13:28:21.618: Could not create screencast portal proxy: De verbinding is gesloten
(gnome-network-displays:13924): WARNING : 13:28:21.618: Error initing screencast portal: De verbinding is gesloten
(gnome-network-displays:13924): WARNING : 13:28:21.618: Falling back to X11! You need to fix your setup to avoid issues (XDG Portals and/or mutter screencasting support)! (gnome-network-displays:13924): DEBUG: 13:28:21.625: WFDP2PRegistry: Found a new device, creating provider (gnome-network-displays:13924): DEBUG: 13:28:21.625: WFDP2PProvider: Found a new sink with peer 0x55c48edb2c50 on device 0x55c48ed9dad0 (gnome-network-displays:13924): DEBUG: 13:28:21.625: WfdP2PProvider: Discover is now set to 1 (gnome-network-displays:13924): DEBUG: 13:28:21.625: SinkList: Adding a sink (gnome-network-displays:13924): DEBUG: 13:28:21.644: NdPulseaudio: Querying sink info by name (gnome-network-displays:13924): DEBUG: 13:28:21.645: NdPulseaudio: Sink does not exist yet, loading module (gnome-network-displays:13924): DEBUG: 13:28:21.680: NdPulseaudio: Module loaded, we are ready to grab audio! (gnome-network-displays:13924): DEBUG: 13:28:21.695: WFDP2PRegistry: Got NMClient (gnome-network-displays:13924): DEBUG: 13:28:24.789: WfdP2PProvider: Discover is now set to 0 (gnome-network-displays:13924): DEBUG: 13:28:24.833: NdWfdP2PSink: Got P2P connection (gnome-network-displays:13924): DEBUG: 13:28:24.833: Found openh264enc for video encoding. (gnome-network-displays:13924): DEBUG: 13:28:24.833: Found x264enc for video encoding. (gnome-network-displays:13924): DEBUG: 13:28:24.833: Found vaapih264enc for video encoding. (gnome-network-displays:13924): DEBUG: 13:28:24.833: Found avenc_aac for audio encoding. ** (gnome-network-displays:13924): DEBUG: 13:28:24.834: Got state change notification from streaming sink to state ND_SINK_STATE_WAIT_SOCKET`
But still waiting for "Connecting" ..... finally says "Error" in the sink selection window.
Perhaps this syslog error has something to do with it: May 23 13:29:10 laptop-hans gnome-shell[1932]: JS ERROR: TypeError: connection.get_setting_ip4_config is not a function#012_isHotSpotMaster@resource:///org/gnome/shell/ui/status/network.js:1322:25#012getIndicatorIcon@resource:///org/gnome/shell/ui/status/network.js:1335:13#012_updateIcon@resource:///org/gnome/shell/ui/status/network.js:2029:52#012_syncVpnConnections@resource:///org/gnome/shell/ui/status/network.js:1832:9
...
Any idea how to solve this? Really appreciate your help!!!!
zapo
commented
5 years ago @dingo35
For the dummy interface connection I had better success using 127.0.0.1 instead of localhost in cvlc.
cvlc rtsp://127.0.0.1:7236/wfd1.0I might be wrong but make sure to restart gnome-network-displays in between tries as it seems it may be left in invalid state preventing further connections ... when that happen I saw that in logs:
Warning from inter video sink: Pipeline construction is invalid, please add queues.For the Samsung Smart TV connection, I have the exact same problem. No permission prompt and I'm left waiting in ND_SINK_STATE_WAIT_SOCKET state until it eventually hit a ND_SINK_STATE_ERROR (probably some sort of timeout). Miraclecast connects properly as you mentionned but can only be used as a sink and not a source.
I also tried using my Samsung phone ("Smart View" feature) using gnome-network-displays as well. This time I do get a wifi direct permission request but gnome-network-displays stays stuck in ND_SINK_STATE_WAIT_SOCKET like with the TV.
@benzea Let me know if you need help testing anything :)
benzea
commented
5 years ago @zapo, could it be that you have a firewall set up that blocks incoming requests?
zapo
commented
5 years ago @benzea I don't have any firewall running during testing as far as I know.
benzea
commented
5 years ago So, WAIT_SOCKET means that we are waiting on the TV to connect to the streaming server using RTSP and eventually we'll just time out and assume no connection will happen.
So for some reason, the TV is either not trying to connect or we are not receiving the connection attempt (hence why I asked about the possibility of a firewall).
Ah, it could well be that we only listen on IPv4 (which should be fine for miracast) and that this is the reason you see a failure when trying to connect to localhost (i.e. ::1 rather than 127.0.0.1).
dingo35
commented
5 years ago @zapo: using 127.0.0.1 instead of localhost makes no difference on my machine.
I'm trying to capture packets with both miracast and gnome-network-displays, to see what is the difference.
Here is the capture with miraclecast, where it scans for devices, finds the TV, starts and finishes a WPS session, then the TV asks for permission to connect, and after giving permission the TV stays in "waiting to connect" status:
miracle.permission.asked.and.given.out.gz
However, when trying to capture the gnome-network-displays traffic, I can capture no traffic between my laptop and my TV (which is impossible, since gnome-network-displays is detecting the TV). Any idea why capturing on my default wireless adapter is not working?
benzea
commented
5 years ago @dingo35 how are you creating the capture?
If you are using a different device to create the capture, then you may simply be on the wrong channel and not see anything. This comment describes how one can capture from the same machine https://github.com/benzea/gnome-screencast/issues/27#issuecomment-488726776
benzea
commented
5 years ago I'll think about it a bit. So the TV asks for permission which means it is using the push-button method for WPS. I thought that this should work fine, but maybe we have a really short timeout for the connection establishment on our side and that makes it fail?
dingo35
commented
5 years ago I am just using tcpdump -w file.out , which then runs on my wifi-adapter. The link you gave just creates another monitoring interface, AFAIK that would only generate only more non-relevant traffic (because the wifi-adapter would be in promiscuous mode).
The only relevant traffic I can discover is: -the TV sending out ARP requests -the TV sending out UDP traffic to 239.255.255. 250, which seems to be SSDP traffic...
EDIT: -also traffic TV sending out UDP to 10.1.0.255, exact same length as th SSDP packets, same layout (35 bytes of payload).
benzea
commented
5 years ago @dingo35, not quite. You need the monitoring interface to be able to see the low level wifi frames, i.e. wifi beacons and probe requests. This can be important to understanding what is going on exactly in some cases.
Though, if you already see UDP traffic from the TV, then the WiFi P2P connection is established. So I guess we are past that.
Do you see any DHCP requests/responses? Most likely your laptop is the group owner and NetworkManager should be putting the P2P device into "shared" mode. This means it will start dnsmasq as a DHCP server. Maybe something is not working with the DHCP server (I have had that happen when I had SELinux issues, though I think that caused a really quick connection failure).
dingo35
commented
5 years ago Ok hadn't thought about the beacons and the probes; I will make a monitor-packet dump when there's not so much interfering traffic ...
benzea
commented
5 years ago Nah, it should be fine, you got the P2P connection established. The only information that is encoded and is relevant should be the RTSP port. I have not yet had a closer look at the earlier dump you created.
dingo35
commented
5 years ago Please note that the dump I included is generated with the miraclecast software, NOT with gnome-network-displays!
And isn't it suspicious that the UDP-traffic from the TV is "send only"; it doesn't seem to get any replies from my laptop...
benzea
commented
5 years ago Not really, those are simply broadcasts about services it is offering.
benzea
commented
5 years ago So, all those UDP packets is the TV advertising apple air play and UPnP support. That seems reasonable, but really shouldn't matter to us.
I did not find any actual connection establishment in the miracle.permission.asked.and.given.out.gz dump.
dingo35
commented
5 years ago That is correct, as I said: "Here is the capture with miraclecast, where it scans for devices, finds the TV, starts and finishes a WPS session, then the TV asks for permission to connect, and after giving permission the TV stays in "waiting to connect" status:" .
The gnome-network-displays doesn't even get into the stage where the TV asks for permission, so I wanted to try to get it that far ....
zapo
commented
5 years ago I played with it again this morning and finally managed to get a connection to my TV (Samsung KS8000 firmware version 1233) using gnome-network-displays (streaming doesn't start yet though). The only way I get the permission prompt "reliably" on the TV is by opening the TV Wifi-Direct menu ("Network" > "Expert Settings") directly and hit the "Refresh" device list and attempt the connection from gnome-network-displays while it's refreshing ... not sure why/how that works (miraclecast doesn't require that and properly prompt for permission even when outside of that menu, same goes for when I connect from my phone to cast to the TV directly).
This brings up a p2p-wlp2s0-X interface that I'm able to capture from with wireshark tv.pcapng.tar.gz.
Not much happened in that session though beside me pinging the TV, it's like gnome-network-displays didn't detect that the connection got established (still stuck in WAIT SOCKET and the UI showing "connecting").
Hope that helps.
Note: I tried with and without IPv6 stack disabled as kernel param ipv6.disable=1 which didn't help much.
Edit: here is a longer/chattier session tv-chatty.pcapng.tar.gz but not much more than what happens with miraclecast happenned (mostly advertising services and me crashing the tv at the end)
dingo35
commented
5 years ago Ok new experiment: I set up an access point with only my laptop and the TV on it, so no interfering network traffic.
First I boot my laptop to Ubuntu 19.04, and start gnome-network-displays; like before, it detects the Samsung TV as a sink, but when selecting it it gets stuck at ND_SINK_STATE_WAIT_SOCKET. I captured the packets in gnome-network-display.eth.gz
Then I rebooted into windows, got into the "add devices" menu, where Windows detected the TV, then the TV asks permission to connect, after giving permission the TV shows an extension of the Windows Desktop (it can be configured to mirror the existing desktop too, but setting didn't seem relevant to this experiment). So with Windows 8.1 everything works ok, I captured the packets in: https://filebin.net/tx6995qikuu9m3en
(cannot upload files bigger than 10Mb so had to use external file service).
zapo
commented
5 years ago I've now been able to connect to my Samsung TV and stream to it (had to downgrade pipewire to 2.5 but that's an other story)! There seem to be a weird state sync/race somewhere (I think in network manager since I have the same issue when connecting directly using nmcli), but basically I have to watch for wpa supplicant logs with journalctl -fu wpa_supplicant and retry the connection everytime I see my device popping in a P2P-DEVICE-FOUND message like:
Jun 19 08:33:58 zapo wpa_supplicant[608]: P2P-DEVICE-FOUND 5e:49:7d:69:de:0a p2p_dev_addr=5e:49:7d:69:de:0a pri_dev_type=7-0050F204-1 name='[TV] Yolo' config_methods=0x188
dev_capab=0x25 group_capab=0x0 wfd_dev_info=0x01131c440036 vendor_elems=1 new=0if the connection doesn't work after a few seconds I have to cancel and wait for an other "P2P-DEVICE-FOUND" message ... after 1 or 2 tries it end up working (I get the exact same behavior when attempting the connection directly with nmcli) ... I wonder if the TV just broadcast too much itself and some peer state in network manager doesn't update properly (I don't have this problem using wpa_cli without NetworkManager directly)
@dingo35 not sure if that helps but you could try to establish the connection with network manager directly like:
nmcli connection edit type wifi-p2p con-name TVand in nmcli set it up like:
nmcli> set wifi-p2p.peer TV_MAC_ADDR # you can get that from looking at wpa_supplicant logs
nmcli> set wifi-p2p.wps-method pbc # I force push button connection cause I couldnt get the pin working with that TV
nmcli> set connection.autoconnect no
nmcli> save
nmcli> quitand then establish the connection with
nmcli connection up TVI noticed that after that connection is setup gnome-network-displays properly reuses it. You can check that by running nmcli connection to list all connections when connecting using gnome-network-displays.
if that still doesn't work you could try using wpa_supplicant directly with wpa_cli (need to stop NetworkManager and wpa_supplicant daemons first)
dingo35
commented
5 years ago 1) the P2P-DEVICE-FOUND trick doesn't work for me; in fact, starting
gnome-network-displays triggers this message...
2) the nmcli procedure doesn't work either.
I gave up on using Miracast, and installed minidlna to send content to
my Samsung TV, works like a charm!!!
Quoting Antoine Niek notifications@github.com:
I've now been able to connect to my Samsung TV and stream to it!
There seem to be a weird state sync/race somewhere (I think in
network manager since I have the same issue when connecting directly
using nmcli), but basically I have to watch for wpa supplicant logs
with journalctl -fu wpa_supplicant and retry the connection
everytime I see my device popping in a P2P-DEVICE-FOUND message like: Jun 19 08:33:58 zapo wpa_supplicant[608]: P2P-DEVICE-FOUND
5e:49:7d:69:de:0a p2p_dev_addr=5e:49:7d:69:de:0a
pri_dev_type=7-0050F204-1 name='[TV] Yolo' config_methods=0x188
dev_capab=0x25 group_capab=0x0 wfd_dev_info=0x01131c440036
vendor_elems=1 new=0 if the connection doesn't work after a few seconds I have to
cancel and wait for an other "P2P-DEVICE-FOUND" message.@dingo35[1] not sure if that helps but you could try to establish
the connection with network manager directly like: nmcli connection edit type wifi-p2p con-name TV and in nmcli set it up like: nmcli> set wifi-p2p.peer TV_MAC_ADDR # you can get that from looking
at wpa_supplicant logs nmcli> set wifi-p2p.wps-method pbc nmcli> set
connection.autoconnect no nmcli> save nmcli> quit and then establish the connection with nmcli connection up TV if that still doesn't work you could try using wpa_supplicant
directly with wpa_cli (need to stop NetworkManager and
wpa_supplicant daemons first)— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[2], or mute the thread[3].
[1] https://github.com/dingo35
[2]
https://github.com/benzea/gnome-network-displays/issues/32?email_source=notifications&email_token=ABOSIX742WNOWQSK7IZ3DDTP3ISXVA5CNFSM4HOTYQD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYBXURI#issuecomment-503544389
[3]
https://github.com/notifications/unsubscribe-auth/ABOSIXYZ27G5N52ESWAHYTLP3ISXVANCNFSM4HOTYQDQ
Mis012
commented
5 years ago If this thing doesn't even get as far as miraclecast, maybe you should have made it interoperate with it instead of reinventing the wheel (poorly) :/
benzea
commented
5 years ago @Mis012, miraclecast is primarily a sink implementation, cannot co-exist with a normal wifi connection, has no proper UI and does not support wayland.
Mis012
commented
5 years ago It has been kind of abandoned in a state where it doesn't support being a source, but it does seem like the fork is interested in a source implementation... It cannot coexist with a wifi connection managed by NetworkManager, I guess it could be even more modular in that regard. And maybe NetworkManager could be told to ignore just the p2p device? Proper UI is not as much of a concern, I'd prefer having to use a script to make multiple command line tools work together over something that may as well never be usable without a graphical toolkit, despite the fact that the miracast protocol is a protocol, and could easily support other usecases, such as streaming a video file or even be it's own monitor and not a mere copy Supporting wayland is also not something that feels related to miracast, even less miraclecast without any form of source implementation
benzea
commented
5 years ago @Mis012 , I really don't understand what you are trying to tell me with your comments here.
benzea
commented
4 years ago Closing this bug. Sorry, it does seem like there is some issue hidden in here, but it is hard to track down at this point (also as this bug has been side tracked quite a bit by people). And it seems like the original reporter has lost interest in tracking this down further.
When I run:
NETWORK_DISPLAYS_DUMMY=1 ./gnome-network-displays
I get a window with the dummy wfd sink, and after some time, it also finds my Samsung Smart TV:
Syslog:
When selecting the dummy sink, it keeps hanging on "Connecting", when I connect with VLC:
Syslog says:
...and immediately the window gets closed;
When I select my Samsung TV, it stays hanging on "connecting" too. When I use Windows 8.1 I can perfectly mirror the laptop's screen to the Samsung TV (it gets installed as a "projector"), so it cannot be a hardware problem.
When I use this software I actually get a connect, the Samsung TV shows a window where it wants permission for the laptop to connect.
The gnome-screencast software seems to be falling back to its X11 mode, but I understand that is expected behaviour.
I am running on Ubuntu 19.04 ; recompiling wpa_supplicant with version 2.8 (which has default P2P enabled) didn't make any difference.
What am I doing wrong?
EDIT: I am a newby on meson, so I just built it by going into the directory where README.md resides, do meson builddir, cd builddir, ninja. Hope that was alright, couldn't find any pointers in the doc...
EDIT: Added multiple quotations so that it is not inline code but multi-line.