Simple NDEF Exchange Protocol

snep-test-server.py

The SNEP test server program implements an NFC device that provides two SNEP servers:

  1. A Default SNEP Server that is compliant with the NFC Forum Default SNEP Server defined in section 6 of the SNEP specification.

  2. A Validation SNEP Server that accepts SNEP Put and Get requests. A Put request causes the server to store the NDEF message transmitted with the request. A Get request causes the server to attempt to return a previously stored NDEF message of the same NDEF message type and identifier as transmitted with the request. The server will keep any number of distinct NDEF messages received with Put request until the client terminates the data link connection.

    The Validation SNEP Server uses the service name urn:nfc:xsn:nfc-forum.org:snep-validation, assigned for the purpose of validating the SNEP candidate specification prior to adoption.

Usage

$ snep-test-server.py [-h|--help] [OPTION]...

Options

--loop, -l

Repeat the command endlessly, use Control-C to abort.

--mode {t,i}

Restrict the choice of NFC-DEP connection setup role to either Target (only listen) or Initiator (only poll). If this option is not given the dafault is to alternate between both roles with a randomized listen time.

--miu INT

Set a specific value for the LLCP Link MIU. The dafault value is 2175 octets.

--lto INT

Set a specific LLCP Link Timeout value. The default link timeout is 500 milliseconds.

--listen-time INT

Set the time to listen for initialization command from an NFC-DEP Initiator. The default listen time is 250 milliseconds.

--no-aggregation

Disable outbound packet aggregation for LLCP, i.e. do not generate LLCP AGF PDUs if multiple packets are waiting to be send. This is mostly to achieve communication with some older/buggy implementations.

-q

Do not print log messages except for errors and warnings.

-d MODULE

Output debug messages for MODULE to the log facility. Logs are written to <stderr> unless a log file is set with -f. MODULE is a string that corresponds to an nfcpy module or individual file, with dots between path components. For example, -d nfc enables all nfcpy debug logs, -d nfc.tag enables debug logs for all tag types, and -d nfc.tag.tt3 enables debug logs only for type 3 tags. This option may be given multiple times to enable debug logs for several modules.

-f LOGFILE

Write debug log messages to <LOGFILE> instead of <stderr>. Info, warning and error logs will still be printed to <stderr> unless -q is set to supress info messages on <stderr>.

--nolog-symm

When operating in peer mode this option prevents logging of LLCP Symmetry PDUs from the nfc.llcp.llc module. Symmetry PDUs are exchanged regularly and quite frequently over an LLCP Link and are logged by default if debug output is enabled for the llcp module.

--device PATH

Use a specific reader or search only for a subset of readers. The syntax for PATH is:

  • usb[:vendor[:product]] with optional vendor and product as four digit hexadecimal numbers, like usb:054c:06c3 would open the first Sony RC-S380 reader and usb:054c the first Sony reader.
  • usb[:bus[:device]] with optional bus and device number as three-digit decimal numbers, like usb:001:023 would specifically mean the usb device with bus number 1 and device id 23 whereas usb:001 would mean to use the first available reader on bus number 1.
  • tty:port:driver with mandatory port and driver name should be used on Posix systems to open the serial port at device node /dev/tty<port> and load the driver from module nfc/dev/<driver>.py. A typical example would be tty:USB0:arygon for the Arygon APPx/ADRx at /dev/ttyUSB0.
  • com:port:driver with mandatory port and driver name should be used on Windows systems to open the serial port COM<port> and load the nfc/dev/<driver>.py driver module.
  • udp[:host][:port] with optional host name or address and port number will use a fake communication channel over UDP/IP. Either value may be omitted in which case host defaults to ‘localhost’ and port defaults to 54321.

snep-test-client.py

Usage

$ snep-test-client.py [-h|--help] [OPTION]...

Options

-t N, --test N

Run test number N. May be set more than once.

-T, --test-all

Run all tests.

--loop, -l

Repeat the command endlessly, use Control-C to abort.

--mode {t,i}

Restrict the choice of NFC-DEP connection setup role to either Target (only listen) or Initiator (only poll). If this option is not given the dafault is to alternate between both roles with a randomized listen time.

--miu INT

Set a specific value for the LLCP Link MIU. The dafault value is 2175 octets.

--lto INT

Set a specific LLCP Link Timeout value. The default link timeout is 500 milliseconds.

--listen-time INT

Set the time to listen for initialization command from an NFC-DEP Initiator. The default listen time is 250 milliseconds.

--no-aggregation

Disable outbound packet aggregation for LLCP, i.e. do not generate LLCP AGF PDUs if multiple packets are waiting to be send. This is mostly to achieve communication with some older/buggy implementations.

-q

Do not print log messages except for errors and warnings.

-d MODULE

Output debug messages for MODULE to the log facility. Logs are written to <stderr> unless a log file is set with -f. MODULE is a string that corresponds to an nfcpy module or individual file, with dots between path components. For example, -d nfc enables all nfcpy debug logs, -d nfc.tag enables debug logs for all tag types, and -d nfc.tag.tt3 enables debug logs only for type 3 tags. This option may be given multiple times to enable debug logs for several modules.

-f LOGFILE

