Developing IoT devices using Bluetooth LE

  • Tutorial


Bluetooth technology is energetically making its way into the Internet of Things area. Part of this technology, called Bluetooth LE ( Bluetooth Low Energy , also known as Bluetooth Smart , also BLE ), directly positions itself as an ideal choice for IoT ( Internet of things ). It is hard not to agree. BLE already knows how to route Internet traffic, determine coordinates in premises, connect industrial programmable logic controllers, support WEB servers, connect scales, thermometers, heart rate monitors, oximeters, tonometers and a lot of other things. C BLEAutomatically solves many problems inherent in solutions using Wi-Fi . Not long until the moment when devices with BLE can be organized in the MESH network , according to technology similar to ZigBee . This is already reflected in the Bluetooth 5.0 specification.

Therefore, when developing my IoT module, I gave absolute preference to BLE as opposed to using Wi-Fi . I will consider the peripheral part of the BLE network using the example of the K66BLEZ debug module .

Here I would like to describe my development route from almost complete ignorance of BLE to the release of a serial product.

An introduction to the K66BLEZ1 module was started in these articles:
Universal controller module for the Internet of things. Inhale the life of the
Universal Controller Module for the Internet of Things. Testing FatFs
Universal Controller Module for the Internet of Things. Basics of programming Project repository
module schema

The K66BLEZ module uses the MKW40Z160 chip ( 48 MHz Cortex-M0 +, 160 KB Flash, 20 KB RAM ) manufactured by NXP as a BLE transceiver . The chip is interesting because along with BLE it can work as a transceiver of 802.15.4 signals . And the 802.15.4 standard , as is known, is a carrier in ZigBee technology . The ZigBee stack for MKW40Z itself is not released, but it is already offered to the firmware where 802.15.4 works simultaneously with BLE . Diagram of the part of the module with the BLE chip is shown below.



(Click to enlarge)


To replace the MKW40 chip, there is already a MKW41 chipwith 128 KB RAM, 512 KB Flash volume and support for all popular protocols: BLE 4.2, BLE Mesh, ZigBee, Thread, IPv6 6LoBLE . The new chip has no open documentation yet, but it promises to be pin compatible with the MKW40.

The BLE chip MKW40 on the module is connected to the main microcontroller MK66 SPI and I2C interfaces. The I2C interface also connects the chip with a charger chip. The main communication channel is implemented on the SPI interface with a bit rate of 6 Mbit / s.

Debugging of the program in the MKW40 chip can be performed via the SWD interface using the JTAG adapter and via the UART0 debugging interface also brought to the X4 debugger connector.
NXP provides more than two dozen examples of the implementation of various applications on the MKW40 chip, including: pressure meters, glucose levels, temperatures, proximity sensors, heart rate meters, etc. There are applications for wireless UART and wireless loader.

I have done a deep refactoring of the NXP framework for these chips and created new profiles with Windows PC demo programs that do not require a separate adapter on the PC side. But more about that later.

Bluetooth LE is hard to learn. The reason is the volume specification and a large number of its brief retellings in the documentation of manufacturers, immediately starting with unusual terminology. So let's start with it.

