I am using the python to send an snmpset message to an snmp agent. I have the correct OID as I can use it to get data with snmpget. However, it will not set the data. I am sending octets in hex format (two hex values) separated by a colon. I might have to put apostrophes around it, right? Here is the example of the line I am sending
foo = os.popen("snmpset -v 2c -c private 192.1.55.222
.1.2.6.5.4.1.24022.4.27.1.6.4.4 x 00:00:04:cf:00:00:00:00:00:00")
as you can see, I am sending an Octet string with type x.
Can anyone hazard a guess as to how I should pass in the set value of "00:00:04:cf:00:00:00:00:00:00". I know the setvalue is of the right length and type because I have used it in a MIB browser.
A couple of things:
1) there is a native python interface you could use instead of calling a system command. There are in fact multiple choices, including pysnmp (done in python) and Net-SNMP's python module (done in C).
2) The Net-SNMP snmpset command expects straight hex code without any :s in it. So if you remove the :s you may find it'll work.
Related
I've been playing around with scapy and want to read through and analyse every hex byte. So far I've been using scapy simply because I don't know another way currently. Before just writing tools myself to go through the pcap files I was wondering if there was an easy way to do it. Here's what I've done so far.
packets = rdpcap('file.pcap')
tcpPackets = []
for packet in packets:
if packet.haslayer(TCP):
tcpPackets.append(packet)
When I run type(tcpPackets[0]) the type I get is:
<class 'scapy.layers.l2.Ether'>
Then when I try to covert the Ether object into a string it gives me a mix of hex and ascii (as noted by the random parenthesis and brackets).
str(tcpPackets[0])
"b'$\\xa2\\xe1\\xe6\\xee\\x9b(\\xcf\\xe9!\\x14\\x8f\\x08\\x00E\\x00\\x00[:\\xc6#\\x00#\\x06\\x0f\\xb9\\n\\x00\\x01\\x04\\xc6)\\x1e\\xf1\\xc0\\xaf\\x07[\\xc1\\xe1\\xff0y<\\x11\\xe3\\x80\\x18 1(\\xb8\\x00\\x00\\x01\\x01\\x08\\n8!\\xd1\\x888\\xac\\xc2\\x9c\\x10%\\x00\\x06MQIsdp\\x03\\x02\\x00\\x05\\x00\\x17paho/34AAE54A75D839566E'"
I have also tried using hexdump but I can't find a way to parse through it.
I can't find the proper dupe now, but this is just a miss-use/miss-understanding of str(). The original data is in a bytes format, for instance x = b'moo'.
When str() retrieves your bytes string, it will do so by calling the __str__ function of the bytes class/object. That will return a representation of itself. The representation will keep b at the beginning because it's believed to distinguish and make it easier for humans to understand that it's a bytes object, as well as avoid encoding issues I guess (alltho that's speculations).
Same as if you tried accessing tcpPackets[0] from a terminal, it would call __repr__ and show you something like <class 'scapy.layers.l2.Ether'> most likely.
As an example code you can experiment with, try this out:
class YourEther(bytes):
def __str__(self):
return '<Made Up Representation>'
print(YourEther())
Obviously scapy's returns another representation, not just a static string that says "made up representation". But you probably get the idea.
So in the case of <class 'scapy.layers.l2.Ether'> it's __repr__ or __str__ function probably returns b'$\\xa2\\....... instead of just it's default class representation (some correction here might be in place tho as I don't remember/know all the technical namification of the behaviors).
As a workaround, this might fix your issue:
hexlify(str(tcpPackets[0]))
All tho you probably have to account for the prepended b' as well as trailing ' and remove those accordingly. (Note: " won't be added in the beginning or end, those are just a second representation in your console when printing. They're not actually there in terms of data)
Scapy is probably more intended to use tcpPackets[0].dst rather than grabing the raw data. But I've got very little experience with Scapy, but it's an abstraction layer for a reason and it's probably hiding the raw data or it's in the core docs some where which I can't find right now.
More info on the __str__ description: Does python `str()` function call `__str__()` function of a class?
Last note, and that is if you actually want to access the raw data, it seams like you can access it with the Raw class: Raw load found, how to access?
You can put all the bytes of a packet into a numpy array as follows:
for p in tcpPackets:
raw_pack_data = np.frombuffer(p.load, dtype = np.uint8)
# Manipulate the bytes stored in raw_pack_data as you like.
This is fast. In my case, rdpcap takes ~20 times longer than putting all the packets into a big array in a similar for loop for a 1.5GB file.
I am using a library called py_openshowvar to communicate with a Kuka robot arm from grasshopper.
Everything works fine if I run the program from a command line python shell. However, when I run the same thing from GhPython, I get the following:
Not sure why I get the exceptions with GhPython but not when I run it outside the GH environment. The program still connects to the server and retrieves/sends the info I need, but I want to make sure and address this exception.
Thanks!
It is hard to tell you how to fix the error as you do not provide the code that triggers it, but in substance it comes from the fact that GHPython is IronPython (an implementation of Python based on .Net) whereas Python Shell is an implementation written in C.
The two implementations are similar but you sometimes hit a difference.
In your case the script is expecting a string or tuple but gets an IronPython.Runtime.Bytes.
Hmm, got bytes when expecting str looks like a unicode string vs byte string problem. You do no describe what are the versions of your CPython and GHPython, but you should know that Python 2 strings are byte strings while Python 3 ones are unicode strings.
If in Python 2 you can force a litteral string to be unicode by prepending it with u: u"foo" is a unicode string. You can also decode a byte string to its unicode version: b'ae\xe9\xe8'.decode('Latin1') is the unicode string u'aeéè'
What I want is to send snmp traps just as the way that one of our network equipment do. The trap contains a name-value of DataTime and it's something like HEX String.
e.g. 1.3.6.1.4.1.193.82.1.8.1.4.0 : 07:de:07:10:0a:0c:1e:00:2b:08:00
When I use snmptrap command of the net-snmp to send the trap, our Trap decoder can successfully parse the hex string to dateandtime format(YYYY-MM-HH hh:mm:ss) just like that it got a real trap from our Network equipment.
The command I use is like this:
sudo /usr/local/net-snmp/bin/snmptrap -v 2c -c LI_OSS 10.184.74.66:162 "" 1.3.6.1.4.1.193.82.2.0.1 1.3.6.1.4.1.193.82.1.8.1.4.0 x "07de07100a0c1e002b0800"
x means that the string "07de07100a0c1e002b0800" is some kind of hex format.
When I try to use pysnmp to send complete the same task, our Trap decoder program do have received the trap but fail to parse the dateandtime.
Here is the code that I use to send the trap, it's the official example of pysnmp, here.
I only modified the host and below part:
ntfOrg.sendNotification(
snmpEngine,
# Notification targets
'my-notification',
# Trap OID (SNMPv2-MIB::coldStart)
(1,3,6,1,4,1,193,82,2,0,1),
# ( (oid, value), ... )
(
('1.3.6.1.4.1.193.82.1.8.1.4.0', rfc1902.OctetString('07de07100a0c1e002b0800'))
)
)
In order to figure out the differences, I captured the packages of sending traps that using snmptrap and pysnmp using WireShark, and here are the differences. Note that I am not using the same TRAP OID, but the phenomenon remain the same.
The first picture is that using snmptrap to send the trap, the other one is when using pysnmp.
The Octet Strings are just different.
Is anyone know why this happened? And how can I make it work to use pysnmp to send the trap in my situation? Thanks a lot in advance!
You passed an ASCII string as OctetString() object initialiser. You should indicate to OctetString constructor that your initialiser is to be interpreted as a hex string. This can be done with the hexValue keyword parameter. Consider:
>>> str(univ.OctetString('07de07100a0c1e002b0800'))
'07de07100a0c1e002b0800'
>>> str(univ.OctetString(hexValue='07de07100a0c1e002b0800'))
'\x07\xde\x07\x10\n\x0c\x1e\x00+\x08\x00'
I need to call an executable in a python script and also pass binary data (generated in the same script) to this executable.
I have it working like so:
bin = make_config(data)
open('binaryInfo.bin', 'wb+').write(bin)
os.system("something.exe " + "binaryInfo.bin")
I thought I could avoid creating the binaryInfo.bin file altogether by passing 'bin' straight to the os.system call:
bin = make_config(data)
os.system("something.exe " + bin)
But in this case I get an error:
"Can't convert 'bytes' object to str implicitly"
Does anyone know the correct syntax here? Is this even possible?
Does anyone know the correct syntax here? Is this even possible?
Not like you're doing it. You can't pass arbitrary binary data on the UNIX command line, as each argument is inherently treated as null-terminated, and there's a maximum total length limit which is typically 64KB or less.
With some applications which recognize this convention, you may be able to pipe data on stdin using something like:
pipe = os.popen("something.exe -", "w")
pipe.write(bin)
pipe.close()
If the application doesn't recognize "-" for stdin, though, you will probably have to use a temporary file like you're already doing.
os.system(b"something.exe " + bin)
Should do it.. However, I'm not sure you should be sending binary data through the command line. There might be some sort of limit on character count. Also, does this something.exe actually accept binary data through the command line even?
how bout base64encoding it before sending and decoding on the other end... afaik command line arguments must be ascii range values (although this maynot be true... but I think it is..) ...
another option would be to do it the way you currently are and passing the file ...
or maybe see this Passing binary data as arguments in bash
I am doing an snmpget using Net-SNMP. Specifically I am sending a command via os.popen("etc"). The value returned is a Hex-string separated by spaces, something like this : "A0 f0 D0". The returned value comes sometimes in the form :"Hex-String: A0 f0 D0.." but sometimes comes in the form "String:\xA0\xf0\xD0" where, as you can see, the spaces are filled with "\x". Does anyone have an idea as to why this might be happening? I would prefer it if the returned value was the HEX-String with spaces, not \x.
I should note that I am using Eclipse with Pydev. I then ran the same code in pyscripter and got back my Hex-String value. I ran it again in Pyscripter and then the \x's returned. Is this something to do with an unclosed pipe?
I should also mention that the data I am getting back is bad in another sense. The Hex-String with spaces returns proper data values, but the String with \xs returns values that are not correct.
I have used Wireshark and it looks like the get request is exactly the same as one sent from the MIB. The MIB request returns the correct data, while the Eclipse request still returns bad data.
PyDev does one thing differently, which is setting: sys.setdefaultencoding(encoding) with the encoding of the java console (so that if you print unicode to the console it won't fail saying that the unicode doesn't decode as ascii). To see if this is your problem, you can go to eclipse\plugins\org.python.pydev\PySrc\pydev_sitecustomize\sitecustomize.py and comment the line which does: sys.setdefaultencoding(encoding)