[Wireshark-dev] Wireshark and real-time network issue detection?
Hi list, I wonder if Wireshark could be extended to provide real-time network issue detection and if there was any interest in the community to implement this feature. Let me explain. What i would like to have is the following: Wireshark (tshark to be precise) would be run from another application (let's call it the Monitor application). There would be a form of interprocess communication between Wireshark and the latter. Wireshark would capture packets, decode them and run certain analysis modules (console style tap-listeners, as can be activated via the -z option). The analysis modules would be designed to detect alarm conditions that correspond to a certain network troubleshooting issue, for example, think of a module that monitors RTP voice conversations and reports whenever there is consecutive packet loss exceeding some threshold. Whenever an alarm condition is met, Wireshark would notify the Monitor application, and the latter would save the coresponding capture files. Wireshark would be run in multiple files option, but the Monitor would erase every written file after a while if no alarm condition has been met during that time. Only the capture files containing alarm conditions would be saved. The goal is to have the whole thing running over several days/weeks without filling up the HDD with unnecessary files. In fact i already have implemented an application that does just that! It was back on Ethereal 0.10.3 and i had to modify Ethereal in a few ways: - Include a form of interprocess communication with the calling Monitor. (was done using Windows IPC, certainly not a good choice, but it was the fastest possible way for me to do), including an ABI for the monitoring taps to use it. - Make Ethereal report whenever it switched to a new capture file. (- Mayeb other things i don't remember any more) Problems i had to cope with: - Ethereal was leaking memory which caused problems when running for several days. My workaround was to have Monitor relaunch Ethereal every now and then. Obviously, keeping up with Wireshark's release frequency is difficult for me. That is why i'm asking wether there would be interest in redesigning, adding and maintaining the Wireshark related part to the Wireshark source tree? best regards, Lars Ruoff ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark and real-time network issue detection?
Hi, Did you have a look at www.snort.org ? It may be what you are looking for. Frederic Heem. Alle 15:03, lunedì 30 ottobre 2006, Lars Ruoff ha scritto: Hi list, I wonder if Wireshark could be extended to provide real-time network issue detection and if there was any interest in the community to implement this feature. Let me explain. What i would like to have is the following: Wireshark (tshark to be precise) would be run from another application (let's call it the Monitor application). There would be a form of interprocess communication between Wireshark and the latter. Wireshark would capture packets, decode them and run certain analysis modules (console style tap-listeners, as can be activated via the -z option). The analysis modules would be designed to detect alarm conditions that correspond to a certain network troubleshooting issue, for example, think of a module that monitors RTP voice conversations and reports whenever there is consecutive packet loss exceeding some threshold. Whenever an alarm condition is met, Wireshark would notify the Monitor application, and the latter would save the coresponding capture files. Wireshark would be run in multiple files option, but the Monitor would erase every written file after a while if no alarm condition has been met during that time. Only the capture files containing alarm conditions would be saved. The goal is to have the whole thing running over several days/weeks without filling up the HDD with unnecessary files. In fact i already have implemented an application that does just that! It was back on Ethereal 0.10.3 and i had to modify Ethereal in a few ways: - Include a form of interprocess communication with the calling Monitor. (was done using Windows IPC, certainly not a good choice, but it was the fastest possible way for me to do), including an ABI for the monitoring taps to use it. - Make Ethereal report whenever it switched to a new capture file. (- Mayeb other things i don't remember any more) Problems i had to cope with: - Ethereal was leaking memory which caused problems when running for several days. My workaround was to have Monitor relaunch Ethereal every now and then. Obviously, keeping up with Wireshark's release frequency is difficult for me. That is why i'm asking wether there would be interest in redesigning, adding and maintaining the Wireshark related part to the Wireshark source tree? best regards, Lars Ruoff ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev __ --- NOTICE --- CONFIDENTIALITY - This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. Thank you. PERSONAL DATA PROTECTION (Law by Decree 30.06.2003 n. 196) - Personal and corporate data submitted will be used in a correct, transparent and lawful manner. The data collected will be processed in paper or computerized form for the performance of contractual and lawful obligations as well as for the effective management of business relationship. Data may be disclosed, in Italy or abroad, for the purpose above mentioned to third parties which cooperate with Telsey, agents, banks, factoring companies, credit recovering companies, credit insurance companies, professional and consultants, and shipping companies. In relation to the same purposes, data may be processed by the following classes of executors or processors: management; administration department; logistics and purchase department; sales department; post sales department quality department; RD department; IT department; legal department. The data processor is Telsey S.p.A. The data subject may exercise all the rights set forth in art. 7 of Law by Decree 30.06.2003 n. 196 as reported in in the following link http://www.telsey.it/privacy.jsp. __ 798t8RfNa6Dl8Ilf ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark and real-time network issue detection?
Hi, frederic heem wrote: Hi, Did you have a look at www.snort.org ? It may be what you are looking for. I had a look at it (although a short one i admit). From what i can see from a first glance, - snort provides nearly no means of decoding (and thus creating rules for) higher level protocols beyond transport layer? - snort's features for having user-defined decoding extensions are very limited? - i can't make rules that track conversations and do conversation-statefull statistics ? Wireshark provides all these features. Also, it is easy to add a new dissector to Wireshark in case i would like to detect issues on a proprietary protocol for example. Also, keep in mind that i want to save the *entire* network traffic that was going on at the time i had the problem, not only the packets i use for detection of the problem. But i don't want to log *all* network traffic over all time. Think of my RTP lost packets example again. If there is an easy way to do that with snort, i'd love to learn it. Lars frederic heem wrote: Hi, Did you have a look at www.snort.org ? It may be what you are looking for. Frederic Heem. Alle 15:03, lunedì 30 ottobre 2006, Lars Ruoff ha scritto: Hi list, I wonder if Wireshark could be extended to provide real-time network issue detection and if there was any interest in the community to implement this feature. Let me explain. What i would like to have is the following: Wireshark (tshark to be precise) would be run from another application (let's call it the Monitor application). There would be a form of interprocess communication between Wireshark and the latter. Wireshark would capture packets, decode them and run certain analysis modules (console style tap-listeners, as can be activated via the -z option). The analysis modules would be designed to detect alarm conditions that correspond to a certain network troubleshooting issue, for example, think of a module that monitors RTP voice conversations and reports whenever there is consecutive packet loss exceeding some threshold. Whenever an alarm condition is met, Wireshark would notify the Monitor application, and the latter would save the coresponding capture files. Wireshark would be run in multiple files option, but the Monitor would erase every written file after a while if no alarm condition has been met during that time. Only the capture files containing alarm conditions would be saved. The goal is to have the whole thing running over several days/weeks without filling up the HDD with unnecessary files. In fact i already have implemented an application that does just that! It was back on Ethereal 0.10.3 and i had to modify Ethereal in a few ways: - Include a form of interprocess communication with the calling Monitor. (was done using Windows IPC, certainly not a good choice, but it was the fastest possible way for me to do), including an ABI for the monitoring taps to use it. - Make Ethereal report whenever it switched to a new capture file. (- Mayeb other things i don't remember any more) Problems i had to cope with: - Ethereal was leaking memory which caused problems when running for several days. My workaround was to have Monitor relaunch Ethereal every now and then. Obviously, keeping up with Wireshark's release frequency is difficult for me. That is why i'm asking wether there would be interest in redesigning, adding and maintaining the Wireshark related part to the Wireshark source tree? best regards, Lars Ruoff ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev __ --- NOTICE --- CONFIDENTIALITY - This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. Thank you. PERSONAL DATA PROTECTION (Law by Decree 30.06.2003 n. 196) - Personal and corporate data submitted will be used in a correct, transparent and lawful manner. The data collected will be processed in paper or computerized form for the performance of contractual and lawful obligations as well as for the effective management of business relationship. Data may be disclosed, in Italy or abroad, for the purpose above mentioned to third parties which cooperate with Telsey, agents, banks, factoring companies, credit recovering companies, credit insurance companies, professional and consultants, and shipping companies. In relation to the same purposes, data may be processed by the following classes of executors or processors: management; administration department; logistics and purchase department;
Re: [Wireshark-dev] Help understanding Epan's dissectors
Hello, I understand that Wiretap passes the necessary information in pseudo-headers, but how does the following subdissections work? I mean, who finds out that an ethernet packet is IP, and from that, which one is TCP, and from that, which one belongs to whatever program... Thanks, Ramiro Polla Quoting Jaap Keuter [EMAIL PROTECTED]: Hi, Good question. For the answer you have to search further up the call chain. Lets see: file.c:add_packet_to_packet_list() epan/epan.c:epan_dissect_run() epan/packet.c:dissect_packet() epan/dissectors/packet-frame.c:dissect_frame() So when reading packets from a capture file, metadata (like wtap_encap) is available passed along with it for the frame dissector to use. It's up to the capture engine writing this capture file metadate to put the right stuff in there. Thanx, Jaap On Sun, 29 Oct 2006 [EMAIL PROTECTED] wrote: Hello, I've been studying Wireshark's source code for a while, but there's something I still don't understand. It's specifically about the inner workings of Epan. How does one dissectors knows and decides which subdissector is the correct one? Such as, how does frame know which wtap_encap is the correct one? Are there any probe functions around that I am missing? Thanks, Ramiro Polla ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark and real-time network issue detection?
Alle 15:32, lunedì 30 ottobre 2006, Lars Ruoff ha scritto: Hi, frederic heem wrote: Hi, Did you have a look at www.snort.org ? It may be what you are looking for. I had a look at it (although a short one i admit). Fine, at least you've had a look a it. Actually, I'm looking for the almost the same feature: The monitor asks tshark to be advised when a packet matches a filter. As soon as tshark received such a packet, it signals the application that has requested such packet. Some work has already been done. Basicely, it uses the D-Bus protocol as the IPC. At the moment, it is able to start and stop the capture, to set the network interface and the capture filename. What's remaining is setting the packet filter and signal the application when such a packet is received. Let me know if you're interested in collaborating on this project. Frederic Heem From what i can see from a first glance, - snort provides nearly no means of decoding (and thus creating rules for) higher level protocols beyond transport layer? - snort's features for having user-defined decoding extensions are very limited? - i can't make rules that track conversations and do conversation-statefull statistics ? Wireshark provides all these features. Also, it is easy to add a new dissector to Wireshark in case i would like to detect issues on a proprietary protocol for example. Also, keep in mind that i want to save the *entire* network traffic that was going on at the time i had the problem, not only the packets i use for detection of the problem. But i don't want to log *all* network traffic over all time. Think of my RTP lost packets example again. If there is an easy way to do that with snort, i'd love to learn it. Lars frederic heem wrote: Hi, Did you have a look at www.snort.org ? It may be what you are looking for. Frederic Heem. Alle 15:03, lunedì 30 ottobre 2006, Lars Ruoff ha scritto: Hi list, I wonder if Wireshark could be extended to provide real-time network issue detection and if there was any interest in the community to implement this feature. Let me explain. What i would like to have is the following: Wireshark (tshark to be precise) would be run from another application (let's call it the Monitor application). There would be a form of interprocess communication between Wireshark and the latter. Wireshark would capture packets, decode them and run certain analysis modules (console style tap-listeners, as can be activated via the -z option). The analysis modules would be designed to detect alarm conditions that correspond to a certain network troubleshooting issue, for example, think of a module that monitors RTP voice conversations and reports whenever there is consecutive packet loss exceeding some threshold. Whenever an alarm condition is met, Wireshark would notify the Monitor application, and the latter would save the coresponding capture files. Wireshark would be run in multiple files option, but the Monitor would erase every written file after a while if no alarm condition has been met during that time. Only the capture files containing alarm conditions would be saved. The goal is to have the whole thing running over several days/weeks without filling up the HDD with unnecessary files. In fact i already have implemented an application that does just that! It was back on Ethereal 0.10.3 and i had to modify Ethereal in a few ways: - Include a form of interprocess communication with the calling Monitor. (was done using Windows IPC, certainly not a good choice, but it was the fastest possible way for me to do), including an ABI for the monitoring taps to use it. - Make Ethereal report whenever it switched to a new capture file. (- Mayeb other things i don't remember any more) Problems i had to cope with: - Ethereal was leaking memory which caused problems when running for several days. My workaround was to have Monitor relaunch Ethereal every now and then. Obviously, keeping up with Wireshark's release frequency is difficult for me. That is why i'm asking wether there would be interest in redesigning, adding and maintaining the Wireshark related part to the Wireshark source tree? best regards, Lars Ruoff ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _ _ --- NOTICE --- CONFIDENTIALITY - This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. Thank you. PERSONAL DATA PROTECTION (Law by Decree 30.06.2003 n.
Re: [Wireshark-dev] [patch] YMSG dissector update
Did anybody have a chance to look over my patch?Gena01On 10/25/06, Gennady Feldman [EMAIL PROTECTED] wrote:
Here is an updated patch. Should be pretty safe. Just added a couple of constants and changed some strings to be cleaner and easier to read.
Gena01On 9/18/06,
Jaap Keuter [EMAIL PROTECTED] wrote:
Hi,Checked in, with the additional change in the version numberThanx,JaapOn Mon, 18 Sep 2006, Gena01 wrote: This should cover most of the services for Yahoo 7. (protocol version 13)
Gena On 9/18/06, Jaap Keuter [EMAIL PROTECTED] wrote:
Hi, So which protocol version is it supporting
i.s.o version 9? That should be stated in the header of the file. Thanx, Jaap On Mon, 18 Sep 2006, Gena01 wrote:My patchprovides new codes for the yahoo_status.I just didn't remove
the old constants. I guess it could be split into two parts: 1. New Service constants 2. New packet statuses which replace the old yahoo_status codes
Gena On 9/18/06, Jaap Keuter [EMAIL PROTECTED]
wrote: Hi,
This patch turns over the yahoo_status stuff completely. Sounds not verybackwards compatible to me? Thanx,
Jaap On Thu, 14 Sep 2006, Gena01 wrote:I am Yahoo plugin developer for Miranda IM
http://www.miranda-im.org I have put together a patch for YMSG packet dissector. This is based onmy own code and service lists (this should match Gaim and Kopete
service lists). This new code should bring the code up to par to most of theknown services. Which should cover up to Yahoo 7.x
or most of it.
I have also setup a new set of constants which are specific to YMSGpackets. These are the types that I've seen in miranda network logs and they
should reveal more information. The other constants are mostly for buddystatuses and need nor apply to the YMSG header.I have left them in the code
(for now). These constants are currently used in my own code. P.S. I haven't touched the copyright or author pieces, since I am
notsure how those should be updated. Thank you,
G.F. aka Gena01 ___Wireshark-dev mailing list
Wireshark-dev@wireshark.orghttp://www.wireshark.org/mailman/listinfo/wireshark-dev
___ Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev ___Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Index: packet-ymsg.c
===
--- packet-ymsg.c (revision 19694)
+++ packet-ymsg.c (working copy)
@@ -197,10 +197,12 @@
YPACKET_STATUS_DEFAULT = 0,
YPACKET_STATUS_SERVERACK = 1,
YPACKET_STATUS_GAME = 0x2,
+ YPACKET_STATUS_AWAY = 0x4,
YPACKET_STATUS_CONTINUED = 0x5,
YPACKET_STATUS_INVISIBLE = 12,
YPACKET_STATUS_NOTIFY = 0x16, /* TYPING */
- YPACKET_STATUS_WEBLOGIN = 0x5a55aa55
+ YPACKET_STATUS_WEBLOGIN = 0x5a55aa55,
+ YPACKET_STATUS_OFFLINE = 0x5a55aa56
};
struct yahoo_rawpacket
@@ -233,7 +235,7 @@
{YAHOO_SERVICE_ADDIDENT, Add Identity},
{YAHOO_SERVICE_ADDIGNORE, Add Ignore},
{YAHOO_SERVICE_PING, Ping},
- {YAHOO_SERVICE_GOTGROUPRENAME, YAHOO_SERVICE_GOTGROUPRENAME},
+ {YAHOO_SERVICE_GOTGROUPRENAME, Got Group Rename},
{YAHOO_SERVICE_SYSMESSAGE, System Message},
{YAHOO_SERVICE_SKINNAME, YAHOO_SERVICE_SKINNAME},
{YAHOO_SERVICE_PASSTHROUGH2, Passthrough 2},
@@ -251,51 +253,51 @@
{YAHOO_SERVICE_GAMEMSG, Game Message},
{YAHOO_SERVICE_FILETRANSFER, File Transfer},
{YAHOO_SERVICE_VOICECHAT, Voice Chat},
- {YAHOO_SERVICE_NOTIFY, YAHOO_SERVICE_NOTIFY},
- {YAHOO_SERVICE_VERIFY, YAHOO_SERVICE_VERIFY},
- {YAHOO_SERVICE_P2PFILEXFER, YAHOO_SERVICE_P2PFILEXFER},
- {YAHOO_SERVICE_PEERTOPEER, YAHOO_SERVICE_PEERTOPEER},
- {YAHOO_SERVICE_WEBCAM, YAHOO_SERVICE_WEBCAM},
- {YAHOO_SERVICE_AUTHRESP, YAHOO_SERVICE_AUTHRESP},
- {YAHOO_SERVICE_LIST, YAHOO_SERVICE_LIST},
- {YAHOO_SERVICE_AUTH, YAHOO_SERVICE_AUTH},
- {YAHOO_SERVICE_ADDBUDDY, YAHOO_SERVICE_ADDBUDDY},
- {YAHOO_SERVICE_REMBUDDY, YAHOO_SERVICE_REMBUDDY},
- {YAHOO_SERVICE_IGNORECONTACT, YAHOO_SERVICE_IGNORECONTACT},
- {YAHOO_SERVICE_REJECTCONTACT, YAHOO_SERVICE_REJECTCONTACT},
- {YAHOO_SERVICE_GROUPRENAME, Group Renamed},
- {YAHOO_SERVICE_CHATONLINE, YAHOO_SERVICE_CHATONLINE},
- {YAHOO_SERVICE_CHATGOTO, YAHOO_SERVICE_CHATGOTO},
- {YAHOO_SERVICE_CHATJOIN, YAHOO_SERVICE_CHATJOIN},
- {YAHOO_SERVICE_CHATLEAVE, YAHOO_SERVICE_CHATLEAVE},
- {YAHOO_SERVICE_CHATEXIT, YAHOO_SERVICE_CHATEXIT},
- {YAHOO_SERVICE_CHATADDINVITE, YAHOO_SERVICE_CHATADDINVITE},
- {YAHOO_SERVICE_CHATLOGOUT, YAHOO_SERVICE_CHATLOGOUT},
- {YAHOO_SERVICE_CHATPING, YAHOO_SERVICE_CHATPING},
- {YAHOO_SERVICE_COMMENT, YAHOO_SERVICE_COMMENT},
- {YAHOO_SERVICE_GAME_INVITE,YAHOO_SERVICE_GAME_INVITE },
-
[Wireshark-dev] Is using a locally defined (ie defined in the function) memory , to store the structure elements in tvb --safer?
Hi, When ever we need to alter the data that is on tvb, we need to copy the data in to our memory. So would it be safer to copy the data from tvb to the local memory ( ie stack memory ) always? I guess ethereal always has a copy of the local memory contents that we add to the display tree. So this avoids the dangling reference issues. So is using the heap memory to copy the contents from the tvb totally discouraged by the ethereal? I've written the code in such a way that i dont need to store the data for later reference. But at some places I've still used g_malloc( ) to allocate the memory ( I've an older version of ethereal and it does not support the ep_alloc ( ) ). So now i can just use locally defined array to store the tvb data? And if I want to freee the memory allocated by the g_malloc( ) , when shall i free that in ethereal that is at what part of theethereal code i need to include the memory deletion. Regards, Prashanth.Jaap Keuter [EMAIL PROTECTED] wrote:Hi,You're getting the host format and transport format mixed up. The hostformat is based on the architecture for the platfom the code runs on. Thetransport format is defined by the protocol used to communicate. Betweenthe two there is to be a translation layer, like the infamousnetinet/in.h macro's ntohs, ntohl, etc. If you want to transportstructured data, you'll have to define your translation layer for that aswell. Depening on eg. Basic Encoding Rules for your transport format, youmost likely can get libraries to do that for you.Now, if you look at wireshark, it reads directly from the wire, so alwaystransport format. That is defined by protocol, not host format. If youwant to do more fancy stuff you have to use tvb_get_ntohs() and friends tomake this translation for you.Thanx,JaapOn Sat, 28 Oct 2006, prashanth joshi wrote: Hi, Suppose the tvb contains a structure and we are supposed to add the structure elements one by one in to the display tree. Suppose the structure has the following elements: char int char int. Now my thinking is , We can not add directly the first item ie char item in to the display tree(using the proto_tree_add_item specifying offset and the length to be added as 1) and then again we can not add directly the second item ie int in to the display tree ( this time offset + 1 and then the length to be added as 4 ) and so on... The reason for my thinking is: The structures are padded. So the tvb may actually be containing char 4 bytes int 4 bytes char 4 bytes int 4 bytes And then I feel structue padding is platform dependent. Hence I feel it should be correct first to memcpy the contents using tvb_memcpy from the tvb to a dynamically allocated object. Because i feel the tvb_memcpy takes care of the platform independece issues. And then i feel we can add the structure elements one by one using the proto_tree_add_item(offset , length to be added as 1 ) and then using, proto_tree_add_item(offset + 1, length to be added as 4). Is my assertion about this structure padding and tvb_memcpy correct? That is when ever we get a structure in tvb we should not directly add its elements directly to the display tree but we should first memcpy the contents of the tvb using tvb_memcpy, to an alllocated structure object and then we should add the elements one by one in to the display tree? Or is this just an imagination of mine.? And one more thing when ever we need to alter the data we need to copy the data in to our memory right? So would it be safer to copy the data from tvb to the local memory ( ie stack memory ) always? I guess ethereal always has a copy of the local memory contents that we add to the display tree. So this avoids the dangling reference issues. So is using the heap memory to copy the contents from the tvb totally discouraged by the ethereal? I've written the code in such a way that i dont need to store the data for later reference. But at some places I've still used g_malloc( ) to allocate the memory ( I've an older version of ethereal and it does not support the ep_alloc ( ) ). So now i can just use locally defined array to store the tvb data? And if I want to freee the memory allocated by the g_malloc( ) , when shall i free that in ethereal. Regards, Prashanth.___Wireshark-dev mailing listWireshark-dev@wireshark.orghttp://www.wireshark.org/mailman/listinfo/wireshark-dev How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.___Wireshark-dev mailing listWireshark-dev@wireshark.orghttp://www.wireshark.org/mailman/listinfo/wireshark-dev Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark and real-time network issue detection?
frederic heem wrote: Actually, I'm looking for the almost the same feature: The monitor asks tshark to be advised when a packet matches a filter. As soon as tshark received such a packet, it signals the application that has requested such packet. That would be a special (trivial) case of my general concept: A filter and a tap which fires the alarm every time it is called. Some work has already been done. Basicely, it uses the D-Bus protocol as the IPC. Don't know D-Bus. At the first glance it looks like overkill to me, but why not. At the moment, it is able to start and stop the capture, to set the network interface and the capture filename. I did this simply via the command line args. I introduced additional command line args for the special taps. Style -z my_tap my_tap_arguments What's remaining is setting the packet filter and signal the application when such a packet is received. Let me know if you're interested in collaborating on this project. Frederic Heem Sure, i am! (Don't have the time to work full-time on it though) br, Lars Ruoff From what i can see from a first glance, - snort provides nearly no means of decoding (and thus creating rules for) higher level protocols beyond transport layer? - snort's features for having user-defined decoding extensions are very limited? - i can't make rules that track conversations and do conversation-statefull statistics ? Wireshark provides all these features. Also, it is easy to add a new dissector to Wireshark in case i would like to detect issues on a proprietary protocol for example. Also, keep in mind that i want to save the *entire* network traffic that was going on at the time i had the problem, not only the packets i use for detection of the problem. But i don't want to log *all* network traffic over all time. Think of my RTP lost packets example again. If there is an easy way to do that with snort, i'd love to learn it. Lars frederic heem wrote: Hi, Did you have a look at www.snort.org ? It may be what you are looking for. Frederic Heem. Alle 15:03, lunedì 30 ottobre 2006, Lars Ruoff ha scritto: Hi list, I wonder if Wireshark could be extended to provide real-time network issue detection and if there was any interest in the community to implement this feature. Let me explain. What i would like to have is the following: Wireshark (tshark to be precise) would be run from another application (let's call it the Monitor application). There would be a form of interprocess communication between Wireshark and the latter. Wireshark would capture packets, decode them and run certain analysis modules (console style tap-listeners, as can be activated via the -z option). The analysis modules would be designed to detect alarm conditions that correspond to a certain network troubleshooting issue, for example, think of a module that monitors RTP voice conversations and reports whenever there is consecutive packet loss exceeding some threshold. Whenever an alarm condition is met, Wireshark would notify the Monitor application, and the latter would save the coresponding capture files. Wireshark would be run in multiple files option, but the Monitor would erase every written file after a while if no alarm condition has been met during that time. Only the capture files containing alarm conditions would be saved. The goal is to have the whole thing running over several days/weeks without filling up the HDD with unnecessary files. In fact i already have implemented an application that does just that! It was back on Ethereal 0.10.3 and i had to modify Ethereal in a few ways: - Include a form of interprocess communication with the calling Monitor. (was done using Windows IPC, certainly not a good choice, but it was the fastest possible way for me to do), including an ABI for the monitoring taps to use it. - Make Ethereal report whenever it switched to a new capture file. (- Mayeb other things i don't remember any more) Problems i had to cope with: - Ethereal was leaking memory which caused problems when running for several days. My workaround was to have Monitor relaunch Ethereal every now and then. Obviously, keeping up with Wireshark's release frequency is difficult for me. That is why i'm asking wether there would be interest in redesigning, adding and maintaining the Wireshark related part to the Wireshark source tree? best regards, Lars Ruoff ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _ _ --- NOTICE --- CONFIDENTIALITY - This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not
Re: [Wireshark-dev] Help understanding Epan's dissectors
Hi, Ah, so all is clear on the wiretap front. Well from there on (look in packet-frame.c) the frame dissector looks in wtap_encap_dissector_table for the dissector handling Ethernet (in this case). This dissector (see packet-eth.c) has registered itself during startup in this table (search for wtap_encap) with the wiretap encapsulation for Ethernet. Therefor it well be selected to decode the next part of the frame. The Ethernet dissector itself knows where to look for the Ethertype (see packet-ethertype.c) in the frame and finds the IP protocol dissector (in this case). Therefor it well be selected to decode the next part of the frame. The IP dissector itself knows where to look for the Protocol (see packet-ip.c) in the frame .. Etc etc etc. So it all depends on the dissectors which register themselves to a lower level dissector to handle a certain protocol. This can be via a dissector table (like frame uses) or, if there is no specific field which describes the next layer protocol (like a UDP payload), via a registration based on certain aspects of the lower layer protocol. Like the bootp dissector (see packet-bootp.c), which registers itself for udp.port 67 and 68. In this the design of Wireshark mimics the protocol stack model perfectly and makes it so extensible. Thanx, Jaap On Mon, 30 Oct 2006 [EMAIL PROTECTED] wrote: Hello, I understand that Wiretap passes the necessary information in pseudo-headers, but how does the following subdissections work? I mean, who finds out that an ethernet packet is IP, and from that, which one is TCP, and from that, which one belongs to whatever program... Thanks, Ramiro Polla Quoting Jaap Keuter [EMAIL PROTECTED]: Hi, Good question. For the answer you have to search further up the call chain. Lets see: file.c:add_packet_to_packet_list() epan/epan.c:epan_dissect_run() epan/packet.c:dissect_packet() epan/dissectors/packet-frame.c:dissect_frame() So when reading packets from a capture file, metadata (like wtap_encap) is available passed along with it for the frame dissector to use. It's up to the capture engine writing this capture file metadate to put the right stuff in there. Thanx, Jaap On Sun, 29 Oct 2006 [EMAIL PROTECTED] wrote: Hello, I've been studying Wireshark's source code for a while, but there's something I still don't understand. It's specifically about the inner workings of Epan. How does one dissectors knows and decides which subdissector is the correct one? Such as, how does frame know which wtap_encap is the correct one? Are there any probe functions around that I am missing? Thanks, Ramiro Polla ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [patch] YMSG dissector update
Hi, Checked in. Thanx, Jaap On Mon, 30 Oct 2006, Gennady Feldman wrote: Did anybody have a chance to look over my patch? Gena01 On 10/25/06, Gennady Feldman [EMAIL PROTECTED] wrote: Here is an updated patch. Should be pretty safe. Just added a couple of constants and changed some strings to be cleaner and easier to read. Gena01 On 9/18/06, Jaap Keuter [EMAIL PROTECTED] wrote: Hi, Checked in, with the additional change in the version number Thanx, Jaap On Mon, 18 Sep 2006, Gena01 wrote: This should cover most of the services for Yahoo 7. (protocol version 13) Gena On 9/18/06, Jaap Keuter [EMAIL PROTECTED] wrote: Hi, So which protocol version is it supporting i.s.o version 9? That should be stated in the header of the file. Thanx, Jaap On Mon, 18 Sep 2006, Gena01 wrote: My patch provides new codes for the yahoo_status. I just didn't remove the old constants. I guess it could be split into two parts: 1. New Service constants 2. New packet statuses which replace the old yahoo_status codes Gena On 9/18/06, Jaap Keuter [EMAIL PROTECTED] wrote: Hi, This patch turns over the yahoo_status stuff completely. Sounds not very backwards compatible to me? Thanx, Jaap On Thu, 14 Sep 2006, Gena01 wrote: I am Yahoo plugin developer for Miranda IM http://www.miranda-im.org I have put together a patch for YMSG packet dissector. This is based on my own code and service lists (this should match Gaim and Kopete service lists). This new code should bring the code up to par to most of the known services. Which should cover up to Yahoo 7.x or most of it. I have also setup a new set of constants which are specific to YMSG packets. These are the types that I've seen in miranda network logs and they should reveal more information. The other constants are mostly for buddy statuses and need nor apply to the YMSG header. I have left them in the code (for now). These constants are currently used in my own code. P.S. I haven't touched the copyright or author pieces, since I am not sure how those should be updated. Thank you, G.F. aka Gena01 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Help understanding Epan's dissectors
Hello, I think I get it now. It is not the higher level dissectors that actively search for lower lever dissectors in their source file. It is the lower level dissectors that register themselves with all possible higher lever dissectors where they might occur. So the packet-*.c files don't probe for anything, they only dissect, and explain their values (like udp.port). After a dissector has finished doing its work, some function will search in its list of possibilities for the most correct sub-dissector. Now, how does the library decide, in the list of possibilities, which is the most correct sub-dissector? I've looked some into call_dissector_work and functions like that, but I don't quite understand how that's done. Thanks, Ramiro Polla Quoting Jaap Keuter [EMAIL PROTECTED]: Hi, Ah, so all is clear on the wiretap front. Well from there on (look in packet-frame.c) the frame dissector looks in wtap_encap_dissector_table for the dissector handling Ethernet (in this case). This dissector (see packet-eth.c) has registered itself during startup in this table (search for wtap_encap) with the wiretap encapsulation for Ethernet. Therefor it well be selected to decode the next part of the frame. The Ethernet dissector itself knows where to look for the Ethertype (see packet-ethertype.c) in the frame and finds the IP protocol dissector (in this case). Therefor it well be selected to decode the next part of the frame. The IP dissector itself knows where to look for the Protocol (see packet-ip.c) in the frame .. Etc etc etc. So it all depends on the dissectors which register themselves to a lower level dissector to handle a certain protocol. This can be via a dissector table (like frame uses) or, if there is no specific field which describes the next layer protocol (like a UDP payload), via a registration based on certain aspects of the lower layer protocol. Like the bootp dissector (see packet-bootp.c), which registers itself for udp.port 67 and 68. In this the design of Wireshark mimics the protocol stack model perfectly and makes it so extensible. Thanx, Jaap On Mon, 30 Oct 2006 [EMAIL PROTECTED] wrote: Hello, I understand that Wiretap passes the necessary information in pseudo-headers, but how does the following subdissections work? I mean, who finds out that an ethernet packet is IP, and from that, which one is TCP, and from that, which one belongs to whatever program... Thanks, Ramiro Polla Quoting Jaap Keuter [EMAIL PROTECTED]: Hi, Good question. For the answer you have to search further up the call chain. Lets see: file.c:add_packet_to_packet_list() epan/epan.c:epan_dissect_run() epan/packet.c:dissect_packet() epan/dissectors/packet-frame.c:dissect_frame() So when reading packets from a capture file, metadata (like wtap_encap) is available passed along with it for the frame dissector to use. It's up to the capture engine writing this capture file metadate to put the right stuff in there. Thanx, Jaap On Sun, 29 Oct 2006 [EMAIL PROTECTED] wrote: Hello, I've been studying Wireshark's source code for a while, but there's something I still don't understand. It's specifically about the inner workings of Epan. How does one dissectors knows and decides which subdissector is the correct one? Such as, how does frame know which wtap_encap is the correct one? Are there any probe functions around that I am missing? Thanks, Ramiro Polla ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Help understanding Epan's dissectors
Hi,
See the frame dissector in packet-frame.c for instance. It uses this line:
if (!dissector_try_port(wtap_encap_dissector_table, pinfo-fd-lnk_t,
tvb, pinfo, parent_tree)) {
It uses wtap_encap_dissector_table to search for the pinfo-fd-lnk_t
entry and calls that dissector (oke it's called try_port since it's
normally used for port based searches, but the idea is the same).
Another way to do this is with heuristic dissectors. More dissectors are
registered for the same lets say UDP port. Now they are called 'in random
order' and the first one that says it recognizes the packet can dissect
it. Chances are it's wrong, but then all we can do is improve the
heuristics of that dissector.
Thanx,
Jaap
On Mon, 30 Oct 2006 [EMAIL PROTECTED] wrote:
Hello,
I think I get it now. It is not the higher level dissectors that
actively search for lower lever dissectors in their source file. It is
the lower level dissectors that register themselves with all possible
higher lever dissectors where they might occur. So the packet-*.c
files don't probe for anything, they only dissect, and explain their
values (like udp.port). After a dissector has finished doing its
work, some function will search in its list of possibilities for the
most correct sub-dissector.
Now, how does the library decide, in the list of possibilities, which
is the most correct sub-dissector? I've looked some into
call_dissector_work and functions like that, but I don't quite
understand how that's done.
Thanks,
Ramiro Polla
Quoting Jaap Keuter [EMAIL PROTECTED]:
Hi,
Ah, so all is clear on the wiretap front. Well from there on (look in
packet-frame.c) the frame dissector looks in wtap_encap_dissector_table
for the dissector handling Ethernet (in this case). This dissector (see
packet-eth.c) has registered itself during startup in this table (search
for wtap_encap) with the wiretap encapsulation for Ethernet. Therefor it
well be selected to decode the next part of the frame.
The Ethernet dissector itself knows where to look for the Ethertype (see
packet-ethertype.c) in the frame and finds the IP protocol dissector (in
this case). Therefor it well be selected to decode the next part of the
frame.
The IP dissector itself knows where to look for the Protocol (see
packet-ip.c) in the frame ..
Etc etc etc.
So it all depends on the dissectors which register themselves to a lower
level dissector to handle a certain protocol. This can be via a dissector
table (like frame uses) or, if there is no specific field which describes
the next layer protocol (like a UDP payload), via a registration based on
certain aspects of the lower layer protocol. Like the bootp dissector
(see packet-bootp.c), which registers itself for udp.port 67 and 68.
In this the design of Wireshark mimics the protocol stack model perfectly
and makes it so extensible.
Thanx,
Jaap
On Mon, 30 Oct 2006 [EMAIL PROTECTED] wrote:
Hello,
I understand that Wiretap passes the necessary information in
pseudo-headers, but how does the following subdissections work? I
mean, who finds out that an ethernet packet is IP, and from that,
which one is TCP, and from that, which one belongs to whatever
program...
Thanks,
Ramiro Polla
Quoting Jaap Keuter [EMAIL PROTECTED]:
Hi,
Good question. For the answer you have to search further up the call
chain. Lets see:
file.c:add_packet_to_packet_list()
epan/epan.c:epan_dissect_run()
epan/packet.c:dissect_packet()
epan/dissectors/packet-frame.c:dissect_frame()
So when reading packets from a capture file, metadata (like wtap_encap)
is
available passed along with it for the frame dissector to use. It's up to
the capture engine writing this capture file metadate to put the right
stuff in there.
Thanx,
Jaap
On Sun, 29 Oct 2006 [EMAIL PROTECTED] wrote:
Hello,
I've been studying Wireshark's source code for a while, but there's
something I still don't understand. It's specifically about the inner
workings of Epan. How does one dissectors knows and decides which
subdissector is the correct one?
Such as, how does frame know which wtap_encap is the correct one?
Are there any probe functions around that I am missing?
Thanks,
Ramiro Polla
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
[Wireshark-dev] Fwd: Bug #1138 fix: 'Follow TP streams gets stream direction wrong...
Anyone get a chance to review this patch for inclusion? Thanks!
- Forwarded message from Stephen Fisher [EMAIL PROTECTED] -
Date: Wed, 25 Oct 2006 20:05:25 -0700
From: Stephen Fisher [EMAIL PROTECTED]
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Bug #1138 fix: 'Follow TP streams gets stream
direction wrong...
Attached is a patch to fix bug #1138: Follow TCP Streams gets stream
direction wrong if started from a server-client frame.
THE PROBLEM: The drop-down list of which direction's flow you want to
see is based on the source port of the currently selected packet. The
actual text is based on a temporary file that starts with follow. If
you clicked on a packet from the server back to the client, the source
port would be of the server not the client. This caused the drop-down
list's results to be the reverse of what it shows. When you clicked on
a packet from client to server, it works correctly.
MY SOLUTION: I rewind() back to the top of the follow text file after
writing it to get the client's source port (the first line written to
the file). I compare the first packet's source port to the source port
of the currently selected packet and reverse the output in the drop-down
if they don't match. This causes the drop-down box to always be tied to
the correct data above. The client-server is always shown first in the
drop-down.
Thanks,
Steve
Index: gtk/follow_dlg.c
===
--- gtk/follow_dlg.c(revision 19694)
+++ gtk/follow_dlg.c(working copy)
@@ -176,6 +176,7 @@
charstring[128];
follow_tcp_stats_t stats;
follow_info_t *follow_info;
+ tcp_stream_chunk sc;
/* we got tcp so we can follow */
if (cfile.edt-pi.ipproto != IP_PROTO_TCP) {
@@ -206,7 +207,7 @@
return;
}
- data_out_file = fdopen(tmp_fd, wb);
+ data_out_file = fdopen(tmp_fd, w+b);
if (data_out_file == NULL) {
simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK,
Could not create temporary file %s: %s,
@@ -256,9 +257,6 @@
/* Free the filter string, as we're done with it. */
g_free(follow_filter);
- /* The data_out_file should now be full of the streams information */
- fclose(data_out_file);
-
/* The data_out_filename file now has all the text that was in the
session */
streamwindow = dlg_window_new(Follow TCP Stream);
@@ -361,10 +359,28 @@
gtk_widget_show(stream_mi);
follow_info-show_stream = BOTH_HOSTS;
+ /* Go back to the top of the file and read the first tcp_stream_chunk
+* to ensure that the IP addresses and port numbers in the drop-down
+* list are tied to the correct lines displayed by follow_read_stream()
+* later on (which also reads from this file). Close the file when
+* we're done.
+*/
+
+ rewind(data_out_file);
+ fread(sc, 1, sizeof(sc), data_out_file);
+ fclose(data_out_file);
+
/* Host 0 -- Host 1 */
- g_snprintf(string, sizeof(string), %s:%s -- %s:%s (%u bytes),
-hostname0, port0, hostname1, port1,
-stats.bytes_written[0]);
+ if(sc.src_port == strtol(port0, NULL, 10)) {
+ g_snprintf(string, sizeof(string), %s:%s -- %s:%s (%u bytes),
+ hostname0, port0, hostname1, port1,
+ stats.bytes_written[0]);
+ } else {
+ g_snprintf(string, sizeof(string), %s:%s -- %s:%s (%u bytes),
+ hostname1, port1, hostname0, port0,
+ stats.bytes_written[0]);
+ }
+
stream_mi = gtk_menu_item_new_with_label(string);
SIGNAL_CONNECT(stream_mi, activate, follow_stream_om_client,
follow_info);
@@ -372,9 +388,16 @@
gtk_widget_show(stream_mi);
/* Host 1 -- Host 0 */
- g_snprintf(string, sizeof(string), %s:%s -- %s:%s (%u bytes),
-hostname1, port1, hostname0, port0,
-stats.bytes_written[1]);
+ if(sc.src_port == strtol(port0, NULL, 10)) {
+ g_snprintf(string, sizeof(string), %s:%s -- %s:%s (%u bytes),
+ hostname1, port1, hostname0, port0,
+ stats.bytes_written[1]);
+ } else {
+ g_snprintf(string, sizeof(string), %s:%s -- %s:%s (%u bytes),
+ hostname0, port0, hostname1, port1,
+ stats.bytes_written[1]);
+ }
+
stream_mi = gtk_menu_item_new_with_label(string);
SIGNAL_CONNECT(stream_mi, activate, follow_stream_om_server,
follow_info);
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
- End forwarded message -
