TCPIP Updates – NET+OS 6.3

Last Updated: 10/21/11 Fix Count: 22

Title
Denial of Service attack

Case: 40393

Date Fixed: 10/21/11

Description

When exposed to UDP port 0 broadcast storm, stack could become non-responsive.

Solution

Fixed deficiency that allowed broadcast storm on UDP port 0 to hang stack.

Title
Profinet hangs under heavy load

Case: 33485

Date Fixed: 09/10/10

Description

Profinet stack crashes when heavy web traffic is present.

Solution

Replaced TPC/IP block size of 1836 with 2048 (1836 became too small to hold a maximum Fusion received packet after some Stack changes). The changes fix some problems for Profinet.

Title

TCPIP stack appears to be in an infinite loop

Case: internal

Date Fixed: 03/16/10

Description

On occasion the TCPIP stack could appear to hang.

Solution

Fixed unintialized variable in stack.

Title

Ethernet receive thread stuck waiting on semaphore.

Case: 1286473

Date Fixed: 02/19/10

Description

Ethernet receive thread could get stuck waiting on a Fusion critical section semaphore.

Solution

Changed h_alloc to not use Fusion critical section when using user heap - NATcpipHeap API. This is useful for Ethernet Bypass receive to avoid waiting on a Fusion critical section semaphore in Ethernet receive thread.

Title

t_start function causing intermittent stack crashes

Case: 1258326

Date Fixed: 12/19/08

Description

The t_start function was not checking to see if the timer already existed.

Solution

Modified t_start function to correct issue.

Title

Connect ME can not communicate from behind a SAGEM cable modem

Case: 1244913

Date Fixed: 03/25/08

Description

Cable modem had problems dealing with SYN packets with 0 window size.

Solution

Modified SYN packet to have window size 1 to accommodate this cable modem.

Title

select() problem

Case: 25051

Date Fixed: 02/20/08

Description

Select() waits forever for data, randomly, when 0 seconds are specified and 500000 usec are specified.

Solution

Fixed in latest stack update. Install this patch and it’s dependencies. Rebuild the BSP and application.

Title

BOOTP requests not being transmitted

Case: 1234934

Date Fixed: 08/21/07

Description

BOOTP requests are no longer sent out after 32 minutes if there is no response from a server.

Solution

A timer was being handled incorrectly. This has been fixed. BOOTP requests will now be sent out until a server responds.

Title

Problem creating more than 61 sockets

Case: 1220906

Date Fixed: 11/22/06

Description

An application that creates approximately 61 - 64 threads that have all called accept to wait for a connection from a client can run into a problem where the system will freeze. This will only be seen when all the threads are waiting simultaneously for a connections from clients.

The code that implements accept was calling into an internal NET+OS tcp/ip stack-related function that facilitates putting threads to sleep while waiting for system action. When the structure for holding information about these sleeping threads completely filled and returned an error condition code, the accept function was not checking the contents of this returned error code. This was leaving the accept code vulnerable to trying to wakeup a thread for which the sleep function's structure had not information. This was causing a freeze condition.

Solution

The accept function now checks the status returned by the sleep function. If this return code indicates an error, accept will return -1 as the socket that would have been created by the call to accept, indicating that the call to accept failed.

In addition, the number of events that the sleep function can wait on has been increased from 64 to 128, placing it on par with the number of sockets available within NET+OS.

An application can now create many more such accept-waiting threads than before. In addition, should the limit be reached, instead of freezing, the accept function will now gracefully return a negative status code to the application.

Title

ARP/Ping incorrectly discarding packets

Case: 1219140

Date Fixed: 10/18/06

Description

Unit failed to acquire IP address when using ARP/Ping method to set an IP address in

the 169.254.x.x range.

Solution

Fixed the function ip_net_deliver() which was discarding packets prematurely.

Title

Low Memory network conditions are slow to recover
 

Case: 16220

Date fixed: 09/22/06

Description

During extreme network activity, the TCP/IP stack enters a low memory condition, causing dropped packets, and causing long delays in networking applications. This is most apparent in wireless applications.

Solution

Corrected defects in the tcp/ip stack when entering low memory conditions.

Title

Non-standard Ping reply

Case: 1204686

Date Fixed: 07/12/06

Description

We were responding to ping requests where the source address of the request is the subnet broadcast address.

Solution

Ping packets where the source address is the subnet broadcast address are now filtered out.

Title

Sockets API bind failures

Case: 16346

Date Fixed: 06/16/06

Description

bind() fails when binding to a specific IP address (versus the more common INADDR_ANY).

Solution

Corrected bind processing to handle specific IP addresses.

Title

DNS failure causes socket overflow

Case: 1212964

Date Fixed: 06/02/06

Description

There was a bug in the DNSgethostbyname() routine that failed to close the socket used

to attempt connect to the DNS server when the DNS server was not found. This eventually

led to a socket overflow condition in which there were no sockets available.

Solution

