Networking and Security

ZentriOS includes a full IPv4 networking stack and SSL/TLS security suite that supports a range of popular networking protocols including TCP, UDP, DNS, DHCP. Additional network application libraries are provided for native HTTP/S and secure cloud access.

The Procedure for Joining a WLAN Network is described in detail below.

For each networking client and server there are configuration variables, and commands and procedures to start and stop the client or server.

When a network connection is established, ZentriOS opens a network stream to write and read data. See Network Connections and Streams.

See the article TCP is a Stream for a discussion of the underlying mechanism of TCP, and how to determine that data is received.

Note that the term stream has different meanings depending on context. See Glossary, Stream.

Other network features include ...

Security features include ...


Procedure for Joining a WLAN Network

Setting WLAN Variables

To join a WLAN network, you need to pre-set some variables. In all cases, save the variable values to NVM with the save command.

Starting the Network Up Sequence

To start the network up sequence, do one of the following:

The Network Up Sequence

The following diagram shows the network up sequence. Click to enlarge.

The auto join retry count is set to zero at the beginning of the entire sequence.

Circled step numbers in the diagram above correspond to the numbered steps in the network up sequence below:

  1. check retry count:

    • IF join attempt count >= wlan.join.retries, GOTO step 6: join attempt failed.
    • ELSE continue to next step.
  2. first time?:

    • IF network has previously been joined successfully: skip probe and attempt to join with existing network details. GOTO step 4: attempt to join.
    • ELSE continue to next step.
  3. probe for network details:

    • IF join attempt count == 1, ZentriOS probes for network with wlan.bssid and/or wlan.security if set, else wlan.ssid. Probing uses all wlan.scan.* variables
    • IF probe NOT successful, GOTO step 6: join attempt failed.
    • ELSE continue to next step: attempt to join
  4. attempt to join: ZentriOS attempts to associate using network details found in probe or in stored in previous successful join:

    • IF ZentriOS has network details (i.e. bssid, channel and security), ZentriOS attempts to associate to network, with timeout after wlan.join.timeout ms.
      • IF association successful, goto step 5, get IP address, DNS and gateway values
      • ELSE IF association failed, ZentriOS failed to associate to network. Increment join retry count and GOTO step 1
    • ELSE if network not found in probing, the join attempt failed. GOTO step 6.
  5. get IP address, DNS and gateway values:

    • IF the device successfully joins the network:
      • IF wlan.dhcp.enabled is TRUE, ZentriOS attempts to get an IP address from the AP, timeout after wlan.dhcp.timeout seconds
      • ELSE IF wlan.dhcp.enabled is FALSE then ZentriOS uses the wlan.static.* variables, which you should preset to appropriate values
      • network up sequence successful. GOTO step 7: network up sequence complete.
    • ELSE the join attempt failed. GOTO step 6, join attempt failed.
  6. join attempt failed: Try again if auto join enabled, WLAN interface not just forced down, and auto join retries not exceeded:

  7. network up sequence complete

Zentrios has either succeeded or failed in joining the network. You can check wlan.join.result to determine the final result of the network_up sequence.

DHCP Client

The ZentriOS DHCP client obtains an IP address from the WLAN DHCP server when the network is brought up with the wlan interface.

Configure the DHCP client with the variables:

Bring the network up by issuing any command that requires the network, or use the command:


DHCP Server

The ZentriOS DHCP server supplies IP addresses to clients connecting to the soft AP when the network is brought up with the softap interface.

Configure the DHCP server with the variables:

The soft AP starts on reboot when configured to auto-start with the softap.auto_start variable.

You can bring up the soft AP with the network_up command. Either specify the softap interface, or set the network.default_interface variable to softap.

The soft AP starts automatically when you use Web Setup.


DNS Client

The DNS Client works with all the network protocols, including HTTP, TCP and UDP.

The network.dns.timeout variable controls the length of time ZentriOS waits while attempting to resolve a hostname via DNS.

The wlan.network.dns variable returns a list of addresses currently in use by the WLAN interface.


DNS Server

DNS Server features are available for the Soft AP interface.

