let's say i want to make a monitoring application to monitor a bunch of devices in my network, my question is quite simple: why use SNMP-Get requests when devices can send trap to the manager ? does popular monitoring applications use traps or SNMP-get requests ?
thanks.
There are a couple of considerations, and this can be generalized to the management
philosophies of push (traps, notifications) vs. pull (get* requests):
1) only the management application knows exactly the information it wants to get
from the device. In pull architectures (ie. SNMP). it asks for the information
via GET* requests. In push architectures, it has to configure a push, eg. the device
has to be setup to send the notifications, eg. if a instrumented value is above a
certain threshold, which is expensive.
2) maintaining the push configuration on the device is expensive. In SNMP, the
device is supposed to be dumb, the manager is supposed to be smart. These days
devices are getting more powerful, thus you are seeing more push models (certain
MIBs, NetFlow, sFlow, etc).
3) besides configuration, just making notifications reliable is expensive. In
SNMP there are TRAP and Inform-Request PDUs. The former is unreliable, and is
regarded merely as a hint that something happened on the device, the application
then uses pull to get all the info. The latter is acknowledged, with the device
having to maintain information to make it reliable (timeouts, retransmits, etc).
With the above, just think of the effort to setup push (traps) on a device
exclusively:
1) your application (one of potentially multiple) has to configure the device
to tell it that you want traps/notifications. That in itself cannot be done
exclusively via push, there MUST be some SET requests;
2) your app has to tell it exactly what traps you want, again SET requests;
3) your device now has to make sure each notification reliably gets to all the
applications that have registered themselves with the device.
As far as "popular monitoring applications", in SNMP the vast majority of info
is pulled, notifications are used to indicate an exception that prompts pulling
information.
Related
I am having issues of writing a very huge mib, as due to the senario that I have only one agent connected with many devices which do not have snmp. All Devices are sending same type of data to agent by pushing and agent is then sending snmp traps to SNMP manager. Also Manager is sending SNMP GETs to agent. I want to write a standard mib, which applies to every device and Manager has to send only some OIDs to get values against, not hundreds of OIDs.
A very huge mib means a lot of branches.
A sub-agent is an additional SNMP daemon that extends functionality of the master agent. Basically, OID sub-trees are assigned to the sub-agent(s). There are also a few other ways of extending functionality. For example, Here's a nice article on different ways of extending an Net-SNMP agent.
Some of the differences pointed out in the article include:
No configuration is needed for the master agent to accept an
additional sub-agent. A sub-agent registers to the master agent the
MIB modules (or part of them) it wants to take care of.
A sub-agent is decoupled from the master agent. It can run with a
different identity or be integrated into another daemon to export its
internal metrics, send traps or allow remote configuration through
SNMP.
AgentX protocol can be carried over TCP. Sub-agents can therefore run
on a foreign host or in a jailed environment.
64bit types are fully supported. Traps are also supported.
From what I can understand, you have remote devices pushing data to an agent, who in turn needs to be able to process and return this data to an SNMP manager using SNMP traps and/or SNMP gets. One thing to keep in mind is that your SNMP agent may be blocking when processing the incoming data. A sub-agent could be helpful in taking care of this work independently.
In regards to having a large amount of branches to cover each device, a table could be used. Depending on what kind of data your sending, bit fields can also be useful. Defined bitfields can be used to send large amounts of information on one device via one transaction.
I'm planing to start some sms based application and currently in feasibility study part. In my application client have to sms their problem to the server and we have to analyse the problem and take reasonable action. Also We have to find the tentative location through which tower they have been connected. I have seen about silent sms feature but not understand. Is any body have experience on how to detect location of sms creator (not in android or iphone). Please help me on determining whether it is possible or not to find the location. If possible then how?
In short this is not possible.
an SMS message weather in PDU mode or text mode does not carry the information to match the source location to the message in any way shape or form.
With reference to the article you linked to in your opening post, I'm sorry to say that there's so much B$$l S$$t in that post that I can smell it from here.
In all the years Iv'e worked with GSM systems, both as a network maintenance engineer and later as a developer writing software to use these systems, not once have I heard of anything such as an 'LMU' or an 'E-OTD' in fact the only acronym that article really got correct was 'BTS' oh and the bit on passing the data over the signalling channel.
As for the silent SMS, well that part actually is true. The special type of SMS they refer to is actually called a Ping-SMS and it exists for exactly the same reason that a regular PING on a TCP/IP network exists, and that's to see if the remote system is alive and responding.
What it's NOT used for is the purpose outlined in the article, and that's for criminal gangs to send it to your phone and find out where you are.
For one, the ONLY people that can correctly send these messages are the telephone operator themselves. That's not to say that it's impossible to send one from a consumer device by directly programming a PDU if you have the necessary equipment and know how. You could for instance pull this stunt off using a normal GSM modem, a batch of AT commands and some serious bit twiddling.
However, since this message would by it's very nature have to go through your operators SMSC and most operators filter out anything from a subscriber connection that's not deemed regular consumer traffic, then there's a high chance this would fail.
You could if you had an account, also send this message using a web sms provider that allowed you to directly construct binary messages, but again they are likely to filter out anything not deemed consumer grade messages.
Finally, if you where to manage to send an SMS to a target device, the target device would not reply with anything anywhere near a chunk of location based info, cell tower, GPS or otherwise. The reason the SMS operators (and ultimately the law enforcement agencies know this info) is because EVERY handset that's attached to the GSM network MUST register itself in the operators MSC (Mobile switching centre), this registration (Known as ratching up) is required by the network so it can track what channels are in use by which device on which towers so that it knows where to send paging and signalling info.
Because of the way the PING SMS works it causes the destination device to re-register itself, usually forcing the MSC to do a location update on the handset which causes a re-registration.
Even then, all you get in the MSC is an identifier of the cell site the device is attached too, so unless you have a database in the organisation of all cell sites along with their exact lat/long co-ordinates, it's really not going to help you all that much.
As for the triangulation aspect, well for that to work you'd need to know at least 2 other transmitters that the device in question can see, and what's more you'd need that device to report that info back to someone inside the network.
Since typically it's only the Ril (Radio interface layer) on the device that actually keeps track of which transmitters it can see, and since the AT commands for many consumer grade GSM modems have the ability to query this information disabled, then it's often not easy to get that info without actually hacking the firmware in the device in question.
How does Google do it? well quite easy, they actually have commercial agreements with network providers that pass the details of registered towers to their back-end infrastructure, in the apps themselves, they have ways of getting the 'BSS List' and sending that list back to Google HQ, where it's cross referenced with the data from the network operator, and the info they have in their own very large transmitter database and finally all this is mashed together with some insane maths to get an approximate location.
Some GSM Modems and some Mobile phone handsets do have the required AT commands enabled to allow you to get this information easy, and if you can then match that information to your own database you can locate the handset your running from, but being able to send a special SMS to another device and get location info back is just a pipe dream nothing more, something like this is only going to work if your target device is already running some custom software that you can control, and if your device is running software that someone else is controlling, then you have bigger problems to worry about.
We have a system where there are typically two processes running on the same system. One process handles the GUI and the other runs like a service (although for historical reasons, it's not a service, just an exe with no visible window).
The two processes undertake IPC mainly via registered messages asynchronously - i.e. we use RegisterWindowMessage() in both processes to define a large'ish set of messages that effectively form the API to the server process.
I have written a "hands-free" monitoring application that uses SetWindowsHookEx() to monitor and display the message queues of both processes and provide some level of decoding of the way the API is being utilised and how notifications are being propagated to the GUI process (each individual window can subscribe to notifications from the server directly).
So, there are a large number of messages in both directions so I have filtering and summary counts etc. so I can focus on particular activity. All this can be done without affecting the live code, which is good.
This all works well, but it now would be very useful to be able to "tag" a message originating in the GUI so I can trace the same message when it's processed by the server. This would be enormously useful for debugging and diagnosing system issues, but I can't find a clean way (actually I can't find any way!) of doing this without adding such support to our registered message API, which would be a lot of work and involves more risk than I'm comfortable with at the moment. It gets further complicated by the fact that the server pre-processes some messages and then does a PostMessage() back to itself to perform the action, so the originating message can get "lost".
Has anyone here tackled this type of problem? If so, can you give me some pointers? If not, then are there any documented or undocumented ways of adding a small block of data to a Windows message and retrieving it later? I've looked at SetMessageExtraInfo() but that seems to be per-queue rather than per-message.
FindWindow or FindWindowEx will give you the details of the GUI Window. Compare the details with message intercepted
In KEXT, I am listening for file close via vnode or file scope listener. For certain (very few) files, I need to send file path to my system daemon which does some processing (this has to happen in daemon) and returns the result back to KEXT. The file close call needs to be blocked until I get response from daemon. Based on result I need to some operation in close call and return close call successfully. There is lot of discussion on KEXT communication related topic on the forum. But they are not conclusive and appears be very old (year 2002 around). This requirement can be handled by FtlSendMessage(...) Win32 API. I am looking for equivalent of that on Mac
Here is what I have looked at and want to summarize my understanding:
Mach message: Provides very good way of bidirectional communication using sender and reply ports with queueing mechansim. However, the mach message APIs (e.g. mach_msg, mach_port_allocate, bootstrap_look_up) don't appear to be KPIs. The mach API mach_msg_send_from_kernel can be used, but that alone will not help in bidirectional communication. Is my understanding right?
IOUserClient: This appears be more to do with communicating from User space to KEXT and then having some callbacks from KEXT. I did not find a way to initiate communication from KEXT to daemon and then wait for result from daemon. Am I missing something?
Sockets: This could be last option since I would have to implement entire bidirectional communication channel from KEXT to Daemon.
ioctl/sysctl: I don't know much about them. From what I have read, its not recommended option especially for bidirectional communication
RPC-Mig: Again I don't know much about them. Looks complicated from what I have seen. Not sure if this is recommended way.
KUNCUserNotification: This appears to be just providing notification to the user from KEXT. It does not meet my requirement.
Supported platform is (10.5 onwards). So looking at the requirement, can someone suggest and provide some pointers on this topic?
Thanks in advance.
The pattern I've used for that process is to have the user-space process initiate a socket connection to the KEXT; the KEXT creates a new thread to handle messages over that socket and sleeps the thread. When the KEXT detects an event it needs to respond to, it wakes the messaging thread and uses the existing socket to send data to the daemon. On receiving a response, control is passed back to the requesting thread to decide whether to veto the operation.
I don't know of any single resource that will describe that whole pattern completely, but the relevant KPIs are discussed in Mac OS X Internals (which seems old, but the KPIs haven't changed much since it was written) and OS X and iOS Kernel Programming (which I was a tech reviewer on).
For what it's worth, autofs uses what I assume you mean by "RPC-Mig", so it's not too complicated (MIG is used to describe the RPC calls, and the stub code it generates handles calling the appropriate Mach-message sending and receiving code; there are special options to generate kernel-mode stubs).
However, it doesn't need to do any lookups, as automountd (the user-mode daemon to which the autofs kext sends messages) has a "host special port" assigned to it. Doing the lookups to find an arbitrary service would be harder.
If you want to use the socket established with ctl_register() on the KExt side, then beware: The communication from kext to user space (via ctl_enqueuedata()) works OK. However opposite direction is buggy on 10.5.x and 10.6.x.
After about 70.000 or 80.000 send() calls with SOCK_DGRAM in the PF_SYSTEM domain complete net stack breaks with disastrous consequences for complete system (hard turning off is the only way out). This has been fixed in 10.7.0. I workaround by using setsockopt() in our project for the direction from user space to kext as we only send very small data (just to allow/disallow some operation).
My son has a MacOS 9 box to which he is sending remote AppleEvents from his Leopard-based MacBook. Is there any way, programmatically, that I can send remote AppleEvents via TCP/IP from my Windows 7 Toshiba?
If it helps, apple events are sent on port 3031 via TCP/UDP.
From the high level, there are four pieces to apple events:
The data aggregation API (data requests are put into an opaque in memory structure). This API as it stands was wordy and painful to use. Thank goodness you have access to languages that have better data aggregation tools
Conversion/serialization - the opaque data structure is turned into something that can be serialized and transported to another process and for same machine events, this may be a null serialization
Transport the data is transported from one process to another. Single machine is probably just enqueuing a copy of the data. Remote machine is transport over a network protocol, which could be TCP/IP (but it works with AppleTalk as well) and may require authentication.
Deserialization/Conversion
You will most likely need to do steps 2, 3, and 4. If you don't care about getting any information back, you can skip 4, since one of the flags in a sent event is "no reply".
There are a relatively small number of types in the AE data model. I would write code on your OS X machine to send each and every type and reverse engineer the packets when they're sent. To speed up the process you might want to use appscript, on the OS X machine which will let you send events from Ruby, Objective C, or Python.
Sniff the packets between the MacBook and the MacOS 9 box using something like tcpdump or Wireshark. This will tell you what an AppleEvent looks like on the wire.
Then replicate those packets using your programming environment of choice on Windows.
I suggest wrapping up the code that you write into a library that you can reuse in other applications.
Good luck - this might be quite tricky!!
if you're talking about growl notification, there are libraries to use that. for example, here is the growl library for ruby