µTasker Forum

µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: mcosta on February 25, 2009, 10:48:49 PM

Title: MCF5223X SP9 SNMP
Post by: mcosta on February 25, 2009, 10:48:49 PM
Hi Mark,

I prepare a new directory with all SP´s, from SP1 to SP9.
I tried to use the SNMP agent (I see that you did a lot of work on it),
but I could´t get it to work.

Everytime that I issue a snmpwalk command the uTasker get stucked on the
SNMP_COMMUNITY_CHECK and the snmpwalk command returns with a timeout.

Is there anything, besides SUPPORT_SNMP, that I have to check ?

Regards,
Marcelo Costa
Title: Re: MCF5223X SP9 SNMP
Post by: mark on February 25, 2009, 10:55:53 PM
Hi Marcelo

When working with service packs it is only necessary to install the latest one (on top of the original one).

The SNMP is only demonstrating a few features of SNMP and is thus not a complete module. See also the following:
http://www.utasker.com/forum/index.php?topic=246.msg939#msg939

As noted there there has been a kind contribution from Andriy K. which is available on demand which contains a more or less complete SNMPV1 solution - this is however not supported in the forum but Andriy invites feedback. please contact me directly if you would like to receive the SNMPV1 module.

Regards

Mark
Title: Re: MCF5223X SP9 SNMP
Post by: mcosta on February 25, 2009, 11:02:13 PM
Mark,

you sent me snmp.c and another file sometime ago. It is the same ones or there were any improvement?

Regards,
Marcelo Costa
Title: Re: MCF5223X SP9 SNMP
Post by: mcosta on February 26, 2009, 12:04:06 PM
Hi Mark,

Using your snmp code, when I issue a snmpget command:


snmpget -c public -v 1 <ip> 1.3.6.1.2.1.1.1

I get a "First-chance exception in uTaskerV1-3.exe: 0xC0000005: Access Violation."
at
   
if (ptrUDP->ucState != UDP_STATE_OPENED ) return SOCKET_CLOSED;
(udp.c at fnSendUDP function )


Does this error happened with you too ?

Regards,

Marcelo Costa
Title: Re: MCF5223X SP9 SNMP
Post by: mark on February 26, 2009, 05:53:52 PM
Hi Marcelo


The exception that are receiving is probably because the pointer ptrUDP is a zero.

In the transmission function the following are relevant:
    UDP_TAB *ptrUDP = tUDP;
..
    ptrUDP += SocketHandle;
..
    if (ptrUDP->ucState != UDP_STATE_OPENED ) return SOCKET_CLOSED;

tUDP is a local pointer to the UDP table:
static UDP_TAB *tUDP = 0;
which is initialised the first time that a UDP socket is requested (fnGetUDP_socket()) :


    if (!tUDP) {                                                         // automatically get heap space on first call
        tUDP = (UDP_TAB*)uMalloc(sizeof(UDP_TAB)*UDP_SOCKETS);           // get UDP table space (our malloc zeroes it)
    }

This doesn't seem to be a specific problem with the SNMP part but rather with the fact that its socket has not been initialised (or not successfully).

Check that fnGetUDP_socket() is being called before an SNMP activity takes place. Check also that it has obtained the memory it needs to work. Verify then that fnSendUDP() is being called with a valid socket handle (it must not be negative - meaning not initialised).

Good luck

regards

Mark

Title: Re: MCF5223X SP9 SNMP
Post by: mcosta on February 28, 2009, 09:03:01 PM
Hi Mark,

I double checked the snmp.c and udp.c functions and the SocketNr is not negative.
As I am not using any other udp subsystem, the value of SocketNr is 0 (zero) and it is OK.
the problem is the null ptrUDP.

I trace the problem to the fnFreeBuffer(Ethernet_handle, cEthernetBuffer); @ Ethernet.c.
After all SNMP/UDP jobs, it will call this function and an exception occours.

Do you have an idea of the problem?

Regards,
Marcelo Costa
Title: Re: MCF5223X SP9 SNMP
Post by: mark on February 28, 2009, 09:54:33 PM
Hi Marcelo

The function fnFreeBuffer(Ethernet_handle, cEthernetBuffer); is called to free the present Ethernet input buffer and so is called after handling each received Ethernet frame, irrespective of the protocol.

It seems you have identified that ptrUDP is really a null pointer. This can be due to one of three reasons:

1) It was never set due to no sockets being installed (set a break point where the memory is allocated and see whether it arrives there).

2) It tried to get memory for the UDP socket but couldn't since there was no more memory on the heap. Try with same break point and see whether the uMalloc() returns zero. If it does, verify the amount of heap reserved (OUR_HEAP_SIZE in config.h) and see whether it can be increased (and what is using heap in the system to cause this to fail).

3) The pointer was originally correctly set but later gets overwritten (to zero). This is a bit more difficult to solve since it could be overwritten by any code (making a mistake with writing to memory).

regards

Mark