Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Victor Kirhenshtein

#961
Hi,

I have identified the issue. Problem is in how Fortigate builds index for ipAddressTable. For example, for address 192.168.188.1 OID in ipAddressTable looks like this:

.1.3.6.1.2.1.4.34.1.3.1.192.168.188.1.33

where .1.3.6.1.2.1.4.34.1.3 is base OID, 1 is address type (ipv4 in that case), 192.168.188.1 is IP address, and 33 is interface index (which is also strange because IP MIB does not specify interface index here). But the problem is that generic driver expects IP address prefixed with length, like in this example (taken from H3C switch):

.1.3.6.1.2.1.4.34.1.3.2.16.32.1.4.112.223.51.0.1.0.0.0.0.0.0.0.1

Here 2 is address type (ipv6), 16 is address length, and 32.1.4.112.223.51.0.1.0.0.0.0.0.0.0.1 is an address.

So when driver reads interface list from Fortigate it gets correct addresses from ipAddrTable and then picks incorrect addresses from ipAddressTable (168.188.1.33 in this example, shifted by one byte because server skips the one expected to hold address length).

I don't know what format is correct and what is not. Most devices that I have encountered does not support ipAddressTable at all and those that do returns addresses with length prefix. If somebody has better knowledge on this subject - please comment. For now I have added additional checks when reading ipAddressTable for correct value in length field - this should fix issue for Fortigate devices. It will be included into upcoming 3.3 release.

Best regards,
Victor
#962
Just checked - there was a fix in DB init script between 3.2.400 and 3.2.472 for exactly this issue. Completely forgot about it.

Best regards,
Victor
#963
It could be bug in upgrade procedure. This is new access right introduced in version 3.2, so if you have upgraded from older version it may not have been added by database upgrade tool.

Best regards,
Victor
#964
Hi,

make sure that your user has system access right "manage web service definitions".

Best regards,
Victor
#965
It informs server that primary communication address does not belongs to the node itself but only used to communicate with the node somehow. So it is not added to internal indexes, search by this IP address will not return nodes where it is configured as "remote management address", it will not affect topology for such node.

Best regards,
Victor
#966
General Support / Re: Bug: Image libary
April 14, 2020, 11:12:44 PM
Hi,

just fixed, new console will be published soon.

Best regards,
Victor
#967
General Support / Re: World map loading time
April 14, 2020, 11:12:04 PM
Hi,

just fixed it, updated console (version 3.2.493) will be published soon.

Best regards,
Victor
#968
Попробуйте в свойствах DCI включить опцию "interpret SNMP raw value as" и выбрать подходящий тип данных.
#969
General Support / Re: World map loading time
April 13, 2020, 03:34:17 PM
Hi,

it definitely looks like a bug. What is map zoom level when you experience this issue? Or what is approximate area covered?

Best regards,
Victor
#970
I think ssh.nsm was never included into those packages (because it has dependency on libssh). We will discuss it internally, but likely solution is to build libssh and add it to the package together with ssh.nsm.

Best regards,
Victor
#971
General Support / Re: Bug: Image libary
April 13, 2020, 12:07:09 PM
Does it appear if you relogin?

Best regards,
Victor
#972
This is really strange. In your first post you mention interface FL-Signage with index 209 as having wrong IP address, but I don't see such interface in walk output. Could you please send me screenshot of overview page and interfaces page for that node? You can send it in PM if it contains sensitive information.

Best regards,
Victor
#973
It could be due to timeout. Server will wait for answer from agent for time specified in server configuration parameter AgentCommandTimeout. If you are accessing remote system over slow link or command execution takes significant amount of time then executeSSHCommand may just timeout.

Best regards,
Victor
#974
Hi,

yes, #1 is correct. Any way that get you working bcm2835 library is fine. Looks like download URL in that post is outdated.

#3 - you did rename nxmc-3.2.478.war to nxmc.war? If yes and still nothing shown check Tomcat log files or post them there.

Also, we have Raspbian repository for agent and server so you can just install them without building yourself.

Best regards,
Victor
#975
Hi!

What exact errors you are getting? I see commands in your post but no actual output with error messages. Also, what version of Raspbian you are using?

Best regards,
Victor