Advance Web = Server fixes =96 NETOS 6

From: Subject: =?Windows-1252?Q?Advance_Web_Server_fixes_=96_NETOS_6?= Date: Wed, 5 Jan 2011 14:11:40 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://ftp1.digi.com/support/patches/SNMPUpdates_63.htm X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Advance Web = Server fixes =96 NETOS 6

SNMP Updates =96 NET+OS = 6.3

Last Updated: 12/30/10 = Fix Count: 16

Title

snmp get-bulk can =
crash V6.3 stack

Case: = 37153

Date = fixed:=20 12/30/10

Description

Denial of =
service possible in current release.

Solution

Corrected defective that caused = SNMP to run=20 out or resources during a get-bulk with max repetitions of 10000 causing = a=20 denial of service.

Title

Increased allowable length of =
community name to 32 =
characters

Case: = 1272924

Date = fixed:=20 06/11/09

Description

Customers requested that a community =
name of up to 32 bytes be allowed in traps. Additionally, when trap send =
requests were fielded, logic error in the traps processing code could =
have caused a buffer overrun as the length of the community string was =
not being checked. Also the root.c file was =
sending (be default) traps to the port on which the UDP request was =
received as opposed to (by default) sending the trap to UDP port 162 =
(though this is configurable by the =
user).

Solution

The internal=20 buffer into which the community (or user) was stored for internal traps=20 processing was 24 bytes in length. There were no restrictions placed on = the size=20 of community names passed into naSnmpSendTrap(), = thus there was=20 the potential for a buffer overrun and memory corruption, at worst, or = community=20 name truncation, at best. The length of the community name is now = checked and if=20 it is greater than the max length the error=20 NA_STATUS_INVALID_PARAMETER is returned. =

In root.c, has been changed to (by default) send the = user=20 generated traps to UDP port 162 on the machine that sent the UDP = request. Root.c is shipped as source code allowing the user = to=20 configure both the IP address and the port at that IP address to which = the traps=20 are sent.

Title

Community name missing and PDU type =
incorrect in authentication =
traps

Case: = 27937

Date = fixed:=20 09/08/08

Description

Authentication traps were missing =
the community name and were incorrectly set at SNMPv2 trap =
(7).

Solution

Authentication=20 traps now contain the community name and the PDU type is correctly set = to V1 PDU=20 (4).

Title

SNMP hangs during MIB =
walk

Case: = 26746

Date = fixed:=20 07/30/08

Description

The problem was that the code would =
get itself into an infinite loop where it was always trying to find the =
next item in the vacmSecurityGroup table, =
but the functions to get the next item would always return the current =
one. It was determined that the vacmSecurityToGroupTableLocalCompare function was =
not handling the case where two group tables were the same except for =
the vacmSecurityGroup =
field.

Solution

Modified=20 code that handles the compare.

Title

Support for virtual interfaces =

Case: = none

Date = fixed:=20 07/03/08

Description

Added API to add virtual SNMP=20 interfaces.

Solution

Added naSnmpSetSysObjectID, naSnmpSetSysDescr, naSnmpSetSysServices, naSnmpGetIfDescr, and naSnmpSetIfDescr.

&nbs= p; = ; = =20

Title

Memory leak =

Case: = 26746

Date = fixed:=20 07/01/08

Description

When sending traps, a memory leak =
could cause traps not to be sent.

Solution

Buffers=20 were being saved for reuse and never cleaned up.

Title

Data abort when sending enterprise =
traps

Case: = 26746

Date = fixed:=20 06/16/08

Description

When sending enterprise traps, if =
the specific trap type is one, you get a data =
abort.

Solution

The=20 first two var binds in a trap are the sysUpTimeOid and snmpTrapOID. snmpSendTrap was setting up the snmpTrapOID for a generic trap, and then = overwriting the OID=20 in it if the trap was actually for a specific trap. In this case, snmpTrapOID is set to an enterprise OID. However, when it did this, it = didn't=20 free memory it allocated when it initially created snmpTrapOid for the generic trap. This caused problems later = when the SNMP=20 agent later tried to free the enterprise OID, which was not malloced. =20 Changed the code to free the buffer and update the flags = appropriately to=20 indicate the buffer had been freed.

Title

V2c Traps =
malformed

Case: = 21020

Date = fixed:=20 02/28/07

Description

Multiple V2c traps are grouped =
together in one packet rather than sent as separate =
traps.

Solution

Fixed =
problem that was causing the trapVarList to =
be initialized improperly when multiple =
traps were queued.

Title

Trap type selection =
feature

Case: = internal

Date = fixed:=20 01/03/07

Description

Currently Net+OS sends a trap as V3 if it's authenticated =
and as V1 if it's not.

Solution

Two new functions have been added to allow manually = switching=20 trap types:

int SNMPSetTrapVersion(int =
version);

int SNMPGetTrapVersion(void); =

version would be1 for V1 traps, 2 for V2c =
traps, and 3 for SNMPv3 traps. This now enables sending plain V3 traps =
as well as V2c traps.

See ApiReference for details.

Title

V3 Traps =
malformed

Case: = internal

Date = fixed:=20 12/20/06

Description

The original code did not set the =
PDU type of the message correctly, and did not encrypt messages with the =
correct encryption key.

