vaunale peopeo dennett

[Laurelino Braendel]

I should know if socket is not connected at the first "Test" sending because in my application I would send a string, then save it in an SD card and append a flag that tells me if the string has been correctly sent or not.

Network stacks can tell you when your local Ethernet cable has been unplugged, but they can't tell you if the NEXT cable (after the first hub) has been unplugged or if the remote server is still working.

After you attempt a Send, if the connection has been down it can take up to 5 minutes or so for the standard TCP timeouts to finally give up and signal to the Application that THE NEXT send failed. That's not a bug. TCP Writes are queued. The return status indicates they have been QUEUED successfully, not end-to-end-DELIVERED. You can't rely on it taking 3 seconds either. The time taken to time out and signal the disconnection depends on the measured network latencies. You may be getting 3 seconds on your desk, but if you then put the device somewhere else on the Internet or on a slow connection the timing will get longer (up to the 9 minute maximum).

It only goes into states that signal "TCP_FINRCVD" after the connection has been CLOSED, either from your end or the other end. So if you send data then actively CLOSE the connection, waiting for the FINRCVD state will tell you that the data got send, then the close, and the close has been completed. If you don't want to perform a CLOSE after every send, then reading TCP_FINRCVD shouldn't tell you anything that the error return from a send already does.

The problem is that now I receive incorrect characters on the USB port (in echo mode, as basic example in the USB stack): whatever I'm sending I receive 0x20 for the first character and 0x45 for the second.

But we encountered another "little" problem we didn't face before in our TCP send/receive experiments: we manage to send only 10 bytes to a TCP port, not more, despite we charge a char array buffer with more, and we provide the correct size to send.

I would like to use the FNET stack (specifically the bootloader) with a GSM module, which I access via the UART. I'm using a Simcom SIM900 and it uses AT commands to configure and connect, and offers a 'transparent' mode with which, as the documentation states, "All received data from the serial port will be treated as data packet to be transferred later...", but to establish the connection requires opening a port on the remove server first through AT commands. Is it possible to somehow open the port and then pass over communications to FNET?

Andrey, thank you, yes I already use this module for communicating with a server by AT commands, so I have no problem making a connection to a server port and sending or receiving packets. It's getting FNET working with it from that point I'm not sure about. When you say to implement PPP, is this something that is already supported by FNET, i.e. can I add PPP below TCP/IP? Or is this what you mean about having to write from scratch?

We provide some examples with the lwpi, but it will depend if you are using FreeRTOS or Bare Metal.
In other words, if you select Bare Metal, the lwpi stack is handling by polling, and as you know FreeRTOS works with interrupts.

It only has an interrupt level setting and not a priority. The level is the lower 3 bits of FNET_MCF_INTC0_ICR(irq_number) so it looks to me this will always get set to 7 and the level, which is shifted into bits 3/4/5 gets ignored.

By debugging a basic firware, just sending few characters to a selected remote TCP port, either using CodeWarrior V10.3 and V10.5 I go to PE_DEBUGHALT _if_ I set Optimization Level 0 in compiler options; this as soon as I get connected to the remote TCP server.

Since 1 month now we totally finished our software and our system (IRIG-B Generator synchronised by GPS, with ethernet communication on a PC) hang up (I am not sure of the good word in english) 1 or 2 time a day and the watchog don't reset the system.

I found that the level of interrupt of the watchdog was 1 and the one of PHY is 2 and DMA Timer3 is 3 (this 2 ints are used by FNET). So I changed watchodg level to 4 and now, our system reset when issue occur (this is better than reset by manual off/on !).

You have the whole system in front of you, at a good breakpoint, exactly in the middle of the problem. You're the only one who can work through this. The first thing to do is to dump all of the FEC registers and all of the ring contents. Find what state it is in and then try to work back to how it got into that state.

You should use the "ping" utility to send ICMP Echoes at it to see if that makes it happen more often. You could even get a "flood ping" going from a unix box, or use "ping -w" with a low timeout value.

You should check the Timer interrupts in case they're happening in the middle of some FNET or FEC code that isn't expecting it. You could try setting the Timer interrupt lower than the FEC one and see if the problem goes away.

