How to I beam/send an URL to a Nexus Galaxy

Asked by Hartmut Benz

Thanks to the start-up from Stephen in https://answers.launchpad.net/nfcpy/+question/183886 I am now facing the actual challenge:

  write a mini-script that offers/beams a URL to a phone (SCM3711 to Galaxy Nexus)

So far, I have tried modifying snep-test-client.py to address "com.android.npp" (see below). The phone shows the 'beam' sequence, but it did not react to the URL I sent it, nor did the computer show any received data when I tried to beam anything to it (see below).

I've also tried things with npp test, but except for the phone making a noise of recognizing 'some' NFC, nothing happened.

Every nudge into the right direction is very welcome.

/Hartmut

Question information

Language:
English Edit question
Status:
Solved
For:
nfcpy Edit question
Assignee:
No assignee Edit question
Solved by:
Stephen Tiedemann
Solved:
Last query:
Last reply:
Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said :
#1

The Galaxy Nexus uses SNEP and the default SNEP server at service access point 4 (which corresponds to the service name "urn:nfc:sn:snep"). The SnepClient.put() method connects to the default SNEP server if not done with SnepClient.connect().

snep = nfc.snep.SnepClient()
snep.put( some ndef message )

Revision history for this message
Hartmut Benz (hartmut-benz) said :
#2

I've got the basic functionality working, i.e. the URL reaches the phone an it is reacting appropriately.

Is there a special way that I have to terminate the connection again?

Because the Linux side complains about "shutdown on link disruption", and the android side shows an error (and I did not remove the phone from the SLC3111):

01-17 08:58:16.249: D/dalvikvm(9931): GC_CONCURRENT freed <1K, 2% free 16951K/17287K, paused 1ms+2ms
01-17 08:58:16.553: I/NFC JNI(28396): LLCP Link deactivated
01-17 08:58:16.553: D/NfcService(28396): LLCP Link Deactivated message. Restart polling loop.
01-17 08:58:16.553: D/NfcService(28396): disconnecting from target
01-17 08:58:16.553: A/libc(28396): Fatal signal 11 (SIGSEGV) at 0x0000001c (code=1)

Here is the code I'm using (called like any test_n from snep-test-client.py):

validation_server = "urn:nfc:sn:snep"
def sendURL():
    message = UriRecord("http://www.google.com").tostring(True,True)

    snep = nfc.snep.SnepClient()
    try:
        info("connect to {0}".format(validation_server))
        snep.connect( validation_server )
    except nfc.llcp.ConnectRefused:
        raise TestError("could not connect to server")

    try:
        snep.put( message )
        time.sleep(0.5) # This sleep is crucial for the phone to accept it, though the time might be too long
    except Exception as e:
        TestError("exception: " + str(e))
    finally:
        info("disconnect from {0}".format(validation_server))
        snep.close()
        time.sleep(0.5)

Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said :
#3

For the link you're trying to send you should use a smartposter message. Then Android will dispatch it to the browser and open the page.

I don't know why Android crashes with your example. but that surely is the cause for "shutdown on link disruption" and indicates that the Android NFC stack stopped communicating for at least the link timout interval. You can enable debug messages for LLCP with "-d nfc.llcp" and for low level stuff with "-d nfc.dev".

Revision history for this message
Hartmut Benz (hartmut-benz) said :
#4

Hi Stephen
I am creating a SmartPoster now like this:
     uri = UriRecord("http://www.utwente.nl")
     sp = SmartPosterRecord()
     sp.uri = uri
     sp.title = "hallo"
     message = sp.tostring(True,True)

