I've done a quick round of testing some devices I had access to
against our sink-test and desktop_source, see
* Wi-Fi P2P mostly just works with current connman: we usually get a
RTSP connection with every device now
* Our RTSP handling seems fairly robust but we're probably going to
find lots of things to fix as we test with new devices (as an example:
the Netgear device seems to consider RTSP messages contents case
* desktop_source video format selection probably needs work before the
other sinks will play our stream
Unfortunately I don't have a Windows 8.1 machine with WiFi P2P capable
hardware as the Acer tablet broke. If anyone has a newish laptop I
could use (just for an hour or so), I'd appreciate it.
> Yep, in practice the sink always wants to be the GO.
> Though there IP bug on TCP connection is just a big _WTF_ :')
Yeah. It didn't make any sense... so I've been going through all the
DHCP fields today, and I think I found one interesting problem. It's
not in the stack we thought it was, at least not in the first place :)
Connman DHCP (both client and server) seems to have an endianness bug
with the dhcp server id (option 54). The data never seems to go
through htonl/ntohl even though other IP addresses (e.g. "requested
I'm not qualified to comment on whether the Netgear device should be
using option 54 for anything, but if my understanding is correct this
would explain so much... I showed a tcpdump to Jukka Rissanen and he
seemed to agree it's probably a connman bug.
Tomasz, can you check this -- should be easy to reproduce: either run
connman dhcp server and look at bootp messages in tcpdump, or just use
the client and print out the server id somewhere in the code.
Since I had to re-read the wifi display spec I thought I'd share my
findings. Tomasz: please comment if you have anything to add (note
that my interpretation of the spec is a bit different than it was on
First a little context for those who haven't heard of this: Connman
uses "go-intent" (a 0-15 figure that describes how much it wants to be
group owner & DHCP server) to a value 7. Android source seems to use
value 0 -- I'll still have to confirm the android value though. It
seems that using 7 with our desktop-source exposes bad bugs in some
sinks: Connman will end as the GO and DHCP server and It looks like
the sinks have not been tested in a situation where they are not the
GO & DHCP server.
The section "3.2.1 Wi-Fi P2P" says this:
| If a WFD Session including a single WFD Sink, either a WFD Source
| or a WFD Sink may be a P2P GO. If a WFD Session includes both a
| Primary Sink and a Secondary Sink, then the WFD Source shall be a
| P2P GO.
So what connman is doing _should_ be ok...
"4.9.4 WFD Device Pairing" says:
| If the underlying connectivity mechanism is resolved as Wi-Fi P2P,
| one of the following sequences is used to setup the corresponding
| connection between the WFD Source and WFD Sink(s):
| (a) If a P2P Group exists with the WFD Source as the P2P GO, the
| Primary and the Secondary Sinks join the existing P2P Group, or
| (b) The Primary or the Secondary Sink initiates a P2P Group
| formation procedure with the WFD Source setting the GO-intent
| to zero as defined in , indicating preference not to be the
| GO for the P2P Group (prior to the ensuing GO-negotiation phase
| of the Wi-Fi P2P connection setup), or
| (c) The WFD Source initiates a P2P Group formation procedure with
| the Primary Sink setting its GO-intent to indicate ‘GO-only’
| prior to the ensuing GO-negotiation phase of the Wi-Fi P2P
| connection setup.
The above is all in context of _coupled sink_ operation. It's written
quite badly but I read it like this:
b) If coupled sink initiates P2P group formation,
sink should set go-intent=0
c) If source initiates P2P group formation with primary (coupled) sink,
source should set go-intent=15
Implied: go-intent of the peer that does not initiate P2P group
formation is not specified
My first idea was that we should do what the coupled sink procedure
specifies in every case: If we're a sink, set go-intent=0. If we're a
source, set go-intent=15.
The problem is that this seems to go directly against the test
results: when we're a source and become the GO, the Netgear Push2TV
will get an IP but will then try to make an RTSP connection to
"22.214.171.124" -- seemingly an endianness bug in their end: I can only
assume they've never tested the case where they are DHCP client. If I
modify connman to use go-intent=0, then the Netgear device will become
GO & DHCP server and things Just Work...
At the moment I have no idea what connman or or wysiwidi should do
with regards to go-intent... I'll re-check the go-intent values
android source and some sinks are using at least.
The P2P code and its sink integration are now merged. It's not too
pretty (e.g. I still have to fix the whitespace nastiness that I
introduced while developing on the test machine without proper editor
settings) but it works _much_ more reliably than anything before this.
Naturally you should not expect this to work with connman that's older
than ~5 days.
There's also a PR for supporting the P2P code in source side:
With that patch you can use a wysiwidi source to stream to a wysiwidi
sink. The streaming is choppy but again, getting a connection is quite
reliable now so we can actually start debugging the gstreamer problems
Source usage: You can start a scan with command "scan" when running
the source (the initial scan happens automatically though). When sinks
are found they will be printed like this
0 : Wysiwidi Test
and then you can connect with "connect <index>" where index is the
number that was printed.
A quick report on the gstreamer & connman -using test-sink: I have a
version that pretty consistently works with Tomasz's latest connman
The testing instructions for this code:
* start supplicant, connmand
* connmanct: enable P2P tech
* connmanctl: "agent on"
* sink: start sink "sink/sink-test"
* Android: select the sink in "Settings>Display>Cast Screen" and start
* connmanctl: when agent asks, accept the connection
* sink: RTSP negotiation should now start and the video should show in a moment
* the network stack still goes in a bad state after a P2P connection:
need to restart everything in between tests
my todo list for next days:
* clean up my patches, make a PR (after connman patches go in)
* make sure the p2p API is useful for the source as well -- I've not
tested this part yet