Connect Raspberry with Android through Wifi Direct (p2p) services

Question

I'm trying to connect an android app with a raspberry using OS jessie 8.

I can connect manually if only one android device is available near the raspberry. But if there is more than one android device available I can't identify which device the raspberry has to connect. To solve this I am trying to use WifiP2P Services.

I'm using something like this configuration.

p2p_supplicant.conf:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
driver_param=p2p_device=1
update_config=1
device_name=Pi
device_type=1-0050F204-1
p2p_go_intent=1
p2p_go_ht40=1

Config for the wlan interface:

sudo wpa_supplicant -B -dd -iwlan0 -Dnl80211 -c/etc/wpa_supplicant/p2p_supplicant.conf

I use wpa_cli v2.3 to connect manually to the android device. But I can't obtain any information about the service (i.e service name or any service related info), I only receive the following:

>p2p_find
<3>P2P-DEVICE-FOUND 8a:79:7e:12:0f:22 p2p_dev_addr=8a:79:7e:12:0f:22 pri_dev_type=10-0050F204-5 name='Moto G (4)' config_methods=0x188 dev_capab=0x25 group_capab=0x0
>p2p_peers
8a:79:7e:12:0f:22
>p2p_serv_disc_req 00:00:00:00:00:00 02000001
P2P-SERV-DISC-RESP 8a:79:7e:12:0f:22 82 81000101002436383539646564652d383537342d353961622d393333322d313233343536373839303132095f70726573656e6365c00c0010011562756464796e616d653d4a6f686e20446f65363234116e616d653d5f766963696e69747961707011617661696c61626c653d76697369626c650f6c697374656e706f72743d363736373900010100095f70726573656e6365c00c000c012436383539646564652d383537342d353961622d393333322d313233343536373839303132c027

From the documentation I know that the event P2P-SERV-DISC-RESP should have the format:

P2P-SERV-DISC-RESP: Indicate reception of a P2P service discovery response. The following parameters are included after the event prefix: source address, Service Update Indicator, Service Response TLV(s) as hexdump.

But, I can't decode the tlv's response. I tried to use online decoders but They are not working either.

How can I decode this tlv's response? or if I can't, How can I can identify the android device?

Answer 1

Just for (partial) completeness - despite the question being years old - the converter at this link:

https://tomeko.net/online_tools/hex_to_ascii.php?lang=en

decodes the last hex string i.e. 81000101002436383539646564652d383537342d353961622d393333322d313233343536373839303132095f70726573656e6365c00c0010011562756464796e616d653d4a6f686e20446f65363234116e616d653d5f766963696e69747961707011617661696c61626c653d76697369626c650f6c697374656e706f72743d363736373900010100095f70726573656e6365c00c000c012436383539646564652d383537342d353961622d393333322d313233343536373839303132c027 to:

[129][0][1][1][0]$6859dede-8574-59ab-9332-123456789012[9]_presence[192][12][0][16][1][21]buddyname=John Doe624[17]name=_vicinityapp[17]available=visible[15]listenport=67679[0][1][1][0][9]_presence[192][12][0][12][1]$6859dede-8574-59ab-9332-123456789012[192]'

From this I presume the following:

Local URL: 6859dede-8574-59ab-9332-123456789012._presence._tcp

Service Information:

1. buddyname=John Doe624
2. name=_vicinityapp
3. available=visible
4. listenport=67679

According to the link the decimal values in the square brackets correspond to bytes outside 32...126 range and although I've been able to decode some of them below, some I haven't yet yet.

However the text 8a:79:7e:12:0f:22 is the sending device's Mac Address, which clears that up.

The single quotation mark at the end after the [192], vis-a-vis [192]' seems to be the end of the intended message because in my experience the message will occasionally repeat itself straight afterwards, and it is not unusual to see four or five message repetitions in a row with [192]' at the end of each repetition.

However we can decode it further:

[129][0][1][1][0]$6859dede-8574-59ab-9332-123456789012[9]_presence[192][12][0][16][1][21]buddyname=John Doe624[17]name=_vicinityapp[17]available=visible[15]listenport=67679[0][1][1][0][9]_presence[192][12][0][12][1]$6859dede-8574-59ab-9332-123456789012[192]'

Note the dollar sign ($), which is directly before the Guid, the hex for the dollar is 24, which in decimal is 36 ... and the guid is 36 characters long.

So now it gets easier -

• [9]_presence equates to _presence being 9 characters long ...
• [21]buddyname=John Doe624 equates to buddyname=John Doe624 being 21 characters long ...
• [17]name=_vicinityapp - you guessed it, the following is 17 characters ...
• [17]available=visible - once again, 17 characters long ...
• [15]listenport=67679 - 15 characters long ...
• [9]_presence - 9 characters long ...
• $6859dede-8574-59ab-9332-123456789012 - as repeated from above, the $ means 36 characters long ...

"MAGIC NUMBERS"

So that leaves the following 'magic number' parts to resolve:

• [129][0][1][1][0] (at the start)
• [192][12][0][16][1] (separating the preceding guid + bonjour fragment from the service information strings that follow)
• [0][1][1][0] (after the service information strings but before the second bonjour dns fragment)
• [192][12][0][12][1] (before the guid being repeated)
• [192] (after the repeated guid but before the repetition marker)

However it would seem that the [192] represents a change in the following data context - and as the ascii for 192 is a right-angle (tangent), it seems that as a separator, what follows a 192 is tangential to what preceded the 192.

And that seems reasonable because it would indicate that before the first 192 is the header, before the second 192 are the components that make up the bonjour domain url, what precedes the next 192 is the service information dictionary (however my conundrum here is that the 2nd bonjour fragment is with the service information dictionary), what precedes the last 192 (despite being a repeat of the guid) is the unique part of the bonjour url which as a key distinguishes this service from other services.

I'll work on that and comment when I make more progress.