Core locked checking when using the SNMP netconn implementation

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Core locked checking when using the SNMP netconn implementation

Harrold Spier
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Dirk Ziegelmeier-2
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Harrold Spier
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.png

Best regards,
Harrold


On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Dirk Ziegelmeier-2
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 * [hidden email] * http://www.ziegelmeier.net


On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <[hidden email]> 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.png

Best regards,
Harrold


On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Harrold Spier
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.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 <[hidden email]> 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 * [hidden email] * http://www.ziegelmeier.net


On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <[hidden email]> 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.png

Best regards,
Harrold


On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Dirk Ziegelmeier-2
The last two options will both work. Read the lwip threading hints in the docs!

Harrold Spier <[hidden email]> 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.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 <[hidden email]> 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 * [hidden email] * http://www.ziegelmeier.net


On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <[hidden email]> 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.png

Best regards,
Harrold


On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Harrold Spier

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 <[hidden email]> wrote:
The last two options will both work. Read the lwip threading hints in the docs!

Harrold Spier <[hidden email]> 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.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 <[hidden email]> 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 * [hidden email] * http://www.ziegelmeier.net


On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <[hidden email]> 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.png

Best regards,
Harrold


On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Dirk Ziegelmeier-2
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 <[hidden email]> 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 <[hidden email]> wrote:
The last two options will both work. Read the lwip threading hints in the docs!

Harrold Spier <[hidden email]> 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.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 <[hidden email]> 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 * [hidden email] * http://www.ziegelmeier.net


On Thu, Mar 12, 2020 at 11:34 AM Harrold Spier <[hidden email]> 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.png

Best regards,
Harrold


On Thu, Mar 12, 2020 at 11:16 AM Dirk Ziegelmeier <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

goldsimon@gmx.de
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 fact, I think SNMP is most often
used with the callback API, so bug reports in this area are welcome!

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

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 when using the SNMP netconn API.
But maybe I oversee something.

The benefits of using the netconn API for SNMP is the possibility to run the SNMP thread on a much lower priority than the tcpip thread.

I assume the issue can be solved by replacing all calls to LWIP_ASSERT_CORE_LOCKED() in the SNMP app by a call to LWIP_ASSERT_SNMP_LOCKED() and define LWIP_ASSERT_SNMP_LOCKED as LWIP_ASSERT_CORE_LOCKED only if SNMP_USE_RAW == 1.

Best regards,
Harrold


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

goldsimon@gmx.de
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 when using the
> SNMP netconn API.
> But maybe I oversee something.
>
> The benefits of using the netconn API for SNMP is the possibility to run
> the SNMP thread on a much lower priority than the tcpip thread.
>
> I assume the issue can be solved by replacing all calls to
> LWIP_ASSERT_CORE_LOCKED() in the SNMP app by a call to
> LWIP_ASSERT_SNMP_LOCKED() and define LWIP_ASSERT_SNMP_LOCKED as
> LWIP_ASSERT_CORE_LOCKED only if SNMP_USE_RAW == 1.

Yes, that might work. We'd lose the check for the netconn case, but
better than an invalid error that halts the stack...

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Core locked checking when using the SNMP netconn implementation

Harrold Spier

Thanks, I will post a bug report and upload a patch file.

Regards,
Harrold

On Fri, Mar 13, 2020 at 8:26 PM [hidden email] <[hidden email]> 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 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 something.
>
> The benefits of using the netconn API for SNMP is the possibility to run
> the SNMP thread on a much lower priority than the tcpip thread.
>
> I assume the issue can be solved by replacing all calls to
> LWIP_ASSERT_CORE_LOCKED() in the SNMP app by a call to
> LWIP_ASSERT_SNMP_LOCKED() and define LWIP_ASSERT_SNMP_LOCKED as
> LWIP_ASSERT_CORE_LOCKED only if SNMP_USE_RAW == 1.

Yes, that might work. We'd lose the check for the netconn case, but
better than an invalid error that halts the stack...

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users