Decoding and translation of terms and abbreviations, slang.


  • Pairing - binding (peyring). The process of creating pairs of BLE devices of one or more shared secret keys for subsequent encryption of traffic. The user is involved in this process when the system asks for a PIN code.
  • Bonding - binding (bonding). The process of retaining shared secret keys for use in subsequent trusted connections of pairs of BLE devices.
  • Device authentication - verification (authentication) that two devices have the same secret keys.
  • Advertising - The process of broadcasting a BLE device by means of an alert package (advertising). In these packages, the device reports its name and address, reports on the services it provides, as well as specific information.
  • Scanning - The process of receiving packets of overwriting from other BLE devices during passive scanning. With active scanning, sending packets of requests for additional information from devices working in the advertising mode.
  • Profile - profile. A set of lists of functions, properties, behaviors, and roles for a set of levels of a specific protocol stack.
  • UUID - universally unique identifier. 128-bit unique attribute identifier.
  • BLE Host - host. The part of the BLE stack software running on the main processor on which the main application is running and the bridge functionality to the main application is running. The host contains GAP, GATT, GATT, L2CA database.
  • BLE Controller - controller. A piece of software stack BLE running on a Bluetooth radio chip.
  • HCI - Host Controller Interface. Protocol or API depending on the context for communication between the BLE host and the BLE controller.
  • GAP - Generic Access Profile, typical access profile. This is usually called a layer immediately. But it is rather strange to call a profile a layer. In the source it is presented as a set of macros, declarations and functions for establishing and maintaining communication between BLE devices.
  • GATT - Generic Attribute Profile, a generic attribute profile. In source, this is a set of functions for exchanging data between devices. Attributes are data units of different types (strings, numbers, structures ...) organized in a hierarchical tree whose nodes are services, characteristics, descriptors, etc. The attribute is characterized by the fact that it has a unique identifier UUID.
  • L2CA - Logical Link Control and Adaptation Layer. The program layer with the appropriate protocol is responsible for establishing and maintaining logical communication channels. Engaged in forwarding scheduling, error checking, packet segmentation, flow control, packet multiplexing between upper layer protocols. It is part of the BLE host.
  • SMP - Security Manager Protocol. The protocol used for peering. Works on a dedicated channel in L2CA.
  • LTK - Long-Term Key. The secret key used to encrypt BLE traffic.
  • IRK - Identity Resolving Key. The key to decrypt the real address of the device from the confusing public.
  • CSRK - Connection Signature Resolving Key. Key for signing messages.
  • RAND - 64-bit random variable, used to form LTK
  • EDIV - 16-bit random variable, used to form LTK
  • MITM - man-in-the-middle. Attempting to open by a third party the joint secret key of two devices being introduced into the communication channel between devices as an intermediate link.
  • Message integrity - protection against message falsification.
  • The framework is what I call software in source code here, designed to simplify the creation of applications on a specific hardware platform with specific libraries of communication protocol stacks. It usually includes BSP (board support package), HAL (hardware abstraction layer), OSA (OS abstraction layer), middleware (middleware) such as: memory managers, file systems, schedulers and timers, and so on.

Competitive Decision Analysis


When choosing a chip for BLE, I conducted a small analysis of offers from the most well-known manufacturers. Most of all I was interested in the composition of the proposed software, frameworks and tools for compiling-assembling-debugging projects for the ARM core. An important factor was the continuity with the IAR environment and the RTOS MQX framework, which are used when developing the application on the main processor of the module.

NORDIC SEMICONDUCTOR

provides an SDK for the nRF51822 chip with a Cortex - M0 core . Compiled in IAR, KEIL, GCC. The BLE stack is represented by a monolithic library without source codes called SoftDevice where all APIs are implemented: GAP, GATT, L2CA, HCI. A framework with drivers is being built around this library. The framework comes with two RTOSs: RL-ARM RTX from Keil, and FreeRTOS . The framework uses protobuf serialization technology and Segger RTT debugging .

In addition, nrf5 IoT SDK is offered.. It includes the sources of the MQTT, COAP, TLS protocols (taken from the MBED project), cJSON, lwip (a free TCP / IPv4 / IPv6 protocol stack), an interface of sockets, an adapter for IPv6. There are 6LoWPAN , but without the source code.

Texas Instruments

on ARM makes only 2-core BLE chips CC2640 ( Cortex-M3 and Cortex-M0 ), but the corresponding Bluetooth 4.2 specifications . For downloading provides the SDK SimpleLink Bluetooth low energy Software Stack 2.2.0 Compiled by its own development environment Code Composer Studio, as well as in the IAR environment. It comes with its own RTOS TI-RTOS 2.16 and a developed framework around the BLE stack libraries. SDK as one of the scenarios involves the use of an external application processor - Simple Application Processor (SAP). The CC2640 chip itself is referred to as the Simple Network Processor (SNP). Communication is established between them using a protocol called the Unified Network Processor Interface.(NPI). On the CC2640 side, TI-RTOS is required, on the SAP processor side, you can use RTOS optionally. The NPI source code is supplied with the SDK for both the SAP side and the SNP side. This is SimpleLink technology .

The BLE stack itself is divided into 3 precompiled libraries without source code: host, controller, HCI. All three libraries work only on the Cortex-M3 processor, which is part of the CC2640 chip. In addition to studying TI-RTOS, the user will need to study a special software mechanism or protocol for interacting with the BLE stack called iCall.

Microchip-atmel