The =
effect was to cause SNMP version 3 traps sent by the agent to be =
malformed.

Solution

Updated libraries now properly set the PDU type of the = message,=20 and use the correct encryption key.

Title

sysUpTiime rolling over =
prematurely

Case: = 1220419

Date = fixed:=20 11/10/06

Description

When running a MIB browser (snmp) such=20 as MG-Soft, the sysUpTime value displayed = would=20 increase up to approximately 49.6 days plus some number of hours, = minutes and=20 seconds. At that point, the sysUpTime value = would roll=20 over to 00 days, 3 hours, some number of minutes and seconds. If you = looked at=20 the communications between the NET+OS snmp = agent and a=20 MIB browser, the sysUpTime number would get = to=20 something like FF712345 and then "roll over" to something like 15436345 = (these=20 are not meant to be exact numbers just close = approximations).

Solution

There were two problems causing this problem. First = the internal=20 value that is used to accumulate 1/100 second timer ticks that is then = used as=20 the sysUpTime value was mistakenly being = accumulated=20 at 10 times the rate actually needed. Secondly, some code in the ASN1 = area of=20 our code was mistakenly removing the 2 high order bytes from numbers = greater=20 having 9 or more consecutive bits in the high order bytes of the value. = These=20 two problems have been addressed.

Title

Tabular data missing from ipNetToMediaTable

Case: = 1219675

Date = Fixed: 11/02/06

Description

When performing a MIB walk, get or =
get next snmp mib browser action, =

against the MIB-II ip =
portion of a NET+OS SNMP tree, the ipNetToMediaTable

(OID =
1.3.6.1.2.1.4.22) only displays the indicies. The actual tabular =
data

(MAC address, IP Address and dynamic/static =
status) are not displayed.

Solution

A coding error in the code that =
extracts fields from the fusion stack

and makes this data available to the ASN1 processing code =
was dropping all

tabular fields except the index. This problem has been =
identified and corrected.

Title

ipForwarding can not be =
set from MIB browser

Case:  =
1216228

Date Fixed:  =
08/22/06

Description

Changing the =
ipForwarding OID from a MIB browser had no =
effect on the stack.

Solution

Fixed problem where MIB setting was not being passed = to the=20 stack to allow change.

Title

SNMP v3 traps not working

Case: = 1214064

Date = Fixed: 07/13/06

Description

SNMP v3 traps and especially encrypted v3 traps were = not being=20 sent out correctly.

Solution
The=20 macro constant SNMP_TRAP_VERSION was not being set for V3 traps, and a buffer was not being properly = allocated for an=20 encryption key. Both = issues=20 resolved.

Title

v1/v2 traps being = sent out=20 twice

Case: 18803

Date = Fixed: 06/13/06

Description

In certain cases, v1/v2 traps would be sent out = twice

Solution

Corrected issue with logic that detected the trap had = previously=20 been sent.

Title

Customizable ports for SNMP and = traps

Case: = internal

Date = Fixed: 11/28/05

Description

SNMP ports were previously hard coded to 161 and = 162.

Solution

Changed to use user provided port number (through = naSnmpSetPortNumber,
naSnmpSetTrapPortNumber). Default will be 161 = (snmp port) and 162 (trap
port).

Files: = netos\bin\mibman.jar

&nbs= p; =20 netos\h\nastatus.h

&nbs= p; =20 netos\h\snmpapi.h

&nbs= p; =20 netos\h\snmp\nasnmpvirtif.h

&nbs= p; =20 netos\h\snmp\snmp.h

&nbs= p; =20 netos\h\snmp\snmpv3api.h

&nbs= p; =20 netos\h\snmp\osdefs.h

&nbs= p; =20 netos\lib\arm7\32b\ghs\libsnmp.a

&nbs= p; =20 netos\lib\arm7\32b\gnu\libsnmp.a

&nbs= p; =20 netos\lib\arm9\32b\ghs\libsnmp.a

&nbs= p; =20 netos\lib\arm9\32b\gnu\libsnmp.a

&nbs= p; =20 netos\lib\arm7\32b\ghs\libsnmpv3.a

&nbs= p; =20 netos\lib\arm7\32b\gnu\libsnmpv3.a

&nbs= p; =20 netos\lib\arm9\32b\ghs\libsnmpv3.a

&nbs= p; =20 netos\lib\arm9\32b\gnu\libsnmpv3.a

&nbs= p; =20 netos\lib\arm7\32b\ghs\libmanMib.a

&nbs= p; =20 netos\lib\arm7\32b\gnu\libmanMib.a

&nbs= p; =20 netos\lib\arm9\32b\ghs\libmanMib.a

&nbs= p; =20 netos\lib\arm9\32b\gnu\libmanMib.a

&nbs= p; =20 netos\src\examples\nasnmpv3\cli.c

&nbs= p; =20 netos\src\examples\nasnmpv3\appconf.h

&nbs= p; =20 netos\src\snmpcust\Makefile

&nbs= p; =20 netos\src\snmpcust\Snmp_api.c

&nbs= p; =20 netos\src\examples\nasnmpd\root.c

Special=20 Instructions

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

Patch = Link: SNMPUpdate= s_63

Dependencies

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

TCPIPUpda= tes_63

ACEUpdates_= 63

ApiRefe= rence_63