I have two questions to ask:
A previous issue (https://www.netxms.org/forum/general-support/help-h3c-port-security-policy-causes-the-switch-to-fail-to-learn-the-interface/msg32436/#msg32436) seems to have reappeared in the latest version. When a port security policy is configured on a switch interface, the MAC address status on the switch shows as secure instead of learned, and NetXMS appears to ignore MAC addresses in the secure state.
The AI model cannot execute tool calls, as shown in the screenshot. My configuration in netxmsd.conf is as follows:
plaintext
Module=aitools

[AI/Provider/qwen3]
Type = openai
URL = http://IP/v1/chat/completions
Model = qwen3.6-35b-a3b
Token = xxx
ContextSize = 32000
Timeout = 900
Slots = default

[AI]
DefaultProvider = qwen3
Looking forward to your reply. Thank you very much!

Hi,

FDB related code was not changed, it still handles type 6 (secure) in a same way as type 3. Could you please show screenshot of "FDB" page for problematic switch, output of server debug command "show fdb <id>" (replace <id> with actual switch object ID), and result of SNMP walk on 1.3.6.1.2.1.17.7.1.2.2.1?

Best regards,
Victor

Thank you very much for your reply.

Is there really only one row in SNMP walk result? If yes, try to do separate walks on 1.3.6.1.2.1.17.7.1.2.2.1.3 and 1.3.6.1.2.1.17.7.1.2.2.1.2 - there should be more entries. Also try walk on 1.3.6.1.2.1.17.4.3.1.3

Regarding AI invocation - I've tried to check qwen3.6-35b-a3b model via OpenRouter, but looks like they don't have providers with tool calling support. From your screenshot it seems that tool call is not recognized and interpreted as part of an answer. Are you sure that runner or service you are using actually follows Open AI API?

The SNMP walk result for 1.3.6.1.2.1.17.7.1.2.2.1 indeed returns only one entry, which is rather unusual. Many H3C switches show exactly the same result, whereas this used to work normally before.The SNMP traversal results for other OIDs are listed below. Thanks for your help.

Quote from: Victor Kirhenshtein on May 04, 2026, 01:58:42 PMRegarding AI invocation - I've tried to check qwen3.6-35b-a3b model via OpenRouter, but looks like they don't have providers with tool calling support. From your screenshot it seems that tool call is not recognized and interpreted as part of an answer. Are you sure that runner or service you are using actually follows Open AI API?

Thanks for your guidance. I'll check with my colleague in charge of AI large models.

Quote from: Victor Kirhenshtein on May 04, 2026, 01:53:50 PMIs there really only one row in SNMP walk result? If yes, try to do separate walks on 1.3.6.1.2.1.17.7.1.2.2.1.3 and 1.3.6.1.2.1.17.7.1.2.2.1.2 - there should be more entries. Also try walk on 1.3.6.1.2.1.17.4.3.1.3

This issue does not occur in version 5.X. Could you please assist us with the diagnosis and troubleshooting?

It looks like regression in SNMP library. Could you please try same SNMP walk from command line using nxsnmpwalk tool? Ideally do walk on same device using nxsnmpwalk from v5 as well.
If there will be discrepancies between v5 and v6, send me packet capture from v6 walk if possible.

I tested the command nxsnmpwalk -v 2c -c stonewell2000 10.61.43.131 1.3.6.1.2.1.17.7.1.2.2.1 separately on version 5.0.8 and 6.1.1, and there are obvious discrepancies between the two results. Only version 5.0.8 can retrieve the complete data normally.The packet capture logs of v6.1.1 have been uploaded as an attachment. Thank you so much!

Problem is with device processing SNMP GET NEXT requests incorrectly; standard requires that GET NEXT should return OID that is strictly higher than previous one; however, device returns entries in FDB in random order:

1.3.6.1.2.1.17.7.1.2.2.1.2.67.180.5.93.216.211.69 [INTEGER]: 15
1.3.6.1.2.1.17.7.1.2.2.1.2.70.28.131.65.44.65.209 [INTEGER]: 53
1.3.6.1.2.1.17.7.1.2.2.1.2.64.180.5.93.216.211.179 [INTEGER]: 53

third entry actually less than first one.

In version 6 we did some optimizations to SNMP walk, including stricter checks for loop detection, this is why walk on H3C start failing. In next patch release we will relax it to handle buggy devices like this one.

That's wonderful! I'm looking forward to the next version update, and thank you so much for your tremendous help!