manufactures Bluetooth LE chips ATBTLC1000 on the core Cortex-M0 . The entire stack of chips is written in ROM. No open tools for programming these chips were found on the Atmel website. Atmel instead suggests using an external microcontroller to interact with the ATBTLC1000. Software for an external microcontroller and examples are in the Atmel Software Framework package. Compiled in Atmel Studio (shell for GCC) or in IAR.

Cypress Semiconductor Corp.

manufactures Cortex-M0 - PSoC 4 cores of programmable BLE chips on the core : PSoC 4XX8 and PRoC CYBL1XX7X supporting Bluetooth 4.2 specifications . Projects for chips are created in a special IDE PSoC Creator. Chips differ from Cypress in that there is no ready configuration of the periphery (UART, SPI, I2S, PWM, etc.), it needs to be created from library elements in the circuit editor with the addition of program libraries. This is intended to provide some flexibility. Although the developer adds a considerable amount of work. A configured project can be compiled by one of the toolchains: GCC, IAR, Keil. BLE there is one of the libraries. The BLE stack comes in the form of a precompiled monolithic library without source code combining the BLE host, BLE controller and HCI. However, the company posted the source code for Android and iOS applications working with BLE.

Siliconon labs

manufactures EFR32 Blue Gecko Bluetooth Smart SoCs on the ARM Cortex-M4 core supporting Bluetooth 4.2 specifications. The EFR32BG1P332F256GMxx type chips can deliver power up to 19.5 dBm and combine a separate radio channel at 868 MHz with a power up to 20 dBm and a sensitivity of -121.4 dBm. The chip of Silicon Labs chips is a huge selection of alternative pin functions and a system called Peripheral Reflex System(PRS). Although the periphery cannot be created like Cypress chips, but its connection to the pins is almost arbitrary, the presence of PRS makes it possible to interact with the periphery without the involvement of the processor. Silicon Labs' BLE stack is able to accept the results of profile generation by Bluetooth Developer Studiowhich will be discussed below. Silicon Labs offers two Bluetooth stacks. One of them is designed for Bluegiga modules and supports, in addition to BLE, also regular Bluetooth. The second stack complies with specification 4.2 and only LE. BLE stack comes as a monolithic precompiled library without source code. For the version with an external microcontroller, a serial protocol and API in the source code are offered. Both GCC and IAR and Keil can compile. Everything is done in a single development environment Simplicity Studio V4 . The accompanying framework stack is not supported by RTOS. But in the source code of Simplicity Studio you can find such pearls as Speex at 8 kbps suitable for voice over BLE and a powerful windowed GUI from Segger.

STMicroelectronics

makes the Cortex-M0 based BlueNRG network controller chips containing the BLE stack according to the Bluetooth 4.1 specification . The chips themselves are not programmed, but have a serial application command interface (ACI) through which the external microcontroller must communicate with them. A framework has been developed for ACI, and it can be included as an integral part of the STM32Cube proprietary development environment from ST.



CSR PLC

does not make BLE chips on ARM Cortex, but interested in its implementation of the MESH network on Bluetooth modules. The video is here . Laid out the source of various BLE applications for Android and iOS. There is an SDK.

Renesas

makes BLE chips on its 16-bit RL78 core . BLE stack is issued only to premium users. All yours - compiler, RTOS, host microcontroller. But there is a plugin for Bluetooth Developer Studio

Dialog Semiconductor

offer, as they claim, the smallest BLE chips . However, the chips with DA14583 Flash memory (the rest are only from ROM) cannot be called the smallest - 5x5 mm. Core Cortex-M0 . Maximum power 0 dBm . Support Bluetooth 4.1 specification . To get the SDK from the company, you need to register and get tested. But with such chip parameters I didn’t even try to get the SDK.

So, the sources MQTT, COAP, TLS, SPEEX, LwIP and so on. We are of little interest in the various SDKs, and so you can freely find them on Github without reference to specific frameworks. Supporting the Bluetooth 4.2 specification does little because on the PC this is not yet possible to use.

Niche RTOS like TI-RTOS or special planners will make it harder for us to master, we try to avoid such solutions.

I was pleased that I chose the solution on Kinetis.

What is interesting about the Bluetooth LE stack from NXP for the Kinetis family?


