Thanks, I will post a bug report and upload a patch file.
Regards,
Harrold
On Fri, Mar 13, 2020 at 8:26 PM goldsi...@gmx.de wrote:
> Am 13.03.2020 um 09:12 schrieb Harrold Spier:
> >
> > I wonder whether there is something wrong with the current SNMP app
> > implementation.
> > As long as all S
Am 13.03.2020 um 09:12 schrieb Harrold Spier:
>
> I wonder whether there is something wrong with the current SNMP app
> implementation.
> As long as all SNMP API functions are called by the same (SNMP) thread,
> there should be no problem.
> In my opinion, only checking for core locked is not valid
I wonder whether there is something wrong with the current SNMP app
implementation.
As long as all SNMP API functions are called by the same (SNMP) thread,
there should be no problem.
In my opinion, only checking for core locked is not valid when using the
SNMP netconn API.
But maybe I oversee some
Dirk Ziegelmeier wrote:
> Hm, you again found a bug. In this case I don't even have quick fix...
> We (the company I work for) never used traps so they are basically untested.
I don't think traps are untested. But the combination of traps and using SNMP
via that netconn API might be untested. In f
Hm, you again found a bug. In this case I don't even have quick fix... We
(the company I work for) never used traps so they are basically untested.
Sorry
Dirk
Harrold Spier schrieb am Do., 12. März 2020,
14:38:
>
> I tried, but unfortunately the last two options both did not work :-(
>
> I see
I tried, but unfortunately the last two options both did not work :-(
I see function snmp_coldstart_trap() at the end is calling netconn_sendto()
to send the packet.
So I wonder whether it allowed anyway to call the netconn_sendto()
functions in the tcpip thread?
The function will probably try to
The last two options will both work. Read the lwip threading hints in the
docs!
Harrold Spier schrieb am Do., 12. März 2020,
13:42:
> Hi Dirk,
>
> Yes, this fixes the reported problem. But there is probably more.
> Executing snmpwalk using a wrong community may generate an authentication
> trap:
Hi Dirk,
Yes, this fixes the reported problem. But there is probably more. Executing
snmpwalk using a wrong community may generate an authentication trap:
snmpwalk -v1 -c wrongcommunity 192.168.28.2 1.3
[image: image.png]
This will also generate the core lock assert,
because snmp_send_trap_or_
you found a bug :-)
Try this, and please create a bug entry:
static s16_t
system_get_value(const struct snmp_scalar_array_node_def *node, void *value)
{
const u8_t *var = NULL;
const s16_t *var_len;
u16_t result;
switch (node->oid) {
case 1: /* sysDescr */
var = sysdescr;
Hi Dirk,
Thanks for your quick response.
Function snmp_set_device_enterprise_oid() is called by my application,
but snmp_get_device_enterprise_oid()
for example is called (indirectly) by snmp_receive(), which runs in the
snmp_netconn thread.
[image: image.png]
Best regards,
Harrold
On Thu, Ma
The netconn thread receives SNMP packets and processes them in the SNMP
stack, nothing else. It never calls snmp_set_device_enterprise_oid(). Put a
breakpoint in calls snmp_set_device_enterprise_oid() and check the call
stack. I guess it's your application that makes this call from the wrong
thread
Hi,
After enabling core locked check (LWIP_ASSERT_CORE_LOCKED
and LWIP_MARK_TCPIP_THREAD), I got a lot of asserts in SNMP functions.
I use the SNMP netconn implementation (SNMP_USE_NETCONN = 1), so I assume
all SNMP functions should be called by the snmp_netconn thread, not by
the tcpip_thread.
S
12 matches
Mail list logo