I've just looked at how "fnet_isr_lock()" works. Weird. It makes interrupts PENDING, and then has them run later. I'd be interested to know why this code doesn't simply disable the CPU interrupts around critical sections.

The Zephyr network stack is a native network stack specifically designedfor Zephyr OS. It consists of layers, each meant to provide certain servicesto other layers. Network stack functionality is highly configurable via Kconfigoptions.

Network Application. The network application can either use the providedapplication-level protocol libraries or access theBSD socket API directly to create a networkconnection, send or receive data, and close a connection. The application canalso use the network management API to configurethe network and set related parameters such as network link options,starting a scan (when applicable), listen network configuration events, etc.The network interface API can be used to set IPaddress to a network interface, taking the network interface down, etc.

Network Interface Abstraction. This provides functionalitythat is common in all the network interfaces, such as setting networkinterface down, etc. There can be multiple network interfaces in the system.See network interface overview for more details.

L2 Network Technologies. This provides a common API for sending andreceiving data to and from an actual network device.See L2 overview for more details.These network technologies include Ethernet,IEEE 802.15.4,Bluetooth, CANBUS, etc.Some of these technologies support IPv6 header compression (6Lo),see RFC 6282 for details.For example ARP for IPv4 is done bythe Ethernet component.

The device driver allocates enough network buffers to store the receiveddata. The network packet is placed in the proper RX queue (implemented byk_fifo). By default there is only one receive queue inthe system, but it is possible to have up to 8 receive queues.These queues will process incoming packets with different priority.See Traffic Classification for more details. The receive queues alsoact as a way to separate the data processing pipeline (bottom-half) asthe device driver is running in an interrupt context and it must do itsprocessing as fast as possible.

A socket handler then finds an active socket to which the network packetbelongs and puts it in a queue for that socket, in order to separate thenetworking code from the application. Typically the application is run inuserspace context and the network stack is run in kernel context.

The network packet is then classified and placed to the proper transmitqueue (implemented by k_fifo). By default there is onlyone transmit queue in the system, but it is possible to have up to 8transmit queues. These queues will process the sent packets with differentpriority. See Traffic Classification for more details.After the transmit packet classification, the packet is checked by thecorrect L2 layer module. The L2 module will do additional checks for thedata and it will also create any L2 headers for the network packet.If everything is ok, the data is given to the network device driver to besent out.

Forescout researchers have discovered vulnerabilities in multiple TCP/IP stacks in which ISNs (Initial Sequence Numbers within TCP connections) are improperly generated, leaving TCP connections of a device open to attacks. Forescout researchers analyzed 11 total stacks: uIP, FNET, picoTCP, Nut/Net, lwIP, cycloneTCP, uC/TCP-IP, MPLAB Net, TI-NDKTCPIP, Nanostack, and Nucleus NET.

ISNs ensure that every TCP connection between two devices is unique and that there are no collisions, so that third parties cannot interfere with an ongoing connection. To guarantee these properties, ISNs must be randomly generated so that an attacker cannot guess an ISN and hijack an ongoing connection or spoof a new one.

These vulnerabilities were discovered and disclosed to the affected vendors and maintainers in October 2020. Most vendors have already issued patches and/or mitigation recommendations to users. The developers of Nut/Net are working on a solution, and Forescout has not received a response from the uIP developers.

The popularity and some use cases of the vulnerable stacks is extensive. As we outlined in our AMNESIA:33 report, uIP, FNET, picoTCP and Nut/Net are used by millions of devices, including everything from IT file servers to IoT embedded components. We believe that CycloneTCP, uC/TCP-IP, NDKTCPIP, MPLAB Net and Nucleus NET are equally popular and widespread.

In this research, Forescout has not tried to identify affected devices or device manufacturers. Still, there are several notable public use cases of some of the stacks, such as medical devices, wind turbine monitoring systems, remote terminal units (RTUs) and IT storage systems.

Identifying and patching devices running the vulnerable stacks is challenging because it is often unknown which devices run a particular stack, and embedded devices are notoriously difficult to manage and update.

c01484d022