3 - Connection Types
DynaPro Go| Handheld PIN Pad Device with MSR/Contact/Contactless | Programmer’s Manual (COMMANDS)
Page 33 of 247 (
D998200136-31
)
3.3.1
How to Use 802.11 Wireless Connections (802.11 Wireless Only)
DynaPro Go ships from the manufacturer with TLS
Enabled
. This setting can be set to
Disabled
by the
customer, which may be useful for initial network setup and testing.
MagTek strongly recommends
that TLS always be Enabled when it is deployed in the field.
To use the device’s 802.11 wireless connection, first follow the configuration steps in the device’s
Installation and Operation Manual
, available from MagTek, to set up the network, host, and device,
and switch the device’s Active Connection to
802.11 Wireless
.
Host software that uses the 802.11 wireless connection must do so using a TLS library, which may
include the host software operating system’s cipher suite (for example,
above). The host will generally follow these steps to communicate with the device:
1)
The host software must establish a permanent listener on the TCP port where the device is configured
to connect. See section
3.3.3 How to Receive Data On the 802.11 Wireless Connection
2)
On power-up, the device connects to the configured 802.11 wireless access point. If it is configured
to use DHCP, it registers its device name (
TLS
plus its serial number) with the DNS server, and gets
an IP address.
3)
Based on configuration, the device either opens a TCP listening socket immediately and waits for the
host to connect, or opens an unsecured TCP connection to the configured host, sends
Request Host Connection (Handheld Operation Only, 802.11 Wireless Only)
, and opens a TCP
listening socket.
4)
If the device has TLS enabled, the host must then establish a mutually authenticated TLS connection
with the device’s listening port. Depending on the operating system and library the host is using, this
may involve:
a)
Establishing an unsecured TCP connection to the port the device is listening on, using either the
device’s DNS name or IP address. The host should continuously monitor the status of this
connection to make sure the device is still available, and if the connection is terminated, it should
assume the device has returned to the idle state, and cancel any pending operations.
b)
Using the operating system certificate store to get a handle to the certificate chain the host will
use to authenticate, and validate the full chain.
c)
Use the TLS library to perform a mutual authentication sequence on the TCP connection. For
example,
AuthenticateAsClient (ServerName, Certs,
SslProtocols.Tls12, False)
. With some libraries, the host will have to perform
additional steps directly, such as specifying what cipher suites the host supports. For details, see
the documentation for the TLS library and operating system the host software is using.
d)
Wait a reasonable period of time (e.g., 10ms) for the device to prepare to receive commands.
e)
If the host fails to connect:
i)
Temporarily disable TLS to verify basic connection to the device is OK. See the device’s
Installation and Operation Manual
for proper host configuration and installation of
certificates.
ii)
Use a network packet capture tool on the host, such as Wireshark, which can help debug the
TLS handshake.
5)
If the device does not have TLS enabled, the host must establish an unsecured TCP connection with
the device’s listening port. The host should continuously monitor the status of this connection to
