Can you provide screenshots or output?
In my experience there is one field in particular when using the system.find call that ouputs that way. IPV4.
However, the IP Address and IPV6 fields output just fine.
Unfortunately I cannot provide screen shots, however I can say that it is for any IPV4 addresses (ie. source and target IPs, analzyer IP). They all appear to be 10 single digits with a negative value. This could have some thing to do with url encoding, not sure where exactly the disconnect would be.
What api call are you using? System.find for example...
I will try and do some digging and see...
I am executing remote (existing) queries and working with the output in json (typically). To be exact: executeQuery. My apologies, I should have been more specific about tihs initially.
I have not tried an ad-hoc query. I'll give this a shot when I have time to try it out, could shed some more light on the remote queries.
Ad hoc query shows the same weird IP format as well (pulling from event details).
I cannot seem to replicate the issue you are having. Hopefully someone will stumble upon the thread and can help you out.
I thought maybe these would be base 10 decimal (doesn't explain the - sign in front though), however this does not appear to be the case either. I have a ticket in with support, I'll post findings if they can figure it out.
I think I found out the problem. The IP address is decimal format, however the way it's retrieved is too long so it gets a negative number assigned. Not sure yet on a solution.
We are actually storing the IP address as integers in the range [-2^31, (2^31)-1] so that they will inside a 32-bit integer (and be stored in the database as an "int" type). To do this, we take each of the four octets of the IP address, shift it to the left, and the result is bitwise-ORed with the result.
To take that int and turn it into a readable IPv4 address, you need to do something like this:
- convert the result to a long (depending on the language you're using)
- add MAX_INT (2^31-1) to that number
- add another 1
- bit-shift it right by 24 bits, bitwise-AND the result with 0xFF - this is your first octet
- bit-shift right by 16 bits (and do the bitwise-AND) for the second octet
- bit-shift it right by 8 bits, etc, for the third octect
- just perform the bitwise-AND for the final octet
Adding to it was working, but you gave the exact answer I needed to cover all ground, thank you!