Configuration options for the soft AP DNS server are:

The setup.web.url variable defines a list of URLs that clients can use to connect to the ZentriOS Web App.


HTTP Client

The HTTP Client consists of a group of commands for HTTP methods:

For a secure TLS transaction, the url scheme specified with the command must be https. See HTTPS Client.

The http_get, http_post and http_head commands have an option to queue the request, prior to sending. While the request is queued, use the http_add_header to add custom headers as required, as shown in the example below. Use the stream_write command to add data to the body of a POST request.

Use the http_read_status command to read the HTTP response after a request is completed.

Connection timeout for the HTTP client commands is controlled by the tcp.client.connect_timeout variable.

Stream Type: HTTP. See Network Connections and Streams, Stream Types.

HTTP POST Example

The following (fictitious) HTTP POST example shows how to post data to an HTTP web server using the ZentriOS HTTP API. The HTTP body data posted in this example is a small piece of JSON (sent using stream_write 0 7). Since the -o option is used with the http_post command, a connection stream to the HTTP server is opened, but the HTTP POST is queued locally on the module.

Queuing the HTTP POST locally provides the ability to add HTTP headers using the http_add_header command, and to post data in the HTTP body using the stream_write command. Once all headers and body data are queued, the HTTP POST is sent to the server and completed using the http_post command.

Any response data received from the server may be read using stream_read.

> http_post -o example.com/hello application/json
[2014-04-23 | 19:40:23: Opening: example.com]
Request POST /hello
Connecting (HTTP): example.com:80
[2014-04-23 | 19:40:23: Opened: 0]
0
> stream_write 0 7
... JSON data goes here ...
Success
> http_read 0
HTTP response: 200
Chunked response
200
> stream_read 0 1000
{
  "response": "howdy!"
}
> stream_close 0
Closing: 0
[2014-04-23 | 19:40:40: Closed: 0]
Success

HTTP Client File Upload and Download

The HTTP Client feature includes commands to handle file upload and download, between the ZentriOS device file system and an HTTP/S host:

The http_upload and http_download commands use HTTP POST requests in the background.

For a secure TLS transaction, the url scheme specified with the command must be https.

See:

HTTP Client Native API

See Native API HTTP Client group.


HTTP Server with RESTful API

The ZentriOS HTTP webserver may be configured to run as a service on either the softAP or WLAN interface.

The server supports HTTP Basic Authentication with (or without) HTTPS security.

There is no network stream associated with the HTTP server. An HTTP client issues a request and the HTTP server sends a response. The client and server do not read or write data outside the request.

ZentriOS provides a simple RESTful API on top of the HTTP server. The API allows for a remote HTTP(S) client to issue any ZentriOS command. The result of the command is returned in a simple JSON format.

The RESTful API can be used in a number of ways:

The HTTP Server is configured with the following variables:

A client can use the RESTful API to issue ZentriOS commands and receive responses, and also for retrieval of module log messages.

The available requests are as follows:

GET  /command
POST /command
GET  /log
POST /stream

See the HTTP Server RESTful API application note for low-level examples.

The ZentriOS Web App provides a complete demonstration of the HTTP Server RESTful API, and can be customized as required. See Customizing the ZentriOS Web App.

Notes

Command Request/Response

The API supports either a simple GET request or a slightly more complex POST request.

GET Request

GET /command/<ZentriOS command>

POST Request

POST /command
{
   "flags"   : <flags>,
   "command" : "<ZentriOS command>",
   "data"    : "<command data>"
}

where:

With the REST API, the procedure for issuing commands is:

  1. Open HTTP socket to server
  2. POST JSON formatted command to device
  3. Device processes request
  4. Device returns a JSON formatted response
  5. HTTP connection closed

To issue another command, repeat steps 1-5.

HTTP Response Codes

Response body

{
   "id"       : <unique id>,
   "code"     : <response code>,
   "flags"    : <flags>,
   "response" : "<command response>"
}

where:

Log Request/Response

The API also buffers log messages. This is the request to retrieve the log messages.

GET Request

GET /log

HTTP Response Codes