Write debug log messages to <LOGFILE> instead of <stderr>. Info, warning and error logs will still be printed to <stderr> unless -q is set to supress info messages on <stderr>.

--nolog-symm

When operating in peer mode this option prevents logging of LLCP Symmetry PDUs from the nfc.llcp.llc module. Symmetry PDUs are exchanged regularly and quite frequently over an LLCP Link and are logged by default if debug output is enabled for the llcp module.

--device PATH

Use a specific reader or search only for a subset of readers. The syntax for PATH is:

  • usb[:vendor[:product]] with optional vendor and product as four digit hexadecimal numbers, like usb:054c:06c3 would open the first Sony RC-S380 reader and usb:054c the first Sony reader.
  • usb[:bus[:device]] with optional bus and device number as three-digit decimal numbers, like usb:001:023 would specifically mean the usb device with bus number 1 and device id 23 whereas usb:001 would mean to use the first available reader on bus number 1.
  • tty:port:driver with mandatory port and driver name should be used on Posix systems to open the serial port at device node /dev/tty<port> and load the driver from module nfc/dev/<driver>.py. A typical example would be tty:USB0:arygon for the Arygon APPx/ADRx at /dev/ttyUSB0.
  • com:port:driver with mandatory port and driver name should be used on Windows systems to open the serial port COM<port> and load the nfc/dev/<driver>.py driver module.
  • udp[:host][:port] with optional host name or address and port number will use a fake communication channel over UDP/IP. Either value may be omitted in which case host defaults to ‘localhost’ and port defaults to 54321.

Test Scenarios

Connect and terminate

$ snep-test-client.py -t 1

Verify that a data link connection with the remote validation server can be established and terminated gracefully and that the server returns to a connectable state.

  1. Establish a data link connection with the Validation Server.
  2. Verify that the data link connection was established successfully.
  3. Close the data link connection with the Validation Server.
  4. Establish a new data link connection with the Validation Server.
  5. Verify that the data link connection was established successfully.
  6. Close the data link connection with the Validation Server.

Unfragmented message exchange

$ snep-test-client.py -t 2

Verify that the remote validation server is able to receive unfragmented SNEP messages.

  1. Establish a data link connection with the Validation Server.
  2. Send a Put request with an NDEF message of no more than 122 octets total length.
  3. Verify that the Validation Server accepted the Put request.
  4. Send a Get request that identifies the NDEF message sent in step 2 to be retrieved.
  5. Verify that the retrieved NDEF message is identical to the one transmitted in step 2.
  6. Close the data link connection.

Fragmented message exchange

$ snep-test-client.py -t 3

Verify that the remote validation server is able to receive fragmented SNEP messages.

  1. Establish a data link connection with the Validation Server.
  2. Send a Put request with an NDEF message of more than 2170 octets total length.
  3. Verify that the Validation Server accepted the Put request.
  4. Send a Get request that identifies the NDEF message sent in step 2 to be retrieved.
  5. Verify that the retrieved NDEF message is identical to the one transmitted in step 2.
  6. Close the data link connection.

Multiple ndef messages

$ snep-test-client.py -t 4

Verify that the remote validation server accepts more than a single NDEF message on the same data link connection.

  1. Establish a data link connection with the Validation Server.
  2. Send a Put request with an NDEF message that differs from the NDEF message to be send in step 3.
  3. Send a Put request with an NDEF message that differs from the NDEF message that has been send send in step 2.
  4. Send a Get request that identifies the NDEF message sent in step 2 to be retrieved.
  5. Send a Get request that identifies the NDEF message sent in step 3 to be retrieved.
  6. Verify that the retrieved NDEF messages are identical to the NDEF messages transmitted in steps 2 and 3.
  7. Close the data link connection.

Undeliverable resource

$ snep-test-client.py -t 5

Verify verify that the remote validation server responds appropriately if the client requests an NDEF message that exceeds the maximum acceptable length specified by the request.

  1. Establish a data link connection with the Validation Server.
  2. Send a Put request with an NDEF message of total lenght N.
  3. Verify that the Validation Server accepted the Put request.
  4. Send a Get request with the maximum acceptable lenght field set to N − 1 and an NDEF message that identifies the NDEF message sent in step 2 to be retrieved.
  5. Verify that the server replies with the appropriate response message.
  6. Close the data link connection.

Unavailable resource

$ snep-test-client.py -t 6

Verify that the remote validation server responds appropriately if the client requests an NDEF message that is not available.

  1. Establish a data link connection with the Validation Server.
  2. Send a Get request that identifies an arbitrary NDEF message to be retrieved.
  3. Verify that the server replies with the appropriate response message.
  4. Close the data link connection.

Default server limits

$ snep-test-client.py -t 7

Verify verify that the remote default server accepts a Put request with an information field of up to 1024 octets, and that it rejects a Get request.

  1. Establish a data link connection with the Default Server.
  2. Send a Put request with an NDEF message of up to 1024 octets total length.
  3. Verify that the Default Server replies with a Success response message.
  4. Send a Get request with an NDEF message of arbitrary type and identifier.
  5. Verify that the Default Server replies with a Not Implemented response message.
  6. Close the data link connection.