The BLE stack for Kinetis, like the others, comes in the form of precompiled libraries. A multitasking framework is built around these libraries, including a driver and a layer of hardware abstraction in source code independent of the operating system. The framework can be configured to work without an operating system, or it can be used. Immediately in the delivery framework is adapted for FreeRTOS. But it interacts with FreeRTOS through an auxiliary set of functions, called the abstraction layer from the operating system (OS abstraction, OSA).

Thanks to OSA, instead of FreeRTOS, you can substitute any other operating system that supports message queuing, preemption, flags, and timer. For example, RTOS MQX. The stack is compiled, oddly enough, only in the IAR environment. Fortunately, in my case, this is not a problem.

More interesting is that the stack is divided into two libraries - BLE host and BLE controller. And the BLE host library can work on another chip.

The libraries interact with each other in this case through the HCI protocol. Those. where other manufacturers come up with another communication protocol for the application to communicate on an external microcontroller with the BLE stack (recall SimpleLink), NXP offers a standard solution. And most importantly, with this approach, moving BLE host to a more powerful external microcontroller, we significantly increase the capabilities of our GATT database and services.

BLE in brief


An open version of the Bluetooth specification version 4.2 is available here . The description of the BLE lower level ( Controller level ) is included as “Vol.6 Core System Package [Low Energy Controller volume]” from page 2544. The upper level ( Host level ) with the description of the ATT protocol and the GATT profile is in the “vol.3” part Core System Package [Host volume] " document from page 1693.

The range of frequencies used

(Click to enlarge)


Three frequencies (in the figure above are indicated by channel numbers 37,38,39) are allocated for broadcast indirective parcels, and the rest for packet transmission when establishing logical communication channels between devices. A well-known feature of Bluetooth is that during the transmission of packets, each next packet is transmitted on a different frequency of the selected pseudo-random from the list of allowed.

All data in BLE packets can be encrypted and authenticated. Dynamic random generation of device addresses and their identification using hashing, i.e. Having intercepted the device address on the air, we will not be able to use it for longer than 15 minutes, since the address will change in this time according to an algorithm unknown to us.

BLE modules can operate as unidirectional transmitters, i.e. without setting up a bidirectional connection, it’s easy to broadcast some data in the form of ad packets, for example, temperature. For this, the data type in the Advertising packages designated as Manufacturer Specific Data can be used . A computer or tablet can receive data from hundreds of such transmitters without unnecessary preliminary steps in searching, establishing a connection, entering a pincode, and so on.
Another possibility to transfer data without setting a communication channel is to transmit in the request-response mode (request - ScanRequest package , module response - ScanResponce package ). This BLE is significantly different from Wi-Fiwhere even for the simplest thermometer it is necessary to establish a connection that takes away the resources of the router.

BLE protocol stack


The figure below shows the BLE representation as seen by the microcontroller programmer. The BLE stack consists of two software parts: Host and Controller . The software part of the Host deals with high-level functions of organizing and managing data and connections, while the Controller controls the physical peripherals of the transceiver, works with secret keys, and deals with other low-level functions. The named parts are connected by the HCI ( Host Controller Interface ) software interface . In the PC implementation, the Host part works on the computer, and the Controller part works in the hardware transceiver.Bluetooth , and the HCI protocol is most often transmitted via USB . In the implementation on the microcontroller, both parts work on the same chip, and the HCI interface simply turns into direct data transfer from the task (software module) of the host to the task (software module) of the controller and vice versa.
In fact, the programmer sees several sets of APIs running at the Host : level called GATT , GAP, L2CA, SMP, HCI . With the help of the GAP API , the device operation mode is set to Central, Peripheral, Observer, Broadcaster and the connection is established when needed. And using the GATT APIdirect transfer and reception of useful data and their analysis is performed.

(Click to enlarge)


Most existing devices still support BLE 4.1, despite the existence of version 4.2.

All the differences between version 4.2 and the previous one concern precisely the improvements in the part of BLE: speed increase, the ability to transmit IP protocol and HTTP traffic, increased cryptographic protection and unrecognizability for outsiders.

