actively re-start llcp connection

Asked by hank

Is it possible to actively shut down and re-start an LLCP connection while the peer remains in range? I guess the "normal" use case is that an LLCP connection 'disconnects' by the peer moving out of range. However I'd like to actively stop and restart an LLCP connection.

I tried the sequence of llcp.startup, connect using clf.poll or .listen, llcp.activate -- now SNEP activity here --, llcp.shutdown and then again llcp.startup & connect, however the peer (Google Nexus S) crashes on the llcp.shutdown bit. I saw that llcp.shutdown only sends a Disconnect PDU so handling of that PDU may be buggy in the peer, or the above is not following proper protocol?

Would it be possible to restart an LLCP connection w/o sending the Disconnect PDU. I tried above sequence w/o the shutdown part, on rare occasions it would work, but mostly I get 'missing ack frame from pn53x' or 'IndexError: index out of range: 6' in file nfc/dev/pn53x.py.

Question information

Language:
English Edit question
Status:
Answered
For:
nfcpy Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
hank (droid-5) said :
#1

FYI Android bug report file here, let's see what comes out of that: http://code.google.com/p/android/issues/detail?id=29483

Revision history for this message
hank (droid-5) said :
#2

I partially solved the problem by eliminating the Disconnect PDU from the shutdown. To do so I commented out the part in llc.run() where it says "self.mac.exchange(pdu.to_string(), timeout=1)" (after "if pdu == link_terminate_pdu") and run nfcpy in initiator mode. This way the llcp.shutdown results in a kind of shutdown that makes the peer think that the device moved out of range instead of an active/forced shutdown.

Not sure how to obtain the same result in target mode.

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

As you said, the "normal" termination is when proximity is lost. So not much testing was done for nfcpy w.r.t. the shutdown sequence, main concern is just that it safely terminates. But certainly sending just a single DISC PDU to the remote link manager is correct. In summary, errors may exist on both sides.

But what are you trying to achieve? A fresh connection to the SNEP server - then you could just close the data link connection.

Revision history for this message
hank (droid-5) said :
#4

Not sure what you mean by "just close the data link connection". SnepClient.close()? Won't do the trick. The LLCP disconnect/reconnect is to trigger the Android device to go into "beam" mode. Sorry to keep you bugging with what are basically workarounds to shortcomings in Android but Android is big in the NFC space right now so I have to deal with it.

Android only lets you send (SNEP PUT) 1 NdefMessage per LLCP connection, and only if no messages have been sent (PUT) by the peer before, so re-establishing the LLCP connection allows for sending a 2nd PUT message or for sending one after having received one.

Revision history for this message
hank (droid-5) said :
#5

FYI it will be resolved on the Android side in an upcoming release: http://code.google.com/p/android/issues/detail?id=29483

Can you help with this problem?

Provide an answer of your own, or ask hank for more information if necessary.

To post a message you must log in.