# SNMP Input Plugin Integer Overflow **URL:** \ **Category:** Logstash\ **Created:** [July 22, 2019, 1:36pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649 "2019-07-22T13:36:06Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 22, 2019, 1:36pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/1 "2019-07-22T13:36:06Z")
Hello everyone! We are gathering our firewall data from our cisco ASA 5545 via snmp v3. Now when we query ciscoMemoryPoolFree somewhere an overflow occurs. Return value: CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree.1 = Gauge32: 4294967295 bytes When this value gets saved into elasticsearch it is saved as -1. The mapping in elasticsearch is: "ciscoMemoryPoolFree": { "properties": { "1": { "type": "long" }, "6": { "type": "long" }, "7": { "type": "long" }, "8": { "type": "long" } It looks like there is an overflow somewhere in the pipeline. Maybe someone knows more. Best regards ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [July 22, 2019, 1:50pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/2 "2019-07-22T13:50:28Z")
What else would you expect it to get saved as? 4294967295, or 0xFFFFFFFF, is -1 in a long field. ---
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 22, 2019, 2:16pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/3 "2019-07-22T14:16:13Z")
Thanks for your reply. So if this is the normal behaviour, how can i change the mapping in logstash so that the correct values are written to elasticsearch? ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [July 22, 2019, 2:36pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/4 "2019-07-22T14:36:08Z")
As I asked before, what do you consider the "correct value" to be? ---
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 22, 2019, 2:48pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/5 "2019-07-22T14:48:15Z")
I would have expected it to get saved as 4294967295. That is the number of free ram in bytes. ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [July 22, 2019, 3:01pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/6 "2019-07-22T15:01:18Z")
> [@pprugger](#): > > I would have expected it to get saved as 4294967295. OK, so you want it to be integer, not long. Which makes sense, since the RFC defines Guage32 to be a non-negative integer... The Gauge32 type represents a non-negative integer, which may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum value. The maximum value can not be greater than 2^32-1 (4294967295 decimal), and the minimum value can not be smaller than 0. The value of a Gauge32 has its maximum value whenever the information being modeled is greater than or equal to its maximum value ---
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 22, 2019, 3:08pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/7 "2019-07-22T15:08:12Z")
But isnt integer defined as maximum value of 2^31 -1 ? Like said here: [https://www.elastic.co/guide/en/elasticsearch/reference/current/number.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/number.html) So it wouldnt fit into the integer? ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [July 22, 2019, 3:09pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/8 "2019-07-22T15:09:53Z")
> [@pprugger](#): > > So it wouldnt fit into the integer? Yes it would. It is exactly equal to the largest number you can fit in integer. ---
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 23, 2019, 12:08pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/9 "2019-07-23T12:08:02Z")
Hello! i tried several methods of conversions: filter { mutate { convert =\> { "9.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTable.ciscoMemoryPoolEntry.ciscoMemoryPoolFree.1" =\> "integer" } } } grok { match =\> ["9.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTable.ciscoMemoryPoolEntry.ciscoMemoryPoolFree.1", "%{NUMBER:testconversion:int}"] } Nothing works, i still get only -1. Any tips? ---
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [July 23, 2019, 12:35pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/10 "2019-07-23T12:35:33Z")
> [@Badger](#): > > Yes it would. It is exactly equal to the largest number you can fit in integer. I retract this. The number you have is the largest 32-bit unsigned integer. However, in elasticsearch the integer type is signed, so your value is too large to fit. ---
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 23, 2019, 12:40pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/11 "2019-07-23T12:40:32Z")
Well my solution for the moment is just. if [9.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTable.ciscoMemoryPoolEntry.ciscoMemoryPoolFree.1] == -1 { mutate { replace =\> { "9.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTable.ciscoMemoryPoolEntry.ciscoMemoryPoolFree.1" =\> 4294967295 } } } Not beautiful, but the only thing that works. ---
**Author:** ![pprugger](https://avatars.discourse-cdn.com/v4/letter/p/3e96dc/32.png) [@pprugger](https://discuss.elastic.co/u/pprugger)\ **Post date:** [July 25, 2019, 4:30pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/12 "2019-07-25T16:30:28Z")
It is indeed a bug in the snmp-input plugin. I wrote a patch and an issue on github. You can find it here: > ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 22, 2019, 4:30pm UTC](https://discuss.elastic.co/t/snmp-input-plugin-integer-overflow/191649/13 "2019-08-22T16:30:29Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.