GithubHelp home page GithubHelp logo

weston-embedded / uc-tcp-ip Goto Github PK

View Code? Open in Web Editor NEW
99.0 21.0 70.0 1.99 MB

A compact, reliable, high-performance TCP/IP protocol stack. Features dual IPv4 and IPv6 support, an SSL/TLS socket option, and support for Ethernet, Wi-Fi, and PHY controllers.

License: Apache License 2.0

C 99.66% Assembly 0.34%
stack tcp-ip ip-stacks micrium embedded network ipv4 ipv6 sockets uc-tcpip

uc-tcp-ip's Introduction

µC/OS is a full-featured embedded operating system originally developed by Micriµm™. In addition to the two highly popular kernels, µC/OS features support for TCP/IP, USB-Device, USB-Host, and Modbus, as well as a robust File System.

Since its founding in 1999 as a private company, Micriµm and its team of engineers have offered world-class embedded software components for the most critical and demanding real-time applications. Recognized as having some of the cleanest code in the industry, with easy-to-understand documentation, the Micrium real-time kernels, and software components have successfully been deployed in thousands of products worldwide across a broad range of industries. Micrium’s µC/OS-II™ kernel has been certified for use in safety-critical applications and remains a respected favorite in the medical, aerospace, and industrial markets. µC/OS continues to be the RTOS of choice for engineers requiring the most reliable and trusted solution for their mission-critical applications.


Founded by a team of former Micrium employees, Weston Embedded Solutions is the official custodian for the µC/OS RTOS and Stacks software repository to ensure it remains the trusted choice for embedded engineers around the world.


Product Documentation and Release Notes *************** https://micrium.atlassian.net/

Technical Support

https://weston-embedded.com/micrium-support

Example Projects ********* https://weston-embedded.com/micrium-examples

Commercial Licensing Option ********* https://weston-embedded.com/products/cesium

Who to Contact ********* https://weston-embedded.com/company/contact

uc-tcp-ip's People

Contributors

forg0ne avatar jamagasr avatar wes-jmagasrevy avatar yasosa305 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

uc-tcp-ip's Issues

uC/TCP-IP: TCP Socket Initialization is failed in uC/OS-II

Hello everyone,
I am building a project in Xilinx SDK and using Xilinx Zynq-7000 Zedboard evaluation board.
I am running in uCOS-II v1.43. TCP Socket Objects Initialization is failed when initializing “Net Sock Conn Req”.
Meanwhile, If I run in uCOS-III, all process of UC/TCP-IP initialization are successful.
What is the diffenrence between uCOS-II and uCOS-III in there ?
Please help me to understand it and resolve this issue. Thank you very much !

Best Regards,
Dat Phung

Possible bug in NetIPv4_GetAddrSrcHandler()

NetIPv4_GetAddrSrcHandler() checks if the IP address contained in variable 'addr_remote' resides in the same subnet as the IP address configured in the current interface. The problem is that 'addr_remote' is in network order and hence that comparison will always fail. In other words, the if statement on line 2447 of net_ipv4.c (V3.05.00) should be:

if ((NET_UTIL_NET_TO_HOST_32(addr_remote) & p_ip_addrs->AddrHostSubnetMask) == p_ip_addrs->AddrHostSubnetNet) {
}

When in the FIN_WAIT_2 state and both NET_ERR_CFG_ARG_CHK_DBG_EN and NET_DBG_CFG_MEM_CLR_EN are disabled, there is a buffer leak.

In a nutshell, I was expecting the data that came in during the DATA_AVAIL state to be still processable and prompted this change at the end of NetTCP_RxPktConnHandlerFinWait2(). I also tested the change with NET_DBG_CFG_MEM_CLR_EN and NET_ERR_CFG_ARG_CHK_DBG_EN enabled.

The nitty-gritty:

When both NET_ERR_CFG_ARG_CHK_DBG_EN and NET_DBG_CFG_MEM_CLR_EN are DEF_DISABLED, there can be a situation where the EntriesLostCur and EntriesLostTot are incremented in the RxBufLargeStatPool statistics. This means that these buffers are irrecoverable because the function that frees these buffers (NetBuf_FreeHandler()) determined that the particular buffer has an address outside the buffer LIB memory pool's address range yielding a LIB_MEM_ERR_INVALID_BLK_ADDR_IN_POOL error.

I traced this issue back to a change in NetTCP_RxPktConnHandlerFinWait2() when the shutdown() function was being implemented. Adding the following conditional assignment: "*p_err = (data_avail) ? err_rtn : NET_TCP_ERR_CONN_DATA_NONE;" solved an issue at the application level during testing that allowed me to consume all the data in the Rx queue when the socket is shut down in the WR direction and our stack transitions from FIN_WAIT_2 to its non-standard DATA_AVAIL state.

Upon further inspection, I found out that our stack makes the decision to NOT process any incoming data in the DATA_AVAIL state and sends out a [RST] to let the other host know that the data it sent during (what it thought was) FIN_WAIT_2 was lost (See NetTCP_RxPktConnHandler() Note #3). Internally, the stack starts counting down from the generous (I call it egregious) 1800s User Timeout to allow the application to consume what's left in the receive queue and call close() to terminate it's end of the connection from an application level.

If we really want to fix this, we'd need to create a NetTCP_RxPktConnHandlerDataAvail() function that behaves like NetTCP_RxPktConnHandlerFinWait2() that queues received data when the connection is half-closed (i.e. shutdown in the WR direction) and doesn't just issue a RST when said data comes in.

axi-ethernet files are not complete

Hi
I want to use axi-ethernet.
Which NetDev_API_<controller> should I use in NetIF_Add function?
Note : file "ucos_tcpip_init" for this purpose uses NetDev_API_XIL_ETHER from "Dev/Ether/XIL_ETHER/net_dev_xil_ether.h" but net_dev_xil_ether.h does not exist in repository

regards,

When HTTP server is used in conjunction with the emSSL port, there is a bug that causes the HTTP server to set a connection in the incorrect state if the socket receive queue is empty.

NetSecure_SockRxDataHandler() checks for an empty socket receive queue when it should check for a closed receive queue. The consequence of this is that HTTPsSock_ConnDataRx() handles the NET_SOCK_ERR_RX_Q_CLOSED error differently than NET_ERR_RX.

In the emSSL port, NetSecure_SockRxDataHandler() checks for an empty receive queue to conditionally set 'p_err':

{{ if (result < 0) {
tcp_conn_id = NetConn_Tbl[p_sock->ID_Conn].ID_Transport;
rx_q_empty = (NetTCP_ConnTbl[tcp_conn_id].RxQ_App_Head == (NET_BUF *)0);
(rx_q_empty) ? (*p_err = NET_SOCK_ERR_RX_Q_CLOSED) : (*p_err = NET_ERR_RX);
} else {
ret_err = result;
}}}

The problem is that NET_SOCK_ERR_RX_Q_CLOSED is better suited to describe a connection in a NET_TCP_RX_Q_STATE_CLOSED state and you can have a connection in another state, say, NET_TCP_RX_Q_STATE_CONN and have nothing in the receive queue. We should change this conditional assignment to:

{{ if (result < 0) {
tcp_conn_id = NetConn_Tbl[p_sock->ID_Conn].ID_Transport;
rx_q_closed = (NetTCP_ConnTbl[tcp_conn_id].RxQ_State == NET_TCP_RX_Q_STATE_CLOSED);
*p_err = (rx_q_closed) ? (NET_SOCK_ERR_RX_Q_CLOSED) : (NET_ERR_RX);
} else {
ret_err = result;
}}}

Denial of Service with multipart forms when '=' not found

if the '=' character is not found in a multipart form request,a NULL pointer is returned in Str_Char_N, this pointer is then incremented and dereferenced which can lead to a crash. See HTTPsReq_HdrParse() for details. I recommend adding a test for NULL.

Improve the random generation of TCP sequence numbers.

We need to strengthen the security of Cs/NET, particularly when generating initial sequence numbers (ISNs). We follow RFC 793 but we should try to adhere to RFC 6528 from 2012, which describes an algorithm that consists of a random source (secret key) generated by the concatenation of the (source_ip, source_port, remote_ip, remote_port) four-tuple and feeding it to a hashing function (e.g. MD5).

ISNs for TCP connections not sufficiently random

Initial sequence numbers (ISNs) are not derived from a sufficiently random source which could lead to an attacker either hijacking an existing connection or spoofing future connections. ISNs should adhere to RFC6528 to be more secure. ISNs are retrieved by NetUtil_InitSeqNbrGet().

Add/Fix out-of-bounds check in array access.

The variable 'if_nbr' passed to NetBuf_Discard() needs to be checked for validity. This only becomes a problem if NET_ERR_CFG_ARG_CHK_DBG_EN is disabled.

The following line:

NET_CTR_ERR_INC(Net_ErrCtrs.IFs.IF[if_nbr].BufLostCtr);

(A) needs to be modified as:

if (if_nbr < NET_IF_NBR_IF_TOT) {
NET_CTR_ERR_INC(Net_ErrCtrs.IFs.IF[if_nbr].BufLostCtr);
}

in NetBuf_Discard()

OR (B) the check in the NetBuf_FreeHandler() -> NetBuf_Discard() path needs to have removed the
#if (NET_ERR_CFG_ARG_CHK_DBG_EN == DEF_ENABLED) conditional preprocessor directive that encloses NetIF_IsValidHandler() in NetBuf_FreeHandler(). This way this path will resemble the other two paths that lead to NetBuf_Discard(); which don't have this preprocessor directive.

NetBuf_Discard Out of Bound Write

net_buf.c line 3113.

No check on if_nbr so if out of range (ie 0xFF), the err ctr will increment at memory address out of bounds.
Probably replace with:

if(if_nbr < NET_IF_NBR_IF_TOT)
{
  NET_CTR_ERR_INC(Net_ErrCtrs.IFs.IF[if_nbr].BufLostCtr);
}

ARP module fails to invalidate cache entry in the RENEW state if the host becomes unreachable.

If a host becomes unreachable and the cache entry for said host expires, the ARP state machine transitions to the RENEW state where it remains for 10 minutes and keeps re-transmitting the ARP request until a maximum number of retries. The problem is that every retry repeats every 10 minutes and there's a maximum of 15 retries, which is too long. The ARP implementation is also considering the wrong timeout for those retries (it should be the request pend timeout instead of the cache renew timeout).

Garbage value returned to caller in func NetMLDP_HostGrpLeave

Hi everyone,

I found the return value of function NetMLDP_HostGrpLeave will be an uninitialized variable if users call this function without occupying the Net_GlobalLock and parameter p_addr is a null pointer.

In detail, assuming that the branch judgment condition on line 566 is satisfied, then the function will goto exit_release and return host_grp_leave, which is not initialized anywhere. The caller will get dirty garbage, leading to some unexpected results...

This is a public API, the wrong return value may mislead the user. Looking forward to your reply!

Incorrect Shift Operand in GMAC driver

When setting the DMA configuration, GMAC_DMA_DESC_SKIP_LEN is shifted by 3 instead of 2 as stated in the reference manual. However, the value of GMAC_DMA_DESC_SKIP_LEN is 0 so this does not have any impact on the driver's behavior.

NetICMP_TxEchoReq() Returns Wrong Error Code

System Configuration

The following is my configuration.

  1. uc/USB: CDC-ACM
  2. uc/USB: CDC-EEM
  3. uc/Shell: Shell
  4. uc/Shell: Terminal
  5. uc/TCPIP

The terminal is accessed through a serial port which is hosted over the CDC-ACM port. The shell at startup registered all net commands.

Bug Overview

NetICMP_TxEchoReq() function can return the wrong error code. In the following code, if kal_err != KAL_ERR_NONE then an error has occurred. For any error after setting p_err the software will issue a jump to release.

    switch (kal_err) {
        case KAL_ERR_NONE:
             result = DEF_OK;
            *p_err  = NET_ICMP_ERR_NONE;
             goto release;

        case KAL_ERR_TIMEOUT:
             result = DEF_FAIL;
            *p_err  = NET_ICMP_ERR_ECHO_REQ_TIMEOUT;
             goto release;

        case KAL_ERR_ABORT:
        case KAL_ERR_ISR:
        case KAL_ERR_WOULD_BLOCK:
        case KAL_ERR_OS:
        default:
             result = DEF_FAIL;
            *p_err  = NET_ICMP_ERR_ECHO_REQ_SIGNAL_FAULT;
             goto release;
    }
release:
    NetICMP_LockAcquire(p_err);

    KAL_SemDel(sem_handle, &kal_err);

    if (*p_err == NET_ICMP_ERR_NONE) {
        if (data_len > 0) {
            if (p_echo_req_handle_new->DataCmp != DEF_OK) {
                *p_err = NET_ICMP_ERR_ECHO_REPLY_DATA_CMP_FAIL;
            }
        }
    }

Once execution resumes at release, the first function, NetICMP_LockAcquire(p_err), will overwrite p_err resulting in any previous error code being lost.

Reproduction

  1. Start system. System not connected to internet.
  2. Connect to system over serial port (using USB CDC-ACM).
  3. Issue a net_ping command using IP address that is not on local network.
  4. Shell prints error error code 12033 (NET_ICMP_ERR_ECHO_REPLY_DATA_CMP_FAIL).

Shell should return NET_ICMP_ERR_ECHO_REQ_TIMEOUT.

Debugging shows that p_err does get set correctly to NET_ICMP_ERR_ECHO_REQ_TIMEOUT, but is overwritten once code following release starts executing.

Resolution

If the switch statement is changes so that errors use goto exit_kal_fault instead of goto release, the system will not call Mem_DynPoolBlkFree() which results in a memory leak. Since this code uses goto, the following code section

exit_kal_fault:
    Mem_DynPoolBlkFree(&NetICMP_DataPtr->EchoReqPool,
                        p_echo_req_handle_new,
                       &lib_err);


exit_release_lock:
    NetICMP_LockRelease();


exit_return:
    return (result);

could be replaced with

exit_kal_fault:
    Mem_DynPoolBlkFree(&NetICMP_DataPtr->EchoReqPool,
                        p_echo_req_handle_new,
                       &lib_err);

exit_release_lock:
    NetICMP_LockRelease();
    goto exit_return;

exit_kal_fault_with_cleanup:
    Mem_DynPoolBlkFree(&NetICMP_DataPtr->EchoReqPool,
                        p_echo_req_handle_new,
                       &lib_err);

exit_return:
    return (result);

where exit_kal_fault_with_cleanup will be used in the switch case instead of goto release for the fault conditions.

As I can't find a coding standard I do not know what the appropriate solution would be.

NetSock_Accept may release globalLock but not Acquire it

In function NetSock_Accept(),when check Validate initial addr len (line:4554-4588) error, the function
exit with Net_GlobalLockRelease() from label exit_err_acccept,but the function did not call Net_GlobalLockAcquire() before.

Corruption of NET_BUF in FIN_WAIT_2/TIME_WAIT states

When TCP session moves to the FIN_WAIT_2 state and a FIN is received from other side, the FIN Rx buffer is added to the RxQ_App_Tail and the TIME_WAIT is setup. But the p_buf, which contains the FIN packet, is freed, but there remains a reference to it in RxQ_App_Tail. Meanwhile some other mechanism (ie NetIF_RxTask receives a packet or app layer transmit a packet) allocates the same memory location. Then when the TIME_WAIT fires, it thinks it needs to clear RxQ_App_Tail since that reference is not null and the packet header is in use. That then corrupts another socket's buffer which can result in the connection dropped or an error on the app data.

This means that someone causing a device side shutdown may result in terminating other sockets and/or loss of data.

net_tcp.c line 8751 in NetTCP_RxPktConnHandler
`
case NET_TCP_CONN_STATE_FIN_WAIT_2:
NetTCP_RxPktConnHandlerFinWait2(p_conn, p_buf, p_buf_hdr, p_err);

         switch (*p_err) {
             case NET_TCP_ERR_CONN_RESET_VALID:
             case NET_TCP_ERR_CONN_DATA_NONE:
                  NetTCP_RxPktFree(p_buf);
                                                            /* 'break' intentionally omitted; MUST execute the ...  */
                                                            /* ... following case : 'NET_TCP_ERR_CONN_DATA_VALID'.  */

             case NET_TCP_ERR_CONN_DATA_VALID:
                  NET_CTR_STAT_INC(Net_StatCtrs.TCP.RxSegCompCtr);
                  break;

net_tcp.c line 30697 in NetTCP_ConnFreeHandler
NetTCP_ConnFreeBufQ(&p_conn->RxQ_App_Head , &p_conn->RxQ_App_Tail );
`

NetTCP_RxPktConnHandlerFinWait2 <- Adde p_buf to RxQ_App_Tail
NetTCP_RxPktFree(p_buf) <- p_buf is freed but RxQ_App_Tail still points to the memory location.
NetTCP_ConnFreeBufQ(&p_conn->RxQ_App_Head , &p_conn->RxQ_App_Tail <- free's up memory owed by other session
if alloicated.

I don't know the code that well but one solution might be since the AppData is no longer needed, the NetTCP_RxPktFree should
be replaced with
NetTCP_ConnFreeBufQ(&p_conn->RxQ_App_Head, &p_conn->RxQ_App_Tail);
so that when the TIME_WAIT fires, it doesn't need to free the RxQ_App's and it doesn't core.

Reproduce

  1. Open 2 TCP Session (uC/TCP is run on server)
  2. Send request that cause the server to close one session
  3. Once connection has closed. Open another connection.
  4. Send request that causes a reply on both sockets.

Repeat steps 2 - 4. Sometimes the other session not requested to close is dropped. Sometimes the next connection doesn't receive the request.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.