Response

{
  "logs" : [ "<log data>", "<log data>", ....] }
}

Note: the log buffer has limited space. Older logs are replaced by newer ones. This should be called periodically to avoid losing logs.

HTTP Response Codes

HTTP Server Security and Authorization

The HTTP server is secured using HTTP Basic Authentication. This requires that a client supplies a username and password. Note that the username/password are sent in the HTTP request header which is encrypted only if the HTTP request itself is encrypted.

Client Authorization

The HTTP Basic Authentication client authorization feature is enabled when both the http.server.username and http.server.password variables are set.

When the HTTP Server username/password settings are set, authorization is required to access certain files and api commands.

The client must supply a username and password that matches the http.server.username and http.server.password variables.

If authorization fails the ZentriOS HTTP Server returns:

Protecting or Securing a File

When client authorization is enabled, authorization is required to download all files (except unprotected files).

To unprotect a file, the -u (unprotected) flag must be explicitly specified when the file is created using the file_create or http_download commands.

When client authorization is disabled, all files may be downloaded from the ZentriOS web server.

Securing the REST API, Whitelisting API Calls

When the authorization feature is enabled all REST API calls require authorization. It is possible to 'whitelist' certain API calls.

This is done by creating the file: http_whitelist.csv which contains a comma separated list of REST API calls that do not require authorization.

This file also supports a trailing wildcard character *. Some examples of this file are as follows:

CORS (Cross Origin Resource Sharing)

The ZentriOS HTTP server supports CORS (Cross-Origin Resource Sharing).

The http.server.cors_origin variable allows you to specify origins for which the same-origin policy is relaxed.

This allows control of the module, via the HTTP server, from a remote site provided the module has originally been set up with a http.server.cors_origin domain that allows access from that site. Via the ZentriOS HTTP server ZentriOS JavaScript API, the remote site can issue all ZentriOS commands, including reboot.

Setting the http.server.cors_origin results in the ZentriOS HTTP server inserting a corresponding CORS Access-Control-Allow-Origin (ACAO) response header into resources it delivers. It also results in the ZentriOS HTTP server responding to an OPTION request with a set of options supporting remote control.

When a client connects to the HTTP server, the server validates the client's 'origin' header against http.server.cors_origin. If the origin does not match http.server.cors_origin then the HTTP server immediately terminates the connection.

HTTP Server Security Variables

The variables for managing HTTP Basic Authentication are:

The variable for managing CORS is:

HTTPS Client

HTTPS client commands include:

The HTTP client commands use TLS when the URL supplied has the scheme https.

The TLS CA certificate is supplied as a command argument or by default configured with the variables:

HTTPS Server

The HTTP Server becomes an HTTPS Server when TLS is configured for HTTP Server with the variables:

All the features described above for the HTTP Server are supported for the HTTPS Server.


NTP Client

Network Time Management

ZentriOS devices can obtain time data from an NTP (Network Time Protocol) server.

Configure NTP with the variables:

Time related variables are:

If NTP is enabled, time.last_set returns the seconds since the time was last set by NTP.

To read the time, get time.rtc and to determine the time zone, get time.zone.


SMTP Client

The SMTP Client allows ZentriOS devices to send email messages via an external SMTP server.

Configure email via SMTP with the variables:

Send email with the command:

To use TLS with the SMTP client, set the value of network.tls.ca_cert.

See the Sending a Secure SMTP Email application note.

SMTP Native API

See Native API SMTP group.


TCP Client

Configure the TCP client with the variables:

Start the TCP client with the command:

Stream Type: TCPC. See Network Connections and Streams, Stream Types.

TCP Client Auto Connect

To connect automatically to a remote host when the network is brought up, configure TCP client auto-connect with the variables:

To auto start with a TLS connection, set tcp.client.tls_enabled = TRUE. See TLS Client.

TCP Client Connection Retry Sequence

The TCP client connection retry sequence is shown in the following diagram. Click to enlarge:


TCP Server

Configure the TCP server with the variables:

Start and stop the TCP server with the TCP server command:

Stream Type: TCPS. See Network Connections and Streams, Stream Types.

