I have a program that is using the netsnmp C API to query device for snmp information. So far everything has been working fine, but when I polled a new OID (1.3.6.1.2.1.138.1.1.1.3.0 (isisSysID)) its doesn't work, and I just get the noSuchName error, other OIDs such as from the IF-MIB have been working fine.
However when I test using snmpget from the same system to the same endpoint it works fine. (v1 or v2c)
snmpget -v2c -c 1.3.6.1.2.1.138.1.1.1.3.0
Thanks.
Figured out the issue,
In my code I was using the method get_node to convert a OID string to the OID object used for the request by the netsnmp api. This works fine if the OID you are using contains a text named portion such as "sysName.0" but fails if the OID you use is entirely numerical ie "1.3.6.1.2.1.138.1.1.1.3.0".
Luckily a workaround is that you can shorten that OID to "mib-2.138.1.1.1.3.0" as "mib-2" is the text replacement for "1.3.6.1.2.1"
Related
While working with the open source ELK stack, we have run into an issue where one of the Logstash inputs snmptrap is formatting data in a way that is unusable for us. Within the SNMPv1_Trap class there is an instance variable called agent_address which is stored as a SNMP::IpAddress. For anyone familiar with the way SNMP works, the agent address is extremely important in determining where a SNMP trap originated from when using trap relays on your network.
The problem can be seen when you take a look at an event generated by Logstash upon receiving a trap. Mainly, the inspect method of the agent_address variable is dumping data that does not match anything valid.
A sample event looks kind of like this:
#<SNMP::SNMPv1_Trap:0x2db53346 #enterprise=[1.3.6.1.4.1.6827.10.17.3.1.1.1], #timestamp=#<SNMP::TimeTicks:0x2a643dd1 #value=0>, #varbind_list=[#<SNMP::VarBind:0x2d5043a5 #name=[1.0], #value=#<SNMP::Integer:0x29fb6a4a #value=1>>], #specific_trap=1000, #source_ip=\"192.168.87.228\", #agent_addr=#<SNMP::IpAddress:0x227a4011 #value=\"\\xC0\\xA8V\\xFE\">, #generic_trap=6>
We know however, that the IpAddress object used in SNMP::SNMPv1_Trap is able to return us a nicely formatted string representing the IPv4 address it is storing.
For example:
require 'snmp'
include SNMP
address = IpAddress.new(192.168.86.254)
puts address
will yield 192.168.86.254 whereas:
require 'snmp'
include SNMP
address = IpAddress.new(192.168.86.254)
puts address.inspect
will yield:
#<SNMP::IpAddress:0x0000000168ae88 #value="\xC0\xA8V\xFE">
This is the expected behaviour of an object whose .inspect method has not been overridden.
Obviously the IPv4 address in #value is not useful to us, it has only three valid hex sequences (xC0=192, xA8=168, xFE=254) and also contains an invalid hex sequence ('V'). The same thing occurs whenever an octet string representing an IPv4 address is sent as a variable binding as well, which suggests some strange encoding.
Unfortunately, aside from writing our own SNMP input, there is no interface level access to this object. The object we receive via 'event' contains the inspect string, not the object itself. Therefore, the easiest apparent way to get the information we need would be to reconstruct the SNMPv1_Trap object and then make our own calls to it via Object.#send.
If I have the raw, unformatted and default string dump returned by Object.#inspect, is there any way to physically recreate the object used to make this inspect dump on the fly?
For example, given the string dump:
#<Integer:0x2737476 #value=1>
is it possible to recreate an Integer object with a field whose value is 1?. If this is possible, is there also a way to recreate nested objects the same way? For example, given the string:
#<SNMP::SNMPv1_Trap:0x2ef73621 #value=1, #agent_address=#<SNMP::IpAddress:0x0000000168ae88 #value="\xC0\xA8V\xFE">>
Would it possible to have an object that looks like the following?
SNMP::SNMPv1_Trap{
#value : 1
#agent_address : SNMP::IpAddress{
#value : 1
}
}
If I have the raw, unformatted and default string dump returned by Object#inspect, is there any way to physically recreate the object used to make this inspect dump on the fly?
No. inspect is intended for debugging purposes to be read by humans.
It is not guaranteed to be machine-readable. It is not guaranteed to be the same across different Ruby versions. It is not guaranteed to be the same across different Ruby implementations. It isn't even guaranteed to be the same across different versions of the same Ruby implementation implementing the same Ruby version. Heck, I don't even think it is guaranteed to be the same across two runs!
It is not a serialization format.
There are plenty of serialization formats specifically for Ruby (Marshal) or generically (XML, YAML, JSON, and of course ASN.1), but inspect isn't it.
I am trying to pass a variable (emailAddress) to Parse Cloud Code from Arduino.
ParseCloudFunction cloudFunction;
cloudFunction.setFunctionName("SendEmail");
cloudFunction.add("email", emailAddress);
ParseResponse response2 = cloudFunction.send();
However, Parse sees this as a Boolean...
E2015-08-19T16:17:14.622Z]v10 Ran cloud function SendEmail for user XXXXXXXX with:
Input: {"email":true}
Result: Uh oh, something went wrong
Anyone know how to pass the variable without sending as a Boolean?
I had a similar problem and i think i've just solved it.
If you change the datatype for the email address to char* (i'm assuming you were using a string before) then it should work.
I'm not 100% sure why but i think its to do with referencing a pointer. I think parse.com requires a pointer to reference a variable and so a 'String' does not have that and parse.com only sees a boolean. Anyway this may not be quite correct but all i know is when i changed my String to char* it worked!
I took the inspiration from this documentation from Parse http://parse.com/docs/arduino/api/class_parse_object_create.html
Hope it works!
I'm trying to calculate the tf*idf of a term in my index.
Following Yonik's post from http://yonik.com/posts/solr-relevancy-function-queries/ I tried
http://localhost:8080/solr/select/?fl=score,id&defType=func&q=mul(tf(texto_completo,bug),idf(texto,bug))
(where texto_completo is the field, and 'bug' is the term) without much success. The response was:
error 400: The request sent by the client was syntactically incorrect (null).
I went ahead and looked at this answer /a/13477887 so I tried to do a simpler function query:
http://localhost:8080/solr/select/?q={!func}docFreq(texto_completo,bug)
And yet, I got the same error.
What is my syntax lacking to work properly?
For this not working:
q={!func}docFreq(texto_completo,bug)
use all lower-case docfreq:
q={!func}docfreq(texto_completo,bug)
I just tried:
q={!func}mul(tf(name,movie),idf(name,movie))
in Solr 4.2.1 and it is working fine. My field name is name (Text type) and term I am looking for is movie.
UPDATE: You need at least Solr 4.0 to use these. See http://wiki.apache.org/solr/FunctionQuery#Relevance_Functions
I'm using splunk-client to extract results from splunk. Here's the code:
query = "sourcetype=collection #{order_id}"
search = #splunk_client.search(query)
search.wait
The search is happening fine, and it seems like I'm doing everything according to the example (https://github.com/cbrito/splunk-client), but I get this error on the 'search.wait' line:
Undefined namespace prefix: //s:key[#name='isDone']
Any ideas what could be going wrong? Running these commands in irb works fine. Is there some sort of blocking issue?
There is currently very little error checking which occurs within the gem itself. The reason for the error is that wait looks for the status of the isDone key to change to true.
Since your credentials were not properly setup in the first place, the gem creates a search object with an invalid session. The search does not initially fail, because enough response came back from Splunk that Nokogiri processes it into an object without a Splunk search sid.
In the future I should likely raise an exception if a proper sid is not returned to avoid confusion.
Source: I wrote the gem.
I found out the issue -- the splunk client wasn't authenticating properly, and so search was actually a broken SplunkJob object (with a nil username and authentication key). It's strange that there was no error raised until the wait command, but upon inspecting the search object, one of the fields stated that the object was malformed.
I have a really strange thing happening on my site and I cant figure it out.
I have an auto complete box that queries an LDAP connection. The connection works fine and I get responses from the LDAP Query. BUT, here is where the problems start.
On my local machine, I get the response:
[{"label":"TestUser, Bill","value":"Testuesr, Bill","AdLogon":"bill.testuser"}]
but on my server I get the response:
[{"label":"TestUser, Bill","value":"Testuesr, Bill","AdLogon":[67,111,108,109,95,67]}]
Does anyone have any ideas what could be starting this?
Update
If I change the AppPool from AppPoolIdentity to NetworkService then it returns the proper values.
"67,111,108,109,95,67" is the integer array for "Colm_C", It's so becaise of the special catacter '_' . If think that an underlying layer need to transform sAMAccountName in a B64 string and it's then given back as an array.