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 <harrold.sp...@gmail.com> schrieb am Do., 12. März 2020,
14:38:
>
> 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 do the core lock itself.
> This would explain it does not work.
>
> Regards,
> Harrold
>
>
> On Thu, Mar 12, 2020 at 2:07 PM Dirk Ziegelmeier <d...@ziegelmeier.net>
> wrote:
>
>> The last two options will both work. Read the lwip threading hints in the
>> docs!
>>
>> Harrold Spier <harrold.sp...@gmail.com> 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:
>>>
>>> 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
>>
>> _______________________________________________
>> 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
