|
TReK ANSI-C
5.3.3
All ANSI-C APIs
|
The trek_toolkit_ds_api library provides ANSI C functions that create and communicate with Transmission Control Protocol (TCP) sockets, User Datagram Protocol (UDP) sockets, Unix local/domain sockets, and Delay-Tolerant Network (DTN) Bundle Protocol (BP) devices on both Windows and Red Hat Enterprise Linux operating systems. In addition, TReK provides ANSI C functions that enable FIPS 140-2 compliant encryption or decryption of packets or bundles that flow across the aforementioned sockets or devices.
Background
Internet Protocol (IP) sockets are software constructs that work with a Network Interface Card (NIC) to move IP traffic between a network and a user application. There are two types of IP traffic, TCP and UDP. TCP is connection oriented, once a connection is established, packets of data can be sent bidirectionally. TCP breaks up or groups packets into segments to ensure delivery and order to a network destination endpoint. It is the responsibility of the receiving application layer to retrieve the packets from the segments. UDP is a simpler, connectionless Internet protocol. Multiple messages are sent as packets in chunks using UDP. UDP does not guarantee the delivery or the sequential order of the packets.
TCP sockets, sockets that only work with TCP traffic, come in three flavors: listeners, servers and clients.
TCP client sockets make connection requests to TCP listener sockets. TCP listener sockets accept connection request from TCP client sockets. A TCP connection is established when a TCP listener socket creates a TCP server socket and connects it to a TCP client socket. A TCP client sockets must be connected to a TCP server socket before data can be sent bidirectionally. A TCP client socket may be connected to only one TCP server sockets however, a TCP listener socket may accept connections from multiple TCP client sockets.
UDP sockets, sockets that only work with UDP traffic, are always clients. UDP client sockets do not require connections and may send and receive data from multiple UDP client sockets. A multicast UDP socket is a UDP socket that has joined a multicast IP address group. UDP packet transmission is generally one to one. One sockets sends a packet to the IP address and port number of one other socket. Multicast transmissions have the advantage of one socket sending a packet to multiple sockets simultaneously. A Time-To-Live (TTL) parameter is associated with all multicast packets to prevent them from perpetually flowing on the connected networks.
Unix local sockets, sockets that may only be created on platforms with Unix-like operating systems, are created for inter-process communication between application running on the same platform. Two Unix local sockets establish an interface with each other by identifying a unique name in an abstract name space. Packets of data may then be sent between the two Unix local sockets without the communication overhead associated with traditional IP traffic.
DTN is a digital communication networking technology that enables data to be conveyed between two communicating entities automatically and reliably even if one or more of the network links in the end-to-end path between those entities is subject to very long signal propagation latency and/or prolonged intervals of unavailability.
The Interplanetary Overlay Network (ION) software is an implementation of DTN. The TReK Device Services (DS) library's BP device is dependent on the ION DTN BP architecture as described in Internet RFC 4838. TReK's BP device sends and receives packets of data using ION's implementation of the bundle protocol. Packet ordering and delivery are dependent on the bundle protocol configuration parameters defined when the TReK BP device is created.
Device Services Library
Socket Creation:
The first step to perform when using the Device Service (DS) library is to create one or more sockets or devices. The DS socket creation functions include: CreateTCPListenerSocketDevice, CreateTCPClientSocketDevice, CreateUnicastUDPSocketDevice, CreateIPv4MulticastUDPSocketDevice, CreateUnixLocalClientSocketDevice.
Each of these functions requires an IP address and/or a port number or a path and filename and returns a character string called a device key. All device keys are unique and are used by the DS library to identify sockets or devices. If a user application needs to work with a pre-defined name for a socket, DS library provides the CreateDeviceKeyAlias function to associate a device key with the user's pre-defined name or alias.
Once an alias has been established, DS functions that require the device key may also use the alias. All DS sockets may be created with an associated packet queue to improve performance of the socket in high packet rate conditions. The size of the packet queue is configurable. Queued packets will be dequeued when one or more packet destinations
(e.g., callback functions or other devices) have been identified and associated with the socket. If no packet destination is associated with the socket, the socket's queue will fill up and newly received packets will be dropped. The socket's device statistics provides a count of dropped packets. No packet statistics are collected for the queued or dropped packets.
This behaviour is not duplicated with a socket that does not have a queue. A socket without a queue provides packet statistics on all received packets and does not increment the packets dropped count if no packet destination is associated with the socket.
Simply put, a socket with a queue "blocks" while waiting for a packet destination association and a socket without a queue does not "block" while waiting for a packet destination association.
TCP Sockets:
If the newly created socket is a TCP client socket it needs to be connected to a TCP listener socket. The ConnectSocketDevice function connects a TCP client socket to a TCP listener socket by specifying the device key or alias of the TCP client socket and the IP address and port number of the TCP listener socket. The DS library provides two callback functions to help the manage TCP connections. The RegisterAcceptConnection function registers a callback functions that identifies and notifies the user application when a TCP client socket is attempting to connect to the user application's TCP listener socket. The RegisterDropConnectionFromListener function registers a callback functions that identifies and notifies the user application when a TCP client socket drops a connection with the listener's server socket. The RegisterDropConnectionFromClient function registers a callback functions that identifies and notifies the user application when a TCP server socket drops a connection with the client socket. Simply provide the TCP socket device key and a pointer to the appropriate callback function when registering for notification of socket accept or socket close events. TCP connections should be closed if a network experiences an anomaly and is unable to transport IP traffic or one end of the TCP connection is compromised. TCP sockets determine connection integrity by sending keep-alive packets after a designated time of network inactivity. The connection is closed if a keep-alive response is not received from the connected socket. The SetTCPKeepalive function configures a TCP socket to send keep-alive packets to ensure connection integrity.
Packet Header Processor:
One more step is required before packets can be retrieved from TCP sockets. Unlike UDP sockets, TCP sockets may receive packet segments and not fully assembled packets. So, an application that receives packets from a TCP socket may receive the packet in multiple segments or it may receive multiple packets in a single segment. To retrieve the packets of data from the segment(s), packets must either be a fixed size or designed with a packet header that at a minimum includes a packet length and/or a packet synchronization pattern. By defining, creating and associating a DS packet header processor with a TCP socket, the DS library can retrieve packets from TCP segments. The library provides five functions to define and create a DS packet header: DefinePHPFixedPacketSize, DefinePHPPacketSizeField, DefinePHPSyncHexPattern, DefinePHPPacketKeyField and DefinePHPPacketSequenceCountField. After defining and creating the DS packet header processor simply associate it with one or more TCP sockets using the AddPacketHeaderProcessor function. Only one uniquely defined DS packet header processor may be associated with a socket or device.
A packet header processor may also be used to identify packets and detect packet sequence errors that have occurred during the reception of packets by a device such as a socket. The DefinePHPPacketKeyField function defines the bit location of a value
that is used to create a packet key string. One or more packet key fields may be defined for a packet header processor.
The packet key string that is associated with the packet is a dotted ASCII numeric string of key field values (e.g.,php_name.1, CCSDS.1.2, EHS.3.4.5).
The character string at the the beginning of the key describes or identifies the packet stream type.
The user provided packet header processor name is the default value for the stream type. The order of key field values after the packet stream type follows the order the key fields were defined/added to the packet header processor. The packet key is used to identify statistics for distinct packet groups and includes any packet sequence errors that might have occurred if the packet header processor was defined with a packet sequence count field using the DefinePHPPacketSequenceCountField. Packet statistics may be recorded for later viewing using the StartRecordingStatSnapshot function.
UDP Sockets:
UDP sockets require no connections. Once a UDP is successfully created, it is ready to send and receive packets. However, if the UDP socket is a multicast UDP socket, it must join a multicast group prior to receiving packets sent to the multicast group address. The JoinMulticastGroup function associates a multicast socket with a multicast IP address using the socket's device key. A multicast socket may join multiple multicast IP address groups. In addition, a TTL parameter must be defined for all packets sent to a multicast address. The SetMulticastTTL function defines the TTL of multicast packets sent by the UDP socket with the designated device key.
BP Devices:
To create a BP device using the DS library the host platform must be running ION's BP applications prior to creating the device. Users must also know the ION service number that associates the BP device with ION's configured BP service. Additional BP device parameters define each transmitted bundle's lifespan, priority, transmission mode and criticality. The CreateBPDevice function creates a BP device and returns a device key. The following table identifies and describes the BP device transmission parameters.
| BP Device Transmission Parameters | Description |
| lifespan | The lifespan is the bundle's "time to live" (TTL) in seconds. The bundle is destroyed if its TTL has expired and it has not reached its destination. A typical value is 86400. |
| bp_class_of_service | The BP class of service defines the transmission priority of outbound bundles from three ION priority queues corresponding to bulk, standard and expedited priorities. The three BP class of service parameter values are BULK_PRIORITY, STD_PRIORITY and EXPEDITED_PRIORITY. The expedited priority queue must be empty before bundles in the standard or bulk queues are serviced by ION. Therefore, bundles with EXPEDITED_PRIORITY should only be sent in critical/emergency situations. A typical value is STD_PRIORITY. |
| expedited_priority_ordinal | The expedited priority ordinal is only associated with the EXPEDITED_PRIORITY class of service. Ordinal values range from 0 (lowest priority) to 254 (highest priority). A typical value is 0. |
| transmission_mode | The transmission mode defines the reliability of bundle delivery to a destination. The three transmission mode parameter values are BEST_EFFORT, ASSURED and ASSURED_WITH_CUSTODY_TRANSFER. BEST_EFFORT relies upon the underlying convergence-layer protocol (e.g., Transmission Control Protocol or TCP) to retransmit missing bundles. ASSURED is a step up in reliability and includes BP support in detecting a lost TCP connection and re-forwarding of bundles assumed aborted by the convergence-layer protocol failure. ASSURED_WITH_CUSTODY_TRANSFER requires the reception, by the sending node, of a custody acceptance or refusal signal (packaged in a bundle) from the receiving node. The default value is ASSURED_WITH_CUSTODY_TRANSFER. |
| criticality | A critical bundle is one that has to reach its destination as soon as is physically possible. For this reason, bundles flagged as critical may not include custody transfer and require an ION configuration with contact graph routing. In some cases, a critical bundle may be sent over multiple routes to ensure delivery to its final destination. Critical bundles are placed in the expedited priority queue and should only be used in emergency situations. The two criticality parameters are NOT_CRITICAL and CRITICAL. A typical value is NOT_CRITICAL. |
IP Address Discovery:
The IP address of the host platform may be determined by calling the PopulateIPAddressStructArray function. This function returns an array of IPAddress structures that identify valid IP addresses for the platform. The IP address structure is defined as follows:
| Data Type | Member Variable Name | Description |
| char | ip_address | IP address |
| ip_address_version_type | ip_address_version | Version (e.g., IPV4, IPV6) |
| ip_address_v6_category_type | ip_address_v6_category | Version 6 category (e.g., UNDEFINED_IP_ADDRESS_V6_CATEGORY, GLOBAL_FIXED, GLOBAL_TEMPORARY, LINK_LOCAL, TAREDO_TUNNELING, IPV6_TO_IPV4_TUNNELING, MULTICAST, OTHER) |
Packet Reception:
The DS library provides two different methods to receive packets from sockets. The first method works with a callback function to deliver packets to a user application. The second method works with a timed wait interface to deliver packets to a user application. The RegisterReceivePacketFromSocket function registers a user's callback functions with a socket that is identified by its socket device key. When a packet is received by the socket, the packet is provided to the user's callback function and includes the IP address and port number of the socket that sent the packet. The ReceivePacketFromSocketDevice is a timed wait functions that will wait the prescribed amount of milli-seconds for a packet to be received by the socket.
If no packet arrives in the prescribed window of time, then the functions return with an appropriate return value. If a packet arrives in the prescribed window of time, the function returns with a pointer to the packet.
The DS library also provides two different methods to receive packets transmitted as bundles from ION. The first method works with a callback function to deliver packets to a user application. The second method works with a timed wait interface to deliver packets to a user application. The RegisterReceivePacket function registers a user's callback functions with a BP device that is identified by its device key. When a packet is received by the BP device, the packet is provided to the user's callback function and includes the packet's origin or source endpoint id string (e.g.,<source node number>.<source service number>). The ReceivePacketFromDevice is a timed wait functions that will wait the prescribed amount of milli-seconds for a packet to be received by the BP device.
If no packet arrives in the prescribed window of time, then the functions return with an appropriate return value. If a packet arrives in the prescribed window of time, the function returns with a pointer to the packet.
Packet Transmission:
The DS library provides multiple functions for packet transmission from a socket. The SendPacketFromUDPSocketDevice sends a packet to a user specified IP address and port from a UDP socket. The SendPacketFromTCPServerSocketDevice sends a packet from a TCP server socket identified by its server and listener device key to its connected client socket. The more general SendPacket function may be used to send a packet from a TCP client socket to its connected server socket or it may be used to send a packet from all the servers associated with a listener to all the listener's connected clients.
The DS library also provides a function for packet transmission from a BP device. The SendPacketFromBPDevice sends a packet to a user specified node and BP service number from a BP device.
Packet Encryption and Decryption:
The DS library's TReK encryption library uses OpenSSL's FIPS 140-2 validated cryptographic module and public/private key pairs to encrypt and decrypt packets and bundles. TReK encryption library support is provided on 32 bit and 64 bit Linux operating systems and 64 bit Windows operating systems. TReK encryption library support is not available on 32 bit Window operating systems. Both the flight platform and ground platform generate and store public/private key pairs using TReK's "trek_crypt" application or the DS library's GeneratePublicPrivateKeyPair or GeneratePublicPrivateKeyPairWithPassphrase functions. TReK's public key/private key encryption architecture is based on Elliptic Curve Cryptography (ECC) using curve P-256 providing 128-bit security with 128 or 256 bit keys. The cipher packages included with the TReK encryption library are the Advance Encryption Standard (AES) Galois/Counter Mode(AES GCM) and the AES Counter with CBC-MAC (AES CCM) ciphers offering confidentiality, authenticity and integrity. The library supports 128 and 256 bit cipher key sizes and provides AES 128 and 256 bit key-wrap/unwrap functions.
Fresh Cipher Encryption Keys (CEK) are created for files and packets using a Password-Based Key Derivation Function 2 (PBKDF2).
DS library's GeneratePublicPrivateKeyPair or GeneratePublicPrivateKeyPairWithPassphrase functions generate and store the public and private key pair using ECC. The private key is wrapped/encrypted prior to storing in a file with a default passphrase when using DS library's GeneratePublicPrivateKeyPair or a user passphrase when using DS library's GeneratePublicPrivateKeyPairWithPassphrase. The shared secred key is generated using the private key and the remote/destination platform's public key referred to as the peer public key. The peer public key (i.e., the public key of the destination platform) must be exchanged manually prior to encryption or decryption, no automated key exchange mechanisms is implemented. The TReK encryption library may be configured to generate a new CEK for every encrypted packet or bundle in a stream. The TReK encryption library may also be configured to generate a new CEK, for a stream, once every "x" seconds to support encryption of high rate packet or bundle streams.
No "encryption handshaking" is required between flight and ground hardware during the encryption and decryption of packet or bundle streams.
The DS library provides three functions to enable sockets and BP devices to encrypt and decrypt packets and bundles: AddCipherToDevice, AddCipherToDeviceWithPeerIPAddress and AddCipherToDeviceWithPeerBPNodeNumber. When an encryption/decryption cipher is added to a device, packets or bundles sent by the device may be encrypted and packets or bundles received by the device may be decrypted. The AddCipherToDevice function enables the encryption of all packets or bundles sent by the device and decryption of all packets or bundles received by the device using a single peer public key.
The AddCipherToDeviceWithPeerIPAddress function enables encryption and decryption of packets that are sent to and received from a particular peer IP address.
This function may be called multiple time for a single socket device allowing the socket device to use different peer public keys when encypting and decrypting packets sent to and received from different IP addresses. If a packet is sent to or received from an IP address that is not found in the socket device's list of peer IP addresses, the packet will not be encrypted or decrypted. The AddCipherToDeviceWithPeerBPNodeNumber function is similar to the AddCipherToDeviceWithPeerIPAddress function except the peer IP address is replaced by the peer BP node number. Bundles sent to or received from the peer BP node number are encrypted or decrypted using the peer public key associated with the peer BP node number.
This function may be called multiple time for a single BP device allowing the BP device to use different peer public keys when encypting and decrypting bundles sent to and received from different BP node numbers. The following table identifies and describes the different parameters associated with the three add cipher functions.
| Add Cipher Parameters | Description |
| device_key | A character string that uniquely identifies each device. |
| cipher_class | The cipher package that the TReK encryption library will use to encrypt and decrypt data. The cyphers support either a 128 bit or 256 bit symmetric key. The cipher_class_type is defined in the file "ds_shared.h" as follows: AES_128_GCM, AES_256_GCM, AES_128_CCM and AES_256_CCM. |
| public_key_pathname | The path and file name of the public key. |
| private_key_pathname | The path and file name of the private key. |
| peer_public_key_pathname | The path and file name of the peer public key. The peer public key is the public key of the remote/destination platform. |
| pkt_key_encrypt_time_interval_sec | Determines how often the packet encryption key is changed while encrypting a stream of packets. If the packet encryption key time interval is set to zero, the TReK encryption library will generate a new packet encryption key for every packet in the stream. |
| bundle_key_encrypt_time_interval_sec | Determines how often the bundle encryption key is changed while encrypting a stream of bundles. If the bundle encryption key time interval is set to zero, the TReK encryption library will generate a new bundle encryption key for every bundle in the stream. |
| peer_ip_address | The IP address of the remote/destination platform that is receiving the encrypted data or sending the encrypted data (i.e., the IP address of the remote/destination platform whose public key is represented by the peer public key). |
| peer_bp_node_number | The DTN ION node number of the remote/destination platform that is receiving the encrypted data or sending the encrypted data (i.e., the DTN ION node number of the remote/destination platform whose public key is represented by the peer public key). |
| crypt_user_passphrase | The passphrase that is used to wrap/encrypt the private key prior to storing the key in the private key file. Pass an empty string (i.e., "") if no crypt_user_passphrase was defined when the public/private key pair was created. |
Messages:
A callback function may be used to deliver error, warning, information, progress and debug messages to a user application. The user must register their callback function using the RegisterMessage function. The callback function returns messages inside a message structure defined as follows:
| Data Type | Member Variable Name | Description |
| char | time_stamp | The GMT time the message was generated |
| enum message_category | category | The message category (e.g., MSG_CAT_ERROR, MSG_CAT_ERROR_ALERT, MSG_CAT_WARNING, MSG_CAT_WARNING_ALERT, MSG_CAT_INFO, MSG_CAT_INFO_ALERT, MSG_CAT_PROGRESS, MSG_CAT_DEBUG) |
| char | message | The message |
Logging:
The DS library information, debug, progress, information, warning and error messages may be logged to a user specified file using the StartLoggingMessages function. A user application may also write messages to the log file using the LogMessage function. The StopLoggingMessages function closes the log file and prepends a time tag to the log file name.
Statistics:
The DS library may record a snapshot of device and packet statistics to a user specified file using the StartRecordingStatSnapshot function. The snapshot of device and packet statistics is updated once a second with current statistics information at both the device and packet level. Device statistics provides information on all packets that are being received or sent by the device. Packet statistics provides information on the individual packet groups that are being received or sent by the device. (Note: The ability to identify and group packets is not currently exposed in the DS library). Device and packet statistics information for all devices may be reset to zero by calling the ResetStatistics function. The StopRecordingStatSnapshot function closes a statistics file and prepends a time tag to the file name. The file generated by statistics recording is a text file with values separated by commas.
A ".csv" file extension is also added the to the end of the filename if no file extension is provided. Spreadsheet applications may be used to view the statistics file. The following two table identifies and describes the device and packet statistics parameters.
| Device Statistics Parameter | Description |
| Device Key | A character string that uniquely identifies each device. |
| IP Address | The IP address of the device if it is a socket. |
| Port (C/L/S) | The port number of the device if it is a socket. If the socket is a client socket then the port number will be followed by two "/". If the client socket is connected to a listener socket, the listener's port number is also listed. If the socket is a server socket then the client port number that is connected to the server is listed first, followed by two "/" and the server's listener port number. If the socket is a listener socket the listener's port number is listed between two "/". |
| Protocol | The IP transportation protocol, either TCP or UDP, if the device is a socket. |
| Segments Rcvd | The number of segments received by the device if the device is a TCP socket. |
| Pkts Rcvd | The total number of packets received by the device. |
| Pkts Sent | The total number of packets sent by the device. |
| Pkt Rcv Rate | The number of packets received by the device in the last second. |
| Max Pkt Rcv Rate | The maximum packet receive rate experienced by the device. |
| Kbit Rcv Rate | The number of kilobits received by the device in the last second. |
| Max Kbit Rcv Rate | The maximum kilobit receive rate experienced by the device. |
| Pkt Send Rate | The number of packets sent by the device in the last second. |
| Max Pkt Send Rate | The maximum packet send rate experienced by the device. |
| Kbit Send Rate | The number of kilobits sent by the device in the last second. |
| Max Kbit Send Rate | The maximum kilobit send rate experienced by the device. |
| Pkts Dropped | The total number of packets that were dropped because they could not be temporarily stored in a queue or buffer. The most likely cause of dropped packets is packets arriving at very high packet rates and/or a queue size that is too small. |
| Packet Statistics Parameter | Description |
| Packet Key | A character string that uniquely identifies each packet type. |
| Pkts Rcvd | The total number of packets that are received and identified as this packet type. |
| Pkts Sent | The total number of packets that are sent and identified as this packet type. |
| Pkt Rcv Rate | The number of packets received and identified as this packet type in the last second. |
| Max Pkt Rcv Rate | The maximum packet receive rate experienced by this packet type. |
| Kbit Rcv Rate | The number of kilobits received and identified as this packet type in the last second. |
| Max Kbit Rcv Rate | The maximum kilobit receive rate experienced by this packet type. |
| Pkt Send Rate | The number of packets of this packet type sent in the last second. |
| Max Pkt Send Rate | The maximum packet send rate experienced by this packet type. |
| Kbit Send Rate | The number of kilobits of this packet type sent in the last second. |
| Max Kbit Send Rate | The maximum kilobit send rate experienced by this packet type. |
| Pkts Dropped | The total number of packets, of this type, that were dropped because they could not be processed by another device. The most likely cause of dropped packets is packets arriving at very high packet rates. |
| Pkt Seq Errors | The total number of packet sequence errors identified for this packet type. For example, the primary header of the CCSDS packet contains a 14-bit number that is used as a sequence count. For each packet that arrives, the sequence count is compared to the sequence count of the previous packet. If the count is not the next in the sequence, the packet sequence error value is incremented. |
| Max Pkt Seq Error | The maximum packet sequence error experienced by this packet type. |
Final Notes
The DS library is thread safe. Call the DSCleanUp function prior to exiting to gracefully shut down and properly clean up the DS library. Be sure to look at the examples provided with this library for a better understanding on how to use the library functions.
Click on this link toolkit_ds_api_ansi_c.h to go to the header file with all the functions.
Functions from other APIs
GetMessageCategoryAsString
GetMessageCategoryAsPaddedString
TCAACGetHomeDirectory
Examples
The following examples are provided to show how to use the TReK DS library functions:
Send and receive multicast packets
Shows how to send and receive multicast packets using a unicast UDP socket, a multicast UDP socket, the SendPacketFromUDPSocketDevice function and the RegisterReceivePacketFromSocket callback function.
Source File:
network_multicast/main.c
Send and receive TCP packets
Shows how to send and receive TCP packets by creating and connecting a TCP client socket to a TCP listener socket. Uses the SendPacket function and the RegisterReceivePacketFromSocket callback function to send and receive packets.
Source File:
network_tcp/main.c
Send and receive UDP packets
Shows how to send and receive UDP packets using two unicast UDP sockets, the SendPacketFromUDPSocketDevice function and the RegisterReceivePacketFromSocket callback function.
Source File:
network_udp/main.c
Send and poll to receive UDP packets
Shows how to send and poll to receive UDP packets using two unicast UDP sockets, the SendPacketFromUDPSocketDevice function and the ReceivePacketFromSocketDevice function.
Source File:
network_udp_polling/main.c
Simple network BP destination node
An application that is acting as the destination/remote EID or node for the network BP examples applications.
Source File:
network_bp_destination/main.c
Send and receive packets transmitted as bundles from ION
Shows how to send and receive bundles using a BP device, the SendPacketFromBPDevice function and the RegisterReceivePacket callback function.
Source File:
network_bp_source/main.c
Send and poll to receive packets transmitted as bundles from ION
Shows how to send and poll to receive bundles using a BP device, the SendPacketFromBPDevice function and the ReceivePacketFromDevice function.
Source File:
network_bp_polling/main.c
Send encrypted and receive decrypted UDP packets
Shows how to send encrypted UDP packets and receive/decrypt UDP packets using two unicast UDP sockets, the SendPacketFromUDPSocketDevice function, the RegisterReceivePacketFromSocket callback function, the GeneratePublicPrivateKeyPair function, the GeneratePublicPrivateKeyPairWithPassphrase function, the AddCipherToDevice function and the AddCipherToDeviceWithPeerIPAddress function.
Source File:
network_encrypt_decrypt/main.c
Send encrypted and receive decrypted packets transmitted as bundles from ION
Shows how to send encrypted bundles and receive decrypted bundles using a BP device, the SendPacketFromBPDevice function, he RegisterReceivePacket, callback function, the GeneratePublicPrivateKeyPair function, the GeneratePublicPrivateKeyPairWithPassphrase function, the AddCipherToDevice function and the AddCipherToDeviceWithPeerBPNodeNumber function.
Source Files:
network_bp_source_encrypt_decrypt/main.c
network_bp_destination_encrypt_decrypt/main.c
Additional Dependencies
The TReK Device Services API is also dependent on the following libraries.
trek_toolkit_common_api
trek_toolkit_ds_api
trek_bp_attach_device_api (ION)
trek_bp_device_api (ION)
trek_toolkit_dropbox_device_api
trek_opencrypt_device_api (Cryptography)