I am working on a project about SNMP.
I know that between SNMPv1 and SNMPv2, SNMPv2 has GetBulk and Inform commands in addition. I would like to know that for the commands that are supported in the three versions like Get GetNext Set etc.., is there a difference in terms of compatibility or is there any difference that I should know?
SNMPv1 is missing GetBulk and the TRAP2 and INFORM commands (and REPORT, but you probably don't ever need to know that it exists). Other than that, SNMPv2c is a minor change to SNMPv1 that only adds these three commands. SNMPv3 uses the SNMPv2 PDU format so the command list is identical. SNMPv3 only wraps security and other processing around the SNMPv2 PDU set.
REPORT is almost v3 only.
GET BULK, TRAP v2 and INFORM are v2c/v3 only.
TRAP v1 is almost v1 only.
Other commands are available in all three versions.
Note that the message format is almost identical in v1 and v2c, while v3 uses a more complex format.
http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat-3.htm
http://www.tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats.htm
http://www.tcpipguide.com/free/t_SNMPVersion3SNMPv3MessageFormat.htm
The SNMP RFC documents listed in this Wikipedia page provide you more details on them,
http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
There might be other issues during your exploration, and once you hit anything, you can post here again as a new question.
Related
By default gammu have support for most standard modem. I have a very particular modem with some special requirements and I would like to add a protocol to gammu.
Is there a guide for this somewhere or someone who can list the basic steps for me?
EDIT: #user1664784 recommended to look att Kannel, and actually any system able to handle incoming and outgoing SMS is acceptable as long as it is stable. But I need to know how to modify the system so that I can handle a specific protocol. It is AT-based but a slight dialect. So any suggestion of a system handling SMS from a device connected over serial port is interesting. I need to find a system where someone can give me information on where in the source code I can begin adding a new AT-based protocol.
If someone have done some sample code in this area it would also be greatly appreciated.
It really depends how much different it is from standard AT commands.
If the difference is minor (eg. needs custom initialization), it can be easily achieved by feature flags. This can be seein ATGEN_PostConnect which handles initialization for ZTE or Huawei devices.
If the differences are big, you will probably need to write own driver, which will fall back to AT in some cases. Something similar can be seen in the AT OBEX driver which switches Bluetooth connection between OBEX and IrMC modes.
I think we used to have documentation on adding support for new devices, but I'm unable to find it right now.
before I start I realise there are a few SNMP related questions here already but not many seem to have been answered - that could mean I'm asking in the wrong place but I don't know where else to go at the moment.
I've been reading up as best I can on SNMP for a couple of days but am finding it difficult to get my head around what is meant to be happening. The idea is eventually we will integrate SNMP into our Java application server which will allow the end users to incorporate it into their pre-existing Network Management Systems(NMS).
Unfortunately I'm feeling entirely confused by what is meant to be going on. From what I understood from talking to the end users (which was unfortunately before any research) was that the monitoring allows their existing NMS to give their admin guys a view of the vital statistics in a tree type display, giving them feedback regarding different parts of the system at a high level and allowing them to dig down into specific subsystems.
From reading around we would implement an 'Agent' which has several defined interfaces allowing for GET requests etc to be processed and responded to. That makes sense but I am at a loss to work out what the format of the communication is - there don't seem to be any specific examples of what any of the messages look like, how the information is encoded.
More of my confusion though is regarding Management Information Base(MIB). I had, wrongly, assumed that the interface of the agent would allow for the monitored attributes to be requested and then in turn the values for those attributes requested. Allowing any new Agent to be started and detected without any configuration on the NMS end (with the exception of authentication in v3). This, if I understand correctly, is not the case and the Agent must instead define MIBs which can be used by the NMS to determine those attributes. My confusion is increased when people start referring to thousands of existing MIBs and that they can be reused which I don't understand. Is the intention that a single MIB definition can be used to say describe how a particular attribute of a network device (something simple like internet connected on a router:yes/no) for many different devices? If so I don't believe that our software would allow the monitoring of anything common to any other device/system but should we be looking for already exising MIBs? At the moment I don't really see any good rational for such a system, surely it would be easier for the Agent to export that information - so I'd appreciate it if someone could enlighten me!
I think it would help if I was able to setup a simple SNMP agent and some sort of client, I could begin to see the process and eventually inspect the communication between the two but am finding it difficult to find anywhere that provides any information on doing such a thing. Nagios has been recommended to us as a test 'client'/NMS but their 'get started quick' section recommends downloading a 600Mb virtual machine - surely there is a quicker way to get started?
Any help or suggestions will be appreciated, I have been through the Wiki page but it doesn't seem to go into much detail about the MIBs and the having not had to deal with anything like the referenced RFCs before, while they may contain all of the information they seem completely impenetrable to me at the moment. Or if there are any books that can be recommended for an overview and implementation of v3?
Thanks for reading and even more thanks if you think you can help!
It seems to me that you read all SNMP information piece by piece in an disorganized way. This is highly not recommended and of course lead you to confusion.
What about forgetting what you have learnt so far and dive into a good book such as Essential SNMP?
http://shop.oreilly.com/product/9780596008406.do
Click the Google Preview icon to preview it please.
You could not depend on a network forum to tell you the ABCs, as that's impractical I find out.
The communications interface is SNMP. That's the protocol used for transmission (usually on top of UDP). The thing that services information requests is an SNMP Agent. The thing that sends information requests is an SNMP Manager.
The definition of what information should be made available by the Agent, and requested by the Manager, goes in a MIB. A MIB is the "glue", a directory of what sort of things any particular system can/should offer. It maps numeric codes to names and types that allow us to make sense of the data, much like how a phone directory maps phone numbers to people's names and addresses.
Generally you would create and ship and use your own MIBs that can describe aspects specific to your own product, but you are supposed to service some standard information requests as well, which are defined in existing MIBs. Yes there are thousands of other pre-existing MIBs and the likelihood that you need more than one or two of these is remote. They are typically published versions of MIBs for existing products.
The conventional way to "toy around" is to install Net-SNMP (a software suite that includes an agent implementation and allows you to "bolt on" your own logic and your own MIBs fairly easily) then examine the results using a packet capturer like Wireshark.
For a fuller implementation in production you may stick with Net-SNMP, or write your own Agent software, or do what I did and create a hybrid of the two that's a little more flexible and performant but uses Net-SNMP's backend for handling all the low-level SNMP stuff.
Your first step, though, is to read a book or some other teaching material that can clear all your misconceptions, because guesswork won't cut it.
I had success using the samples from this page. Both the shell and Perl NetSNMP code was very straightforward to implement and query.
Forgive my ignorance if this is a trivial question. I am writing some code to support communication over SNMPv3; our application only supports SNMPv2c currently.
The response object when communicating using SNMPv3 is blank unless I match community strings. I was under the impression that community strings were an "SNMPv2/1 thing" and that "the new way" was to use a username/authentical protocol/privacy protocol.
Wikipedia states that:
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, it looks much different due to new textual conventions, concepts, and terminology.[1]
This statement leads me to believe that I do, in fact, need to supply community strings, too.
I just wanted to confirm this because it is difficult for me to tell whether I am getting data back because I fulfilled the SNMPv2 requirement or because I successfully fulfilled all the SNMPv3 requirements.
I'm using Dart's SNMP library to communicate with the other device and I have specified that my request should user SNMP version three -- but perhaps it falls back to SNMPv2 behind-the-scenes when given valid SNMP communities?
No, you don't. The internal packet structure changes to a number of new concepts, like the above quote tries to indicate. The protocol side that the above is stating is the same has to do with PDU operations, etc. IE, technically there are 3 versions of SNMP:
version 1: community string based authentication with SMNPv1 PDUs
version 2c: community string based authentication with SNMPv2 PDUs
(the SNMPv2 PDUs add GETBULK, INFORM, and REPORT PDUs)
version 3: modular security with SNMPv2 PDUs
IE, version 3 didn't touch how the actual operations work (it's still using the PDU types from version 2), but merely adds other header-stuff around them (like better and more modular security; in fact we now have 3 different security types to pick from at this point: USM, SSH, and (D)TLS).
I've implemented an SNMP agent using SNMP4J. I've read in various places (including in SNMP4J javadoc) that there is support for a 'getSubtree' operation, but it always seems to be done from the client side, using getNext and/or getBulk. What I'm trying to do, though, is define a new PDU for 'getSubtree', and implement the server-side agent support for it.
Has anyone successfully (a) implemented a new PDU type (beyond the 7 standard ones) using SNMP4J, and/or (b) implemented 'getSubtree' support within an agent (I already know how to simulate it from a client.) Is either (a) or (b) even possible? Any pointers on how to do either would be GREATLY appreciated!
SNMP is not an extensible protocol that allows you to add new operations to it. So legally, you can't actually do that. The RFCs restrict the PDUs to the existing ones. GETBULK is the most efficient way to gather a bunch of information from an agent, even though it has its own issues with using it (data overrun for example).
Reading the FTP RFC (RFC959), I notice some modes that I've never seen used, and indeed don't seem to be implemented by popular FTP software (vsftpd for example). In particular, for the STRU command, only file mode "STRU F" is commonly used, and for the MODE command, only stream mode "MODE S" is commonly used.
So the question is, when following best practice for developing interoperable FTP client and server software:
Is it useful to support the other STRU options (record and page)? These seem like something very old fashioned.
Is it useful to support the other MODE options (block and compressed)? I can see the point in compressed, but I'm particularly wondering whether any clients/servers will expect block to be there.
Are there any surveys of which existing FTP implementations support which options?
(On the MODE one, I can see why compressed is useful, I'm more wondering about whether any clients/servers will expect block mode to be there).
I maintain a custom FTP server and regularly refer to http://cr.yp.to/ftp.html for these sort of questions. Specificly, I followed the suggestions for TYPE/MODE/STRU at http://cr.yp.to/ftp/type.html and so far have had no issues.
No client I've seen connect has sent an STRU request besides "STRU F". Similarly, I've only ever seen "MODE S".
I would suggest to search for open source FTP clients and servers (especially those still being actively updated) and look at how many of them implement these "obsolete" transfer modes.
I made once (about seven years ago) a FTP client and implemented just the most basic transfer modes (ASCII and binary, if I remember correctly). Never had a problem with any server when using it.
It sounds like you are mostly concerned with interoperability. The answer is a bit different between client and server.
For server, you want to implement the basic modes that clients use. For every client, you need to support a minimum of one configuration, so the number of combinations should be relatively low. Beyond the minimum, supporting active -and- passive mode would probably the major addition (the mozilla community has wanted passive support for a long time, and it is probably never going to happen).
If you are a client, providing good URL support and date/time handling is probably the biggest barrier.