NetXMS Support Forum

Hi,

sorry, didn't get to this issue yet. I assume that sibnet 10.1.0.0/16 was already exist when server create another one?

Could you please also provide output of command

nxadm -c "show index subnet" | grep 10.1

?

Best regards,
Victor

Я посмотрю сегодня/завтра проблему с кириллицей. Похоже на какой-то баг при чтении из базы. При сборке --enable-unicode был указан?

Да, это можно сделать в драйвере устройства. Сервер выбрал какой-то драйвер (видно на закладке Overview) или остался GENERIC?

Не совсем понял, что где поменять?

So, it seems that disconnects cause those delays. Probably we need to add some sort of keepalive on XMPP connection to prevent it from timing out. I'll check that.

Best regards,
Victor

Hi,

please set debug level to 6, run configuration poll, and show all log records related to that router.

Best regards,
Victor

Hi,

looks like MSL uses "public" as community ignoring configuration settings. Quick search found description of similar issue: https://thwack.solarwinds.com/thread/33561. If this is the case then it's a bug in MSL firmware.

Best regards,
Victor

Hi,

configuration seems correct. Please filter server log by "SMTP:" messages and post them here. On debug level 8 server should log entire SMTP conversation.

Best regards,
Victor

Second nxmc is internal application path where it should be redirected automatically from /nxmc. I'll try to reproduce this myself and check.

Best regards,
Victor

Hi,

tcp/4700: server -> agent
tcp/4701: client (gui or integration tools) -> server
tcp/4747: mobile agent -> server

Best regards,
Victor

Can you communicate with the library using command line tool (nxsnmpwalk or nxsnmpget)? For example

nxsnmpwalk -v2c -c your_community ip_address .1.3.6.1.2.1.1

also try community "public".

Best regards,
Victor

Did configuration poll detect MSL node as SNMP node? If yes, it could be some other server trying to communicate with MSL over SNMP, and MSL just sending SNMP authentication failure traps to NetXMS server (because it is configured so).

Best regards,
Victor

Добавил feature request про SAPI в новой консоли: https://dev.raden.solutions/issues/1271 (чтобы не забылось).

One (or two) issues here. First of all, ensure that you are using "SNMP walk - OIDs" as discovery method (because you want instance to be interface index). Alternatively, you can change base OID to return interfaces indexes as values.
And most important, you replace original instance value with interface operational state:


return %(true, oper, dec . " - " . nam);


effectively reducing all instances into few. Correct will be to keep interface index as instance:\


return %(true, $1, dec . " - " . nam);


Best regards,
Victor

Hi,

it's definitely a network issue. One possible cause could be MTU mismatch and/or disabled fragmentation somewhere along the route. This could explain why small packets (connection setup and ack) pass through while larger packets with data cannot.

Best regards,
Victor