The phone apparently reads the smart poster (generally, it opens the browser; screenshot from reading the message with the NXP's
TagInfo.

The log from the phone (attached) still shows the signal 11 kill of of the link and the terminal running the connect prog mentions
link disruption (see below). The dongle stayed in reach of the phone the whole time. The phone beeped twice.

activated as p2p target in 424 kbps active mode
LLCP Link established, I'm the DEP Target
Local LLCP Settings
LLCP Version: 1.1
Link Timeout: 1000 ms
Max Inf Unit: 1024 octet
Service List: 0000000000000011
Remote LLCP Settings
LLCP Version: 1.0
Link Timeout: 1500 ms
Max Inf Unit: 128 octet
Service List: 0000000000000001
connect to urn:nfc:sn:snep
disconnect from urn:nfc:sn:snep
shutdown on link disruption
Script terminated.
/Hartmut

Revision history for this message
Hartmut Benz (hartmut-benz) said :
#5

Alas, the attached files did not make it..

Here is the terminal log *with* llcp debug switched on
Connection timed out
activated as p2p target in 424 kbps active mode
llc cfg {'recv-lto': 1500, 'send-miu': 128, 'send-agf': True, 'send-lto': 1000, 'send-lsc': 3, 'recv-miu': 1024, 'recv-wks': 3, 'send-wks': 1, 'rcvd-ver': (1, 0)}
LLCP Link established, I'm the DEP Target
Local LLCP Settings
LLCP Version: 1.1
Link Timeout: 1000 ms
Max Inf Unit: 1024 octet
Service List: 0000000000000011
Remote LLCP Settings
LLCP Version: 1.0
Link Timeout: 1500 ms
Max Inf Unit: 128 octet
Service List: 0000000000000001
connect to urn:nfc:sn:snep
RECV 0 -> 0 SYMM
DLC (32,None) CONNECT dequeue CONNECT PDU
SEND 32 -> 1 CONN MIU=128 RW=1 SN=urn:nfc:sn:snep
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 4 -> 32 CC MIU=248 RW=1
DLC (32,None) CONNECT enqueue CC PDU
connected (32 ===> 4)
DLC (32,4) ESTABLISHED send() DLC 32 <-> 4 ESTABLISHED RW(R)=1 V(S)=0 V(SA)=0 RW(L)=1 V(R)=0 V(RA)=0
DLC (32,4) ESTABLISHED dequeue I PDU
SEND 32 -> 4 I N(S)=0 N(R)=0 LEN=38 SDU=100200000020d1021b537091010b5501757477656e74652e6e6c5101085402656e68616c6c6f
RECV 4 -> 32 RR N(R)=1
DLC (32,4) ESTABLISHED enqueue RR PDU
SEND 0 -> 0 SYMM
RECV 4 -> 32 I N(S)=0 N(R)=1 LEN=6 SDU=108100000000
DLC (32,4) ESTABLISHED enqueue I PDU
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
DLC (32,4) ESTABLISHED necessary ack DLC 32 <-> 4 ESTABLISHED RW(R)=1 V(S)=1 V(SA)=1 RW(L)=1 V(R)=1 V(RA)=0
SEND 32 -> 4 RR N(R)=1
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
SEND 0 -> 0 SYMM
RECV 0 -> 0 SYMM
disconnect from urn:nfc:sn:snep
DLC (32,4) ESTABLISHED close()
DLC (32,4) DISCONNECT dequeue DISC PDU
SEND 32 -> 4 DISC
RECV 4 -> 32 DM REASON=0
DLC (32,4) DISCONNECT enqueue DM PDU
shutdown requested
SEND 0 -> 0 DISC
wait_command: IOError [Errno 10] rf field not activated in time by active mode peer
shutdown on link disruption
closing service access point 1
closing service access point 0
llc run thread terminated
Script terminated.

The screen from NFC's TagInfo reads:
type: "Sp"
  URI
  type: "U"
  > http;//www.utwente.com
  Text
  type: "T"
  > encoding: UTF-8
  > lang: en
  > text: "hallo"

Revision history for this message
Best Stephen Tiedemann (stephen-tiedemann) said :
#6

Hi Hartmut,

regarding smartposter creation you can also directly assign the URL string to sp.uri, no need to construct it separately. To create the NDEF message the usual way would be "msg = nfc.ndef.Message(sp)". Your code gives the same result because the SmartPoster message has only a single record. If a message shall contain multiple records, nfc.ndef.Message() can take them as a list of records be added one after the other using msg.append().

Don't worry about the "shutdown on link disruption" From nfcpy's point of view It happens here because the Nexus has stopped to answer after receipt of the DISC(0->0) command (which means LLCP link termination). I will eventually have to have a second look after the termination sequence which has also changed a bit in LLCP 1.1. But generally speaking, link disruption is the most expected thing to happen in real life, when a user touches for a limited time.

The segmentation fault on the Nexus is of course a bit unexpected. From nfcpy's log I can see absolutely no reason and maybe it's worth a bug report on Android.

/Stephen

Revision history for this message
Hartmut Benz (hartmut-benz) said :
#7

Thanks Stephen Tiedemann, that solved my question.