To use the TCP server with TLS, configure the tcp.server.tls* variables and use the tls_server command. See TLS Server.


TLS 1.0-1.2 Support

ZentriOS supports TLS 1.0 to TLS 1.2.

For a full description of TLS errors and the commands that use TLS, see TLS Errors.

Supported TLS Cipher Suites

ZentriOS supports the following Cipher Suites for TLS 1.0 - 1.2:

OpenSSL NameKey ExchangeEncryptionHashing Algorithm
DHE_RSA_WITH_AES_256_CBC_SHA256DHE RSAAES-256SHA-256
DHE_RSA_WITH_AES_256_CBC_SHADHE RSAAES-256SHA-1
DHE_RSA_WITH_AES_128_CBC_SHA256DHE RSAAES-128SHA-256
DHE_RSA_WITH_AES_128_CBC_SHADHE RSAAES-128SHA-1
RSA_WITH_AES_256_CBC_SHA256RSAAES-256SHA-256
RSA_WITH_AES_256_CBC_SHARSAAES-256SHA-1
RSA_WITH_AES_128_CBC_SHA256RSAAES-128SHA-256
RSA_WITH_AES_128_CBC_SHARSAAES-128SHA-1

Acronyms Used in Above Table

TLS Memory Requirements

Increasing Available Memory for TLS

TLS connections require a considerable amount of RAM. Low memory may result in TLS errors such as TLS malloc failed.

To establish a TLS connection, other memory intensive features may need to be disabled. You can return the device to the default state with a factory reset.

TLS Errors

TLS Error Format

In the event of TLS failure, the response includes an error message with a format similar to the following:

Error with TLS handshake: <error code> (state: <tls state>, code: <internal error code>)

where:

TLS Error Example

