Harrold Spier <address@hidden> 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.3This 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 <address@hidden> 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;_______________________________________________On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <address@hidden> 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.Best regards,Harrold_______________________________________________On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <address@hidden> 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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
