NetXMS Support Forum

Hi,

yes, it can be done, but it will take some time to move all strings to message files. I will update on progress.

Best regards,
Victor

For L2 maps server consider any node without bridge capability to be end node. Bridge capability determined by attempting to access BRIDGE-MIB during configuration poll (specifically OIDs .1.3.6.1.2.1.17.1.1.0 and .1.3.6.1.2.1.17.1.2.0).

Best regards,
Victor

I've made changes to disable usage of ipAddrTable and ipAddressTable by setting to true attributes snmp.ignore.ipAddrTable and snmp.ignore.ipAddressTable. Those changes will be included into upcoming patch release.

Best regards,
Victor

Hi,

if data in IP-MIB is incorrect that it definitely can cause strange results. Do those devices provide correct address information under .1.3.6.1.2.1.4.20.1.1 (ipAddrTable)? If yes, I can made small change that will allow to disable usage of .1.3.6.1.2.1.4.20.1.1 (ipAddressTable) for specific devices.

Best regards,
Victor

Hello!

This is download link for current message files: https://cloud.radensolutions.com/s/zrYw4jDxcfTbKFG.
However, we are currently in process of moving to new UI, so it could be more productive to work on new UI when most of functions will be transferred. I expect most work to be done during May and early June. We will try to re-use translations from legacy UI as much as possible though.
Also, please note that some texts in UI are not moved to language files yet and are hard-coded as English texts. This is also work in progress.

Best regards,
Victor

Actual code that caused crash looked like this:

   int bytes = request->packetSize - sizeof(IPHDR);
   packet.m_icmpHdr.m_wChecksum = 0;
   packet.m_icmpHdr.m_wChecksum = CalculateIPChecksum(&packet, bytes);


If total packet size < 20, bytes will be negative, which will cause crash within CalculateIPChecksum. With packet size between 20 and 27, result will be positive and CalculateIPChecksum will actually calculate checksum for requested number of bytes, but invalid ICMP packet will be sent (with only part of the header).

Best regards,
Victor

Try to deploy new web under different name - will it have same issue?

Looks like old client version still deployed, or some parts of old version stuck in cache. Try to clear Tomcat working directory.

Best regards,
Victor

Quote from: troffasky on May 12, 2022, 04:18:36 PM
Is it worth bringing these up here?

Yes, absolutely. We will look into it and hopefully fix before next patch release.

Best regards,
Victor

Fixed it just an hour ago Fix will be included into next patch release.

Best regards,
Victor

Documentation is wrong, I checked source code Will fix that.

Actually as I start thinking about it, minimum size is 28, not 46. Because this value includes both IP header (20 bytes) and ICMP header (8 bytes), it cannot be less than that. 46 is minimum payload size for Ethernet frame. If you are using only Ethernet for communications, setting ping size to any value less than 46 will not reduce traffic, as payload will be padded to minimum length anyway. However, if you are using communication channels capable of sending shorter frames than reducing ping size further can make sense.

Hi,

looks like you have server configuration parameter ICMP.PingSize set to 1 (or other small value). It has to be set to at least 46. There is a bug in a server that it does not check this value for validity, and incorrect value causes crash later on.

Best regards,
Victor

session.findObjectById(objectID).getObjectId() is kind of pointless - you already know object ID, but you use it to find object by that ID, only to get that same ID from object...

Yes, that makes sense. I've added it as feature request: https://track.radensolutions.com/issue/NX-2260

Best regards,
Victor