Eclipse ThreadX - NetXDuo is an advanced, industrial-grade TCP/IP network stack designed specifically for deeply embedded real-time and IoT applications
Home Page: https://github.com/eclipse-threadx/rtos-docs/blob/main/rtos-docs/netx-duo/index.md
License: MIT License
If netX TLS is set as server mutual auth and the client try to connect in TLS 1.2 without certificate the alert "Bad certificate" is sent twice, connection isn't closed and server do not listen anymore :
My workaround is to comment "send alert process" in _nx_secure_tls_server_handshake(). (send alert is done later, at higher level) :
With this correction, the alert message is sent once (Packet 18) and the connection is closed correctly:
Note : this issue does'n t happen in TLS 1.3
Hi, I'm using NetX Duo with two ethernet interfaces, each with its IP instance (named ip_0 & ip_1).
These IP instances have a DHCP client each (dhcp_client_0 & dhcp_client_1).
After creating and starting both DHCP clients only the last one created works, this is because the receive notification function
uses only the DHCP instance pointed by _nx_dhcp_created_ptr, and doesn't look for the interface's specific one:
VOID _nx_dhcp_udp_receive_notify(NX_UDP_SOCKET *socket_ptr)
{
NX_PARAMETER_NOT_USED(socket_ptr);
/* Set the data received event flag. */
tx_event_flags_set(&(_nx_dhcp_created_ptr -> nx_dhcp_events), NX_DHCP_CLIENT_RECEIVE_EVENT, TX_OR);
}
A possible fix that worked for me could be:
(This is just to show the idea, I used some externs to access my two IP/DHCP instances)
extern NX_IP ip_0;
extern NX_DHCP dhcp_client_0;
extern NX_IP ip_1;
extern NX_DHCP dhcp_client_1;
...
VOID _nx_dhcp_udp_receive_notify(NX_UDP_SOCKET *socket_ptr)
{
NX_PARAMETER_NOT_USED(socket_ptr);
if(socket_ptr->nx_udp_socket_ip_ptr == &ip_0)
{
tx_event_flags_set(&(dhcp_client_0.nx_dhcp_events), NX_DHCP_CLIENT_RECEIVE_EVENT, TX_OR);
}
else if(socket_ptr->nx_udp_socket_ip_ptr == &ip_1)
{
tx_event_flags_set(&(dhcp_client_1.nx_dhcp_events), NX_DHCP_CLIENT_RECEIVE_EVENT, TX_OR);
}
}
Cheers
There is example of implementation using Preview feature "Device Updates" here
Is there any example how to leverage "IoT device configuration" IotHub feature for firmware update?
During testing TLS connectivity, we came across a condition within NetX 6.1.8 causing a connection dead-lock scenario with HTTPS connections.
Once the dead lock occurs, neither IP thread nor HTTPS web server thread will process new connections on port 443.
We use the nx_web_http_server add-on component to implement TLS encrypted web services.
Producing repeated, concurrent and short-lived HTTPS connections (by clicking on the refresh button in Chrome browser) on port 443 which the NetX TLS stack terminates due to errors (error code NX_SECURE_TLS_NO_SUPPORTED_CIPHERS 0x10E or NX_NOT_CONNECTED 0x38).
The problem does not seem to occur if HTTPS connections are performed sequential (using wget as a client for example).
It only occurs when a browser is used which does open multiple connections and some of them will be queued.
This hints that the issue has to be in conjunction with the listen queueing mechanism (NX_WEB_HTTP_SERVER_SESSION_MAX set to 2, NX_WEB_HTTP_SERVER_MAX_PENDING set to 4).
We were not able to reproduce with normal HTTP traffic. This also hints that it is related to TLS and
maybe to the clean-up of an unsuccessful TLS session in function _nx_tcpserver_connect_process() while at the same time a new connection is presented.
Also this is independent to the two race conditions reported here #42 and #43. Patches for those have been applied and the issue occurs with or without those patches.
The IP thread is still running, this has been confirmed with logs and debugger. Other IP services still work.
But it won't touch port 443 again as it has queued connections in its listen list.
According to file nx_tcp_packet_process.c line 597, the listen socket is checked for NULL:
if ((listen_ptr -> nx_tcp_listen_socket_ptr) &&
((tcp_header_ptr -> nx_tcp_header_word_3 & NX_TCP_RST_BIT) == NX_NULL))
and if it is NULL, according to this comment in line 772:
/* The application needs to call relisten with a new server request to process this queued
connection. */
the IP thread will not process it and depends on the https web server thread to do a re-listen.
The HTTPS web server thread is also still running, it cyclically calls _nx_tcpserver_relisten in its event loop.
But the HTTPS web server thread won't perform a re-listen because the socket is in NX_TCP_LISTEN_STATE.
So we end up with the IP thread not dealing with the new connection because the listen socket has been set to NULL
and the server thread not re-listening because there is still a socket in listen state.
The listen queue's state and the server's socket state don't seem to lign up any more.
This TraxeX file is attached.
Adding the following code snippet after line 209 of nx_tcpserver.c will log that a dead lock
was triggered and also recover from it by unaccepting and re-listening the socket.
else if(server_ptr -> nx_tcpserver_listen_session -> nx_tcp_session_socket.nx_tcp_socket_state == NX_TCP_LISTEN_STATE)
{
struct NX_TCP_LISTEN_STRUCT *listen_ptr;
listen_ptr = server_ptr -> nx_tcpserver_ip -> nx_ip_tcp_active_listen_requests;
if (listen_ptr)
{
do
{
if (listen_ptr -> nx_tcp_listen_socket_ptr == NULL &&
listen_ptr->nx_tcp_listen_port == server_ptr -> nx_tcpserver_listen_session -> nx_tcp_session_socket.nx_tcp_socket_port &&
listen_ptr->nx_tcp_listen_queue_current > 0)
{
_nx_trace_event_insert(5000,
listen_ptr -> nx_tcp_listen_socket_ptr,
server_ptr -> nx_tcpserver_listen_session -> nx_tcp_session_socket.nx_tcp_socket_state,
listen_ptr->nx_tcp_listen_queue_current, 0,
NX_TRACE_ALL_EVENTS, 0, 0);
SEGGER_RTT_printf(0, "Got you! Connection dead-locked on port %d (queue: %d of %d)!!!!!!!!!!!!!!!!!!!!!!\n", listen_ptr->nx_tcp_listen_port, listen_ptr->nx_tcp_listen_queue_current, listen_ptr->nx_tcp_listen_queue_maximum);
//assert(listen_ptr -> nx_tcp_listen_socket_ptr);
// Recover from dead-lock:
nx_tcp_server_socket_unaccept(&server_ptr -> nx_tcpserver_listen_session -> nx_tcp_session_socket);
status = nx_tcp_server_socket_relisten(server_ptr -> nx_tcpserver_ip,
server_ptr -> nx_tcpserver_listen_port,
&server_ptr -> nx_tcpserver_listen_session -> nx_tcp_session_socket);
if((status != NX_SUCCESS) && (status != NX_CONNECTION_PENDING))
{
SEGGER_RTT_printf(0, "%d, %d\n", status, __LINE__);
return NX_TCPSERVER_FAIL;
}
}
/* Move to the next listen request. */
listen_ptr = listen_ptr -> nx_tcp_listen_next;
} while (listen_ptr != server_ptr -> nx_tcpserver_ip -> nx_ip_tcp_active_listen_requests);
}
}
If AEAD Cipher is enabled, AEAD Cipher checking is necessary to detect cipher algorithms other than AES-CCM or AES-GCM. NX_SECURE_AEAD_CIPHER_CHECK macro defines whether the AEAD chcking is used or not.
But actually, the AEAD checking is not working even if NX_SECURE_AEAD_CIPHER_CHECK macro is defined (See https://github.com/azure-rtos/netxduo/blob/master/nx_secure/src/nx_secure_tls_record_payload_decrypt.c#L158 ). Also, if using cipher algorithms other than AES-CCM or AES-GCM, the communicating counterparty will raise a Bad Record MAC alert.
I think it's a bug in the code. I suggest the following change.
Note: When apply this change, the warning "NX_SECURE_AEAD_CIPHER_CHECK macro redefined" will happened. Please clear the warning.
https://github.com/azure-rtos/netxduo/blob/master/nx_secure/inc/nx_secure_tls.h#L123
| Incorrect | #ifndef NX_SECURE_AEAD_CIPHER_CHECK #define NX_SECURE_AEAD_CIPHER_CHECK(a) NX_FALSE #endif /* NX_SECURE_AEAD_CIPHER_CHECK */ |
|---|---|
| Correct | #ifdef NX_SECURE_AEAD_CIPHER_CHECK <-- #define NX_SECURE_AEAD_CIPHER_CHECK(a) NX_FALSE #endif /* NX_SECURE_AEAD_CIPHER_CHECK */ |
Are you planning on supporting peer to peer mode via Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up L2 messages?
Hello, I am planning to use NetXDuo with a cellular modem (in my case, SIM7600 is used). After reading Chapter 5 - Azure RTOS NetX Duo Network Drivers, I still don't have a clear clue to port my SIM7600 to NetXDuo. Can you give some suggestions?
Where can I find nx_6lowpan.h file?
你好，请原谅我的英文不好表达，请问你们提供的addons里的ppp有实际测试过跟4G模块通信吗？我现在一直卡在LCP阶段，需要自己修改底层吗，看得有点吃力
PPP TX:
7E FF 7D 23 C0 21 7D 21 74 7D 20 7D 28 7D 21 7D |.}#.!}!t}.}(}!}
24 7D 25 DC BE 20 7E |$}%...
PPP RX:（你们的协议栈已经解包了）
7E FF 03 C0 21 01 00 00 18 02 06 00 00 00 00 03 |...!...........
04 C0 23 05 06 B4 1C 4F 67 07 02 08 02 C1 28 7E |..#....Og.....(
PPP TX:
7E FF 7D 23 C0 21 7D 22 7D 20 7D 20 7D 38 7D 22 |.}#.!}"}.}.}8}"
7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 |}&}.}.}.}.}#}$.#
7D 25 7D 26 B4 7D 3C 4F 67 7D 27 7D 22 7D 28 7D |}%}&.}<Og}'}"}(}
22 7D 2D C5 7E |"}-.
PPP RX:
7E FF 03 C0 21 02 74 00 08 01 04 05 DC 6E AA 7E |...!.t......n.
还有你们的协议栈有留出打印数据的接口吗，没找到。这样好难调试
Hi!
I try to transfer a large size data to server by TFTP client service.
I use Synergy S7G2 processor, SSP 2.0.0 and IAR compiler.
I can transfer a small size data(ex. 2048bytes) to server.
But I can't transfer a large size data(Ex. 9MBytes).
The transmit always stops at 24th block.
Please give me a hint to solve.
Best regards.
#define WLAN_TFTP_SEND_TIMEOUT (500)
#define WLAN_TFTP_PACKET_SIZE (512)
static NX_PACKET *my_packet;
extern NX_TFTP_CLIENT g_tftp_client0;
#if 1 //FOR TEST
static uint8_t buf[9*1024*1024+3];
#endif
UINT Tftp_Send(uint8_t *data_addr, uint32_t data_size)
{
uint32_t status=0;
UINT server_addr=0;
uint32_t transfer_cnt=0;
uint32_t remaining_size=0;
uint32_t i=0;
#if 1 //FOR TEST
for(int j=0; j < sizeof(buf); j++){
buf[j] = j;
}
data_addr = buf;
data_size = sizeof(buf);
#endif
//calculate trans num
if( (data_size % WLAN_TFTP_PACKET_SIZE) == 0){
transfer_cnt = data_size / WLAN_TFTP_PACKET_SIZE;
}else{
transfer_cnt = (data_size / WLAN_TFTP_PACKET_SIZE) + 1;
remaining_size = data_size % WLAN_TFTP_PACKET_SIZE;
}
//server address
server_addr = IP_ADDRESS(192,168,1,3);
// TFT Open
status = nx_tftp_client_file_open(&g_tftp_client0, "/test.bin", server_addr, NX_TFTP_OPEN_FOR_WRITE, WLAN_TFTP_SEND_TIMEOUT);
// Transfer data
for(i=0; i < transfer_cnt; i++){
// allocate
status = nx_tftp_client_packet_allocate(&g_packet_pool0, &my_packet, WLAN_TFTP_SEND_TIMEOUT);
if(remaining_size==0){
my_packet -> nx_packet_prepend_ptr = data_addr + WLAN_TFTP_PACKET_SIZE*i;
// Write pointer update
my_packet -> nx_packet_length = WLAN_TFTP_PACKET_SIZE;
my_packet -> nx_packet_append_ptr = my_packet -> nx_packet_prepend_ptr + WLAN_TFTP_PACKET_SIZE;
}else{
if(i == transfer_cnt-1){
my_packet -> nx_packet_prepend_ptr = data_addr + WLAN_TFTP_PACKET_SIZE*i;
// Write pointer update
my_packet -> nx_packet_length = remaining_size;
my_packet -> nx_packet_append_ptr = my_packet -> nx_packet_prepend_ptr + remaining_size;
}else{
my_packet -> nx_packet_prepend_ptr = data_addr + WLAN_TFTP_PACKET_SIZE*i;
// Write pointer update
my_packet -> nx_packet_length = WLAN_TFTP_PACKET_SIZE;
my_packet -> nx_packet_append_ptr = my_packet -> nx_packet_prepend_ptr + WLAN_TFTP_PACKET_SIZE;
}
}
// Transfer
status = nx_tftp_client_file_write(&g_tftp_client0, my_packet, WLAN_TFTP_SEND_TIMEOUT);
}
/* close */
status = nx_tftp_client_file_close(&g_tftp_client0);
return status;
}
There are several printf calls in file addons/web/nx_tcpserver.c which probably either should not be in there (leftovers from debugging?) or should be wrapped in something like NX_DEBUG:
if((status != NX_SUCCESS) && (status != NX_CONNECTION_PENDING))
{
printf("%d, %d\n", status, __LINE__);
return NX_TCPSERVER_FAIL;
}
Integration with the new RX65N RSK, the RX GCC compiler has defined size_t as 8 bytes. This causes a number of compiler errors in places where an unsigned int* is passed into a function expecting a size_t*.
Compiler:
https://gcc-renesas.com/rx-download-toolchains/
Error:
FAILED: lib/netxduo/CMakeFiles/netxduo.dir/addons/azure_iot/nx_azure_iot_hub_client.c.obj
"C:\Users\ryanw\AppData\Roaming\GCC for Renesas RX 8.3.0.202004-GNURX-ELF\rx-elf\rx-elf\bin\rx-elf-gcc.exe" -DASC_SERIALIZER_USE_CUSTOM_ALLOCATOR -DLOG_LEVEL=0 -DNX_INCLUDE_USER_DEFINE_FILE -DTX_INCLUDE_USER_DEFINE_FILE -IC:/projects/iot/getting-started/core/lib/netxduo/ports/rx65n/gnu/inc -IC:/projects/iot/getting-started/core/lib/netxduo/common/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/auto_ip -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot -IC:/projects/iot/getting-started/core/lib/netxduo/addons/BSD -IC:/projects/iot/getting-started/core/lib/netxduo/addons/cloud -IC:/projects/iot/getting-started/core/lib/netxduo/addons/dhcp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/dns -IC:/projects/iot/getting-started/core/lib/netxduo/addons/ftp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/http -IC:/projects/iot/getting-started/core/lib/netxduo/addons/mdns -IC:/projects/iot/getting-started/core/lib/netxduo/addons/mqtt -IC:/projects/iot/getting-started/core/lib/netxduo/addons/nat -IC:/projects/iot/getting-started/core/lib/netxduo/addons/pop3 -IC:/projects/iot/getting-started/core/lib/netxduo/addons/ppp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/pppoe -IC:/projects/iot/getting-started/core/lib/netxduo/addons/smtp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/snmp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/sntp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/telnet -IC:/projects/iot/getting-started/core/lib/netxduo/addons/tftp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/web -IC:/projects/iot/getting-started/core/lib/netxduo/crypto_libraries/inc -IC:/projects/iot/getting-started/core/lib/netxduo/nx_secure/inc -IC:/projects/iot/getting-started/core/lib/netxduo/nx_secure/ports -Ilib/netxduo/custom_inc -IC:/projects/iot/getting-started/core/lib/threadx/ports/rx65n/gnu/inc -IC:/projects/iot/getting-started/core/lib/threadx/common/inc -Ilib/threadx/custom_inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/tests/core/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module/iot-security-module-core/inc -mcpu=rx64m -misa=v2 -mlittle-endian-data --specs=nano.specs -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin -fshort-enums -Wall -Wextra -Wuninitialized -Wshadow -Wdouble-promotion -Werror -Wno-unused-parameter -O0 -g3 -std=gnu99 -MD -MT lib/netxduo/CMakeFiles/netxduo.dir/addons/azure_iot/nx_azure_iot_hub_client.c.obj -MF lib\netxduo\CMakeFiles\netxduo.dir\addons\azure_iot\nx_azure_iot_hub_client.c.obj.d -o lib/netxduo/CMakeFiles/netxduo.dir/addons/azure_iot/nx_azure_iot_hub_client.c.obj -c C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c: In function 'nx_azure_iot_hub_client_connect':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:305:86: error: passing argument 4 of 'az_iot_hub_client_get_client_id' from incompatible pointer type [-Werror=incompatible-pointer-types]
(CHAR *)buffer_ptr, buffer_length, &buffer_length);
^~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:153:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_client_id_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:325:86: error: passing argument 4 of 'az_iot_hub_client_get_user_name' from incompatible pointer type [-Werror=incompatible-pointer-types]
(CHAR *)buffer_ptr, buffer_length, &buffer_length);
^~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:131:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_user_name_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c: In function 'nx_azure_iot_hub_client_telemetry_message_create':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:789:79: error: passing argument 5 of 'az_iot_hub_client_telemetry_get_publish_topic' from incompatible pointer type [-Werror=incompatible-pointer-types]
topic_length, &topic_length);
^~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:244:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_topic_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c: In function 'nx_azure_iot_hub_client_device_twin_reported_properties_send':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:1572:79: error: passing argument 5 of 'az_iot_hub_client_twin_patch_get_publish_topic' from incompatible pointer type [-Werror=incompatible-pointer-types]
buffer_size, &topic_length);
^~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:464:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_topic_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c: In function 'nx_azure_iot_hub_client_device_twin_properties_request':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:1744:82: error: passing argument 5 of 'az_iot_hub_client_twin_document_get_publish_topic' from incompatible pointer type [-Werror=incompatible-pointer-types]
buffer_size, &topic_length);
^~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:441:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_topic_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c: In function 'nx_azure_iot_hub_client_sas_token_get':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:2432:89: error: passing argument 7 of 'az_iot_hub_client_sas_get_password' from incompatible pointer type [-Werror=incompatible-pointer-types]
(CHAR *)sas_buffer, sas_buffer_len, &sas_buffer_len);
^~~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:215:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_password_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c: In function 'nx_azure_iot_hub_client_direct_method_message_response':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:2625:86: error: passing argument 6 of 'az_iot_hub_client_methods_response_get_publish_topic' from incompatible pointer type [-Werror=incompatible-pointer-types]
topic_length, &topic_length);
^~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_hub_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_hub_client.h:350:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_topic_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
FAILED: lib/netxduo/CMakeFiles/netxduo.dir/addons/azure_iot/nx_azure_iot_provisioning_client.c.obj
"C:\Users\ryanw\AppData\Roaming\GCC for Renesas RX 8.3.0.202004-GNURX-ELF\rx-elf\rx-elf\bin\rx-elf-gcc.exe" -DASC_SERIALIZER_USE_CUSTOM_ALLOCATOR -DLOG_LEVEL=0 -DNX_INCLUDE_USER_DEFINE_FILE -DTX_INCLUDE_USER_DEFINE_FILE -IC:/projects/iot/getting-started/core/lib/netxduo/ports/rx65n/gnu/inc -IC:/projects/iot/getting-started/core/lib/netxduo/common/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/auto_ip -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot -IC:/projects/iot/getting-started/core/lib/netxduo/addons/BSD -IC:/projects/iot/getting-started/core/lib/netxduo/addons/cloud -IC:/projects/iot/getting-started/core/lib/netxduo/addons/dhcp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/dns -IC:/projects/iot/getting-started/core/lib/netxduo/addons/ftp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/http -IC:/projects/iot/getting-started/core/lib/netxduo/addons/mdns -IC:/projects/iot/getting-started/core/lib/netxduo/addons/mqtt -IC:/projects/iot/getting-started/core/lib/netxduo/addons/nat -IC:/projects/iot/getting-started/core/lib/netxduo/addons/pop3 -IC:/projects/iot/getting-started/core/lib/netxduo/addons/ppp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/pppoe -IC:/projects/iot/getting-started/core/lib/netxduo/addons/smtp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/snmp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/sntp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/telnet -IC:/projects/iot/getting-started/core/lib/netxduo/addons/tftp -IC:/projects/iot/getting-started/core/lib/netxduo/addons/web -IC:/projects/iot/getting-started/core/lib/netxduo/crypto_libraries/inc -IC:/projects/iot/getting-started/core/lib/netxduo/nx_secure/inc -IC:/projects/iot/getting-started/core/lib/netxduo/nx_secure/ports -Ilib/netxduo/custom_inc -IC:/projects/iot/getting-started/core/lib/threadx/ports/rx65n/gnu/inc -IC:/projects/iot/getting-started/core/lib/threadx/common/inc -Ilib/threadx/custom_inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/tests/core/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module/inc -IC:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module/iot-security-module-core/inc -mcpu=rx64m -misa=v2 -mlittle-endian-data --specs=nano.specs -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin -fshort-enums -Wall -Wextra -Wuninitialized -Wshadow -Wdouble-promotion -Werror -Wno-unused-parameter -O0 -g3 -std=gnu99 -MD -MT lib/netxduo/CMakeFiles/netxduo.dir/addons/azure_iot/nx_azure_iot_provisioning_client.c.obj -MF lib\netxduo\CMakeFiles\netxduo.dir\addons\azure_iot\nx_azure_iot_provisioning_client.c.obj.d -o lib/netxduo/CMakeFiles/netxduo.dir/addons/azure_iot/nx_azure_iot_provisioning_client.c.obj -c C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c: In function 'nx_azure_iot_provisioning_client_send_req':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:641:110: error: passing argument 4 of 'az_iot_provisioning_client_register_get_publish_topic' from incompatible pointer type [-Werror=incompatible-pointer-types]
(CHAR *)buffer_ptr, buffer_size, &mqtt_topic_length);
^~~~~~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_provisioning_client.h:312:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_topic_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:647:94: error: passing argument 5 of 'az_iot_provisioning_client_query_status_get_publish_topic' from incompatible pointer type [-Werror=incompatible-pointer-types]
buffer_size, &mqtt_topic_length);
^~~~~~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_provisioning_client.h:334:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_topic_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c: In function 'nx_azure_iot_provisioning_client_sas_token_get':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:775:63: error: passing argument 7 of 'az_iot_provisioning_client_sas_get_password' from incompatible pointer type [-Werror=incompatible-pointer-types]
&(resource_ptr -> resource_mqtt_sas_token_length));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_provisioning_client.h:185:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_password_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c: In function 'nx_azure_iot_provisioning_client_initialize':
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:895:100: error: passing argument 4 of 'az_iot_provisioning_client_get_user_name' from incompatible pointer type [-Werror=incompatible-pointer-types]
(CHAR *)buffer_ptr, buffer_size, &mqtt_user_name_length)))
^~~~~~~~~~~~~~~~~~~~~~
In file included from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.h:30,
from C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/nx_azure_iot_provisioning_client.c:14:
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc/azure/iot/az_iot_provisioning_client.h:104:13: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'UINT *' {aka 'unsigned int *'}
size_t* out_mqtt_user_name_length);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
Hi,
Is there any test suite that can be run to validate the NetX stack?
If it exists, can it be shared?
Thanks,
Shahab
The CMakeLists.txt file for the cortex_m33 is missing and as a result compilation fails when THREADX_ARCH is set to cortex_m33.
Hi,
The current code supports HTTP 1.0, is there any implementation available for HTTP 1.1?
If not, is there any plan? Can you please share the timeline?
Thanks,
Shahab
Heya,
In _nx_ip_thread_entry there is a ULONG (which may be an unsigned int on 64-bit Linux targets) which gets promoted directly to a NX_IP*.
The compiler gets upset about this too if -Werror is used.
In file included from /home/pleb/netxduo_fuzzing/git/netxduo/common/src/nx_ip_thread_entry.c:28:
/home/pleb/netxduo_fuzzing/git/netxduo/common/src/nx_ip_thread_entry.c: In function '_nx_ip_thread_entry':
../git/netxduo/common/inc/nx_api.h:131:71: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
131 | (a) = (b *)(c); \
| ^
/home/pleb/netxduo_fuzzing/git/netxduo/common/src/nx_ip_thread_entry.c:135:5: note: in expansion of macro 'NX_THREAD_EXTENSION_PTR_GET'
135 | NX_THREAD_EXTENSION_PTR_GET(ip_ptr, NX_IP, ip_ptr_value)
-B
The following line contains an unnecessary cast from a uint32_t to a double, and back to a uint32_t.
This is generating a gcc compiler warning (for the Renesas RX GCC compiler):
C:/projects/iot/getting-started/core/lib/netxduo/addons/azure_iot/azure_iot_security_module/iot-security-module-core/src/core.c:126:31: error: conversion from 'uint32_t' {aka 'long unsigned int'} to 'double' may change value [-Werror=conversion]
double interval = priority_collectors_get_interval(prioritized_collectors);
Sorry for simple question.
Does AzureRTOS NetX Duo Web HTTPS Server application with TLS1.3 enabled works well?
In my testing, if TLS1.3 enabled with a global macro “NX_SECURE_TLS_ENABLE_TLS_1_3”, an error (the error code returned from nx_secure_tls_process_clienthello_extensions() is NX_SECURE_TLS_UNKOWN_CERT_SIG_ALGORITHM) is occurred. I use RSA SHA256 as signature algorithm in server certificate.
I think this error code "NX_SECURE_TLS_UNKOWN_CERT_SIG_ALGORITHM" means the signature algorithms proposed from client are not matched to one that used in server. This checking are performed in _nx_secure_tls_proc_clienthello_signature_algorithms_extension(). However, if server's local (server) certificate uses RSA, expected signature algorithms were not set, and then the checking result is no matched algorithms (See here)
When NX_CRYPTO_SELF_TEST is defined, the module nx_crypto_module_start.c is compiled which appears to be hardware specific (STM32F469) and not compatible with the gcc compiler showing following compilation errors:
[build] .../netxduo/crypto_libraries/src/nx_crypto_module_start.c:70:60: error: expected '=', ',', ';', 'asm' or '__attribute__' before string constant
[build] 70 | const unsigned long long _nx_crypto_module_program_begin @ "NX_CRYPTO_PROGRAM_BEGIN" = 0ull;
[build] .../netxduo/crypto_libraries/src/nx_crypto_module_start.c:228:16: error: unknown type name '__nounwind'
[build] 228 | NX_CRYPTO_KEEP __nounwind __interwork __softfp __aapcs_core void __aeabi_memcpy (void *dest, const void *src, size_t size)
Once the module nx_crypto_module_start.c is removed from netxduo\crypto_libraries\CMakeLists.txt, NetXDuo compiles and _nx_crypto_method_self_test() can be called and used.
If I am using AC6 compiler，Can I use AC5 or keil ports‘s files ?
According to the last commit, it mentioned "updated to 6.0.1 and added additional processors/toolchains".
It's great in "\threadx\ports\", it really supports multiple toolchains, like as iar, kiel.
However in "\netxduo\ports\cortex_m4", it's still gnu toolchain only.
When will push the code for iar or kiel toolchain ?
Hello, in the NetXDuo file nxd_dhcp_client.c at line 387, 406, 432 the check is on NX_SUCCESS while it should be on TX_SUCCESS given the ThreadX API called.
Given that NX_SUCCESS = TX_SUCCESS = 0 the execution flow is not affected but in case an error is returned the wrong code is misleading.
Best regards
How can TLS' Secure Client-Initiated Renegotiation be disabled or limited? We tried to set NX_SECURE_TLS_DISABLE_SECURE_RENEGOTIATION but this also disables the server initiated renegotation which would weaken security. We only like to the disable client initiated renegotiation or limit its attempt numbers to prevent DoS.
We also tried using nx_secure_tls_session_renegotiate_callback_set to implement a limit
but there seems to be no API hooks to call this function when using the nx_web_http_server component.
Could a define like NX_SECURE_TLS_DISABLE_SECURE_CLIENT_RENEGOTIATION be introduced ?
A security audit flagged the Secure Client-Initiated Renegotiation as DoS vulnerability (see below)
and we like to close this potential security hole.
Refer to audit log generated with ssltest.sh:
In NetX Secure TLS 1.3, I think nx_secure_tls_server_state variable is necessary in TLS Client mode to save the state of server.
But, if disabled server function by NX_SECURE_TLS_SERVER_DISABLED macro to reduce code and data usage, this variable is removed. So, we get build error "NX_SECURE_TLS_SESSION' has no member named 'nx_secure_tls_server_state".
I think nx_secure_tls_server_state variable should not be removed if using TLS1.3.
I suggest the following change.
| Incorrect | #ifndef NX_SECURE_TLS_SERVER_DISABLED /* The state of the server handshake if this is a server socket. */ NX_SECURE_TLS_SERVER_STATE nx_secure_tls_server_state; #endif (See https://github.com/azure-rtos/netxduo/blob/master/nx_secure/inc/nx_secure_tls.h#L1206) |
|---|---|
| Correct | #if !defined(NX_SECURE_TLS_SERVER_DISABLED) || (NX_SECURE_TLS_TLS_1_3_ENABLED) /* The state of the server handshake if this is a server socket. */ NX_SECURE_TLS_SERVER_STATE nx_secure_tls_server_state; #endif |
Why does pop3 client use a specific port "4228"?
when i open NX_IPSEC_ENABLE switch, it build error.
../common/src/nx_icmp_interface_ping6.c:40:10: fatal error: nx_ipsec.h: No such file or directory
I made some progress porting azure RTOS with netxduo to my M4 processor. I have most everything working but having some issues debugging ethernet packets.
The low level Ethernet hardware is setup and it looks like I am sending TX frames (I can see DHCP discover frames in Wireshark coming from my device) correctly but I am having issues with receive. I would like to get more visibility into the rx packets.
I am not sure how to build with packet debugging turned on. How do you do this and am I on the right path?
Hi I wanted to understand how POST and PUT requests are processed in HTTP server.
From the example provided in sample codes Sample code, I understood that it is not mandatory to provide the callback function to process the requests.
If I am correct, I have following concerns/questions assuming that user has not provided callback function to process the requests:
Case 1: PUT request- General Understanding/Expected behavior:
Actual results
Case 2: POST request- General Understanding/Expected behavior:
Actual results
Hi All,
Recently I have started using NetxDuo to write few IoT applications and I was successful in writing MQTT standalone application by referring the sample provided in git repo.
Now my requirement is CoAP standalone support. If I search for CoAP its point to LWM2M which is based on CoAP.
Could you please help me that how can I proceed with to get standalone CoAP implementation? Any pointers would be helpful to me.
Thanks,
Srinivas.
tx_port.h for Cortex-M defines a 64-bit type as follows:
typedef unsigned long long ULONG64;
Then in nx_crypto_huge_number.h we find this definition:
#define ULONG64 unsigned long long
The two definitions result in the gcc compiler to see this after preprocessing:
typedef unsigned long long unsigned long long;
which of course causes compilation errors like these:
...\netxduo\crypto_libraries\inc/nx_crypto_huge_number.h:81:39: error: duplicate 'unsigned'
81 | #define ULONG64 unsigned long long
...\rm_threadx_port/tx_port.h:90:49: note: in expansion of macro 'ULONG64'
90 | typedef unsigned long long ULONG64;
| ^~~~~~~
...\netxduo\crypto_libraries\inc/nx_crypto_huge_number.h:81:48: error: 'long long long' is too long for GCC
81 | #define ULONG64 unsigned long long
| ^~~~
Once the conflicting definition of ULONG64 is commented out and the definition for HN_UBASE2 changed to unsigned long long, the offending code compiles.
Hi!
I want to search synergy(s7g2) device by computer name from network.
Do you have any solution by NetX (Duo)?
I don't know to solve it.
Best Regards.
I discovered a race condition when _nx_tcp_socket_send_internal() is called and pre-empted by the IP thread and the IP thread is changing the socket's state.
We have an application using the nx_web_http_server web server component. When running some some tests, we encounter the following situation:
While processing HTTP requests the web server calls nx_web_http_server_send(), which calls nx_tcp_socket_send() which again calls nx_tcp_socket_send_internal().
Upon entering nx_tcp_socket_send_internal(), the state of the socket is checked for possible closure while interrupts are disabled. As soon as interrupts are enabled in line 175, a context switch takes place and the IP thread runs. The IP thread now processes a socket closure on the very same socket we are in the process of sending.
The IP thread changes the state of the socket to LISTEN and surrenders CPU.
nx_web_http_server thread is scheduled again and execution of nx_web_http_server_send() continues. Now the socket is in LISTEN state and the source_ip and dest_ip information is evaluated in line 180 onwards, but this evaluation yields in invalid address information as the socket was closed in the mean time and the address information zeroed.
nx_web_http_server() continues execution and aquires the IP mutex (too late now, we already have been preempted) and then calls _nx_ip_checksum_compute().
_nx_ip_checksum_compute() will fail when checking the assertions for src_ip_addr and dest_ip_addr.
NX_ASSERT((src_ip_addr != NX_NULL) && (dest_ip_addr != NX_NULL));
and the system will crash.
Here is a TraceX diagram of this scenario:
I am not sure yet how to best mitigate this race condition. Once a good solution is found, I could test and submit a PR with a fix.
I use the bsd sample , call the socket return –1, i found out the socket call the txe_mutex_get function and the function return TX_MUTEX_ERROR. How to solve this problem
Chapter 2 of the NetxDuo FTP Guide lists a number of files, some of which I can't find in this repo. In particular, I am looking for filex_stub.h. Could you point me to it's location or send me a copy please.
Hello! Thanks for all the great work on the project. I was wondering if there was any way you could use multiple FileX disks with one FTP server? I currently have a FLASH drive and a RAM drive and would like to be able to access them both from the same FTP server.
I have a project where I only need TLS 1.3.
To save some space I tried to disable TLS 1.2 by :
#define NX_SECURE_TLS_TLS_1_2_ENABLED (0)
But it causes build error in tls 1.3 client handshake files :
netxduo/nx_secure/src/nx_secure_tls_1_3_client_handshake.c: In function '_nx_secure_tls_1_3_client_handshake': netxduo/nx_secure/src**/nx_secure_tls_1_3_client_handshake.c:358:68:** error: 'NX_SECURE_TLS_CRYPTO' {aka 'struct NX_SECURE_TLS_CRYPTO_STRUCT'} has no member named 'nx_secure_tls_handshake_hash_sha256_method' 358 | method_ptr = tls_session -> nx_secure_tls_crypto_table -> nx_secure_tls_handshake_hash_sha256_method; |
Someone know a way to solve this issue ?
The line
https://github.com/azure-rtos/netxduo/blob/f66451ca193a96b5734e9a99d6d0ed9de44c9ac5/common/src/nx_tcp_socket_packet_process.c#L109
might trigger an Hard fault because of "Unaligned access to memory" on some processors (eg. STM32H7 family).
Suggested workaround:
memcpy(&tcp_header_copy, packet_ptr -> nx_packet_prepend_ptr, sizeof(tcp_header_copy));
If I'm not mistaken the socket_ptr -> nx_tcp_socket_duplicated_ack_received is also increased on segments that contain data, from my understanding a 'real' DUPACK is a pure ACK packet that does not contain data, socket_ptr -> nx_tcp_socket_duplicated_ack_received should therefore only be increased if the segment contains no data. We have observed this behaviour where NetX initiates a fast retransmit without the receiver explicitly signaling packet loss by sending DUPACKs.
When nx_azure_iot_json_writer_append_json_text() is used to write elements of an array, the resulting JSON packet is incomplete. The NX_PACKET's byte count is short of exactly the amount of commas inserted internally by az_json_writer_append_json_text().
This is an issue with the underlaying azure-sdk-for-c and a PR has been submitted here: Azure/azure-sdk-for-c#1905
However as this bug also affects the JSON writing functionality of NetX Duo I believe this should be reported here as well, hoping that a fix can be coordinated between the two Microsoft dev teams and be available with the next NetXDuo release.
Hi,
The MQTT client supports version 3.1.1 in the current codebase.
Is there any plan or implementation to support version 5.0?
Thanks,
Shahab
Hello!
WebSocket protocol may be useful for industrial systems... Do you have any plans to support it?
This function makes no allowances for additional compilers and defaults to GCC. This produces compiler errors using other compilers such as IAR and RXCC if ASC is enabled.
Are there any plans in the future to add the possibility of broker-less pubsub technology to netxduo, for example, nng (https://github.com/nanomsg/nng)?
nx_tcpserver_tls_setup() works well for RSA key but not with EC
I found nx_secure_tls_ecc_initialize() call is missing.
My workaround is :
Hello everyone,
I have a question to ask, and it is wrong to transplant the netxduo to SDRAM, but it is ok to compile the code to the STM32H7 internal sram.
According to the docs, there should be a CoAP package. IIRC that has always been part of ThreadX NetX Duo.
This is a testing issue for testing purpose.
Setup description :
We are testing the netxduo (6.1.9) with a DTLS server.
The DTLS server code is based on the documentation ( https://docs.microsoft.com/fr-fr/azure/rtos/netx-duo/netx-secure-dtls/chapter2#small-example-system-dtls-server ) with the updates below :
On client side, we use openssl : "openssl s_client -connect 192.168.2.2:4321 -dtls -CAfile ca.crt"
Issue
After each connection/disconnection, we can see a memory leak of 1 packet (nx_packet_pool_available decreases by one).
According to my tests, the memory leak seems to appear during the DTLS handshake.
Note : Coincidentally, I found that adding a delay in nx_secure_tls_packet_release() before calling nx_packet_release() solves the memory leak.
I have an "almost" fully functioning port to an ARM M4 controller.
I have verified the Threadx demo programs function completely.
The netxduo is very close I believe I have the lowlevel EMAC seetup and mostly working.
I have verified I can send/receive DHCP packets as well as the DNS and SNTP set up.
But I stalls at the point where it actually starts to send/receive TCP based socket packets.
My terminal out puts looks like:
Initializing DNS client
DNS address: 192.168.1.1
SUCCESS: DNS client initialized
Initializing SNTP client
SNTP server 0.pool.ntp.org
SNTP IP address: 171.66.97.126
SNTP time update: Apr 4, 2021 19:14:1.422 UTC
SUCCESS: SNTP initialized
Initializing Azure IoT Hub client
Hub hostname: testhubti.azure-devices.net
Device id: mydev_2
So you can see I am almost there.
The wireshark packets show good handshake for all DHCP/DNS/SNTP packets all the way up to the first TCP packet at which point it makes all the way to the nx_tcp_socket_packet_process.c line 109.
VOID _nx_tcp_socket_packet_process(NX_TCP_SOCKET *socket_ptr, NX_PACKET *packet_ptr)
{
UINT packet_queued = NX_FALSE;
NX_TCP_HEADER tcp_header_copy;
VOID (*urgent_callback)(NX_TCP_SOCKET *socket_ptr);
ULONG header_length;
ULONG packet_data_length;
ULONG packet_sequence;
ULONG rx_sequence;
ULONG rx_window;
UINT outside_of_window;
ULONG mss = 0;
/* Add debug information. */
NX_PACKET_DEBUG(__FILE__, __LINE__, packet_ptr);
/* Copy the TCP header, since the actual packet can be delivered to
a waiting socket/thread during this routine and before we are done
using the header. */
/*lint -e{927} -e{826} suppress cast of pointer to pointer, since it is necessary */
tcp_header_copy = *((NX_TCP_HEADER *)packet_ptr -> nx_packet_prepend_ptr);
I can set a breakpoint at this last line
tcp_header_copy = *((NX_TCP_HEADER *)packet_ptr -> nx_packet_prepend_ptr);
and it makes it here but if I do one more step it hard faults.
I am not sure how to interpret the comment or why this fails.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.