Added logic to be sure sockets are closed when the DNS server can't be contacted.

 
Title
Subnet masks may be set incorrectly
 
Case:  17746
 
Date Fixed:  01/20/06
 
Description
In some instances, TCP/IP stack processing related to subnet masks might be incorrect. This could manifest itself by packets not being routed correctly and/or an invalid subnet mask displayed at OID 1.3.6.1.2.1.4.20.1.3 in a MIB browser.
 
Solution
Removed TCP/IP stack restrictions on subnets based on network classes.

Title

Sockets do not receive UDP broadcasts if bound to anything except INADDR_ANY

Case: 17529

Date Fixed: 12/15/05

Description

Code was missing from the stack for handling UDP broadcast messages. UDP broadcast messages were handled correctly if the socket was boundto a specific IP address.

Solution

Code was added, to the TCP/IP stack to handle UPD broadcast when the socket is bound to a specific address.

Title

Restarting ACE

Case: internal

Date Fixed: 11/04/05

Description

One should be able to call customizeStopAce(ifname) for all interfaces, and then call customizeStartAce() once to restart ACE..

Solution

Changed ace_initialize to do thread and timer initialization only on a 1^st call, and now we also create a mutex for ACE callbacks only on a 1^st call of customizeAceCreateLock, so cusomizeStartAce could be called more than once.

Title

ACE Start/Stop Issues

Case: 1216183

Date Fixed: 11/04/05

Description

To implement os_sleep and os_wakeup functions, Fusion uses an event table, with each entry consisting of an event pointer, used as an argument of os_sleep and os_wakeup calls, and a ThreadX event flag. These two entities were not accessed in one atomic operation, so the context switch could occur in os_sleep between resuming the thread, by getting an event flag, and clearing the event pointer.

As the result, if two threads called os_wakeup with the same pointer at the same time, the second thread could set an event flag after os_sleep had gotten an event

flag, but before it had cleared an event pointer. After this an empty event table entry would have a set event flag and some unrelated os_sleep, called later, would

wake up, without actually sleeping.

This created a problem for the ARP probe timer code that called os_sleep and expected to be woken up either by address conflict event or by timeout, but instead os_sleep returned without sleeping. Deleting the ARP probe timer created a data corruption.

Solution

The fix guarantees that os_sleep and os_wakeup functions access the Fusion event pointer and the ThreadX event flag in one atomic operation. The change has been made in Fusion osdep.c file.

Also fixed in this patch is a memory leak in aceCallbacks.c caused by not freeing the ifname from the previous customizeStartAce call.

Title

ACE Invalid Address problem

Case: 17079

Date Fixed: 10/11/05

Description

Registering an invalid address (e.g. 0.0.0.0) could put ACE into an infinite loop

Solution

Upon registering a bad address, customizeErrorHandler is called with ERROR-ACE-FAILURE and ERROR-SUBCODE-BAD-ACE-CONFIGURATION

Title

Method to flush Arp cache added

Case: 17258

Date Fixed: 07/26/05

Description

New feature added to flush the arp cache.

Solution

Added naArpFlush();

Title

IGMPv3 Packet Processing Failures

Case: 15849

Date Fixed: 07/11/05

Description

Multicasts across routers are failing because IGMPv3 packets are being

ignored.

Solution

IGMPv3 packet size is now ignored (IGMPv3 packets are longer than v2) and the packet is treated like a v2 packet.

Title

TCP/ICMP blind connection reset attack

Case: 16474

Date Fixed: 06/28/05

Description

TCP connections are reset under the blind ICMP destination unreachable attack. Reproducible with Retina Network Security Scanner from eEye Digital Security.

Solution

Added sequence number check into stack as suggested in raft-gont-tcpm-icmp-attacks-03.txt.

Files: netos\h\select_support.h

netos\h\tcpip\naarpapi.h

netos\h\tcpip\natcpipheap.h

netos\src\bsp\devices\common\serial\select_support.c

netos\src\apps\tcpbm\appconf.h

netos\src\apps\template\appconf.h

netos\lib\arm7\32b\ghs\libtcpip.a
netos\lib\arm9\32b\gnu\libtcpip.a
netos\lib\arm7\32b\ghs\libtcpip.a
netos\lib\arm9\32b\gnu\libtcpip.a
netos\lib\arm7\32b\ghs\libdnsclnt.a
netos\lib\arm9\32b\gnu\libdnsclnt.a
netos\lib\arm7\32b\ghs\libdnsclnt.a
netos\lib\arm9\32b\gnu\libdnsclnt.a

Special Instructions

• Unzip the patch(es) to the root of your NET+OS installation, for example C:\netos63_gnu\.
• Be sure to install any patches listed under Dependencies below
• Rebuild your bsp.
• Rebuild your application.

Patch Link: TCPIPUpdates_63

Dependencies

This patch also requires the installation of the following patch(es):

ACEUpdates_63

ApiReference_63

BSPUpdates_63

ThreadXUpdates_63