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_notification_or_inform_generic() checks for it.
So I'm a little bit confused :-|
Assume I want to generate a coldstart trap at the start of my application,
what would be the correct way to do so, using the netconn implementation?
- Call snmp_coldstart_trap() directly from any thread you like.
- Call snmp_coldstart_trap() only via the tcpip_callback() function.
- Call snmp_coldstart_trap() after calling LOCK_TCPIP_CORE() and before
UNLOCK_TCPIP_CORE().
Best regards,
Harrold
On Thu, Mar 12, 2020 at 11:48 AM Dirk Ziegelmeier <d...@ziegelmeier.net>
wrote:
> 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;
> var_len = (const s16_t *)sysdescr_len;
> break;
> case 2: { /* sysObjectID */
> #if SNMP_USE_NETCONN && LWIP_TCPIP_CORE_LOCKING
> LOCK_TCPIP_CORE();
> #endif
> const struct snmp_obj_id *dev_enterprise_oid =
> snmp_get_device_enterprise_oid();
> #if SNMP_USE_NETCONN && LWIP_TCPIP_CORE_LOCKING
> UNLOCK_TCPIP_CORE();
> #endif
> MEMCPY(value, dev_enterprise_oid->id, dev_enterprise_oid->len *
> sizeof(u32_t));
> return dev_enterprise_oid->len * sizeof(u32_t);
> }
> case 3: /* sysUpTime */
> MIB2_COPY_SYSUPTIME_TO((u32_t *)value);
> return sizeof(u32_t);
> case 4: /* sysContact */
> var = syscontact;
> var_len = (const s16_t *)syscontact_len;
> break;
> case 5: /* sysName */
> var = sysname;
> var_len = (const s16_t *)sysname_len;
>
> Ciao
> Dirk
>
> --
> Dirk Ziegelmeier * d...@ziegelmeier.net * http://www.ziegelmeier.net
>
>
> On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <harrold.sp...@gmail.com>
> wrote:
>
>> 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, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <d...@ziegelmeier.net>
>> wrote:
>>
>>> 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.
>>>
>>> Ciao
>>> Dirk
>>>
>>>
>>> On Thu, Mar 12, 2020 at 10:57 AM Harrold Spier <harrold.sp...@gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>> So why does a function like snmp_set_device_enterprise_oid() does a
>>>> core check (LWIP_ASSERT_CORE_LOCKED())?
>>>> I assume this would only be valid for the snmp raw implementation.
>>>>
>>>> Or do I miss something?
>>>>
>>>> Best regards,
>>>> Harrold
>>>> _______________________________________________
>>>> lwip-users mailing list
>>>> lwip-users@nongnu.org
>>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>>
>>> _______________________________________________
>>> lwip-users mailing list
>>> lwip-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>> _______________________________________________
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
