TCPIP Stack Updates – NET+OS 7.2

Last Updated: 01/13/11 Fix Count: 7

 
Title
DHCP hangs when NAK received from server
 
Case: 37023
 
Date Fixed: 01/13/11
 
Description
Client stops sending DHCP Discovers after getting a NAK response from DHCP server.
 
Solution
Fixed issue caused by freeing wrong buffer pointer. Also found that the naIamRelease routine would exit in error when called by treck_dhcp_notify after receiving a DHCP NAK.  Changed naIamRelease so that it will restart the negotiation process when this event occurs.

 
Title
Getsockopt with SO_TYPE fails with error 109
 
Case: 34877
 
Date Fixed: 08/25/10
 
Description
getsockopt with type SO_TYPE is supposed to give you an indication of whether a socket is a tcp-related (stream) or a udp-related (DGRAM) socket. This was not working.
 
Solution
Added getsockopt SO_TYPE.

 
Title
DNSGetServer returning wrong values
 
Case: 25658
 
Date Fixed: 02/22/08
 
Description
DNSGetServers() is not properly reporting the address of available DNS servers.
 
Solution
DNSGetServer now returns the IP addresses of the DNS servers.

 
Title
sockatmark function not supported
 
Case: 25097
 
Date Fixed: 01/08/08
 
Description

Compile errors are generated when trying to use the sockatmark function.

 
Solution
Added support for sockatmark().

 
Title
Incompatibility with SonicWall DHCP corrected
 
Case: 24354
 
Date Fixed: 12/27/07
 
Description

There is a problem negotiating an address with a SonicWall DHCP server.

 
Solution
Fixed bug where overload option flag is not cleared after processing the overload fields.

Title

Subnet broadcast issue

Case: 24978

Date Fixed: 11/27/07

Description

Under certain conditions, subnet broadcasts packets do not leave the device, but sendto() may indicate that packets were sent.

Background

An all network broadcast IP address is of the form 255.255.255.255 or in hex FF.FF.FF.FF. An IP subnet broadcast address might be of the form 10.255.255.255 or 10.52.255.255. This issue refers to IP broadcast addresses of the form of the later two addresses mentioned above.

If a device’s gateway address is set to an invalid address, either 0.0.0.0 or a non-existent gateway address, the RFC’s associated with subnets indicate that the subnet-related broadcast packets should still be successfully transmitted from the device. In NET+OS V7.x, due to a bug in the TCP/IP stack library, subnet broadcast packets were not being transmitted. Further, the sendto command was returning information to the caller, indicating that the packets were successfully being transmitted. A user using a network analyzer package would have seen that the packets were not being successfully transmitted. The problem was that under certain conditions of gateway address and subnet mask combinations, the stack would not view the subnet broadcast address as a broadcast address, but view it as a unicast address. Because of this mistake, the IP stack would attempt to “ARP” the nonexistent gateway address. Since no machine would respond to the ARP request (because it was for a nonexistent IP address), the IP stack could not send out the packets..

Solution

The corrected behavior is to send the packet out, without ARPing for the gateway (broadcast behavior vs. unicast behavior).

Title

naArpFlush added

Case: 23632

Date Fixed: 11/19/07

Description

There was no method to clear the ARP cache.

Solution

Added functionality to clear ARP cache and ARP API header. See the API Reference for details.

Files: netos\h\naarpapi.h

netos\lib\arm7\32b\ghs\libtcpip.a

netos\lib\arm7\32b\gnu\libtcpip.a

netos\lib\arm9\32b\ghs\libtcpip.a

netos\lib\arm9\32b\gnu\libtcpip.a

netos\lib\arm7\32b\ghs\libtcpip_no_ipsec.a

netos\lib\arm7\32b\gnu\libtcpip_no_ipsec.a

netos\lib\arm9\32b\ghs\libtcpip_no_ipsec.a

netos\lib\arm9\32b\gnu\libtcpip_no_ipsec.a

netos\lib\arm7\32b\ghs\libdnsclnt.a

netos\lib\arm7\32b\gnu\libdnsclnt.a

netos\lib\arm9\32b\ghs\libdnsclnt.a

netos\lib\arm9\32b\gnu\libdnsclnt.a

netos\src\examples\nadnsclnt\root.c

Special Instructions

• Unzip the patch(es) to the root of your NET+OS installation, for example C:\netos72\.
• Be sure to install any patches listed under Dependencies below
• Rebuild your BSP.
1. GNU Users Only -From the root of your NET+OS installation execute - make PLATFORM=<your platform> clobber
2. GNU Users Only -From the root of your NET+OS installation execute - make PLATFORM=<your platform> clean all
3. GHS Users – Clean and rebuild your BSP
• Rebuild your application.

Patch Link: TCPIPUpdates_72

Dependencies

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

ApiReference_72