> http_get https://google.com
[2015-03-25 | 02:50:33: Opening: https://google.com]
Request GET /
Connecting (https): google.com:443
Starting TLS
TLS malloc failed
Error with TLS handshake: 5035
[2015-03-25 | 02:50:33: Open failed]
Command failed

TLS Error Codes

CodeError
2TIMEOUT
5001RECEIVE_FAILED
5002ALERT_NO_CERTIFICATE
5003ERROR_OUT_OF_MEMORY
5004ERROR_FEATURE_UNAVAILABLE
5005ERROR_BAD_INPUT_DATA
5006ERROR_INVALID_MAC
5007ERROR_INVALID_RECORD
5008ERROR_INVALID_MODULUS_SIZE
5009ERROR_UNKNOWN_CIPHER
5010ERROR_NO_CIPHER_CHOSEN
5011ERROR_NO_SESSION_FOUND
5012ERROR_NO_CLIENT_CERTIFICATE
5013ERROR_CERTIFICATE_TOO_LARGE
5014ERROR_CERTIFICATE_REQUIRED
5015ERROR_PRIVATE_KEY_REQUIRED
5016ERROR_CA_CHAIN_REQUIRED
5017ERROR_UNEXPECTED_MESSAGE
5018ERROR_FATAL_ALERT_MESSAGE
5019ERROR_PEER_VERIFY_FAILED
5020ERROR_PEER_CLOSE_NOTIFY
5021ERROR_BAD_HS_CLIENT_HELLO
5022ERROR_BAD_HS_SERVER_HELLO
5023ERROR_BAD_HS_CERTIFICATE
5024ERROR_BAD_HS_CERTIFICATE_REQUEST
5025ERROR_BAD_HS_SERVER_KEY_EXCHANGE
5026ERROR_BAD_HS_SERVER_HELLO_DONE
5027ERROR_BAD_HS_CLIENT_KEY_EXCHANGE
5028ERROR_BAD_HS_CERTIFICATE_VERIFY
5029ERROR_BAD_HS_CHANGE_CIPHER_SPEC
5030ERROR_BAD_HS_FINISHED
5031HANDSHAKE_TIMEOUT
5032HANDSHAKE_ERROR
5033INIT_FAIL
5034BAD_MESSAGE
5035UNTRUSTED_CERTIFICATE
5036EXPIRED_CERTIFICATE
5037CERTIFICATE_NAME_MISMATCH
5038CERTIFICATE_REVOKED
5039NO_DATA
5040ERROR_UNSUPPORTED_EXTENSION

TLS States

CodeTLS State
0SSL_HELLO_REQUEST
1SSL_CLIENT_HELLO
2SSL_SERVER_HELLO
3SSL_SERVER_CERTIFICATE
4SSL_SERVER_KEY_EXCHANGE
5SSL_CERTIFICATE_REQUEST
6SSL_SERVER_HELLO_DONE
7SSL_CLIENT_CERTIFICATE
8SSL_CLIENT_KEY_EXCHANGE
9SSL_CERTIFICATE_VERIFY
10SSL_CLIENT_CHANGE_CIPHER_SPEC
11SSL_CLIENT_FINISHED
12SSL_SERVER_CHANGE_CIPHER_SPEC
13SSL_SERVER_FINISHED
14SSL_FLUSH_BUFFERS
15SSL_HANDSHAKE_OVER

TLS Client

TLS client commands include:

See also HTTPS Client.

TLS details must be supplied as a command argument or configured with the variables:

To manually initiate a TLS connection with the TCP client, use the tls_client command.

To auto-start the TCP client with TLS, set:

See TCP Client Auto Connect.

The TCP client, with TLS enabled, has the features described in the TCP Client documentation.

Stream Type: TLSC. See Network Connections and Streams, Stream Types.

OTA always uses TLS.

Commands that use TLS respond to TLS failure with a specially formatted error message. See TLS Error Format.

Connect timeout for the TLS client command is controlled by the tcp.client.connect_timeout variable.


TLS Server

Configure TLS Server with the variables:

See commands:

The TLS server has all the features described in TCP Server.

Stream Type: TLSS. See Network Connections and Streams, Stream Types.


UDP Client

Configure the UDP client with the variables:

Start the UDP client with the command:

Stream Type: UDPC. See Network Connections and Streams, Stream Types.

UDP Client Auto Connect

Configure the UDP client auto-connect with the variables:


UDP Server

Configure the UDP server with the variables:

Start and stop the UDP server with the command:

The udp_server has subcommands to read and write. These are equivalent to the stream read and write commands, with the added option of determining the client address and port.

The UDP server uses a single stream for multiple clients. Using the stream read and write commands applies to all clients. Using the UDP server subcommands allows writing to and reading from a specific client.

Stream Type: UDPS. See Network Connections and Streams, Stream Types.

UDP Server Auto Connect

Configure the UDP server auto-connect with the variables:


WebSocket Client

Configuration options for the websocket client include:

The command to invoke the websocket client is:

See the websocket_client documentation for details on the websocket message format.

The websocket client supports TLS via the websocket URL scheme and the websocket_client cert filename argument.

The websocket_client -g option configures a data ready GPIO for a single websocket.

Read from the Websocket with stream_read.

Write to the Websocket with stream_write.

To send a WebSocket ping frame as a keepalive, use the stream_write with the -p option.

To send data chunks as continuation frames, use the stream_write with the -f option.

Stream Type: WEBC. See Network Connections and Streams, Stream Types.


WebSocket Server

The WebSocket protocol provides full-duplex communication channels over a single TCP connection. ZentriOS WebSocket server support requires the HTTP Server. The HTTP REST API includes WebSocket API calls.

Websocket server CORS policy is discussed in HTTP Server, CORS (Cross Origin Resource Sharing).

Configuration variables are:

Stream Type: WEBS. See Network Connections and Streams, Stream Types.

WebSocket Stream

To open a WebSocket, issue the API call POST /stream to the ZentriOS HTTP server. ZentriOS opens a WebSocket and creates a network stream. An MCU can read/write data using the ZentriOS stream_read and stream_write commands. See Network Connections and Streams.

POST /stream
<raw data .... >

See HTTP Server Simple WebSocket Demonstration.

WebSocket URI

When connecting to a Command API WebSocket server, the WebSocket URI is /stream.

When connecting to a ZAP WebSocket server, the WebSocket URI is /zapstreams.

See Native API, HTTP Server Stream.

When connecting to a WebSocket command stream, the WebSocket URI is /cmdstream. See WebSocket Command Stream below.

WebSocket Command Stream

The WebSocket command stream lets you issue commands to your ZentriOS device via a WebSocket from a remote host.

The WebSocket command stream is complementary to the REST API. It uses the WebSocket protocol and the /cmdstream route.

When issuing a command via the WebSocket command stream, the sequence is:

  1. Open WebSocket stream with HTTP server via ws://<host>/cmdstream
  2. Issue msgpack formatted message to ZentriOS device. For details of msgpack format, see http://msgpack.org/.
  3. ZentriOS device processes command message
  4. ZentriOS device returns msgpack formatted response

To issue another command repeat steps 2-4.

You need to import a msgpack library into your webpage or application to use the WebSocket command stream.

The command message is in the following form:

{
   "command" : "<ZentriOS command>",
   "data" : "<command data>",
   "id" : <command id>
}

where:

The response from ZentriOS is of the following form:

{
   "id" : <command id>,
   "code" : <response code>,
   "response" : "<command response>"
}

where:


Network Connections and Streams

Streams are associated with:

When ZentriOS opens a network connection, file, or serial connection, it returns a stream handle. The stream commands act on a stream handle to perform actions such as read, write, poll and close. You can list open streams. Each stream has a specific type. See Stream Types.

Stream Handles

When a stream is open, it is assigned a handle number. This handle is used to read/write/poll/close the stream.

Stream Commands

Refer to the following stream commands to use the stream handle:

Use the stream_list command to view open streams. For example:

> stream_list
! # Type  Info
# 0 TCPS 10.5.6.146:3000 10.5.6.131:63835
# 1 UDPC  107.170.222.80:50007 (15672)
# 2 TCPC  107.170.222.80:50007 (13171)
# 3 FILE  webapp/unauthorized.html-1.0.1.3  (9530, 0)
# 4 FILE  favicon.ico.gz-1.0.1.3  (733, 0)
# 5 FILE  webapp/zentrios.css.gz-1.0.1.3  (22670, 0)
>
Ready
>

Serial STREAM Mode

In serial STREAM mode, a single network connection (TCP/TLS/UDP/WebSocket client/server) streams to the serial bus. No stream read or write commands are required, as data flows automatically between the serial bus and the open stream. See Serial Interface, Stream Mode.

STREAM mode does not support the following stream types:

Note: When in STREAM mode, a TCP/TLS/WebSocket server is limited to one client connection.

STREAM mode is assigned to the auto-start network stream that opens first.

The STREAM mode enabled stream appears in the stream list. Reading and writing data to the stream is not permitted.

Note: If you create a STREAM mode application with multiple network streams set to auto start, then it may not be possible to predict which will open first and which network connection is streaming. We recommend using only one auto-start network connection when booting to STREAM mode.

Stream Limitations

ZentriOS-WZ supports up to 8 simultaneous TCP or UDP streams.

Each stream type in the Stream Types table below uses a single stream, with the following exceptions and qualifications:

Stream Types

List the currently open streams with the stream_list command. Streams are listed with stream handle, type, and information about the stream source.

Note that some stream types support a limited set of operations. The following is a list of stream types, and for each type the command to create it, and the stream operations it supports.

TypeAssociated CommandsStream OperationsDescription
CMDbuffered commandsread/poll/closeBuffered command data for commands that are buffered when the variable system.cmd.buffered = '1'
FILEfile_open/file_create -oread/poll/closeFile system handle. See File system
HTTPhttp_get/http_post/http_headread/write/poll/closeHTTP Client
HTTPShttp_get/http_post/http_headread/write/poll/closeSecure HTTP Client
I2Ci2c_master_openread/write/poll/closeI2C master serial connection. See Peripherals, I2C Master Peripheral Controlling and Monitoring
SPIspi_master_openread/write/poll/closeSPI master serial connection. See Peripherals, SPI Master Peripheral Controlling and Monitoring
TCPCtcp_clientread/write/poll/closeTCP Client
TCPStcp_serverread/write/poll/closeTCP Server client stream. Note that one stream is used per client
TLSCtls_clientread/write/poll/closeTLS Client
TLSStls_serverread/write/poll/closeTLS Server client stream. . Note that one stream is used per client
UDPCudp_clientread/write/poll/closeUDP Client
UDPSudp_serverread/write/poll/closeUDP Server. Note that one stream is used for all server clients
WEBS-read/write/poll/closeWebSocket Server with a connected client.
WEBCwebsocket_clientread/write/poll/closeWebSocket Client

Network Status Indication Using GPIOs

You can configure GPIOs to act as indicators of networking states, such as the state of the WLAN connection, the Soft AP connection, or DHCP progress. You can configure a selection of blink rates to indicate states.

See variables:

See Peripherals, System Indicator Functions.


Remote Terminal Access

You can control a ZentriOS device with a TCP/IP telnet connection via a remote terminal, connected to the device via the Soft AP interface or the WLAN interface.

Configure the remote terminal with the variables:

See the Wi-Fi Remote Terminal application note.


Network Discovery

Discovery Overview

In simple terms, network discovery is used to give the module a name on the local network. So, for instance, if the module has a domain name mymodule.local, a remote client on the same network can connect to the module using the domain mymodule.local even though the domain mymodule.local is not registered with a DNS server. This is useful because the remote client doesn't need to know the IP address of the module.

ZentriOS supports three network discovery protocols: mDNS (multicast Domain Name System), LLMNR (Link-Local Multicast Name Resolution) and NetBIOS. The latter two protocols are used by Windows systems only.

Configure mDNS with the variables:

Start mDNS with the command:

Discovery OS Support

The remote client must support one or more network discovery protocols for device discovery to work.

Apple

Mac OS X & iOS support mDNS by default, with Bonjour.

Windows

Windows has support for mDNS, but by default it uses the LLMNR and NetBIOS protocols. These protocols are very similar to mDNS so their basic domain resolution features are supported by the module as well. When a domain is entered into the web browser, Windows follows this sequence to resolve the domain:

The LLMNR and NetBIOS queries are broadcast to the local network only. The DNS query is typically sent to the internet.

If network discovery is enabled on the module, the module will receive the LLMNR and NetBIOS queries, compare the query domain to its mdns.name, and if they match respond with the module's IP address. In this way the module can easily be found on the local network from a Windows machine.

A NetBIOS domain can have up to 15 characters (including the '.local'). If mdns.name is longer than 15 characters then the NetBIOS protocol is not used.

Finally, some ISPs hijack the .local domain for their own purposes, including advertising. This may cause a Windows PC to fail to resolve the domain. The solution (for Windows only) is to drop .local from the URL and simply use http://mymodule/ directly.

Linux

Linux needs an additional package installed for mDNS support. The most common package is Avahi.

Android

Android does not support mDNS (or other ZeroConf protocols) at the platform level, so third party Android apps like Chrome may not support mDNS. An Android SDK with mDNS support is available, so you can create an Android app with mDNS support. The Zentri Android Discovery app, available from the Google Play Store, demonstrates using the Android mDNS SDK to provide mDNS discovery on Android devices.

Discovery in a Nutshell

Network discovery provides a way for remote clients to resolve the IP address of the module on a local network using a standard protocol. mDNS has other features which allow the module to advertise various services including HTTP, TCP & UDP servers. ZentriOS supports configuration of these additional features with the mdns.service variable.

Discovery Command API

mDNS Native API

See Native API mDNS group.


Broadcast Status Announcement

A ZentriOS device broadcasts its properties in JSON format. The properties can be sent either as UDP packets to a UDP host or by a post request to an HTTP host.

Properties include by default the IP address and the MAC address.

Configure broadcast with the variables:

See also the Broadcast UDP Packet Application Note.


Captive Portal

Captive portal is supported during websetup and optionally for the soft AP. When the HTTP Server receives certain requests, it redirects to the root HTTP server web page. See softap.captive_portal_enabled.