An important feature of BLE in comparison with Wi-Fi is the specification of not only the communication channel, but also the application itself using it. This is called profiles and services. Profiles with services describe the roles of the devices, the purpose of the data, the composition and format of the data, the protection of the data, the order, the types and events of the exchange, and not just how the data is transmitted. This makes it possible not to reinvent the wheel from protocols when developing, for example, a body temperature sensor or a pulse meter. The specifications have already been given, it remains on the side of the device only to fill in the necessary fields to send measurement results. Clients of such devices in the form of smartphones, tablets, PCs or kitchen appliances will recognize this data automatically and display it or use it accordingly. All thanks to the fact That all manufacturers are guided by the same BLE specifications about how temperature or pulse data are presented and how to work with them. But there is still room for the developer’s imagination, since profiles have mechanisms for extending functionality.

Below is a rough attribute hierarchy in a BLE device.

(Click to enlarge)


Below is a slightly more detailed attribute tree. This is not a complete tree, most are omitted because it would take too much space. The colors of the tree are highlighted, each attribute has a unique number - UUID. The entry of standard numbers is reduced to 16 bits. In this picture, all rooms are standard. GAP and GATT profiles are also presented as services with their standard features. Each service can have its own security model and authorization. The entire tree in the device is stored as a database called the GATT database, usually in the form of a simple table with cross-references.


(Click to enlarge)

Service characteristics have many characteristics, as shown below. Here you have to apologize for the tautology, but in BLE there really is some sort of crisis of terminology. In short, the characteristics belonging to the service can be specified tolerances for reading, writing, the need for notices, confirmations, signatures, and so on.


(Click to enlarge)


BLE is a serious technology, so much has been done to ensure security and maximum formalization, which should in turn facilitate the achievement of compatibility.

Data exchange between BLE devices is performed by writing and reading characteristic values. There are no streaming channels such as TCP or UART. And if the devices have them, then it means they are organized by software add-ons of a higher level.

Development tools


Development tools with the proposed Bluetooth Special Interest Group (Bluetooth SIG) site - https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools

The following standard tools are offered on the website of the main standardization organization - Bluetooth SIG :

Bluetooth Developer Studio


Bluetooth Developer Studio is a tool that allows you to correctly form and insert profiles, services, features and descriptors into the BLE device implementation , i.e. create a database. If you buy an additional hardware Bluetooth adapter for $ 99, the program allows you to intercept , decrypt and display Bluetooth protocol packets. There are in the program and opportunities for debugging and testing the services created.

Since in the BLEapproved profiles are described in great detail, even minor errors about the format, numbering, accessibility, and so on. these profiles will cause compatibility issues. But for non-standard profiles it is very difficult to do without a tool that accurately constructs the tree of services, characteristics, descriptors with all the specifications. It is easy to get lost in the names of services, characteristics, descriptors and their multibyte unique numbers - UUID .

The result of the tool in particular are the generated XML files describing the profiles, services, characteristics and descriptors in the user project. These XML files are directly used by Silicon Labs' Simplicity IDE development environment for integration into embedded projects for their chips.


(Click to enlarge)


Another result of the tool can be the source code for the device working with the BLE database . But for this the user needs to write his plugin in JavaScript . The program also provides plug-in user access to the database through a special API to JavaScript .
There are a number of ready-made plug-ins that form the output of various source text files suitable for compiling in third-party software frameworks.

There are no plugins for solutions based on the NXP Kinetis KW40Z Connectivity Software framework .

Application accelerator


Application accelerator 2.1 is a set of sample projects with source texts for different Android 6 operating systems . 0 , Blackberry , iOS 9 , Tizen 2 . 4 and Windows 10 . For Windows 10 projects are only for the Visual Studio development environment under the Universal Windows Platform (UWP) architecture . Those. these projects cannot be compiled under Windows Forms or WPF with .NET . And bridges to transfer ordinary Windows applications to UWPjust being created.

It should be noted that the UWP allows you to place applications in the Windows Store , but it does not create a simple executable .exe file, which you can simply copy and run. The first launch of the UWP application is always accompanied by the installation. All this creates difficulties for the developer. And the functionality of the demonstration projects leaves much to be desired.


(Click to enlarge)


Above is a screenshot of the only demo application for Windows - BLEServiceBrowser .

Gateway smart satarter kit


Gateway Smart Starter Kit - Project of the BLE device gateway to the WEB server and the WEB server itself implementing the user interface for the BLE network of devices. Everything is implemented in the Node.js environment. It is proposed to deploy on a microcomputer Raspberry Pi 2 model B with the operating system Raspbian Jessie . Directly to connect the Raspberry Pi to BLE devices, use Bluetooth HCI sockets interface to L2CAP and USB HCI levelsadapter. To run under Windows, you need to install a special substitute for the standard Bluetooth driver HCI . The solution works on a very limited number of hardware adapter types due to the limitations of the HCI driver.


Peryton


Among commercial tools, the BLE traffic analyzer from Perytons is interesting. The analyzer program runs Windows PCs from version 7 onwards . This is an important point, since native BLE drivers for Windows work only starting from version 8. The analyzer works with a limited list of hardware BLE adapters .

When working with adapters, there are also limitations in the analysis caused by traffic encryption in BLE.


(Click to enlarge)


However, even from the trial version of the program you can get a lot of benefits. The program is accompanied by demonstration records of interceptions of the exchange of real devices. These records after loading into the program give a detailed picture of the work of the entire stack of BLE protocols. Viewing one such interception replaces the study of all Bluetooth specifications.

Bus hound


If you just need to somehow monitor the activity between the computer and the BLE device and you can do without a detailed analysis of the protocol, then the well-known Windows driver traffic interceptor called Bus Hound will do .

In the screenshot below you can see the stream of received advertizing packets. Well noticeable irregularity of time intervals for receiving packets. This indicates a significant packet loss. The advertisy interval for the BLE device was set to 20 ms.


(Click to enlarge) The


screenshot below shows the BLE device in the Bus Hound window after peering from a PC. For each device service after peering, a logical communication channel appears. Here you can see the UUID of the device and services.



Analyzer BLE traffic (sniffer) USB-KW40Z


This is a tool from the Kinetis development support kit. Therefore, I will focus on it in more detail. The sniffer page on the NXP website.


Sniffer was developed by NXP (or rather the former Freescale) and can be purchased inexpensively at popular on-line stores of radio components: Mouser, Digi-Key, Farnell ... It is offered by NXP as a tool for monitoring radio packets sent by BLE devices.

Using this device, you can study the structure of packets, record them in a log, and analyze traffic density. The sniffer scheme is open for study, but the microcontroller program is supplied as a binary file. Sniffer allows you to filter packets by address value.

PC software can be downloaded to the sniffer by the following search request at www.nxp.com - Kinetis_Protocol_Analyzer_Adapter.exe.

Since the sniffer besides the main function can also be a debugging platform for different applications, it contains binary files of the base firmware, with which You can restore the functionality of the sniffer after the experiments. The files come with the KW40Z Connectivity Software package , which is downloaded from the site www.nxp.com for the search query KW40Z_Connectivity_Software. The files will be called Sniffer_processing_core_usbkw40z_k22f.bin (for the MK22FN512 microcontroller on the sniffer board) and Sniffer_radio_core_usbkw40z_kw40z.bin(for the MKW40Z microcontroller on the sniffer board). Files are programmed using SWD debuggers: JLink, STLink, OpenSDA ...

On the PC side, the device is perceived as a composite USB device with one COM port and one debugging port according to the specification, OpenSDA with CMSIS-DAP firmware. Thus, in the IAR environment, it is possible to freely program and debug a sniffer's MKW40Z chip using its other MK22FN512 chip as a carrier of debug adapter functionality. But both chips on the board have standard SWD connectors for an external debug adapter.

Sniffer does not guarantee reception of all packets transmitted over the air. It is easy to flood it, after which it ceases to accept any packets, so it is recommended to enable filtering at the address in order to receive only packets from the node of interest with a rather rare traffic.

Below is a packet sniffer window. The window includes interception across all three channels:


(Click to enlarge)


When installing the analyzer software on a PC, it creates a virtual Ethernet adapter that converts packets captured through the virtual COM port of the sniffer into an Ethernet packet view. In my case, such a virtual adapter automatically got a simple name - Ethernet.
To see the packets, you also need to install the Wireshark Ethernet packet sniffer program.

View of the main window of the Wireshark program while monitoring traffic. Wireshark describes in detail all the bit fields of the Low Layer Link Layer Protocol (LE LL) packets, however, after the connection between devices is established and the L2CAP protocol starts working, the contents of the packets are not recognized because it is transmitted encrypted.


(Click to enlarge)


View of the Wireshark program window with decryption of the announcement package



The contents of the package Connection Request with the parameters that determine the speed of the communication channel

The sequence of packets when establishing a connection


Comments, additions, corrections and objections to the information in this article are welcome.

Also popular now: