butok / fnet Goto Github PK

The FNET is a free, open source, dual TCP/IPv4 and IPv6 Stack (under Apache Version 2.0 license) for building embedded communication software on 32bit MCUs.

Home Page: http://fnet.sourceforge.net/

License: Apache License 2.0

Batchfile 0.01% C 96.41% HTML 0.07% CSS 0.07% Assembly 3.15% C++ 0.27% Shell 0.03%

embedded-software tcpip kinetis lpc imxrt fnet mk64 mk66 mk60 mimxrt1052

fnet's Introduction

FNET TCP/IP Stack.
==================
Please read the FNET Quick Start chapter. You can find it in the /fnet_doc/fnet_user_manual.chm file.

The stack provides following protocols and services:
- Supported Platforms:
	- ARM Cortex-M4
		- Kinetis:
			- MK64FN1M (FRDM-K64F board)
			- MK66FN2M (FRDM-K66F board)
			- MK6DN512 (TWR-K60D100M board)
		- i.MX-RT: 
			- MIMXRT1052 (IMXRT1050-EVKB board).
			- MIMXRT1062 (MIMXRT1060-EVK board).
		- LPC: LPC54628 (OM13098: LPCXpresso54628 board)
	- Qualcomm/Atheros Wi-Fi 202.11: 
		- QCA4002 (GT202-GC3013-FRDM4-KIT board).
		- QCA4004 (SX-ULPAN-2401-SHIELD board). 
- Supported Compilers:
	- IAR: Embedded Workbench for ARM, version 8.22
	- GCC: Kinetis Design Studio, version 3.2 
- Bare-metal TCP/IP stack. No underlying RTOS is required, although it can be used with it. FreeRTOS example is provided.
- Certified logos for:
	- Golden IPv6 Ready.
	- Microsoft Azure IoT.
	- Apple Bonjour. 
- Non-blocking Socket API (DGRAM, STREAM, RAW).
- Core Protocols:
	- TCP (Transmission Control Protocol).
	- UDP (User Datagram Protocol).
	- IPv4.
		- ICMPv4 (Internet Control Message Protocol).
		- IGMP (Internet Group Management Protocol).
		- ARP (Address Resolution Protocol).
	- IPv6. 
		- "IPv6 Ready Logo Certified". Passed IPv6 Core Protocols Conformance and Interoperability tests.
		- ICMPv6 (Internet Control Message Protocol).
		- MLDv1 (Multicast Listener Discovery).
		- Neighbor Discovery for IPv6.
		- IPv6 Stateless Address Autoconfiguration.
		- Path MTU Discovery for IPv6
- Network Interfaces:
	- Ethernet (FEC/ENET module).
	- Wi-Fi (QCA4002/4 module).
	- Loopback.
- Services:
	- HTTP server:
		- HTTP/1.0 or HTTP/0.9 protocols.
		- GET and POST requests.
		- CGI and SSI.
		- Basic access authentication.
		- HTTP over TLS (HTTPS).
	- TELNET server. 
	- DHCPv4 client and server.
	- Auto-IP service. Passed "Link-Local Address Allocation", Bonjour Conformance Test.
	- Azure IoT Hub client adapter. Microsoft Azure certified.
	- DNS client/resolver.
	- Link-Detection service.
	- Multicast DNS (mDNS) "Bonjour" Server/Responder. Passed the Bonjour Conformance Test.
	- LLMNR Server/Responder.
	- PING service.
	- SNTP client.	
	- TFTP server and client. Both Read and Write requests are supported.
	- TLS using mbedTLS library.
	- ROM File System.
	- On-chip Flash Memory driver.
	- Command line shell.
 	- Serial driver.

FNET project directory structure:
	fnet                        - FNET root directory.
	|-- fnet_stack                - FNET TCP/IP stack.
	|    |-- stack                  - FNET TCP/IP stack platform-independent source code.
	|    |-- service                - FNET Services.
	|    |    |-- autoip              - Auto-IP service.
	|    |    |-- azure               - Azure IoT Hub adapter.
	|    |    |-- bench               - Benchmark client and server.
	|    |    |-- dhcp                - DHCPv4 client and server.
	|    |    |-- dns                 - DNS client/resolver.
	|    |    |-- flash               - Flash Memory driver.
	|    |    |-- fs                  - File System driver.
	|    |    |-- http                - HTTP Server service.
	|    |    |-- link                - Link-Detection service.
	|    |    |-- llmnr               - LLMNR server/responder.
	|    |    |-- mdns                - mDNS server/responder.
	|    |    |-- ping                - PING service.
	|    |    |-- poll                - Polling Mechanism library.
	|    |    |-- serial              - Serial Input/Output driver.
	|    |    |-- shell               - Command Shell service.
	|    |    |-- sntp                - SNTP client.
	|    |    |-- telnet              - TELNET server.
	|    |    |-- tftp                - TFTP server and client.
	|    |    |-- tls                 - TLS library.
	|    |-- port                   - FNET port-specific source code.
	|         |-- compiler            - Compiler-specific source code.
	|         |-- cpu                 - FNET platform-specific source code.
	|         |    |-- lpc              - LPC-specific source code.
	|         |    |-- mcf              - ColdFire-specific source code.
	|         |    |-- mk               - Kinetis-specific source code.
	|         |    |-- mpc              - Power Architecture-specific source code.
	|         |-- netif            - Platform-specific network interface drivers.
	|              |-- enet          - ENET Ethernet module driver, used by LPC platform.
	|              |-- fec           - FEC/ENET Ethernet module driver, used by MCF,MPC and MK platforms.
	|              |-- qca           - QCA4002/4 Wi-Fi module driver, adapter for "third_party/qca-x.x.x".
	|-- fnet_doc                  - FNET documentation.
	|-- fnet_demos                - FNET demo projects.
	|    |-- common                 - Common source code used by demos.
	|    |    |-- fnet_application    - Demo application source code.
	|    |    |-- fnet_webpage        - Demo web page source code.
	|    |    |-- startup             - Platform-specific start-up source code and drivers.
	|    |-- build                 - Demo projects.
	|         |-- <board_name>        - Demo projects for a <board_name> board.
	|              |-- shell          - "Shell" demo is a fully featured shell. It allows
	|              |                    view/change various parameters (e.g. IP address,
	|              |                    subnet mask), explore mounted file systems, run 
	|              |                    DHCP client, HTTP and Telnet servers.
	|              |-- shell_azure    - FNET Azure IoT Hub client example.
	|              |-- shell_boot     - FNET TFTP Bootloader.
	|              |-- shell_boot_app - Example application used for the FNET TFTP Bootloader
	|              |                    demonstration. This demo has the same features as
	|              |                    the "Shell" demo, but it`s modified to be able to
	|              |                    work with the FNET Bootloader.
	|              |-- shell_bench    - TCP/UDP Throughput Benchmark application. 
	|              |-- shell_tls      - Example application used for the HTTPS server demonstration.
	|              |                    This demo has the same features as the "Shell" demo,
	|              |                    but in addition it includes the mbedTLS library.
	|              |-- shell_wifi_<board> - Example application used for the Wi-Fi interface demonstration.
	|                                       It has the same features as the "Shell FreeRTOS" demo,
	|                                       but in addition it supports the Wi-Fi network interface using the Qualcomm QCA4002/4 module.
	|-- fnet_tools                - FNET PC tools.
	|-- third_party               - Optional, third-party libraries.
		 |-- azure_iot-x.x.x        - Azure IoT Hub Device C SDK.
		 |-- cmsis-x.x              - ARM CMSIS-Core(M) library, used for ARM Cortex M platforms.
		 |-- mbedtls-x.x.x          - mbedTLS library, used by FNET TLS.
		 |-- freertos-x.x.x         - FreeRTOS, used by freertos examples.
		 |-- qca-x.x.x              - Qualcomm QCA4002/4 driver, used by shell_wifi_<board> example.

fnet's People

Contributors

Stargazers

Watchers

fnet's Issues

FNET DNS doesn't resolve for certain urls

Board: Teensy 4.1 with NativeEthernet library
https://github.com/vjmuzik/NativeEthernet

I'm using this fork of the FNET repository:
https://github.com/vjmuzik/FNET

As far as I could see the concerning service 'fnet_dns.c' doesn't differ between the forks.

The dns service resolves fine for different urls, but not for the one which I use to access my Azure Storage Tables:
'prax47.table.core.windows.net'

This url is resolved without issues on different mcus and frameworks, e.g. Wio Terminal with WiFi library or 'EthernetENC' library.

Wireshark captures show this dns request

and this response

As I interpret the captures FNET dns service regulary sends the request but doesn't accept the response, complaining about malformed packets.

What could be the reason for this behavior?

Virtual routing and forwarding(VRF) integration in FNET stack

Hello everyone,
can anyone tell me, How can I implement Virtual Routing and Forwarding(VRF) into FNET stack.
If yes,please share the methods.

Seeking Guidance: The TCP/IP protocol suite is so complex, how did you test FNET?

FNET has indeed been a great asset to our work. We’ve been utilizing FNET in our products for some time now. However, due to certain circumstances, we’re required to switch the MCU we’ve been using, and unfortunately, the new ones aren’t supported by FNET. I’ve also personally considered porting FNET to the new MCU, but I’m not sure if I have the necessary skills and energy to do so. We’re considering using a new TCP/IP stack and want to ensure it’s as good as FNET. Therefore, we’re interested in applying the same testing methods used for FNET to evaluate this new stack. Could you provide some guidance on this?

Update for MBED-TLS

An update to the included MBED-TLS would be really appreciated since the currently used version seems to have some compiler warnings and security issues that have been resolved in newer versions.
Additionally newer versions support more recent TLS versions.

FNET-4.6.3 shell wrong command bug

in fnet_shell.c
`
if(cur_command->name == 0)
{
fnet_shell_println((fnet_shell_desc_t)shell_if_p, FNET_SHELL_ERR_CMD, argv[0]);
}

`
if cur_command is NULL, the program will crash.
so if I input wrong command, the program will crash.

call fnet_socket_shutdown() in SS_CLOSING cause FNET_ERR_NOTCONN

Assuming the MCU running FNET as a server, after successful connection with the client via TCP, then at some point, the client indicates to shutdown the connection by sending some messages to prepare to tear down the connection, then call API shutdown( clientSock, SHUT_WR). From the FNET server, as the client has not closed yet, calling to fnet_socket_shutdown() shall not return error with the errno FNET_ERR_NOTCONN.

How to reproduce:

Server side (running FNET)
- server_sock = fnet_socket(AF_INET, SOCK_STREAM, 0);
- fnet_socket_bind(server_sock, IP_and_port, sizeof(IP_and_port);
- fnet_socket_listen();
- client_sock = fnet_socket_accetp();
- Above step is successful, then send and receive data as usual, but looking for the special token "exit" every time receive message from the client.
- Upon receiving "exit" message, invoking the fnet_socket_shutdown(client_sock, SD_WRITE);, at this point we get the return value to be (-1) and the FNET_ERR_NUMBER is FNET_ERR_NOTCONN.
Client side (on PC):
- `fnet_socket()'
- 'fnet_socket_connect()`
- upon successful, send and receive data.
- At some point, sending the message "exit" to inform the server that we are about to tear down the connection, then calling the shutdown(clien_socket, SHUT_WR);
- Other sequence is not relevant here.

The problem happens when the server receives the FIN packet, it changes the socket state sk->state = SS_CLOSING. And tracing the problem from the fnet_socket_shutdown, it eventually called to _fnet_tcp_shutdown, the problem seem to be the following code snippet:

static fnet_return_t _fnet_tcp_shutdown( fnet_socket_if_t *sk, fnet_sd_flags_t how )
{
    /* If the socket is not connected, return.*/
    if(sk->state != SS_CONNECTED) /* <<< I think this is where the problem happen, because the state at this point is SS_CLOSING */
    {
        _fnet_socket_set_error(sk, FNET_ERR_NOTCONN); 
        return FNET_ERR;
    }
    else
... /* some more code */

In my opinion, the SS_CLOSING meaning that the connection is still not reach the CLOSED state yet, thus, considering it is the error is not the expected behavior. In the normal case, it shall be able to run the another else branch and sending out the FIN packet and process, before we actually call the close function. My proposal, if that is the valid finding, is changing that if condition to:

if(sk->state == SS_CLOSED)
{
    /* Raise error */
}
else
{
    /* process as usual */
}

I would like to know your opinion on this finding, as it seems the behavior is different from the document from this link https://man.freebsd.org/cgi/man.cgi?query=shutdown&sektion=2

Request for FNET status on CVE vulnerabilities.

Hello Butok,

Thanks for this latest release (https://github.com/butok/FNET/releases) that seems to address one of the TCP randomization security issues. Please let us know if these mentioned vulnerabilities have been addressed in the current release of FNET. If you already addressed them, let me know where this information can be found.

CVE is the public record of the vulnerabilities, FSCT is Forescout's identifier. CERT's public report is at https://kb.cert.org/vuls/id/815128

CVE-2020-17470: Fnet is vulnerable due to Improper Input Validation (CWE-190) when processing a DNS response in function _fnet_dns_poll(fnet_dns.c). This function does not validate both DNS response ID to a matching outgoing query data resulting in corruption of DNS data and DNS cache poisoning on the target device.(FSCT-2020-0025)
CVE-2020-17467: Fnet is vulnerable due to Out of bounds read (CWE-125) when processing Link-local Multicast Name Resolution (LLMNR) hostname value in _fnet_llmnr_poll function in fnet_llmnr.c. The code does not check for Null termination of the incoming link layer data resulting in improper access to memory on the target device. This can result in information leak or other unexpected behavior due to arbitrary access to memory data.(FSCT-2020-0024)
CVE-2020-17469: Fnet is vulnerable to Out-of-bounds read (CWE-125) when reassembling IPv6 fragments in the function _fnet_ip6_reassembly(fnet_ip6.c). This subroutine improperly reads previous packet information using an invalid C-programming pointer (NULL pointer dereferencing). This can lead the target device to provide unexpected memory read access or result in DoS condition.(FSCT-2020-0022)
CVE-2020-17468: Fnet is vulnerable to Out-of-bounds read (CWE-125) when processing IPv6 hop by hop extension header in subroutine _fnet_ip6_ext_header_handler_options (fnet_ip6.c). The routine does not validate the length of the extension header which could result in a crash or an unexpected read access to arbitrary memory locations on the target device.(FSCT-2020-0021)

Bad link status when used PHY DP83848 in latest FNET version

Hi Andrey,
I updated FNET from 4.3.0 to 4.6.3 and I have now issue with link status. The function _fnet_eth_is_connected in file fnet_eth.c return bad status on my board with PHY DP83848. It was working right, but after update, it is still returning LINK UP, but not connected cable. I tried on lot of boards.

I allowed your hack which is commented for PHY DP8340, but it still returning bad value. It seems, that it read from register bad (I see 0xFFFF in data after called function _fnet_eth_phy_read(netif, FNET_ETH_MII_REG_SR, &data); )

Please, could you help me? What did you changed?
Thank you.
Vilem

TLS connections don't close on errors

If using TLS connections, errors in the underlying FNET write or read functions won't cause the TLS connections to close as expected.
This error can be traced down to the callback functions "_fnet_tls_mbedtls_send" and "_fnet_tls_mbedtls_recv". If the underlying FNET connection returns FNET_ERR, these functions return 0, but according to the mbedtls documentation https://tls.mbed.org/api/ssl_8h.html#a38e2b400d361f42f85833cdc30b3916e, the callback must return the number of bytes sent if any, or a non-zero error code.

To fix that, just return -1 or simply remove the else-if-clause.

butok / fnet Goto Github PK

fnet's Introduction

fnet's People

Contributors

Stargazers

Watchers

Forkers

fnet's Issues

FNET DNS doesn't resolve for certain urls

Virtual routing and forwarding(VRF) integration in FNET stack

Seeking Guidance: The TCP/IP protocol suite is so complex, how did you test FNET?

Update for MBED-TLS

FNET-4.6.3 shell wrong command bug

call fnet_socket_shutdown() in SS_CLOSING cause FNET_ERR_NOTCONN

Request for FNET status on CVE vulnerabilities.

Bad link status when used PHY DP83848 in latest FNET version

TLS connections don't close on errors

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent