Re: [Wireshark-dev] Gently migrating to Git + Gerrit
On Thu, Aug 8, 2013 at 1:21 PM, Evan Huus eapa...@gmail.com wrote: Similarly on Mac, it would be nice if the macosx-setup.sh script could as much as possible be replaced with a set of homebrew packages (or some other equivalent). +1 on that -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Epan Memory Leaks
On Sat, Jul 6, 2013 at 2:05 PM, Evan Huus eapa...@gmail.com wrote: This morning, wmem finally hit the point that I was able to land some changes to reduce leaks when calling epan_cleanup(). Yesterday, running valgrind on 'tshark -v' showed over 500KB of leaked memory. Now it shows 1,722 bytes. WOW! Cleaning up those last few leaks will be enormously useful, both for spotting real leaks (we might even be able to fuzz-test with leak-checking some day!) and to make epan behave more like an actual library. However, most of the remaining leaks aren't in dissector code but in subsystems which I know less about, so I am not as confident that simply using epan-scoped memory is the right thing to do. If you're on a platform with valgrind, you can see the remaining leaks by running: ./tools/valgrind-wireshark.sh -l -n If not, here's a brief summary of which subsystems are still problematic. - preferences (a lot of small string leaks, mostly in pre_init_prefs.part.3 and register_string_like_preference) - xml parser (I cleaned up the xml dissector, but the lemon grammar itself seems to be leaking) It is actually in the dtd loader, not in the grammar itself. These are mine and my memory still holds that I deliberatly left them there as every time I tried to fixed I got something else broken, the code for loading the dtd has to be refatored to make sure we know if we can free these items, currently if you try to free them you end up freeing something wrong. I left them there as they are not while running but just a few blocks leaked at start. - user-accessible tables (various leaks in functions called from uat_load_lex in uat_load.l) This most probably are mine but diversely from the dtd ones I was not aware... Another una-tantum leak BTW, not incremental while running. - oids_init More code of mine... yet some more una-tantum leaks at init... It looks like I made a habit then... - capture_column_init_cb Feel free to ping me for more details (including stack traces) if you want to help hunt down some leaks. Cheers, Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wiretap subfiles
Wiretap subfiles are to be indexes of one or more capture files (the source) that (as long as they correctly reference the source) transparently work as if they were a a single capture file with the features of the source. I think they should contain a magic number, the source filename(s), basic common information from the source and a list of file_ids, framenums and offsets realitve to the source. They came to my mind thinking on how to make a handover between two epan processes so that known open transactions were not dropped when a new process starts, starting with a file with just the packets that contain that information would be the easiest way to come with it. But they can be used for tons of other things: - small (low disk use) saves of filter results (you just email the packet list back, not the file with the packets) - can be used as offset cache in wtap for speeding file operations - add your own here... I believe the implementation is a simple matter (not much more than 600 lines of code) And I'll be starting work on it in few weeks from now unless someone beats me at it. Any Ideas? -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 50198: /trunk/ui/qt/ /trunk/ui/qt/: capture_preferences_frame.cpp interface_tree.cpp main.cpp main_window_slots.cpp
I (proudly) still use vi... for quick edits and commit messages... :) On Thu, Jun 27, 2013 at 2:40 PM, Maynard, Chris christopher.mayn...@gtech.com wrote: So I guess you use vi as an editor ... but maybe not this time? :) I've done that from time to time as well when switching from vi to some other editor. - Chris -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto: wireshark-commits-boun...@wireshark.org] On Behalf Of l...@wireshark.org Sent: Thursday, June 27, 2013 3:25 PM To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 50198: /trunk/ui/qt/ /trunk/ui/qt/: capture_preferences_frame.cpp interface_tree.cpp main.cpp main_window_slots.cpp http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=50198 User: lego Date: 2013/06/27 12:24 PM Log: Propagate the main_window_update change of few commits ago into the qt client :wq Directory: /trunk/ui/qt/ ChangesPath Action +2 -1 capture_preferences_frame.cppModified +2 -1 interface_tree.cpp Modified +2 -2 main.cpp Modified +2 -1 main_window_slots.cppModified CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your system and notify the sender by replying to this email. Thank you. ___ Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org ?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] JSONshark -- Was: Applying for GSOC
The starting point is to define a message based interface for using epan. I believe the best place for doing that is the wiki with the help of the other developpers. Then there's the architechture of the system itself. For which I think we have two or three sub-projects here. I believe more people should come in if we want it done in a summer. For the server: My idea is a concurrent server (one that forks as epan cannot run concurrently) that uses websockets. That needs a c program that uses epan and talks JSON via stdin and stdout. Something similar to tshark, but interactive, that uses JSON encoding. And a wrapper for it that invokes it and mantains it, running on an http server. For that can use node.js (http://nodejs.org) and socket.io ( http://socket.io/). Or some other server... Or we could implement our own server in c. For the client we need an html/javascript application that uses our server. There should be a javascript library plus a set of labeled html templates, and a program that using them interacts with the server. \Lego On Tue, Apr 9, 2013 at 11:35 PM, Sumit Toshniwal sumittoshniwa...@gmail.com wrote: Sir I am interested in JSONshark ( A dual project: a JSON message based interface to epan (Wireshark's dissection core), and a Javascript Browser App to control it.) Please Suggest me where should I start…. ** ** ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GUI functionality from plugins
Actually, funnel.h implements some GUI functionality that can be used by plugins. More functionality can be added to it. On Wed, Sep 19, 2012 at 9:34 AM, David Ameiss netsh...@ameissnet.com wrote: Summary: I'd like to propose implementing a method of making GUI functionality more accessible from plugins. We have developed plugin dissectors for our internal protocols, all of which are built on top of UDP and TCP. In addition, we've developed several analytical tools within the plugin. One in particular is modeled after the TCP flowgraph, and actually uses the graph_analysis.c functions to show flows at the sub-frame level. A little explanation: We have a class of messages that allow one process to unicast a message to another process. These are TCP, but are not treated as bidirectional (for a number of reasons which aren't important here). So a conversation between two such processes (actually, objects within a process, identified by IP, port, and domain, which is a designator used for forwarding) really involves a TCP connection from A to B, then another from B to A. Each such message contains information about the destination (domain, IP, and port), as well as where it is coming from (domain, IP, and port). In a LAN, everyone is in the same domain, so things are easy. However, much of our communication takes place across a WAN, between domains, and gateway processes are used to bridge these domains. So while the ultimate destination of a message is a specific domain, IP, and port, the message may actually be sent to a gateway at a different domain, IP, and port. Hence the destination and source embedded in the message. To complicate matters, multiple processes in one domain may be sending messages to multiple processes in other domains, all sent via the intervening gateway, and possibly multiple intervening gateways, depending on where the destination domain actually is. So messages are multiplexed together between gateways. This is not really ground-breaking, I know. What we have done is implement a flow-graph that identifies individual conversations (not really the right word in terms of wireshark), and follows them as they traverse possibly multiple gateway nodes. This is incredibly useful, as you might imagine. This has been implemented following the TCP flowgraph model, which involves a tap listener (the part of the dissector actually doing the dissection queues tap packets - actually, since the protocol allows multiple messages per frame, it can queue multiple tap entries per frame. The fundamental problem is that, in order to retap the capture, the plugin needs access to cfile, which is defined in the Wireshark executable. This works on Linux and OSX - but not on Windows, because cfile isn't exported. And I think there are some issues with making symbols from an executable exported for use by Windows DLLs - probably a solvable problem, but also probably not easily. Yes, I know the best approach is to put our dissectors in the Wireshark distribution, change from a plugin to a built-in, etc. I've been pushing that for nearly 2 years. But that's a political issue, and it appears that the path of least resistance is not to make a decision. So we're stuck with that for now. One idea that occurred to me is the possibility of passing to a dissector a parameter which gives (controlled) access to some things inside wireshark/tshark. Possibly as a parameter to proto_register_XXX() or proto_reg_handoff_XXX(). My thinking is along the lines of a structure which contains either pointers to variables or callbacks which allow the variables to be accessed. At minimum, for our purposes, a way to get at cfile is needed. I'm sure others will have ideas for additional items. And down the road, as Wireshark moves to a more generic GUI interface (as it seems to be doing), this could give access to the various GUI components (such as adding menu entries, although this can be done now via funnel_register_menu()). I realize the dissector/GUI split is useful, but I also know it is not in concrete (the asn1 plugin, for example, creates windows). Short of integrating our (admittedly application-specific) dissectors into Wireshark itself, which isn't currently an option, the only way to provide the analytical functionality is via GUI in the plugin. I would appreciate any comments. -- David Ameiss netsh...@ameissnet.com ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:
Re: [Wireshark-dev] Possible memory leak in ui/gtk/funnel_stat.c:funnel_new_dialog and funnel_dlg_cb
the bellow patch should work...
needs to be compiled and tested...
Index: funnel_stat.c
===
--- funnel_stat.c (revision 43689)
+++ funnel_stat.c (working copy)
@@ -405,14 +405,16 @@
window_destroy(GTK_WIDGET(dd-win));
g_ptr_array_free(returns,FALSE);
+g_free(dd);
return TRUE;
}
static void funnel_cancel_btn_cb(GtkWidget *bt _U_, gpointer data) {
-GtkWidget* win = data;
+struct _funnel_dlg_data* dd = data;
-window_destroy(GTK_WIDGET(win));
+window_destroy(GTK_WIDGET(dd-win));
+g_free(dd);
}
static void funnel_new_dialog(const gchar* title,
@@ -467,7 +469,7 @@
gtk_widget_grab_default(bt_ok);
bt_cancel = g_object_get_data(G_OBJECT(bbox), GTK_STOCK_CANCEL);
-g_signal_connect(bt_cancel, clicked,
G_CALLBACK(funnel_cancel_btn_cb), win);
+g_signal_connect(bt_cancel, clicked,
G_CALLBACK(funnel_cancel_btn_cb), dd);
gtk_widget_grab_default(bt_cancel);
gtk_widget_show(main_tb);
On Thu, Jul 12, 2012 at 11:19 PM, Richard Sharpe
realrichardsha...@gmail.com wrote:
Hi folks,
In funnel_new_dlg we allocate a structure:
struct _funnel_dlg_data* dd = g_malloc(sizeof(struct _funnel_dlg_data));
However, we never seem to free it.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] emem.c:732: failed assertion [sort-of-SOLVED]
On Mon, Mar 1, 2010 at 3:38 PM, varname varn...@gmail.com wrote: just to follow up on this results in a failed assertion whenever http_media.len is rather large (I'm guessing larger than 5MB from the text of the assertion). The assertion itself: That was a typo, it's actually ~2.5MB, as its shifted right by two positions. The source (emem.c:731) states that the limit set is 'arbitrary'; anything that can be done other than changing the limit in the source and recompiling it? Don't know if it's the only way, but changing the limit to 10MB fixed it for my situation. It might have worked it arround until an 11Mb request overflows it again. What it should be done IMHO is to g_malloc()ate the block directly if it happens to be bigger than the limit instead of failing. (and of course that would need to be freed as the ep-memory gets renewed). \L -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] emem.c:732: failed assertion [sort-of-SOLVED]
On Mon, Mar 1, 2010 at 4:48 PM, varname varn...@gmail.com wrote: Luis EG Ontanon wrote: Don't know if it's the only way, but changing the limit to 10MB fixed it for my situation. It might have worked it arround until an 11Mb request overflows it again. sure. That's why I wrote for my situation. I 'never' expect to have to allocate more than 10MB at a time, but that was probably the reasoning of the developer that implemented the check in the first place. What it should be done IMHO is to g_malloc()ate the block directly if it happens to be bigger than the limit instead of failing. (and of course that would need to be freed as the ep-memory gets renewed). I can't comment on that. One thought though: what if a really large block needs to be allocated (100MB reassembled http download for instance)? Might not be too nice on the machine running wireshark? Nope, I think it won't... Could you revert your changes and try the attached patch against your captures? Thanks, \L -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan large_alloc.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Extending wireshark with Python
I wanted to add python support at first I just did not find the right docs to do it. Perl is simply off... I do not think is a good language for embeddng at all... But perl is at lesat for me the most versatile language I've found. It's true that it's too versatile that you often end up writing code that just one day later you cannot read :) . After having to deal with it for a while I just hapen not to like python at all :). I do not like the extremely slow compilation, I do not like the way scopes and variables are handled. But I do like ipython, I use it as my desk calculator on an everyday basis. Keep on the good work. On Mon, Jun 1, 2009 at 3:31 PM, Sébastien Tandel sebast...@tandel.be wrote: Hi Luis, I'm happy to see you're enthusiast! :) On Sun, May 31, 2009 at 22:01, Luis EG Ontanon l...@ontanon.org wrote: I made the Lua bindings an application of the C API, not a simple export. (e.g. proto_item and proto_tree are combined instead of dealt individually, objects are managed in their scope so that deleted objects are not accessed by Lua). As a rule of thumb, I'm trying to follow the C API but the main idea is of course to simplify whenever possible and write less code. That's why I'm not against following some parts of the LUA API. My main goal is to ease development for others people. The reasons why I avoided just mapping the C API were many but all focused on a single point: to make sure that a bug in lua code was hanlded by lua's handler, not by a crash. For sure, that's something I have to work on :) Maybe I did not insist sufficiently on it but it's the *first step* to have a python binding with wireshark. There are a lot of things to do , features to add, bugs to fix, etc... Another drive was simplyfing some wireshark concepts to make coding in lua leaner, if it will take me the same number of lines to write code in lua than it takes me to write it in C why not just write it in C. That's something I want to avoid too. And it's already rather concise, maybe not as concise as LUA is right now? maybe. I had no python experience at the time and I had heard many good things of it... Having dealt way too much (for my taste) with python latelly now IMHO the only think which python does better than perl is well indented code (the thing cannot even help you find a typo in the name of a variable, closures are cumbersome, global variable usage is painful at very least... as for java I do not understand why so many people like it). OK, perl lover ... I was working with perl some years ago and I'm really happy to be able to avoid its use today! BUT my point is that if there were a binding in perl, it would be a good thing for wireshark because there are a lot of people using it. I just won't do it myself. In the same way, I do think that python is a good thing for wireshark too. At the end of the day, just a few people knows LUA. Even being in Brazil, country of origin of LUA, working for one of the largest brazilian IT company, people knows LUA because it's brazilian but nobody can (or want to) develop with it. After all, having a binding is not only for me or for other core people. Having a binding is to ease wirehark extension development for the rest of the community (mainly sysadmin and net guys). If we use an unknown language, like let's say D, it is of little interest because just an elite knows it. (and probably this elite won't even take a look at wireshark). I know that at the company I'm working in, sysadmin and net guys are using a way lot more python than perl, do not even think they could one day extend wireshark in C and as I already said LUA is just known by its name because of its origin. Therefore, what would you choose? Regards, Sebastien Tandel On Sun, May 31, 2009 at 10:41 PM, Sébastien Tandel sebast...@tandel.be wrote: Hi Stig, First, I have to admit that I'm not really aware of the details of the defined LUA API. But as a rule of thumb, I tried to be close as possible to what exists in the C API (not LUA). Here is an informal description of what rules I tried to follow to create this API : 1) create objects as close as possible to the ones known in libwireshark There are three obvious objects until now : Dissector, Tree, TVB. 2) method name of each object as close as possible as the ones defined in libwireshark. I however modify the name because as C is not object, most of the time, a function includes in its name the conceptual object name related to it. This way, it avoids redundance in python API. For example : proto_tree_add_item is one method of the tree object in the C API. in the python API, the Tree class defines a add_item method. With the same idea for tvb_get_ntohl, the method is defined in the TVB class with the name get_ntohl. 3) formal parameters of functions : a) first parameter is in general the C object and it does not make any sense
Re: [Wireshark-dev] Extending wireshark with Python
I made the Lua bindings an application of the C API, not a simple export. (e.g. proto_item and proto_tree are combined instead of dealt individually, objects are managed in their scope so that deleted objects are not accessed by Lua). The reasons why I avoided just mapping the C API were many but all focused on a single point: to make sure that a bug in lua code was hanlded by lua's handler, not by a crash. That meant mainly: To deal with the destruction of objects in a way that is transparent to the Lua program. objects like TVBs that go out of scope would have a destructor invoked, and if a TVB used by libwireshark got destroyed by the lua program you would have a crash, same thing would happen if you preserved a pointer to an object that libwireshark had destroyed and you attempted to use it again (e.g. a tvb from the previous frame). To avoid signals THROWn from libwireshark popping the frames in the Lua stack. This is an issue that caused me serious pain, if an exception got thrown from the API function lua's signal stack got corrupted. Another drive was simplyfing some wireshark concepts to make coding in lua leaner, if it will take me the same number of lines to write code in lua than it takes me to write it in C why not just write it in C. My choice of Lua was both for simplicity (easier to embed, because at the time there wasn't accessible docs on embeding python) and speed (lua is way faster than perl or python). I had no python experience at the time and I had heard many good things of it... Having dealt way too much (for my taste) with python latelly now IMHO the only think which python does better than perl is well indented code (the thing cannot even help you find a typo in the name of a variable, closures are cumbersome, global variable usage is painful at very least... as for java I do not understand why so many people like it). On Sun, May 31, 2009 at 10:41 PM, Sébastien Tandel sebast...@tandel.be wrote: Hi Stig, First, I have to admit that I'm not really aware of the details of the defined LUA API. But as a rule of thumb, I tried to be close as possible to what exists in the C API (not LUA). Here is an informal description of what rules I tried to follow to create this API : 1) create objects as close as possible to the ones known in libwireshark There are three obvious objects until now : Dissector, Tree, TVB. 2) method name of each object as close as possible as the ones defined in libwireshark. I however modify the name because as C is not object, most of the time, a function includes in its name the conceptual object name related to it. This way, it avoids redundance in python API. For example : proto_tree_add_item is one method of the tree object in the C API. in the python API, the Tree class defines a add_item method. With the same idea for tvb_get_ntohl, the method is defined in the TVB class with the name get_ntohl. 3) formal parameters of functions : a) first parameter is in general the C object and it does not make any sense to include it for the method defined in a python object. (in fact, in python it appears in the definition and disappears when called) b) it might happen that some other parameters are always defined in the formal parameters of the C API but are not manipulated by the user and might be included automatically by the python API. For these ones, they also disappear from the formal parameters list of the python API. c) if the parameter takes most of the time one value but sometimes can take another value, it is defined as an optional parameter. d) if the parameter is totally or partially managed by the python API, it is defined as an optional parameter. a good example is Tree.add_item(self, field, offset=0, length=-1, little_endian=False, adv=True) the C API counterpart is : proto_tree_add_item(proto_tree, hfindex, tvb, start, length, little_endian) - As of rule a), proto_tree is in fact the Tree object = disappear from the formal parameter list - As of rule b), tvb is not directly manipulated by the user and therefore disappear from the formal parameter list - As of rule c), little_endian has two possible value False or True. It becomes an optional parameter with the default value set to False. - As of rule d), offset is totally managed by the API with the help of the last *added* parameter which indicates whether offset should be incremented or not. This last parameter is itself an optional parameter with a value of True (offset is incremented by length). Though, offset is totally managed by the python API, it is possible to increment manually the offset. There is already two notable exceptions to what I described here above. There exists two others objects (register_info and Subtrees). It is likely that in the future this list of objects will increase because they've initially have been created because of a ctypes (python module) limitation. At the end, they almost serve
Re: [Wireshark-dev] UAT access from within the registration functions
You welcome, I made uat_load() idempotent to do exactly what you needed, It is used in oids.c to set the path and list the MIBS to be loaded, as such I needed it to be loaded at protocol registration and no later. To avoid it being loaded twice uat_load marks the uat as loaded. \Lego On Fri, Apr 10, 2009 at 3:18 PM, Abhik Sarkar sarkar.ab...@gmail.com wrote: Thank you, thank you, thank you, Luis! It never occurred to me that I could load it manually. This worked! Also, it turns out that my original approach did not work because UAT preferences is one of the only preference types which, if changed, doesn't lead to the calling of the apply_cb passed in prefs_register_protocol... Perhaps there is a reason for it, but for now, my requirement is met and I am submitting a new patch. Thanks again! Abhik. On Fri, Apr 10, 2009 at 8:06 AM, Luis EG Ontanon l...@ontanon.org wrote: You can call uat_load() to have it loaded before preferences. 2009/3/25 Abhik Sarkar sarkar.ab...@gmail.com: Hi All, I want to read some data from a UAT while I am still in the registration functions. Going through the documentation and the code, it seems that all UAT tables are loaded when preferences are being read, and that if some registration needs to be done after preferences have been loaded, then it should be from inside proto_reg_handoff_protoname. My questions are: - is my understanding correct? - if not, is what I am trying to do possible at all? I am trying to revise the patch which I submitted originally for https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3242 Thanks, Abhik. ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] UAT access from within the registration functions
You can call uat_load() to have it loaded before preferences. 2009/3/25 Abhik Sarkar sarkar.ab...@gmail.com: Hi All, I want to read some data from a UAT while I am still in the registration functions. Going through the documentation and the code, it seems that all UAT tables are loaded when preferences are being read, and that if some registration needs to be done after preferences have been loaded, then it should be from inside proto_reg_handoff_protoname. My questions are: - is my understanding correct? - if not, is what I am trying to do possible at all? I am trying to revise the patch which I submitted originally for https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3242 Thanks, Abhik. ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark licence terms and dissectors
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL On Thu, Dec 18, 2008 at 3:59 PM, Rob Meades rob.mea...@qasara.com wrote: Apologies if this is already known, but I couldn't find the answer in the FAQ. We have created a dissector for Wireshark and would like to provide it to our customers. Is a dissector considered a part of Wireshark from the point of view of the GPL license? In other words, are we required to give the source code for the dissector to our customers? Thanks in advance for any pointers. Rob Qasara Limited Harston Mill Campus, Harston Cambridge, CB22 7GG. www.qasara.com Company no. 06493679 E-mail: rob.mea...@qasara.com Skype: rob.meades Mobile: +44 (0)7767 331031 Switchboard/fax: +44 (0)1223 875180 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to find duplicate packets with time interval less than 2ms
On Fri, Nov 28, 2008 at 10:43 PM, Petr Janata [EMAIL PROTECTED] wrote: What is a parameter for the time window? I mean: Instead of giving it a fixed 2ms time window to look for duplicates make that a parameterizable value. Plus, argument parameters are one letter only and the letter i is already used (for (i)nterface), the w is taken too (for (w)ritefile). I'd add this param/feature as a W for duplicate time (W)indow. e.g. $ dumpcap ... -d -W 15 for 15ms Good work, This is a very useful feature IMHO. Petr Luis EG Ontanon napsal(a): The issue there is that you'll need a buffer whose size is indeterminate (you can get way more than 4 packets in 2ms). So the buffer should adjust. BTW if you add a parameter for the time window it would be certainly more useful. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How to find duplicate packets with time interval less than 2ms
The issue there is that you'll need a buffer whose size is indeterminate (you can get way more than 4 packets in 2ms). So the buffer should adjust. BTW if you add a parameter for the time window it would be certainly more useful. On Fri, Nov 28, 2008 at 4:13 AM, Petr Janata [EMAIL PROTECTED] wrote: Stephen Fisher napsal(a): On Thu, Nov 27, 2008 at 11:43:58PM +0100, Petr Janata wrote: I am traiyng to modify editcap, because there is parameter '-d' for skipping duplicate packets. I am going to filter those packets witche have time interval less then 2ms. Do you have any idea? According to editcap's man page, the length and MD5 sum of the MD5 sum of the current packet are compared to the previous four packets. Do you want to change this to 2ms instead? Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev If I compare MD5 checksum I can find duplicate packets. I 'd like to add new parameter '-di' into the editcap. The algorithm skip only pakets that are duplicated and also the time interval betwean them is less than 2ms. Petr ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] VoIP call analysis
On Wed, Nov 26, 2008 at 9:52 PM, Michael Lum [EMAIL PROTECTED] wrote: Hi Luis, thanks for responding, You welcome. I wasn't expecting any tie in between the A-interface (Iu-CS) signaling and MAP/TCAP. Just as an example a Location-Update flows from a BSC to the HLR. RAN -(RANAP/BSSAP)- MSC -(MAP/TCAP)- VLR -(MAP/TCAP)- HLR Similar thing happen to SMSs: RAN -(RANAP/BSSAP)- MSC -(MAP/TCAP)- SMS-C ... I don't think I'm explaining myself properly. I'm only expecting to see the signaling and call state of the one leg. I'm trying to figure out if I should add more functionality here. The current code (as of 1.0.4) shows Location Updates as VoIP calls. Was this intended? Was the SCCP associations code written for VoIP calls? No, the code was originally written to overcome the lack of good heuristics to discover BSSAP and RANAP. In Connection Oriented service the SSN is to be found in only in the CR message so only the Setup message was decoded deterministically, I wrote the code to tie toghether a connection so that other messages in the connection where always decoded by the propper dissector. I wrongly named the connection association, because that is how this information is called in the configuration of the nodes. Later I used this information to collect information about the call to be shown by the dissector. A colleague pointed me out that it would be nice to have flow-graphs for these, and since that job was already there I just mapped it into the VoIP calls dialog. SCCP (RANAP/BSSAP), ALCAP and GCP work differently than other protocols do in the VoIP-Calls dialog because I re-used information already collected by procedures in the dissectors that had already done most of the job. That's why RANAP and BSSAP add its information to the connection data (assoc) in the dissector and pass to the VoIP-Calls facility info about the whole connection via the tap instead of just for the current message's like other protocols do. \Lego -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] VoIP call analysis
On Tue, Nov 25, 2008 at 6:51 PM, Michael Lum [EMAIL PROTECTED] wrote: For calls IOS 5 uses connection-oriented SCCP in the same manner as BSSAP. The call model the voip-calls dialog uses is just too simplistic for taking into account mobile call scenarios. So I used Voip-Call as a synonym of Call-Leg. Using the SCCP preference you mentioned is how I looked at my trace but there are some problems with the SCCP handling in voip_calls.c. - it uses SCCP Connection Request as the start of a call when that message can be used for non-call related procedures, i.e. location updates, SMS, etc. For RAN-CN these procedures are run on top of the connection-less service ([X]UDT). For CN-CN these procedures run on top of MAP/TCAP which uses SCCP connection-less service as well. I've never seen these messages on top of connection oriented SCCP. The Paging messages which are in-fact call-related are not shown by the dialog because they are transported by connection-less service. I don't understand why SCCP is used in VoIP Calls for call state. Call state is too broad to be taken into account what I attempt to do is just to put toghether as much packets as possible for a call so that the user finds it easier to isolate them. I understand how SCCP connections work and the requirement to match the SLR/DLR in the SCCP CC to tie all the messaging together, but only the upper protocols such as RANAP/IOS/BSSAP know the complete call state. As stated before this is not completelly true, a RAN node is aware of the complete state only the for the call-leg it is handling. The anchor-MSC is the only one aware of the complete call state and that cannot be easily inferred from the protocol messages it uses to control the call. Call-leg control information is in the application protocol (RANAP, BSSAP) add these use one SCCP connection for one call-leg, the connection is setup at call setup and it gets released at call release so I used that to add call-legs to the VoIP call dialog. The concept of call in mobile-scenarios is way too complex to be handled by this facility, a call ususaly has several call-legs. e.g.: one end-user-call that does a 2G-3G intra-MSC handover uses: - a BSSAP leg for the initial setup (one SCCP connection) - another RANAP leg after hand-over(another SCCP connection) - a MAP/TCAP session which controls the handover and transports the CP (RANAP) for that call between ancor-MSC and drift-MSC. - The ISUP/BICC call to transport the UP. Things can get even more complex if we are using a split-architecture (MSC-S + MGw). Are the GCP contexts (megaco/h248) created in the various MGws to handle the call to be considered part of the call? I thought I would want the IOS dissector to use the SCCP associations for call analysis but it doesn't seem that anybody is doing that with the other dissectors. ? SCCP and GCP are handled differently from other protocols because I decided to re-use the session information already gathered by the relative dissectors instead of rewriting that code in the voip-calls dialog or writing another dialog as a whole for this. Thanks. -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 Star Solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luis EG Ontanon Sent: November 20, 2008 10:23 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] VoIP call analysis if IOS5 uses the connection-less SCCP service SCCP-connection-tracking cannot help you. If it instead uses the Conection-Oriented SCCP service, you can take a look at how RANAP and BSSAP put interesting information into the SCCP data for the packet/connection. (Beware that in order to trace calls SCCP needs the Keep Track of... preference being enabled). BR Lego On Thu, Nov 20, 2008 at 7:15 PM, Michael Lum [EMAIL PROTECTED] wrote: Hi, I'm looking at voip_calls.c and there is a voip_protocol_name array that contains, among others, SCCP, BSSMAP and RANAP. How does this work for a with the following partial stack: BSSMAP or RANAP SCCP M3UA ... ? I tried out one of my traces with SCCP and it sort of works. Was it meant to be used with the above or for some other kind of protocol layering ? (I thought only A-interfaces used connection-oriented SCCP.) I say it only sort of works because SCCP can't determine a call state or even imply a call is taking place. Should I just ignore the SCCP code eventhough IOS 5 is carried on it ? Thanks. -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 Star Solutions ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When
Re: [Wireshark-dev] sua (ansi / itu tcap payloads)
There are differences in how ANSI-TCAP and ITU-TCAP are encoded. These are used to guess what it is. Take a look to dissect_tcap() in asn1/tcap/packet-tcap-template.c:157 On Tue, Nov 25, 2008 at 5:53 PM, cco [EMAIL PROTECTED] wrote: hi! how exactly does wireshark distinguish the sua packets that carry an ansi tcap payload from the ones that carry an itu one? for example I am seeing sua packets having the same destination ssn (and source ssn) whose payload is decoded as ansi tcap sometimes and as a itu (gsm map) tcap sometimes. thanks a lot! bye now! cristian ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SCCP equivalents in SUA dissector
.[ds]lr .*ssn* .*.gti. *.[nr]i On Thu, Nov 20, 2008 at 11:40 AM, Abhik Sarkar [EMAIL PROTECTED] wrote: Hi All, Just as the M3UA dissector added a section called MTP3 equivalents in packets which make it possible to use MTP3 fields for filtering, would it be fair to have SCCP equivalents in the SUA dissector. I am interested in particular in sccp.calling.digits and sccp.called.digits... though there might be others which are also useful. Thanks, Abhik. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] VoIP call analysis
if IOS5 uses the connection-less SCCP service SCCP-connection-tracking cannot help you. If it instead uses the Conection-Oriented SCCP service, you can take a look at how RANAP and BSSAP put interesting information into the SCCP data for the packet/connection. (Beware that in order to trace calls SCCP needs the Keep Track of... preference being enabled). BR Lego On Thu, Nov 20, 2008 at 7:15 PM, Michael Lum [EMAIL PROTECTED] wrote: Hi, I'm looking at voip_calls.c and there is a voip_protocol_name array that contains, among others, SCCP, BSSMAP and RANAP. How does this work for a with the following partial stack: BSSMAP or RANAP SCCP M3UA ... ? I tried out one of my traces with SCCP and it sort of works. Was it meant to be used with the above or for some other kind of protocol layering ? (I thought only A-interfaces used connection-oriented SCCP.) I say it only sort of works because SCCP can't determine a call state or even imply a call is taking place. Should I just ignore the SCCP code eventhough IOS 5 is carried on it ? Thanks. -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 Star Solutions ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-bugs] [Bug 2978] Crash in Reassembly
2008/10/18, [EMAIL PROTECTED] [EMAIL PROTECTED]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2978 Arun kaliraja.B [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Wireshark-bugs mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-bugs -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Making a dissector for a text proto using ISO 10646 (Unicode) in UCS-2(was: Using external DTD)
About XML/DTD: The XML dissector would need far more than FT_STRING_UNICODE to handle XML with multibyte encoded chars . The tvbparse API (on which the xml dissector) would need to be exteded to handle multi-byte chars. And some parts of how to do it aren't clear to me. What about multibyte chars in entities data and/or entity/element/attribute names in DTDs? That means that the DTD parser needs to be extended as well. \Lego PS: In theory for adding support for an XML protocol all you need is to write a DTD. On Fri, Oct 3, 2008 at 11:59 AM, Anders Broman [EMAIL PROTECTED] wrote: Hi, I took a quick look at this trace and I think it raises some questions: Should ve make routines to handle Unicode? e.g tvb_find_line_end_unicode() how should strings be added to the tree? new FT ( FT_STRING_UNICODE) or ? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: den 1 oktober 2008 14:30 To: Developer support list for Wireshark Subject: [Wireshark-dev] Using external DTD Hi guys I'm trying to use an externally generated DTD to parse some traffic I've attached a packet and my dtd - can anyone point me in the right direction? It's displaying as TCP/XML in Wireshark (1.0.99 and 1.02) but it's simply not decoding. Can anyone help me get this working? Many thanks Scott -- This e-mail is intended for the named addressees only. Its contents may be privileged or confidential and should be treated as such. If you are not an intended recipient please notify the sender immediately and then delete it; do not copy, distribute, or take any action based on this e-mail. In the pursuit of its legitimate business activities and its conformance with relevant legislation, Quantel may access any e-mail (including attachments) it originates or receives, for potential scrutiny. Quantel is the trade name used by Quantel Holdings Limited and its subsidiaries. Quantel Holdings Limited is registered in England Wales. Registration No: 4004913 Contact details for all Quantel Offices and Companies can be found on our website www.quantel.com or by writing to the holding company. Registered address: Turnpike Road, Newbury, Berkshire, RG14 2NX, United Kingdom ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Error while setting up check-out of code
Try to pass the proxy settings manually. e.g.: HTTP_PROXY=1.2.3.4: nmake -f Makefile.nmake setup \Lego On Mon, Sep 29, 2008 at 3:55 PM, Roshan Nair [EMAIL PROTECTED] wrote: Hi, I am seeing thiis error while I execute the command nmake -f Makefile.nmake setup. The error I get is as below : ** glib_2.18.1-1_win32.zip ** Using Internet Explorer proxy settings. HTTP proxy (eng-proxy.net.com:80) has been specified and will be used. Downloading gtk2.14/glib_2.18.1-1_win32.zip into C:\WIRESH~1, installing into glib --2008-09-29 18:55:20-- http://anonsvn.wireshark.org/wireshark-win32-libs/tags/2008-09-25 /packages//gtk2.14/glib_2.18.1-1_win32.zip Resolving anonsvn.wireshark.org... 67.228.110.124 Connecting to anonsvn.wireshark.org|67.228.110.124|:80... failed: Connection timed out. Retrying. What could be the problem ? Thanks in advance! Regards, -Roshan. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 26261: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-xml.c packet-xml.h
I'm curious about where does this lead... On Wed, Sep 24, 2008 at 12:42 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=26261 User: kukosa Date: 2008/09/24 03:42 AM Log: put original tag name (not lowercase) into dissected xml structure too dissect xml even if tree is null Directory: /trunk/epan/dissectors/ ChangesPathAction +6 -3 packet-xml.cModified +1 -0 packet-xml.hModified ___ Wireshark-commits mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] XML Parser
BTW, last night I experimented with xsltproc and xsl to be used to
generate C-code directly from the dictionary, that'd be hard-coded not
user configurable.
The attached (far from complete) XSL transform generates C-code from
the diameter dictionary.
run as:
$ xsltproc diam_dict2c.xsl ws_trunk/diameter/dictionary.xml
\Lego
On Mon, Sep 22, 2008 at 4:48 PM, Luis EG Ontanon [EMAIL PROTECTED] wrote:
Well I wrote that lexer for Diameter to avoid yet-another-dep. I did
not expect yet more parsers to follow-suit.
I myself hate XML and all the paraphernalia that comes with it... my
writing of the XML dissector was an unsuccesful exercise of
de-mystification. I hate it even more after writing it!
If your data can be represented with a simple table avoid XML... use a
simple table. If YAML can do, YAML does it better...
If your data uses a structure expat and other tools do not populate
YOUR structures, they load the data into THEIR framework and then you
have to CODE to get it out... You end up writing as much code for
navigating their structs as you would if you wrote your own parser.
And you have to deal with the runtime-lib dependency too!
If there was an XML framework that given an XSL or DTD and a
conformance file generated C-code to extract data into user defined
C-structs, I'd certainly had used it... (there's a plethora of
similar tools for ASN.1). No such tool found yet arround...
On Mon, Sep 22, 2008 at 4:26 PM, Matt Poduska
[EMAIL PROTECTED] wrote:
So, it sounds as though there is no generic XML parser available. The beauty
of XML is that you don't need to generate a special parser for every schema.
Has there been any thought to adding the Expat XML parser
(http://expat.sourceforge.net) or something like it? If I submit a snapshot
of an open-source XML parsing library to the Wireshark source tree, does it
have a chance of being accepted?
-Original Message-
From: Abhik Sarkar [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 20, 2008 11:54 PM
To: [EMAIL PROTECTED]; Developer support list for Wireshark
Subject: Re: [Wireshark-dev] XML Parser
I needed something similar for feature I have been working on for the SMPP
dissector. I could not (when I started working on this) find any ready-made
XML parser library in the WS tool chain. So, I have shamelessly copied
LEGO's good work on the Diamater Diameter dictionary support (which us also
based on XML files). It was a bit tough for me (because I have never worked
with Lex before), but it was a good learning experience. There is also the
XML dissector which (if I remember correctly) uses the lemon parser
generator.
HTH
Abhik.
On Fri, Sep 19, 2008 at 6:41 PM, Matt Poduska [EMAIL PROTECTED]
wrote:
I'm looking to add support for loading vendor extension information
into the LLRP protocol dissector (submitted, but not yet accepted).
The vendor extension files are XML formatted, and define the structure
and content of extensions to the LLRP protocol. The vendor extension
XML files would be read when the dissector is initialized, and would
produce structures (in
memory) that would be used to dissect the protocol extensions.
Is there an XML parsing library available to my dissector?
Thanks,
Matt Poduska
Software Engineer, RFID Systems
Intermec
550 Second Street SE
Cedar Rapids, IA 52401
voice: 319.369.3331
fax: 319.369.3577
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
?xml version=1.0 encoding=UTF-8?
xsl:stylesheet
version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns=http://www.w3.org/1999/xhtml;
xsl:output method=text/
xsl:template match=/dictionary
xsl:text
/* GPL2 */
/*
/xsl:text
xsl:value-of select=base/@uri/
xsl:text
*/
static value_string vendors[] = {
/xsl:text
xsl:for-each select=base/vendor
xsl:sort select=vendor-id/
xsl:text { /xsl:text
xsl:value-of select=@code/
xsl:text , /xsl:text
xsl:value-of select=@name/
xsl:text },
/xsl:text
/xsl:for-each
xsl:text
{0,NULL}
};
/xsl:text
xsl:text
static avp_t avps[] = {
/xsl:text
xsl:for-each select=*/avp
xsl:variable name='vendor-id' select='./@vendor-id
Re: [Wireshark-dev] XML Parser
Well I wrote that lexer for Diameter to avoid yet-another-dep. I did not expect yet more parsers to follow-suit. I myself hate XML and all the paraphernalia that comes with it... my writing of the XML dissector was an unsuccesful exercise of de-mystification. I hate it even more after writing it! If your data can be represented with a simple table avoid XML... use a simple table. If YAML can do, YAML does it better... If your data uses a structure expat and other tools do not populate YOUR structures, they load the data into THEIR framework and then you have to CODE to get it out... You end up writing as much code for navigating their structs as you would if you wrote your own parser. And you have to deal with the runtime-lib dependency too! If there was an XML framework that given an XSL or DTD and a conformance file generated C-code to extract data into user defined C-structs, I'd certainly had used it... (there's a plethora of similar tools for ASN.1). No such tool found yet arround... On Mon, Sep 22, 2008 at 4:26 PM, Matt Poduska [EMAIL PROTECTED] wrote: So, it sounds as though there is no generic XML parser available. The beauty of XML is that you don't need to generate a special parser for every schema. Has there been any thought to adding the Expat XML parser (http://expat.sourceforge.net) or something like it? If I submit a snapshot of an open-source XML parsing library to the Wireshark source tree, does it have a chance of being accepted? -Original Message- From: Abhik Sarkar [mailto:[EMAIL PROTECTED] Sent: Saturday, September 20, 2008 11:54 PM To: [EMAIL PROTECTED]; Developer support list for Wireshark Subject: Re: [Wireshark-dev] XML Parser I needed something similar for feature I have been working on for the SMPP dissector. I could not (when I started working on this) find any ready-made XML parser library in the WS tool chain. So, I have shamelessly copied LEGO's good work on the Diamater Diameter dictionary support (which us also based on XML files). It was a bit tough for me (because I have never worked with Lex before), but it was a good learning experience. There is also the XML dissector which (if I remember correctly) uses the lemon parser generator. HTH Abhik. On Fri, Sep 19, 2008 at 6:41 PM, Matt Poduska [EMAIL PROTECTED] wrote: I'm looking to add support for loading vendor extension information into the LLRP protocol dissector (submitted, but not yet accepted). The vendor extension files are XML formatted, and define the structure and content of extensions to the LLRP protocol. The vendor extension XML files would be read when the dissector is initialized, and would produce structures (in memory) that would be used to dissect the protocol extensions. Is there an XML parsing library available to my dissector? Thanks, Matt Poduska Software Engineer, RFID Systems Intermec 550 Second Street SE Cedar Rapids, IA 52401 voice: 319.369.3331 fax: 319.369.3577 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] error LNK2001: unresolved external symbol _mtp3_standard
I think it is enough to add mtp3_standard to libwireshark.def as other variables are and then re-link. On Mon, Sep 22, 2008 at 1:08 PM, Xiao Li [EMAIL PROTECTED] wrote: Hello, I have wrote a wireshark plugin and it was built successfully under unix. But when building it under Windows, following error will appear: Generating Code... link -dll /out:pmp.dll /NOLOGO /INCREMENTAL:no /MACHINE:I386 /DEBUG packet-pmp.obj plugin.obj ..\..\epan\libwi eshark.lib C:\wireshark-libs-1.0\glib\lib\glib-2.0.lib C:\wireshark-libs-1.0\glib\lib\gmodule-2.0.lib C:\wireshark-l bs-1.0\glib\lib\gobject-2.0.lib pmp.res Creating library pmp.lib and object pmp.exp packet-pmp.obj : error LNK2001: unresolved external symbol _mtp3_standard pmp.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.EXE' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : return code '0x2' Stop. I added following line plugins/pmp/packet-pmp.c to use the variable mtp3_standard, because under epan/dissectors/, the variable is defined in packet-mtp3.c and declared in packet-mtp3.h. #include epan/dissectors/packet-mtp3.h I did some search online, and it is saying that usually this error means some .lib is not correctly linked. Could someone tell me how to do it in wireshark? Thanks Regards -Xiao ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 26226: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-sctp.c
Does it work if you do guint last_frame = 0; ... if (framenum == 0) framenum = ++last_frame; On Wed, Sep 17, 2008 at 11:59 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=26226 User: morriss Date: 2008/09/17 02:59 PM Log: If we're dissecting for a read filter in the GUI [tshark assigns frame numbers before running the read filter], don't do the TSN analysis. (We can't anyway because we don't have a valid frame number...) Without this change if you load a capture file in the GUI while using a read filter, every SCTP TSN is marked as a retransmission of that in frame 0. Directory: /trunk/epan/dissectors/ ChangesPath Action +20 -8 packet-sctp.cModified ___ Wireshark-commits mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 26226: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-sctp.c
+ static guint last_frame - guint last_frame On Thu, Sep 18, 2008 at 12:06 AM, Luis EG Ontanon [EMAIL PROTECTED] wrote: Does it work if you do guint last_frame = 0; ... if (framenum == 0) framenum = ++last_frame; On Wed, Sep 17, 2008 at 11:59 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=26226 User: morriss Date: 2008/09/17 02:59 PM Log: If we're dissecting for a read filter in the GUI [tshark assigns frame numbers before running the read filter], don't do the TSN analysis. (We can't anyway because we don't have a valid frame number...) Without this change if you load a capture file in the GUI while using a read filter, every SCTP TSN is marked as a retransmission of that in frame 0. Directory: /trunk/epan/dissectors/ ChangesPath Action +20 -8 packet-sctp.cModified ___ Wireshark-commits mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] with-lua does not compile
It appears like lua_State is not defined (like if the configure script
actually found lua but it did not set up propperly CFLAGS and
LDFLAGS).
Can you get this to compile using just what you find in /usr/lib ?
(CFLAGS=/usr/local/include LDFLAGS=/usr/local/lib)
/*start*/
#include stdlib.h
#include lua.h
int main (int c, char** v) {
lua_State* L = lua_newstate(realloc,NULL);
}
/*end*/
On Tue, Sep 2, 2008 at 9:22 AM, Zoran Bošnjak
[EMAIL PROTECTED] wrote:
Latest devel release of wireshark (svn r26107) does not compile when
--with-lua option is set.
$./autogen.sh
$./configure --with-lua=/usr/lib
$make
I get this error:
...
./wslua_tvb.c:600: error: expected ')' before '*' token
./wslua_tvb.c:643: error: expected ')' before '*' token
./wslua_tvb.c:682: error: expected ')' before '*' token
./wslua_tvb.c:715: error: expected ')' before '*' token
./wslua_tvb.c:740: error: expected ')' before '*' token
./wslua_tvb.c:758: error: expected ')' before '*' token
./wslua_tvb.c:785: error: expected ')' before '*' token
./wslua_tvb.c:813: error: expected ')' before '*' token
./wslua_tvb.c:839: error: expected ')' before '*' token
./wslua_tvb.c:854: error: expected ')' before '*' token
./wslua_tvb.c:873: error: expected ')' before '*' token
./wslua_tvb.c:889: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'TvbRange_methods'
./wslua_tvb.c:903: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'TvbRange_meta'
./wslua_tvb.c:910: error: expected ')' before '*' token
make[4]: *** [wslua_tvb.lo] Error 1
make[4]: Leaving directory `/home/bosnjak/wireshark/asterix/epan/wslua'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/bosnjak/wireshark/asterix/epan/wslua'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/bosnjak/wireshark/asterix/epan'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bosnjak/wireshark/asterix'
make: *** [all] Error 2
regards,
Zoran
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] lua http.request and http.response structure
I'm wrote preety much all of WS Lua's interface, and I am not aware of
any such structure...
There are tap-data structures of lua that are extracted from header
files of dissectors using code generated by epan/wslua/make-taps.pl
which in turn is controlled by epan/wslua/taps .
These are *willingly* left un-documented. As my plans are to radically
modify this part of the code (but before I need to have a clear Idea
of what and how this should be done).
The http req/resp data currently passed to Listener calls is a Table
that contains the same data as struct http_info_value_t defined in
epan/dissectors/packet-http.h .
typedef struct _http_info_value_t {
guint32 framenum;
gchar *request_method;
guintresponse_code;
gchar *http_host;
gchar *request_uri;
} http_info_value_t;
Hope this helps...
I hope this helps but do not count on it to be there on future versions.
\Lego
On Tue, Sep 2, 2008 at 10:16 AM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
where can i found informations about the lua http.response and
http.request structure?
Regards,
Riccardo
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] lua http.request and http.response structure
do
local xyz_field = Field.new(http.xyz)
local tap= Listener.new();
...
function tap.packet(pinfo,tvb)
local xyz = xyz_field()
...
end
...
end
On Tue, Sep 2, 2008 at 12:16 PM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
thanks for the aswer.
I think i made the wrong question
I would like to know how can i access to http message parts whit the
Field.new() function.
In particular i'm trying to retrieve the get response body (or data)
I tryed with Fiend.new(data-text-lines) but it gives an error when i
try to print it.
Best Regards,
Riccardo
Luis EG Ontanon wrote:
I'm wrote preety much all of WS Lua's interface, and I am not aware of
any such structure...
There are tap-data structures of lua that are extracted from header
files of dissectors using code generated by epan/wslua/make-taps.pl
which in turn is controlled by epan/wslua/taps .
These are *willingly* left un-documented. As my plans are to radically
modify this part of the code (but before I need to have a clear Idea
of what and how this should be done).
The http req/resp data currently passed to Listener calls is a Table
that contains the same data as struct http_info_value_t defined in
epan/dissectors/packet-http.h .
typedef struct _http_info_value_t {
guint32 framenum;
gchar *request_method;
guintresponse_code;
gchar *http_host;
gchar *request_uri;
} http_info_value_t;
Hope this helps...
I hope this helps but do not count on it to be there on future versions.
\Lego
On Tue, Sep 2, 2008 at 10:16 AM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
where can i found informations about the lua http.response and
http.request structure?
Regards,
Riccardo
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] lua http.request and http.response structure
A bug in wireshark...
That should't fail (not at least that way)!
Can you open a bug in https://bugs.wireshark.org and attach to it both
the code and a capture file that shows the problem
Thanks,
\Lego
On Tue, Sep 2, 2008 at 12:42 PM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
I did this:
do
http__response_data_extractor=Field.new(data-text-lines)
http=Listener.new()
function http.packet(pinfo,tvb)
local http_response_data=http_response_data_extractor()
print(DATA : ,http_response_data)
end
end
but it gives me this error:
ERROR:(ftype-tvbuff.c:133):val_repr_len: assertion failed
(rtype==FTREPR_DFILTER)
Aborted
What's wrong with it?
Thanks,
Riccardo
Luis EG Ontanon wrote:
do
local xyz_field = Field.new(http.xyz)
local tap= Listener.new();
...
function tap.packet(pinfo,tvb)
local xyz = xyz_field()
...
end
...
end
On Tue, Sep 2, 2008 at 12:16 PM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
thanks for the aswer.
I think i made the wrong question
I would like to know how can i access to http message parts whit the
Field.new() function.
In particular i'm trying to retrieve the get response body (or data)
I tryed with Fiend.new(data-text-lines) but it gives an error when i
try to print it.
Best Regards,
Riccardo
Luis EG Ontanon wrote:
I'm wrote preety much all of WS Lua's interface, and I am not aware of
any such structure...
There are tap-data structures of lua that are extracted from header
files of dissectors using code generated by epan/wslua/make-taps.pl
which in turn is controlled by epan/wslua/taps .
These are *willingly* left un-documented. As my plans are to radically
modify this part of the code (but before I need to have a clear Idea
of what and how this should be done).
The http req/resp data currently passed to Listener calls is a Table
that contains the same data as struct http_info_value_t defined in
epan/dissectors/packet-http.h .
typedef struct _http_info_value_t {
guint32 framenum;
gchar *request_method;
guintresponse_code;
gchar *http_host;
gchar *request_uri;
} http_info_value_t;
Hope this helps...
I hope this helps but do not count on it to be there on future versions.
\Lego
On Tue, Sep 2, 2008 at 10:16 AM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
where can i found informations about the lua http.response and
http.request structure?
Regards,
Riccardo
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] lua http.request and http.response structure
On Tue, Sep 2, 2008 at 1:21 PM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
I also found that i'm using the tshark 1.0.0 version.
Should be that the problem was solved in the 1.0.3 ?
http_response_data() returns FieldInfo info whose __tostring() method
triggers the assertion where WS crashes and it is not fixed in 1.0.3.
Maybe accessing the attribute label instead gives you what you want
(beware: long labels are cropped and WS appends ... at the end).
What you want to do is to do something like
for x in http_response_data do
print(DATA: , x.label)
end
Thanks,
Riccardo
Luis EG Ontanon wrote:
A bug in wireshark...
That should't fail (not at least that way)!
Can you open a bug in https://bugs.wireshark.org and attach to it both
the code and a capture file that shows the problem
Thanks,
\Lego
On Tue, Sep 2, 2008 at 12:42 PM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
I did this:
do
http__response_data_extractor=Field.new(data-text-lines)
http=Listener.new()
function http.packet(pinfo,tvb)
local http_response_data=http_response_data_extractor()
print(DATA : ,http_response_data)
end
end
but it gives me this error:
ERROR:(ftype-tvbuff.c:133):val_repr_len: assertion failed
(rtype==FTREPR_DFILTER)
Aborted
What's wrong with it?
Thanks,
Riccardo
Luis EG Ontanon wrote:
do
local xyz_field = Field.new(http.xyz)
local tap= Listener.new();
...
function tap.packet(pinfo,tvb)
local xyz = xyz_field()
...
end
...
end
On Tue, Sep 2, 2008 at 12:16 PM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
thanks for the aswer.
I think i made the wrong question
I would like to know how can i access to http message parts whit the
Field.new() function.
In particular i'm trying to retrieve the get response body (or data)
I tryed with Fiend.new(data-text-lines) but it gives an error when i
try to print it.
Best Regards,
Riccardo
Luis EG Ontanon wrote:
I'm wrote preety much all of WS Lua's interface, and I am not aware of
any such structure...
There are tap-data structures of lua that are extracted from header
files of dissectors using code generated by epan/wslua/make-taps.pl
which in turn is controlled by epan/wslua/taps .
These are *willingly* left un-documented. As my plans are to radically
modify this part of the code (but before I need to have a clear Idea
of what and how this should be done).
The http req/resp data currently passed to Listener calls is a Table
that contains the same data as struct http_info_value_t defined in
epan/dissectors/packet-http.h .
typedef struct _http_info_value_t {
guint32 framenum;
gchar *request_method;
guintresponse_code;
gchar *http_host;
gchar *request_uri;
} http_info_value_t;
Hope this helps...
I hope this helps but do not count on it to be there on future versions.
\Lego
On Tue, Sep 2, 2008 at 10:16 AM, Riccardo Roasio
[EMAIL PROTECTED] wrote:
Hi,
where can i found informations about the lua http.response and
http.request structure?
Regards,
Riccardo
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
Riccardo Roasio
amuser S.p.A.
advanced multimedia services
10149 Torino (Italy) - via Val della Torre, 4
Tel +39 011 291 3777
Fax +39 011 291 3737
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark Rx Interface Decoding
open a bug (https://bugs.wireshark.org), mark it as enhancement, attach rxpolicy.xml to it and add a copy of the line you added to dictionary.xml to the comment when you open it. On Fri, Aug 22, 2008 at 10:32 PM, Bastiani, David [EMAIL PROTECTED] wrote: I have created an XML file for Rx interface decodes as specified in the 3GPP TS 29.214 V7.5.0 (2008-05) specification. To accomplish this I: 1. Created a file rxpolicy.xml and placed it in C:\Program Files\Wireshark\diameter 2. Modified my C:\Program Files\Wireshark\diameter\dictionary.xml file to reference it the rxpolicy.xml file. How do I go about getting this added to the mainline Wireshark builds so the community as a whole can use it? It might make better sense to rename it from rxpolicy.xml to TGPPRx.xml but I'm more interested in getting it included then nit picking over names. Thanks, /dave ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Lint of packet-tcp.c
On Thu, Aug 21, 2008 at 10:50 PM, Ulf Lamping [EMAIL PROTECTED] wrote: Anyway, I would try to avoid using commercial products for open source development where reasonably possible ... It's already We. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] bug in sub-allocator emem.c - guard pages cause unnecessary 'out of memory' condition
Well, that's a security feature (some would call it band-aid security). That's why its's there even if it costs a lot. It's work is to be able to detect memory corruption conditions (and yes it does, we are still getting and fixing of crashes reported by this (buffer overflows) ). But on the other hand you're right, these increase the amount of memory we use by a lot. I've been thinking of some changes that can be made: - have env variables to enable/configure/disable its use (been, BTW, protective by default). - Use 1 word PRBS canaries placed between a configurable num of allocs instead of the large unconditional ones. I'd want to discuss with others an architectural change to emem to allow emem to work this way (and distribute with it enabled) but to be able to use emem for what it was originally meant (get rid of 99% of our sys-calls, avoiding leaking, been much faster than using malloc). \Lego On Fri, Aug 8, 2008 at 6:09 PM, bob frazier [EMAIL PROTECTED] wrote: for very large files (1 hour streaming video capture) tshark will crash when doing analysis of RTP packets (let's say you're extracting specific data and filtering the output and generating text). On FreeBSD there is an unhandled 'out of memory' exception that causes the crash. This crash can be prevented (at least to some extent) by disabling guard pages and canaries in emem.c, then doing a full re-build (incremental build was insufficient). The problem appears to be a serious virtual address fragmentation problem, since when the crash happens the virtual address space is 2Gb, while actual memory used is in the neighborhood of 200Mb. Removing guard pages and canaries seems to resolve the problem. tshark command line looked like this (on a 17Gb capture of RTP/RTSP/RTCP data) tshark -r test.pcap -p -R(ip.dst==192.168.1.100 rtp.p_type==96) -Tfields -eframe.number -eframe.time_relative -ertp.p_type -ertp.extseq Similar problems also exist in the WIN32 version. Modifying the code to compile the no guard page 'malloc' sections (in lieu of 'VirtualAlloc' + 'VirtualProtect') for WIN32 also resolves THAT problem. ___ Wireshark-users mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-users -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol dissector
My vote goes for 2) : Wireshark is a troubleshooting tool and a vulnerable key can be source of trouble. It would be plainly wrong not to notify of a potential source of trouble if we can. I wonder whether we actually need to decrypt? I think we just need to build a hash of broken keypairs indexed by PubKeys and check the PubKey during the setup exchange, if the key is one of the well-known 64k we just mark it. It would be also interesting to check for CA certs whose PrivKey is one of the well known 64k. Is that feasable? \Lego On Thu, Aug 7, 2008 at 1:30 PM, Sake Blok [EMAIL PROTECTED] wrote: On Thu, Aug 07, 2008 at 09:59:41AM +0100, Richard van der Hoff wrote: Paolo Abeni wrote: 2) Change the code to only identify the weak keys, but not use it to decrypt the SSL traffic (would this also be CPU intensive?) Yes. It will take near exactly the same amount of time and computation since, in current code, the larger amount of time is spent looping on candidate weak keys. Right. I'd been labouring under the misunderstanding that you could identify whether a key was weak without having to brute force it. Having looked at Paolo's patch a bit more, I now see that isn't true. Same here... This certainly shouldn't be enabled by default - I don't want my wireshark to spend ages attempting to brute-force keys every time I happen to pick up a bit of SSL traffic. As Wireshark is a Network Protocol Analyzer and not a Vulnerability Scanning Tool, I would prefer not to waste cycles on identifying weak ciphers either... You could leave the code in there, and have an 'identify weak keys' menu option. But at present I'm changing my vote to 1) Don't include the code at all. All considering, I vote for 1) as well. Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol dissector
Insecurity people panic... security people take action... Security people that ban a program that finds/exploits a hole are not security people... security people makes sure a well known a very impacting vulnerabiliy is taken away. I think that letting users to know that e.g. their Bank's website SSL key is broken is a good thing, they will avoid using and start complaining (As I did, now my bank uses a secure key, haven't I proven the key I might have been using for longer). The doctrine of not making people aware of vulnerabilities is a botched one. The point is: Bad people will know about the vulnerability. Having good people not knowing, makes them unable to take action so the result is vulnerability. It's wrong to blame who finds a problem for it... On Wed, Aug 6, 2008 at 1:49 PM, Andrew Hood [EMAIL PROTECTED] wrote: Sake Blok wrote: May I have your votes please? ;-) 1) Don't include the code at all There are enough weak key identifiers out there without burdening Wireshark with a CPU intensive test for a one off problem. The next time someone finds a weakness it is bound to be a different problem needing different discovery. I don't want to have anyone in our networks using a version of Wireshark with the ability to crack keys. It will panic the security people and they will ban Wireshark totally. Wireshark it too useful to let that happen. -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Windows build environment changes
Does that mean that I just need to install the tools (MSVC2008+cygwin) do a checkout, make setup, and make all with no need anymore to modify any files? \Lego On Tue, Aug 5, 2008 at 7:13 PM, Gerald Combs [EMAIL PROTECTED] wrote: I just set the default MSVC_VARIANT in config.nmake to MSVC2008 in order to test that compiler on the Windows buildslave. If it works we can start using Visual C++ 2008 for official builds in the trunk. Also, a new tag was created in wireshark-win32-libs yesterday. You'll have to run nmake -f makefile.nmake setup next time you update SVN (which you should now be warned about). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] intense EP memory corruption checks
Hi folks, Last night I checked in a patch to emem.[ch] and packet.c to enable intense checking of EP canaries. Diverselly to the current checks done only once EP memory is being yield. With this one compiled in, if the env var WIRESHARK_DEBUG_EP_CANARY exists, it performs the canary check in several places in packet.c (before and after calling dissectors), which allows to better pinpoint the corrupter and probably still have it on the stack when it aborts. Other than that the EP_CHECK_CANARY() macro allows to easily add further checks. If compiled in and WIRESHARK_DEBUG_EP_CANARY is not in the env, the funtion doing the check will return immediately, not checking the canaries, thus not impating performance that much. My Question is: Should this feature be compiled by default if canaries are used? Or just left there for the developer to use when deemed necessary. BR \Lego -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol dissector
I'd be against inclusion too... Wireshark is a Protocol-Analyzer not a Network Penetration Analysis tool or something similar. from that PoV it's just unappropriate... On the other hand someone has to tell the sysadmin to dump that key ASAP, bad guys know it's broken already. 65536 attempts to see if eventually we could decrypt and add an expert item in regarding the vulnerability would be appropriate. I Abstain from voting. On Wed, Aug 6, 2008 at 12:48 AM, Bill Meier [EMAIL PROTECTED] wrote: Ulf Lamping wrote: Sake Blok schrieb: snip I personally vote against inclusing of this code into the source tree. How do others feel about the inclussion of this code? FULL ACK to Sake! +1 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] old wiretap-0.3.1.dll in Wireshark 1.0.2win32installer
Preety quickly in relative terms... DJB pointed out the vulnerability back in July 2001... that would be more than 7 years (http://cr.yp.to/djbdns/forgery-cost.txt). \Lego On Mon, Aug 4, 2008 at 7:08 PM, Gerald Combs [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 11:29:54 +0200, Jaap Keuter [EMAIL PROTECTED] wrote: That was talk about c-ares as replacement for adns. It came out on top of my preference list (further candidates: UDNS and posadis). I have had no time to investigate this any further, let alone start design/implementation. It looks like the c-ares community reacted pretty quickly to the DNS poisoning flaw discovered recently (http://daniel.haxx.se/projects/c-ares/mail/c-ares-archive-2008-07/) while the ADNS community hasn't (http://www.kb.cert.org/vuls/id/MIMG-7ECL5U). This is probably a good hint that we should switch. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] lost debugging symbols in off tree build on leopard
I got a new Mac, new processor family (much hotter), new OS version, new checkout... Same configure options I used to use. It builds OK. But, as I launch gdb for wireshark, I get plenty of these warnings : warning: Could not find object file /Users/lego/ws_trunk/build/epan/.libs/libwireshark.lax/libdfilter.a/libdfilter_la-drange.o - no debug information available for ../../../epan/dfilter/drange.c. One for almost each .o (few objects are findable). That turns out make me not to be able to inspect frames for functions defined in most of the source (I see them like those for built in libs). I guess this is because we delete or rename this object files during the build process. Has anyone seen this? Does anyone has a workarround for this? Thanks, \Lego -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Windows build docs step failing on xmllint of wslua_pinfo.xml
I don' get it: Why it fails on line 154 and doesn't do it 6 lines before on line 148 for an identical structure I guess removing the undocumented Grabage collectors from the docs should fix the prior. I'll check the results. section id='lua_fn_tvb___tostring__' titletvb:__tostring()/title paraconvert the bytes of a Tvb into a string, to be used for debugging purposes as '...' will be appended in case the string is too long./para sectiontitleReturns/title parathe string./para /section !-- function_returns_footer: tvb:__tostring -- /section !-- function_footer: -- section id='lua_fn_tvb_len__' titletvb:len()/title paraobtain the length of a TVB/para sectiontitleReturns/title parathe length of the Tvb./para /section !-- function_returns_footer: tvb:len -- /section !-- function_footer: -- On Tue, Jul 29, 2008 at 1:16 AM, Bill Meier [EMAIL PROTECTED] wrote: The Windows buildbot build docs step is failing. I suspect the failure is related to SVN #25845.. - perl make-wsluarm.pl ../epan/wslua/wslua_dumper.c ../epan/wslua/wslua_field.c ../epan/wslua/wslua_gui.c ../epan/wslua/wslua_listener.c ../epan/wslua/wslua_pinfo.c ../epan/wslua/wslua_proto.c ../epan/wslua/wslua_tree.c ../epan/wslua/wslua_tvb.c ../epan/wslua/wslua_util.c touch wsluarm --- WSUG - VALIDATING XML --- xmllint --valid --noout user-guide.xml wsluarm_src/wslua_pinfo.xml:46: element section: validity error : Element section content does not follow the DTD, expecting (sectioninfo? snip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Accessing SCTP data chunk length etc
the information about the length of the transported pdu is passed via the tvb. take a look at tvbuff.h On Mon, Jul 21, 2008 at 3:20 PM, Gastermann, Bernd Christian [EMAIL PROTECTED] wrote: Dear Wireshark team! I am currently writing a wireshark plugin which dissects custom data chunks from within a sctp message. Unfortunately, in order to work properly, it is necessary to know how long this specific sctp data chunk is. I've tried several things (for example writing another sctp plugin which overwrites the existing one) but nothing worked or solved the problem. The only solution was to modify wireshark's internal sctp dissector (packet-sctp) to write all the necessary information (in this case data chunk length without header length) into the private data of packetinfo (pinfo-private_data) so that my dissector can read it. I currently need the data chunk stream id and length from within these sctp packets for debugging. Now I have two questions: Firstly, do you know a better, easier solution for this problem without modifying wireshark itself? And secondly, if there is no better way, do you think it is possible to integrate such changes into wireshark's public source code so that we can access this information in future versions too (although it may not be very useful for others)? I attached a diff-file with all changes I made to 'packet-sctp.c' and 'packet-sctp.h'. I used revision 25778 from SVN. Any suggestions would be highly appreciated! :) Thanks in advance! Bernd Gastermann ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] accessing field in IP header from L2TP dissector
He says the only interesting info there's in the IP header is the length. If he needs it to calculate the length of the payload. There's no need to access the IP header.The length of the payload data is passed to the dissector intrinsically by the tvb (tvb-length). L On Fri, Jul 18, 2008 at 11:04 AM, Géraud Berthomier [EMAIL PROTECTED] wrote: Hello Alex Volinsky, I think that you can have a look on the structure pinfo which have a packet-info type. Have a look in Wireshark/epan/packet-info.h Good luck! Byebye. 2008/7/18 alex volinsky [EMAIL PROTECTED]: Hello everybody. I'm adding DOCSIS DEPI dissector to Wireshark. The packet format is Ethernet/ IPv4 / L2TPv3/ DEPI. To parse DEPI payload correctly, I need to know the packet length, which is obtained from IP header. One of the options is to set my data pointer 18 bytes back in the beginning of L2TPv3 header dissector, but I wonder if there is some function call to access a field (ip.len)of IP dissector from another file ? Thanks everybody Alex Volinsky ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- Cordialement, Géraud Berthomier. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] tshark and /tmp/etherXXXX files
I guess these are very large files. Most people wouldn't bother if they weren't. So I guess you are doing long running captures and periodically tshark crashes http://wiki.wireshark.org/KnownBugs/OutOfMemory . You could wrap tshark in a script that cleans behind those files. A Developer wonders if we can set a call back for when g_malloc() fails? On Fri, Jul 18, 2008 at 10:50 PM, Dan Murphy [EMAIL PROTECTED] wrote: Just installed v 1.0.2. Same thing. tshark leave behind files in tmp. On Thu, Jul 17, 2008 at 10:19 PM, Guy Harris [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 11:30 AM, Dan Murphy wrote: I'm running v 99.7 and I have a problem where the temp files are kind of becoming unmanageable. I noticed my old version 99.5 does not create these. What happens if you run the *current* version of TShark, which is 1.0.2: http://www.wireshark.org/news/20080710.html ___ Wireshark-users mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-users ___ Wireshark-users mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-users -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] tshark and /tmp/etherXXXX files
Or... what happens if you try to open these files with wireshark? Does it crash? On Sat, Jul 19, 2008 at 4:31 AM, Luis EG Ontanon [EMAIL PROTECTED] wrote: I guess these are very large files. Most people wouldn't bother if they weren't. So I guess you are doing long running captures and periodically tshark crashes http://wiki.wireshark.org/KnownBugs/OutOfMemory . You could wrap tshark in a script that cleans behind those files. A Developer wonders if we can set a call back for when g_malloc() fails? On Fri, Jul 18, 2008 at 10:50 PM, Dan Murphy [EMAIL PROTECTED] wrote: Just installed v 1.0.2. Same thing. tshark leave behind files in tmp. On Thu, Jul 17, 2008 at 10:19 PM, Guy Harris [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 11:30 AM, Dan Murphy wrote: I'm running v 99.7 and I have a problem where the temp files are kind of becoming unmanageable. I noticed my old version 99.5 does not create these. What happens if you run the *current* version of TShark, which is 1.0.2: http://www.wireshark.org/news/20080710.html ___ Wireshark-users mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-users ___ Wireshark-users mailing list [EMAIL PROTECTED] https://wireshark.org/mailman/listinfo/wireshark-users -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SVN #25615: Wiretap code probably shouldn't abort the application either.
The one in k12.c is leftover debugging code, The asertion will never fail (not anymore). \Lego On Thu, Jul 17, 2008 at 6:36 PM, Bill Meier [EMAIL PROTECTED] wrote: The Windows buildbot has been failing since about July 1 due to checkAPIs -g abort errors for several wiretap files. One consequence is that the Windows Development install package is not being generated. So: I've removed the -g abort from the wiretap makefile checkAPIs line for now so as to allow the Development Windows install package to be built (assuming no other errors). The following 4 wiretap files appear to use g_error etc in relation to checking for programming errors. Q: Is the use of g_error etc not OK in these cases ? buffer.c: exit,g_error etherpeek.c: g_assert file_access.c: g_error k12.c: g_assert -- A quick look suggests that the following 3 files are using g_assert when checking for file format errors. I would guess that this code should be changed ngsniffer.c: g_assert pppdump.c: g_assert wtap.c: g_assert ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How to register the plugins
On Wed, Jul 16, 2008 at 8:55 AM, [EMAIL PROTECTED] wrote: It is a connection oriented message with CODT type [...] I couldn't understand how bssap packet of same format (CODT) could able to dissect without SSN no. but the one which I wrote couldn't dissect them properly. For Connection Oriented SCCP (and SUA) Wireshark needs to see the CC because it contains the information that will be used to later know how to dissect the payload of following messages. If your file does not contain the CC msg for that call heuristics must be attempted to find out what is the payload . For the heuristic dissectors: It is your code for the xxx heuristics that has to determine whether a packet is XXX or not and either return 1 (yes it is XXX), or 0 (no it s not XXX, try another). I do not understand how and why if you are returning 0 after seeing that it is not XXX wireshark will anyhow decode it as XXX. Most probably theree's something broken in your heuristics. \Lego -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How to register the plugins
Does it use Connection Oriented or Connection Less?
SCCP and SUA carry the SSN number only in the CC message. So, In order
to know which subdissector to use for CO messages other than CC
SCCP/SUA mantains a table of connections, this is disabled by default
(try enabling Trace Associations in SCCP preferences). That has been
tested with SCCP, the implementation in SUA has not being thoroughly
tested due to lack of capture files.
If you can send a capture file we might see what's going with SUA's
connection tracking
(cut the capture just after the SUA header)
On Tue, Jul 15, 2008 at 2:27 PM, [EMAIL PROTECTED] wrote:
Hi
It was my mistake, they are 90 and 91 only not 91 and 92 as stated first.
Regards,
Chandra.
From: [EMAIL PROTECTED] on behalf of Abhik Sarkar
Sent: Tue 7/15/2008 5:41 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How to register the plugins
You said initially that the SSN's are 91 and 92, but you are
subsequently using 90 and 91 during registration... Not sure if that
is correct. If it isn't then XXX messages should be dissected as YYY
messages.
Also, you might want to not register the heuristic dissector and try.
HTH
Abhik.
On Tue, Jul 15, 2008 at 3:39 PM, [EMAIL PROTECTED] wrote:
Hi all,
I wrote two plugins which run on sua layer. The plugins are xxx and yyy and
their subsystem no. are 91 and 92 respectively.
Now I registered the two protocols as
For XXX plugin:
static guint global_xxx_ssn = 90;
Void proto_reg_handoff_xxx(void)
{
static dissector_handle_t xxx_handle;
heur_dissector_add(sua, dissect_xxx, proto_xxx);
xxx_handle = create_dissector_handle(dissect_xxx, proto_xxx);
dissector_add(sccp.ssn, global_xxx_ssn, xxx_handle);
}
For YYY plugin:
static guint global_yyy_ssn = 91;
Void proto_reg_handoff_yyy(void)
{
static dissector_handle_t yyy_handle;
heur_dissector_add(sua, dissect_yyy, proto_yyy);
yyy_handle = create_dissector_handle(dissect_yyy, proto_yyy);
dissector_add(sccp.ssn, global_yyy_ssn, yyy_handle);
}
Now the problem is the data what ever comes above sua layer is dissected as
yyy protocol.
The data which comes after yyy protocol is dissected as xxx protocol.
But both the plugins should run on sua layer and depending on subsystem no.
they have to be differentiated.
Can any one please suggest me how to register the plugins properly so that
then can be dissected properly on sua layer?
Thanks in advance,
Atdev.
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus transmitted
by this email.
www.wipro.com
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] V5.2 and PRI protocols
V5.2 is not implemented and it has to be written (from scratch) there's an V5UA implementation but while semantically it is the same syntactically it's a different protocol. As per ISDN-PRI (DSS1), it uses Q.931 over LAP-B for call control and both are implemented. BTW neither V5.2 nor DSS1 are transported on top of MTP. On Tue, Jul 15, 2008 at 3:55 PM, Mahdi M. Hossaini [EMAIL PROTECTED] wrote: Dear list members, There are two important protocol in PSTN networks which are not supported in wireshark, They are: V5.2 ISDN-PRI (DSS1) These protocols are used on TDM (T1/E1) links as for MTP and ISUP. What is the reason for this weakness in wirshark and what must we do to support them in wireshark? Best regards, Mahdi M. Hossaini RAYAPHONE ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] cast increases required alignment of target type in packet-diameter.c
I think the cast to void* is OK.
the GArray is created given sizeof(struct contained_t) so it is going
to mallocate a block of N*sizeof(struct contained_t) and the very
first struct contained_t will be aligned o the base of the block given
by malloc (a void*), taking into account that compilers are supposed
to size structs into valid pointer boundaries, my guess is that every
struct contained_t in the GArray will be propperly aligned.
On Tue, Jul 15, 2008 at 4:50 PM, Jeff Morriss [EMAIL PROTECTED] wrote:
Hi folks,
My Solaris/SPARC compiles (with gcc-3.4.6) die with an alignment warning
in packet-diameter.c:
packet-diameter.c: In function `dissect_diameter_avp':
packet-diameter.c:340: warning: cast increases required alignment of target
type
(followed by several more such warnings)
The relevant code for the first warning is:
109 typedef struct _diam_vnd_t {
110 guint32 code;
111 GArray* vs_avps;
112 GArray* vs_cmds;
113 } diam_vnd_t;
[...]
126 #define VND_AVP_VS(v) ((value_string*)((v)-vs_avps-data))
[...]
319 const diam_vnd_t* vendor;
[...]
340 vendor_avp_vs = VND_AVP_VS(vendor);
GArray comes from GLIB's garray.h:
34 typedef struct _GArray GArray;
[...]
38 struct _GArray
39 {
40 gchar *data;
41 guint len;
42 };
The Solaris buildbot is not getting this warning but I think the warning
is valid: an array of chars may not be aligned correctly to be accessed
as a 'value_string' (a guint32 followed by a pointer). And it may cause
bus errors because GArrays make copies of the data passed in--so we have
no guarantee how it will be aligned.
Unfortunately GArrays come in only 3 flavors: with pointers to chars,
pointers to guint8s, and pointers to pointers.
Is there an easy way to solve this?
Adding an intermediate cast to void*:
#define VND_AVP_VS(v) ((value_string*)(void*)((v)-vs_avps-data))
solves the warning and it appears this is the approach used by the glib
team:
http://svn.gnome.org/viewvc/glib?view=revisionrevision=6092
but I don't think it's correct. But at the moment I also think the
example (storing gint values) used in the GArrays documentation:
http://library.gnome.org/devel/glib/unstable/glib-Arrays.html
is also not correct/safe on SPARCs. Can someone please tell me I'm wrong?
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark version
I saw a report on this ML of someone downloading the 1.0.0 installer from the 1.0.1 link... is this another case? On Wed, Jul 9, 2008 at 2:59 PM, Jeff Morriss [EMAIL PROTECTED] wrote: Martin Corraine (mcorrain) wrote: Hello, Is there a reason the new version of the win32 Wireshark says 1.0.0 instead of 1.0.1? Where does it say that? In Help-About my Windows Wireshark says: Version 1.0.1 (SVN Rev 25639) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA development highlighting bytefield display with LUA
On Fri, Jun 20, 2008 at 3:58 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
So when you say that using a ProtoField would create a filterable field,
do you mean that wireshark can then filter based on some field in the
protocol which has the ProtoField added to it?
Yes, That's exactly it.
If so, then what would that field be, and how would you access it?
You need to register a protocol, it's name gives you the first part of
the filters. the name of the ProtoField is the second part:
local proto = Proto.new(myproto)
local my_field1 = ProtoField.uint8(field1)
local my_field2 = ProtoField.uint8(field2)
proto.fields = {my_field1, my_field2}
that would create two display filter fields: myproto.field1 and myproto.field2
E.G. does that mean that when I start up my wireshark and start a
capture, can I then try in the filter field something like my_proto
contains my_field and it would then only show the packets that contain
my_field, or did you mean something else by being filterable?
Yes that's almost what that means!
The filter would be myproto.field1 or like myproto.field1 == 3,
not my_proto contains field1.
The keyword contains is for another purposeL my_proto contains
01:02:03 whould match only if the bytes belonging to my_proto contain
the hex sequence 010203.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luis EG
Ontanon
Sent: Wednesday, June 18, 2008 10:32 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LUA development highlighting bytefield
display with LUA
mytree = subtree:add(tvb:range(0x1), STUFF) should work
or better if you defina a protoField lets'say
local pf_mine = ProtoField.uint8(my_field)
...
mytree = subtree:add(pf_mine, STUFF)
should not only highlight the bytes but should create a filterable field
my_proto.my_filed for the byte(s) in the tvbRange.
On Wed, Jun 18, 2008 at 3:15 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
I've been trying to use this to get the subtrees to highlight, and so
far I can only get the first subtree to highlight correctly. Here's
the syntax of what I'm trying.
local subtree = (tree:add(my_proto, tvb:range(), my header)) --
works local mytree = (subtree:add(TEST , tvb:range(0x1), STUFF))
-- doesn't highlight
I know that wireshark can highlight the subtrees just by looking at
the ethernet filters in the hex pane, but for some reason this isn't
highlighting there. What should I do to get this to highlight. The
way I figure this should work is the first one highlights the entire
tvb, which it does, and the second should highlight all but the first
byte, which it doesn't.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luis EG
Ontanon
Sent: Tuesday, June 17, 2008 7:47 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LUA development highlighting bytefield
display with LUA
Lua uses the very same API that dissectors use. For protocol tree
items created with Lua (when they are given a tvbRange) the bytes in
the hex dump pane get highlighted as with any other dissector.
On Mon, Jun 16, 2008 at 3:37 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
Hey there,
I was wondering if there was a way to make my LUA dissector highlight
specific bytes in the bytefield display so that they stand out
easily,
such as the various portions of my header and attach these to the
subtrees that explain what they are. I know something that does this
is already built into wireshark and that it works very well for
predefined message types, for instance it dissects TCP headers is a
very readable way so that you can actually see which bytes correspond
to the source and destination addresses. I would like to do
something
similar on my own message type, so that the specific portions of my
message are easily readable after dissection. Is there any way to do
this inside my LUA script?
Brent Rowswell
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy
yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy
yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman
Re: [Wireshark-dev] LUA development highlighting bytefield display with LUA
it turns the protocol name into lowercase
so that'd be:
myproto.stuff
it should turn green if it is ok.
what about the [Expression...] dialog do you see your proto there?
On Fri, Jun 20, 2008 at 6:05 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
Whenever I try to run the filter on the ProtoFields wireshark comes up
with an error.
I'm trying to assign the ProtoField as such:
local my_proto = Proto(MYPROTO, myproto does some stuff)
local test = ProtoField.uint8(stuff)
my_proto.fields = test
And the filter I'm trying to use is MYPROTO.stuff correct?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luis EG
Ontanon
Sent: Friday, June 20, 2008 10:09 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LUA development highlighting bytefield
display with LUA
On Fri, Jun 20, 2008 at 3:58 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
So when you say that using a ProtoField would create a filterable
field, do you mean that wireshark can then filter based on some field
in the protocol which has the ProtoField added to it?
Yes, That's exactly it.
If so, then what would that field be, and how would you access it?
You need to register a protocol, it's name gives you the first part of
the filters. the name of the ProtoField is the second part:
local proto = Proto.new(myproto)
local my_field1 = ProtoField.uint8(field1) local my_field2 =
ProtoField.uint8(field2)
proto.fields = {my_field1, my_field2}
that would create two display filter fields: myproto.field1 and
myproto.field2
E.G. does that mean that when I start up my wireshark and start a
capture, can I then try in the filter field something like my_proto
contains my_field and it would then only show the packets that contain
my_field, or did you mean something else by being filterable?
Yes that's almost what that means!
The filter would be myproto.field1 or like myproto.field1 == 3, not
my_proto contains field1.
The keyword contains is for another purposeL my_proto contains
01:02:03 whould match only if the bytes belonging to my_proto contain
the hex sequence 010203.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luis EG
Ontanon
Sent: Wednesday, June 18, 2008 10:32 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LUA development highlighting bytefield
display with LUA
mytree = subtree:add(tvb:range(0x1), STUFF) should work
or better if you defina a protoField lets'say
local pf_mine = ProtoField.uint8(my_field)
...
mytree = subtree:add(pf_mine, STUFF)
should not only highlight the bytes but should create a filterable
field my_proto.my_filed for the byte(s) in the tvbRange.
On Wed, Jun 18, 2008 at 3:15 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
I've been trying to use this to get the subtrees to highlight, and so
far I can only get the first subtree to highlight correctly. Here's
the syntax of what I'm trying.
local subtree = (tree:add(my_proto, tvb:range(), my header)) --
works local mytree = (subtree:add(TEST , tvb:range(0x1), STUFF))
-- doesn't highlight
I know that wireshark can highlight the subtrees just by looking at
the ethernet filters in the hex pane, but for some reason this isn't
highlighting there. What should I do to get this to highlight. The
way I figure this should work is the first one highlights the entire
tvb, which it does, and the second should highlight all but the first
byte, which it doesn't.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luis EG
Ontanon
Sent: Tuesday, June 17, 2008 7:47 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LUA development highlighting bytefield
display with LUA
Lua uses the very same API that dissectors use. For protocol tree
items created with Lua (when they are given a tvbRange) the bytes in
the hex dump pane get highlighted as with any other dissector.
On Mon, Jun 16, 2008 at 3:37 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
Hey there,
I was wondering if there was a way to make my LUA dissector
highlight
specific bytes in the bytefield display so that they stand out
easily,
such as the various portions of my header and attach these to the
subtrees that explain what they are. I know something that does
this
is already built into wireshark and that it works very well for
predefined message types, for instance it dissects TCP headers is a
very readable way so that you can actually see which bytes
correspond
to the source and destination addresses. I would like to do
something
similar on my own message type, so that the specific portions of my
message are easily readable after dissection. Is there any way to
do
this inside my LUA script?
Brent Rowswell
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https
Re: [Wireshark-dev] Function explanation of WireShark
Use the SOUrce young padawan... what about tvbuff.h 2008/6/19 Jiabin Liao [EMAIL PROTECTED]: Hi, Recently, I want to write a plug-in for WireShark. But I can do it smoothly, for I always could not understand the examples in the source packeg, such as packet-udp.c. The problem is I can find the explanation of many functions, such as tvb_reported_length_remaining()、dissector_try_heuristic(), and so on. README files do not explain how to use them. Where can I find the explanation? Jiabin. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Recursive dissection
with tvb_new_subset() you create a sub-tvb with the range you are interested in, then you can recur onto your function passing it that sub-tvb. On Wed, Jun 18, 2008 at 9:16 PM, Matt Poduska [EMAIL PROTECTED] wrote: Hello, In order to accept into the Wireshark codebase, it was suggested that I recode a dissector plugin I created and submitted a few months ago. I'm curious if there are any suggestions on the best way to use tvb_* functions for dissecting a recursively-defined protocol. LLRP (the protocol I'm trying to dissect) defines it's messages as a collection of parameters and fields, where parameters can contain other parameters and fields. My current implementation includes buffer wrapper functions to deal with maintaining the current location within the tvb as the message (parameters and fields) are parsed. Is there native tvb_* functions that do this type of thing already? Thanks, Matt Poduska https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1957 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA development highlighting bytefield display with LUA
mytree = subtree:add(tvb:range(0x1), STUFF) should work or better if you defina a protoField lets'say local pf_mine = ProtoField.uint8(my_field) ... mytree = subtree:add(pf_mine, STUFF) should not only highlight the bytes but should create a filterable field my_proto.my_filed for the byte(s) in the tvbRange. On Wed, Jun 18, 2008 at 3:15 PM, Rowswell, Brent [EMAIL PROTECTED] wrote: I've been trying to use this to get the subtrees to highlight, and so far I can only get the first subtree to highlight correctly. Here's the syntax of what I'm trying. local subtree = (tree:add(my_proto, tvb:range(), my header)) -- works local mytree = (subtree:add(TEST , tvb:range(0x1), STUFF)) -- doesn't highlight I know that wireshark can highlight the subtrees just by looking at the ethernet filters in the hex pane, but for some reason this isn't highlighting there. What should I do to get this to highlight. The way I figure this should work is the first one highlights the entire tvb, which it does, and the second should highlight all but the first byte, which it doesn't. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luis EG Ontanon Sent: Tuesday, June 17, 2008 7:47 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] LUA development highlighting bytefield display with LUA Lua uses the very same API that dissectors use. For protocol tree items created with Lua (when they are given a tvbRange) the bytes in the hex dump pane get highlighted as with any other dissector. On Mon, Jun 16, 2008 at 3:37 PM, Rowswell, Brent [EMAIL PROTECTED] wrote: Hey there, I was wondering if there was a way to make my LUA dissector highlight specific bytes in the bytefield display so that they stand out easily, such as the various portions of my header and attach these to the subtrees that explain what they are. I know something that does this is already built into wireshark and that it works very well for predefined message types, for instance it dissects TCP headers is a very readable way so that you can actually see which bytes correspond to the source and destination addresses. I would like to do something similar on my own message type, so that the specific portions of my message are easily readable after dissection. Is there any way to do this inside my LUA script? Brent Rowswell ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA development highlighting bytefield display with LUA
Lua uses the very same API that dissectors use. For protocol tree items created with Lua (when they are given a tvbRange) the bytes in the hex dump pane get highlighted as with any other dissector. On Mon, Jun 16, 2008 at 3:37 PM, Rowswell, Brent [EMAIL PROTECTED] wrote: Hey there, I was wondering if there was a way to make my LUA dissector highlight specific bytes in the bytefield display so that they stand out easily, such as the various portions of my header and attach these to the subtrees that explain what they are. I know something that does this is already built into wireshark and that it works very well for predefined message types, for instance it dissects TCP headers is a very readable way so that you can actually see which bytes correspond to the source and destination addresses. I would like to do something similar on my own message type, so that the specific portions of my message are easily readable after dissection. Is there any way to do this inside my LUA script? Brent Rowswell ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA development changing column headers
pinfo.cols.protocol = MyProto
should work
possible pinfo.columns indexes are:
static const struct col_names_t colnames[] = {
{number,COL_NUMBER},
{abs_time,COL_ABS_TIME},
{cls_time,COL_CLS_TIME},
{rel_time,COL_REL_TIME},
{date,COL_ABS_DATE_TIME},
{delta_time,COL_DELTA_TIME},
{delta_time_displayed,COL_DELTA_TIME_DIS},
{src,COL_DEF_SRC},
{src_res,COL_RES_SRC},
{src_unres,COL_UNRES_SRC},
{dl_src,COL_DEF_DL_SRC},
{dl_src_res,COL_RES_DL_SRC},
{dl_src_unres,COL_UNRES_DL_SRC},
{net_src,COL_DEF_NET_SRC},
{net_src_res,COL_RES_NET_SRC},
{net_src_unres,COL_UNRES_NET_SRC},
{dst,COL_DEF_DST},
{dst_res,COL_RES_DST},
{dst_unres,COL_UNRES_DST},
{dl_dst,COL_DEF_DL_DST},
{dl_dst_res,COL_RES_DL_DST},
{dl_dst_unres,COL_UNRES_DL_DST},
{net_dst,COL_DEF_NET_DST},
{net_dst_res,COL_RES_NET_DST},
{net_dst_unres,COL_UNRES_NET_DST},
{src_port,COL_DEF_SRC_PORT},
{src_port_res,COL_RES_SRC_PORT},
{src_port_unres,COL_UNRES_SRC_PORT},
{dst_port,COL_DEF_DST_PORT},
{dst_port_res,COL_RES_DST_PORT},
{dst_port_unres,COL_UNRES_DST_PORT},
{protocol,COL_PROTOCOL},
{info,COL_INFO},
{packet_len,COL_PACKET_LENGTH},
{cumulative_bytes,COL_CUMULATIVE_BYTES},
{oxid,COL_OXID},
{rxid,COL_RXID},
{direction,COL_IF_DIR},
{circuit_id,COL_CIRCUIT_ID},
{src_idx,COL_SRCIDX},
{dst_idx,COL_DSTIDX},
{vsan,COL_VSAN},
{tx_rate,COL_TX_RATE},
{rssi,COL_RSSI},
{hpux_subsys,COL_HPUX_SUBSYS},
{hpux_devid,COL_HPUX_DEVID},
{dce_call,COL_DCE_CALL},
{NULL,0}
};
On Mon, Jun 16, 2008 at 2:38 PM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
Thank you for getting back to me so quickly,
So you're saying that I can edit the text in the pinfo.columns field,
which should mean that I can change say Protocol, where it normally puts
TCP, UDP, etc. to any string that I want? If so, what would be the
correct syntax to do so? pinfo.columns:_newindex(Protocol,
NameOfProto) doesn't seem to work, which makes me think that my syntax
is off.
Brent Rowswell
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luis EG
Ontanon
Sent: Friday, June 13, 2008 4:57 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LUA development changing column headers
You cannot add columns that way using Lua, Lua can use just the columns
that are already there under pinfo.columns ...
The outdated example you talk about does not create a column it just
switches over the src and dst addresses.
On Fri, Jun 13, 2008 at 12:04 AM, Rowswell, Brent
[EMAIL PROTECTED] wrote:
Over the past few weeks I've been trying to make a LUA script to parse
out my header information, open up the packet and display the
necessary data in a various tree structure. So far all of that has
been done well enough, but I find that the packets that I have
dissected come maybe once every 300 packets, which makes it pretty
hard to compare packets. What I've been trying to do is either edit
the packet column data, such as where the ip source or destination is
displayed into my own data, or add a new column of my own type so that
I can sort the data, which will then put all of my packets next to
each other. I know that on the wiki of lua examples there's an
outdated way of doing something similar, but it no longer works with
the current 1.0.0 build of wireshark. I was wondering if I could get
some help in how the syntax should look, for instance if this would
work: using pinfo.cols to grab the packet's columns, and upon that
use :_newindex(Msgtype, NameofMsg) to put in a new column named
Msgtype where this packets data in that column would be NameofMsg,
thus the message would look like
pinfo.cols:_newindex(Msgtype,NameofMsg)
If anyone can think of another way of doing this, either by adding a
new column or changing the text of an existing one, I would be
appreciative.
Brent Rowswell
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy
yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA development changing column headers
You cannot add columns that way using Lua, Lua can use just the columns that are already there under pinfo.columns ... The outdated example you talk about does not create a column it just switches over the src and dst addresses. On Fri, Jun 13, 2008 at 12:04 AM, Rowswell, Brent [EMAIL PROTECTED] wrote: Over the past few weeks I've been trying to make a LUA script to parse out my header information, open up the packet and display the necessary data in a various tree structure. So far all of that has been done well enough, but I find that the packets that I have dissected come maybe once every 300 packets, which makes it pretty hard to compare packets. What I've been trying to do is either edit the packet column data, such as where the ip source or destination is displayed into my own data, or add a new column of my own type so that I can sort the data, which will then put all of my packets next to each other. I know that on the wiki of lua examples there's an outdated way of doing something similar, but it no longer works with the current 1.0.0 build of wireshark. I was wondering if I could get some help in how the syntax should look, for instance if this would work: using pinfo.cols to grab the packet's columns, and upon that use :_newindex(Msgtype, NameofMsg) to put in a new column named Msgtype where this packets data in that column would be NameofMsg, thus the message would look like pinfo.cols:_newindex(Msgtype,NameofMsg) If anyone can think of another way of doing this, either by adding a new column or changing the text of an existing one, I would be appreciative. Brent Rowswell ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] packet parsing question
You want to read doc/README.developer from the src tree. On Thu, May 29, 2008 at 4:31 PM, Piety, Timothy [USA] [EMAIL PROTECTED] wrote: Hi, I am trying to figure out how wireshark actually does teh dissection of a packet. I have a packet and I know the protocol, but do not have a parser for it. I would like to be able to give the packet to wireshark and have wireshark parse it then read the values back form the appropriate structure. I have been looking a the code and do not see where wireshark a determines what the protocol is and which specific dissector to call. I have been able to find out where it determines which file type the input file is. I have traced the code into a routine called call_dissector_through_handle in packet.c. This appears to call the specific dissector through dissector_handle funtion pointer. I cannot find where the dissector_handle is set. Am I on the right track? Any guidance would be appreciated. thanks, Tim ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
I personally believe not passing retransmitted frames is a better choice, besides that its implementation is narrower, I see it as natural for a transport protocol not to pass retransmissions to the upper layer. All in all the user has a link in the packet details to the originally-transmitted frame if they need to see the dissection of the payload. L On Wed, May 28, 2008 at 10:24 PM, Sake Blok [EMAIL PROTECTED] wrote: On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote: On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: Today I noticed that SSL decryption breaks when there is a tcp retransmission. We never run out of things to fix, do we? :) It's a mixed up world, we should have all bugs fixed before the end of the day and never run out of beer... and *not* the other way around ;-) To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. Something about this just doesn't feel right. Well, at first no. But I reconsidered and to me it feels like the sensible way to go. All statistics will have duplicates when the retransmitted data is sent again to the upper layer dissector. (remember my session on Sharkfest, where enabling or disabling the tcp.desegment_tcp_streams preference gave different results). Dissecting the retransmitted data with the data dissector prevents these glitches. Also, on the system that received the packets, the data is sent to the upper layer only once (in case the ACK got lost and it indeed received the data twice). - Have a retransmitted_data flag in the frame-data structure which can be set by a dissector to warn the called dissector that the data is is receiving is actually a copy of earlier received data so that it can take proper action in dissecting it. I like this idea. The next protocol can then use it if necessary or ignore it. Yep, but that means having to change each and every dissector which has tcp as it's transport layer. - Accept that retransmitted frames will break SSL decryption and let the user delete the retransmitted frames themselves with editcap. Too much work for the user :). Agreed, have a look at the users-list, there is a thread in which this problem occurs :-) Any objections to the following fix: Have a preference in the tcp profile like show retransmitted frames as data with tooltip Dissecting the same fragment of data twice can disrupt the upper layer dissectors (ssl-decryption for example). By default this preference will be unchecked to not change the current behavior. Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Something has happened to the uat dialogs...
On Wed, May 28, 2008 at 8:27 PM, Guy Harris [EMAIL PROTECTED] wrote: Sake Blok wrote: I think these errors were introduced after the whole GTK-1 cleanup. No, the use of GTK_TREE_VIEW() on rep-clist goes back at least as fiar as revision 20599, long before we got rid of GTK+ 1.2[.x] support, if that's what you mean by the whole GTK-1 cleanup. Luis, now that we no longer support GTK+ 1.2[.x], should it be changed to use a GtkTreeView rather than a GtkCList? Yes, I believe it should. BTW I used a GtkCList because a it was GtkCList what was used by the color filter dialog, from which I took most of the GUI code for UAT. Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Lua and heuristic dissectors
No planning on anything... Still it shouldn't be too complex to add heuristic dissectors... We should: - change the current lua dissector (the wrapper that invokes the lua user function) to use the signature of a new-style dissector and pass the return of the lua function. - change the register functions to register new-style dissectors Anyway, being heuristic dissector preety intensive (they are called too many times more than normal ones) you'd probably go better writing your heuristic dissector in C. BR Luis On Fri, May 23, 2008 at 1:31 PM, Will Wagner [EMAIL PROTECTED] wrote: Hi all, I have been using the Lua plugin to quickly write and test my dissector. However I was wondering if there is any support for heuristic dissectors in Lua and if not if it is planned. The Lua support has been great for fast prototyping. Looking at the code it appears there isn't support so I guess I'll just have to start on a plugin. Thanks, Will. -- Will Wagner [EMAIL PROTECTED] Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] request help for packet capture using libpcap
Nothing captured? Unflushed output? 24 bytes is the pcap file header and no packets. On Tue, May 6, 2008 at 1:10 PM, [EMAIL PROTECTED] wrote: Hello , I have been trying to write a small application using libpcap library. Purpose is to capture some live network packets(say 100 packets) and store them in a file (pcap_savefile). Please refer the attachment for the code. As per my understanding the pcap_savefile should be in pcap format as this is the default file format for libpacp. But when I pass this file to wireshark, it does not show any packet data. Also the size of the pcap_savefile is just around 24 bytes for 100 packets. So I was wondering whether the programm is actually capturing any network packet. Could anyone please suggest how I can improve the programe and store the data in pcap format. Thanks in advance. Regards, Atdev Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] own dissector doesn't work with root
Wireshark won't load plugins not owned by root if running as root. That is to avoid someone writing a plugin that (e.g.) executes a shell with root priviledges in a system where wireshark is allowed by sudo. # chown root your_plugin By the way WS as of 1.0 does not require to be run as root anymore, it runs setuid and drops privileges ASAP. Luis On Tue, May 6, 2008 at 12:42 PM, Stephan Neumann [EMAIL PROTECTED] wrote: I have written an own dissector which works without problems, but when I start wireshark as the root (sudo or su) my plugin is not available. Has anybody an idee why it is so? and has anybody an idee how my own dissector is available as a root? -- 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro. Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compiling with VS-2005
you can either build it yourself with MSVC6 (that's what we use for official releases) or just publish it so that it comes with official releases. On Mon, May 5, 2008 at 3:38 PM, Barry Constantine [EMAIL PROTECTED] wrote: I recently wrote my first dissector and compiled with Microsoft VS 2005 Express Edition. I noted on the web that there are issues being able to use the dll in the released Wireshark executable. I only can get mine to work in my own compiled machine. Is there a work around to this? Thanks, Barry ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Help: How to add files to Wireshark
On unix: make clean ./autogen.sh ./configure make On windows: nmake -f Makefile.nmake clean nmake -f Makefile.nmake all On Wed, Apr 30, 2008 at 3:20 PM, goitom kahsay [EMAIL PROTECTED] wrote: Hi Jaap, Thank you very much for every thing. But the added file does not compile. And also it does not create any object file. Thank you in advance On Wed, Apr 30, 2008 at 11:48 AM, Jaap Keuter [EMAIL PROTECTED] wrote: Hi, gtk/Makefile.common is the place for that. Thanx, Jaap goitom kahsay wrote: Hello All, How can i add a file to the wireshark source code? Spesficaly to add a file to the* GTK* folder. Any idea is appriciated -- Benice2all ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- Benice2all ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Do we require lua version 5.1 for the lua plugin?
For practical reasons I removed lua 5.0.x support when I migrated wslua into epan. I thought I had modified the autogen stuff to reflect this. I think we should look for lua_getfield() to verify if we are using the right version. Luis On Tue, Apr 29, 2008 at 7:45 AM, Joerg Mayer [EMAIL PROTECTED] wrote: Hello, Bug http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2510 seems to indicate that we require lua version 5.1 to build but the configure check seems to just check which version of lua is available. What is the intended behaviour: Requiring 5.1 or changing the code to work with lua 5.0 as well? ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how to modify tvbuff_t* tvb
Do not. If you need to modify the buffer get a (ep) copy of the buffer and work on it. On Mon, Apr 28, 2008 at 11:29 AM, prakash chowbey [EMAIL PROTECTED] wrote: hi, as we extract a particular octet from a tvb (of type tvbuff_t*) using tvb_get_guint8(tvb , offset); how can we assign(alter) a particular octet of a tvb, plz give me the function to be used as well as syntax. regards, prakash Share files, take polls, and make new friends - all under one roof. Click here. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Fri, Apr 25, 2008 at 10:17 PM, Jeff Morriss
[EMAIL PROTECTED] wrote:
Guy Harris wrote:
http://www.cs.berkeley.edu/~wychen/cs261/proposal.htm
If Figure 1 is really a problem then my understanding of C just went out
the window...
I wouldn't have got this by myself without the explanation but if you
read the code as:
typedef unsigned short uid_t;
void dowork(uid_t u);
int main() {
int x = read_from_network();
// Squish root (it's not safe to execute dowork() with uid 0)
if ( (x 0x) == 0) exit(1);
// ^
dowork(x);
}
you would have noticed the issue.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25171: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-umts_fp.c
On Sat, Apr 26, 2008 at 3:34 AM, Jeff Morriss [EMAIL PROTECTED] wrote: I get what he's saying but I just don't get it: why would the compiler convert from int to unsigned short *before* it has to send the value into the call to dowork()? E.g., 'x' should be an int until I (explicitly or implicitly) cast it to something else, non? Actually it should still be an int after the call to dowork(); it just won't be an int when dowork() gets it. Maybe I need to go back to school because I'm feeling very noobish right now. function arguments are automatically cast when passed, you can see the reason why this is done in printf when you pass a long long instead of an int for a %i or a %d. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how do you get SDP dissector info to useitwitha new dissector?
. Thanks for any help / advice. The solution might seem obvious to you, but not to me ;-) Regards, David -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Anders Broman Envoyé : mardi 22 avril 2008 17:49 À : Developer support list for Wireshark Objet : Re: [Wireshark-dev] how do you get SDP dissector info to use itwitha new dissector? Hi, Just to add to what Luis said: The SDP dissector hands information to the RTP dissector for the conversation in question if your payload dissector Needs any of this info or additional info you first have to add it to this information to the SDP data structure then the RTP dissector Should hand it to your payload dissector which should be called from the RTP dissector or possibly the payload Dissector could pick it up from the conversation if the info is stored in the conversation dissector data by the SDP or RTP dissector. Probably this is the function you want to look at void srtp_add_address(). Regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luis EG Ontanon Sent: den 22 april 2008 15:25 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] how do you get SDP dissector info to use itwith a new dissector? I do not understand what you want to do. If all you want is to get RTP's media dissected just invoking the sdp dissector to dissect the sdp buffer might be enough. SDP will take care of registering the RTP converstations definded in it so that related media packets are passed to RTP and that RTP calls the propper dissector for the payload. You can take a look on how packet-rtsp.c or packet-sip.c hand over to sdp and how amr or iuup register themselves to be usable as dynamic RTP payload. Hope this helps On Tue, Apr 22, 2008 at 3:11 PM, [EMAIL PROTECTED] wrote: Hi everyone, I've been working on a new dissector that I'll hopefully be able to contribute. So far I've used the protocol preferences menu to allow me to setup parameters that are usually found in an SDP file or via SDP/SAP or via SDP/RTSP. This can be quite tedious as I'm switching between different RTP streams, each having potentially different setup parameters. Hence I would like to try and reuse the already dissected SDP parameters (if found) and use those automatically i.e. If SDP - Media Format (sdp.media.format) = certain value, then SearchSDP - Media format specific parameters (sdp.fmtp.parameter) If found setup parameter, store the value for that setup parameter and associate it with the associated sdp.media.format type End search End SDP search As I expect the SDP information to contain declarations for multiple RTP streams with different dynamic payload types, each having setup parameters for my dissector, what is the best approach I can take? How do I search for any relevant SDP info? I've tried to find relevant examples but haven't exactly succeeded and would appreciate a pointer. Wireshark seems extremely powerful but it's rather daunting to a beginner. I came across tapping, but I'm not sure whether I need to get info from the SDP tap, or whether I need to create a tap for my dissectoror even tap at all?! As for using those parameters: Should I define a structure containing all the relevant setup parameters, define a table containing pointers to that structure, and populate it accordingly for each relevant stream i.e. RTP payload type in SDP having my setup parameters? The idea would then be to search this table for a matching RTP payload type so that my dissector can use the correct setup parameters, extracted automatically from SDP, rather than using the potentially incorrect setup parameters defined in my preferences. Thanks for your help, David ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ 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] Windows Build Error: ascend-scanner.c(1737) : error C2220: warning treated as error - no object file generated
It's a matter with flex 2.5.35 take a look to http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2493 On Wed, Apr 23, 2008 at 12:20 PM, Edward king [EMAIL PROTECTED] wrote: Hi, I am trying to do my first build of Wireshark on Windows platform using: VC6.0 Cygwin GNU bash, version 3.2.33(18)-release (i686-pc-cygwin) bison (GNU Bison) 2.3 flex 2.5.35 env (GNU coreutils) 6.10 perl, v5.8.8 built for cygwin-thread-multi-64int Python 2.4.4 GNU Wget 1.10.2verify tools checked out ok. install libs checked out ok distclean completes ok but build fails. Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. rc /r ..\image\wiretap cl -DWIN32 -DNULL=0 -D_MT -D_DLL -WX -DYYMALLOC=malloc -DYYFREE=free -DHAVE_CONFIG_H /I. /I.. /IC:\wireshark-win32-libs\glib\include\glib-2.0 /IC:\wireshark-win32-libs\glib\lib\glib-2.0\include /IC:\wireshark-win32-libs\zlib123\include /IC:\wireshark-win32-libs\WPdpack/include -D_U_= /Zi /W3 /MD /DMSC_VER_REQUIRED=1200 -Fd.\ -c catapult_dct2000.c erf.c eyesdn.c libpcap.c nettl.c pcapng.c wtap.c ascend-scanner.c k12text.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. catapult_dct2000.c erf.c eyesdn.c libpcap.c nettl.c pcapng.c wtap.c ascend-scanner.c ascend-scanner.c(1737) : error C2220: warning treated as error - no object file generated ascend-scanner.c(1737) : warning C4003: not enough actual parameters for macro 'ascendwrap' ascend-scanner.c(2072) : warning C4003: not enough actual parameters for macro 'ascendwrap' k12text.c k12text.c(967) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MIAF9D~1\VC98\BIN\NMAKE.EXE' : return code '0x2' Stop. I know unistd.h is not a Windows platform file, but k12text seems to be generated from k21text.l ( not from SVN). I have been searching and verifying my tools, but I don't see a solution. thanks for the help in advance. --Edward ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] how do you get SDP dissector info to use it with a new dissector?
I do not understand what you want to do. If all you want is to get RTP's media dissected just invoking the sdp dissector to dissect the sdp buffer might be enough. SDP will take care of registering the RTP converstations definded in it so that related media packets are passed to RTP and that RTP calls the propper dissector for the payload. You can take a look on how packet-rtsp.c or packet-sip.c hand over to sdp and how amr or iuup register themselves to be usable as dynamic RTP payload. Hope this helps On Tue, Apr 22, 2008 at 3:11 PM, [EMAIL PROTECTED] wrote: Hi everyone, I've been working on a new dissector that I'll hopefully be able to contribute. So far I've used the protocol preferences menu to allow me to setup parameters that are usually found in an SDP file or via SDP/SAP or via SDP/RTSP. This can be quite tedious as I'm switching between different RTP streams, each having potentially different setup parameters. Hence I would like to try and reuse the already dissected SDP parameters (if found) and use those automatically i.e. If SDP - Media Format (sdp.media.format) = certain value, then SearchSDP - Media format specific parameters (sdp.fmtp.parameter) If found setup parameter, store the value for that setup parameter and associate it with the associated sdp.media.format type End search End SDP search As I expect the SDP information to contain declarations for multiple RTP streams with different dynamic payload types, each having setup parameters for my dissector, what is the best approach I can take? How do I search for any relevant SDP info? I've tried to find relevant examples but haven't exactly succeeded and would appreciate a pointer. Wireshark seems extremely powerful but it's rather daunting to a beginner. I came across tapping, but I'm not sure whether I need to get info from the SDP tap, or whether I need to create a tap for my dissectoror even tap at all?! As for using those parameters: Should I define a structure containing all the relevant setup parameters, define a table containing pointers to that structure, and populate it accordingly for each relevant stream i.e. RTP payload type in SDP having my setup parameters? The idea would then be to search this table for a matching RTP payload type so that my dissector can use the correct setup parameters, extracted automatically from SDP, rather than using the potentially incorrect setup parameters defined in my preferences. Thanks for your help, David ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 25148: /trunk/epan/ /trunk/epan/: oids.c
On Wed, Apr 23, 2008 at 12:54 AM, Joerg Mayer [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 07:31:07PM +, [EMAIL PROTECTED] wrote: From LEGO: Shouldn't the commit message name Luis as the author? It does! -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Should we support GTK+ 2.0[.x] and 2.2[.x], or just 2.4 and later?
Should the fact that the Older Versions section in http://www.gtk.org/download-linux.html does not show anyone bellow 2.4 be taken as a hint on what to do? On Mon, Apr 21, 2008 at 7:06 PM, Bill Meier [EMAIL PROTECTED] wrote: Guy Harris wrote: Ulf Lamping wrote: So there are not that many places that could show problems here - the problem we have seems to be a lack of tests if GTK 2.0/2.2 is still running. One data point: The GTK+ version distribution in Wireshark bug reports not specifying Windows as the OS and which give the GTK version is as follows: 1 GTK+ 2.0 [2006-11-03] 3 GTK+ 2.2 [2005-10-28] [2006-05-03] [2008-02-17] 64 GTK+ 2.4 144 GTK+ 2.6 4 GTK+ 2.7 114 GTK+ 2.8 158 GTK+ 2.10 2 GTK+ 2.11 149 GTK+ 2.12 1 GTK+ 2.15 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Problem with init.lua
checked in 25042, that should tell you what's failing.
On Tue, Apr 15, 2008 at 11:00 AM, Anders Broman
[EMAIL PROTECTED] wrote:
Hi,
I get this when starting up WS and I think during compile too:
Lua: syntax error during precompilation of
`C:\wireshark\wireshark-gtk2\init.lua':
[string C:\wireshark\wireshark-gtk2\init.lua]:81: '}' expected (to close
'{' at line 63) near 'GUI_ENABLED'
Regards
Anders
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SNMPv3 auth/priv password length
revision 25043 removes this useless check, Thanks. On Tue, Apr 15, 2008 at 1:07 PM, Freudenberger, Markus [EMAIL PROTECTED] wrote: Hi Everyone, For a test setup I need the set passwords for SNMPv3 auth and priv with a characters length 8. Actually in version 1.0.0 , there is a length check which prevents this. My question: Is there a possibility to avoid this check reps. to disable it? As I remember, a few versions ago, when SNMPv3 configuration was done via config file, I set passwords with length 8 and it worked fine. For testing purpose the length check should basically be disabled. Thanks Markus ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Problem with init.lua
revision 25044 changes the directory where it looks for the file. On Tue, Apr 15, 2008 at 2:04 PM, Maynard, Chris [EMAIL PROTECTED] wrote: With SVN 25042, I now see this lua-related error on Windows XP: 'dfilter.lib' is up-to-date cd .. cd wslua NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. perl make-init-lua.pl ../ template-init.lua init.lua cannot open '..//../../wiretap/wtap.h' at make-init-lua.pl line 67. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] se_tree_foreach() not compiling under XP
Hello, se_tree_foreach is not listed in libwireshark.def, *nix.so don't use it while windows dlls do. On Sun, Apr 13, 2008 at 6:39 PM, [EMAIL PROTECTED] wrote: Hello I can't compile my code with the function se_tree_foreach (from emem.h), I got following error (if I comment out the function it runs sucessfully): LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use/NODEFAULTLIB:library libui.lib(compare_stat.obj) : error LNK2019: unresolved external symbol _emem_tree_foreach referenced in function _comparestat_draw wireshark.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.EXE' : return code '0x460' Stop. the interesting thing is that it works on my Fedora. Any Idea what the problem is?? Thank you ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark decoding error- protocol DNS - section Flags for AD and CD bits information
Hi,
Thanks for the detailed report and traces (traces are always very appreciated).
You better open a bug in http://bugs.wireshark.org that way we do keep
track of this. Or else we risk just loosing track of it.
Thanks,
Luis
On Fri, Apr 11, 2008 at 12:29 PM, März, Frank [EMAIL PROTECTED] wrote:
Hello Wireshark Expert,
I think I have found a problem within Wireshark while decoding two bits
within the DNS protocol. The problem can be seen in all Wireshark version I
tried up to 1.0.0 on several OS. Wireshark fails to decode the Flags section
for the bit AD and CD.
Details are in:
RFC2535 - 6.1 The AD and CD Header Bits
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QDCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ANCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|NSCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ARCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
This is the trace in text format:
No. TimeSourceDestination Protocol
Info
50 41.833438 193.254.142.169 213.162.74.3 DNS
Standard query A web.mnc007.mcc232.gprs
Frame 50 (93 bytes on wire, 93 bytes captured)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst:
69:31:65:74:68:34 (69:31:65:74:68:34)
Internet Protocol, Src: 193.254.142.169 (193.254.142.169), Dst: 213.162.74.3
(213.162.74.3)
User Datagram Protocol, Src Port: 35211 (35211), Dst Port: domain (53)
Domain Name System (query)
[Response In: 59]
Transaction ID: 0xcf13
Flags: 0x0110 (Standard query)
0... = Response: Message is a query
.000 0... = Opcode: Standard query (0)
..0. = Truncated: Message is not truncated
...1 = Recursion desired: Do query recursively
.0.. = Z: reserved (0)
..X. = AD: missing
...1 = CD: Non-authenticated data OK:
Non-authenticated data is acceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
Additional records
69 31 65 74 68 34 00 00 00 00 00 00 08 00 45 00 i1eth4E.
0010 00 4f e4 a8 40 00 fd 11 28 a7 c1 fe 8e a9 d5 a2 [EMAIL
PROTECTED](...
0020 4a 03 89 8b 00 35 00 3b db 2f cf 13 01 10 00 01 J5.;./..
0030 00 00 00 00 00 01 03 77 65 62 06 6d 6e 63 30 30 ...web.mnc00
0040 37 06 6d 63 63 32 33 32 04 67 70 72 73 00 00 01 7.mcc232.gprs...
0050 00 01 00 00 29 10 00 00 00 80 00 00 00)
No. TimeSourceDestination Protocol
Info
57 41.854500 213.162.74.3 193.254.142.169 DNS
Standard query response A 213.162.74.125 A 213.162.74.126
Frame 57 (167 bytes on wire, 167 bytes captured)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst:
69:31:65:74:68:31 (69:31:65:74:68:31)
Internet Protocol, Src: 213.162.74.3 (213.162.74.3), Dst: 193.254.142.169
(193.254.142.169)
User Datagram Protocol, Src Port: domain (53), Dst Port: 35211 (35211)
Domain Name System (response)
[Request In: 53]
[Time: 0.021033000 seconds]
Transaction ID: 0xcf13
Flags: 0x8590 (Standard query response, No error)
1... = Response: Message is a response
.000 0... = Opcode: Standard query (0)
.1.. = Authoritative: Server is an authority for
domain
..0. = Truncated: Message is not truncated
...1 = Recursion desired: Do query recursively
1... = Recursion available: Server can do recursive
queries
.0.. = Z: reserved (0)
..0. = AD: missing
...1 = CD: Answer authenticated: Answer/authority
portion was not authenticated by the server
= Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 1
Additional RRs: 2
Queries
Answers
Authoritative nameservers
Additional records
69 31 65 74 68 31 00 00 00 00 00 00 08 00 45 00 i1eth1E.
0010 00 99 d5 6c 40 00 f9 11 3b 99 d5 a2 4a 03 c1 fe
Re: [Wireshark-dev] Triggers
On Thu, Apr 10, 2008 at 11:03 PM, Guy Harris [EMAIL PROTECTED] wrote: Luis EG Ontanon wrote: [snip] I did not notice the load-peak while playing with it but I believe I should have felt it in my very slow PPC mac... do pcap_dispatch works differently in linux and bsds? (Guy?) The main difference is that Linux, unless you're using the memory-mapped capture mechanism (supported by the under-development libpcap 1.0), you get one packet per recvfrom() call, while in OS X and *BSD, BPF will buffer up packets until the buffer fills up or the timeout expires, so you can get multiple packets per read(). Which makes me wonder: Can we get the autoconf script to understand if we can get multiple or single packets per read given the fact that we cannot dare pcap_open_live() in them? Or Is it better to use select() in all unix platforms? Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] wslua: reading raw file?
So, That's not called a dissector but a file format. And NO, lua cannot be used to describe file formats. That would had been simply sluggish (at least the attemt I gave to it besides being an ugly hack it was simply unusable). If the file format is of general interest would be probably better written in C anyway. In the other case the best solution is to write a script to convert those files into libpcap format, and use one of the USER_DLTs. Luis On Wed, Apr 9, 2008 at 7:00 PM, Németh Márton [EMAIL PROTECTED] wrote: Guy Harris wrote: Németh Márton wrote: I started to use wslua and succeed to write a simple dissector on ethernet level. I created a .pcap header and copied my raw file after it. Is it possible using wslua to open a raw file which is not supported by Wireshark, yet? Creating a libpcap-format file header and writing after it packets that don't have libpcap-format packet headers is a waste of time; if you want to write a file that programs that read libpcap format can read, put the libpcap-format file header at the beginning of the file and then put libpcap-format packet headers in front of the packet data for each packet, and if you just want a raw file, just write out the raw file without the libpcap-format headers - without libpcap-format per-packet headers, the libpcap-format file header won't help you. I don't really understand your point, maybe I did not describe well what I would like to do. I would like to write a dissector which is similar to how Wireshark can open .mp3 files. The .mp3 files don't have libpcap headers at all, but Wireshark can handle them. My question is that is it possible to create a dissector which reads a raw file without libpcap header? Márton Németh ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-users] wireshark statistic function (sum)
On Tue, Apr 8, 2008 at 2:46 PM, Sake Blok [EMAIL PROTECTED] wrote: BEWARE: One important thing to note here is that the field that the calculation is based on MUST also be part of the filter string or else the calculation will fail. (from the manpage of tshark) We ought to change that... io,stat should prime the fields it uses by itself either by using proto_tree_prime_hfid(), that is: mark those fields as interesting intead of asking the user to give dfilter_compile() a filter to have them primed or easier (and dirtier) by simply appending || (!frame df1 df2 df3 ...) to the fiter being given. Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Redefining gtk version in uat_gui.c?
I probably just copied these from another file (color filters maybe?). I never noticed this. On Mon, Apr 7, 2008 at 6:18 AM, Stephen Fisher [EMAIL PROTECTED] wrote: Why does this code at the top of gtk/uat_gui.c redefine GTK_MAJOR_VERSION to 1 if it is = 2?? if GTK_MAJOR_VERSION = 2 # undef GTK_MAJOR_VERSION # define GTK_MAJOR_VERSION 1 # define BUTTON_SIZE_X -1 # define BUTTON_SIZE_Y -1 #else # define BUTTON_SIZE_X 50 # define BUTTON_SIZE_Y 20 #endif ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] startup time benchmarks
could you be so kind as to measure the time it takes to: $ time tshark -r empty_file.cap $ time tshark -r empty_file.cap xml.comment I'll ask you again after I commit xml changes Thanks -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24762: /trunk/ /trunk/epan/dissectors/: packet-radius.c packet-radius.h /trunk/epan/: proto.c proto.h radius_dict.l /trunk/gtk/: dfilter_expr_dlg.c /trunk/:
On Fri, Apr 4, 2008 at 7:50 AM, Martin Mathieson [EMAIL PROTECTED] wrote: This is nice. Did you measure any improvement to startup time because of radius? I was stupid enough not to measure the times before :) However radius was the easiest... that's why it waas the pilot. I just did the wimaxasncp plugin, and if no-one beats me to it I'll do diameter (most likely tomorrow now). I'll get straight to XML then (where we'll get the most of it). Regards, Martin On Thu, Apr 3, 2008 at 11:13 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=24762 User: lego Date: 2008/04/03 10:13 PM Log: http://www.wireshark.org/lists/wireshark-dev/200803/msg00308.html proto.[hc] define new APIs to allow delayed registration of protocol fields, so that dissectors with flexible fields like xml, radius, diameter, snmp do not have to load their files at startup but can do so as late as possible. gtk/dfilter_expr_dlg.c : have the expression dialog registering all prefixes so that all fileds appear in the dialog tshark.c register all prefixes when called with -G epan/radius_dict.l epan/dissectors/packet-radius.c epan/dissectors/packet-radius.h refactor registration to delay dictionary loading as long as possible Directory: /trunk/epan/dissectors/ ChangesPath Action +132 -150 packet-radius.cModified +1 -1 packet-radius.hModified Directory: /trunk/epan/ ChangesPath Action +93 -0 proto.c Modified +15 -0 proto.h Modified +5 -10 radius_dict.lModified Directory: /trunk/gtk/ ChangesPath Action +2 -0 dfilter_expr_dlg.cModified Directory: /trunk/ ChangesPath Action +2 -0 tshark.c Modified ___ Wireshark-commits mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24766: /trunk/epan/ /trunk/epan/: libwireshark.def
Guy, already did... On Fri, Apr 4, 2008 at 11:57 AM, Luis EG Ontanon [EMAIL PROTECTED] wrote: proto_initialize_all_prefixes should be added as well (called by the expression dialog and tshark) On Fri, Apr 4, 2008 at 7:26 AM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=24766 User: martinm Date: 2008/04/04 05:26 AM Log: Export proto_register_prefix() Directory: /trunk/epan/ ChangesPathAction +1 -0 libwireshark.defModified ___ Wireshark-commits mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 24766: /trunk/epan/ /trunk/epan/: libwireshark.def
proto_initialize_all_prefixes should be added as well (called by the expression dialog and tshark) On Fri, Apr 4, 2008 at 7:26 AM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=24766 User: martinm Date: 2008/04/04 05:26 AM Log: Export proto_register_prefix() Directory: /trunk/epan/ ChangesPathAction +1 -0 libwireshark.defModified ___ Wireshark-commits mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] encapsulation type for layer 1 messages (strings)
I think that's the way you just need to add WTAP_ENCAP_PLAIN_TEXT to wtap.h and have proto_reg_handoff_text_lines() add text_lines_handle to wtap.encap table On Thu, Apr 3, 2008 at 4:29 PM, Rolf Fiedler [EMAIL PROTECTED] wrote: Hi everyone, I am currently working on modifying the wiretap modules for EyeSDN traces to use WTAP_ENCAP_PER_PACKET, which is working nicely (Q.931/DSS1, SS7/MTP2, PPP, X.25 and ATM support on the way for these traces). However, there is one thing I can not match to the ENCAP types at the moment (maybe because I am too stupid to find this). In these traces there are layer 1 messages like Frame Synchronisation Lost, Alarm Indicator, G.704 Lock etc. These messages are put in the trace file as plain text. And these frames are marked as Layer 1 message frames to distuingish them from the actual captured data. So far I just skip these frames... What I would like to do is mark these frames as WTAP_ENCAP_PLAIN_TEXT or similar and just let wireshark print the frame contents as ASCII to the decoder window and at the left (protocol) side of the frame list. Is there already a dissector which does this? If so, which ENCAP type would I need to specify for these frames. If not, is it ok if I add such a WTAP_ENCAP_* type and the dissector for doing this? Would such a patch be accepted? Kind regards, Rolf ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Using wireshark apis
Merge, don't fork! Unless unfeasible, the drive should be to add functionality to the existing apps instead of writing new ones. libwireshark was made into a lib to hold what wireshark and tshark had to have in common, not to become a dissection libary for other apps. I do not think there has never been an intention to share libwireshark, and that's why there's no documentation on how to use it. BTW it is GPLd not LGPLd, i.e.: programs that link to it must be GPLd. L On Thu, Apr 3, 2008 at 6:14 PM, Eloy Paris [EMAIL PROTECTED] wrote: Hi Pavan, On Thu, Apr 03, 2008 at 12:23:04PM +0530, Gupta, Pavan wrote: I would like to use Wireshark library apis to dissect packets. - Call a function in Wireshark providing the filename or buffer as input. File/buffer will have data in pcap format. This function should return me dissected data. Is there any function that can be called directly? It's not as simple as that - you need to call several functions to initialize the library, to load preferences (which are used by the dissectors), to create the key epan_dissect_t structure, to dissect the packet, to manage the dissection results, etc. It's not hard but the point is that it is not as easy as dissect(data, data_len). I am trying to reverse engineer Wireshark (rather tshark) code but its taking time to understand the finer details. Also, please share the way how I can build my application that links to Wireshark .so libraries. Looking at tshark code, it seems load_cap_file( ) function is the function that needs to be called, but before that some initialization needs to be done (like initializing dissector, etc.). The libraries that I need to link are libwiretap.so and libwireshark.so. It happens that I also have been working on an application that uses libwireshark services for packet dissection. I looked a lot at tshark to understand how the libwireshark API is being invoked and ended up writing a very simple program that allows me to easily play with things without having to deal with the higher complexity of tshark and with the wireshark build environment, and that allows me to play with things like Makefiles and the autoconf script, etc. My test program doesn't have the the bells and whistles that tshark has and uses libpcap to read packets instead of libwirecap. You can download the source code from: http://www.chapus.net/wshark-test/ You may have better luck trying to understand this program instead of tshark/wireshark. I was thinking about using this little program as the basis of new documentation on how to write applications that use libwireshark services. Perhaps write a README.libwireshark for the doc/ directory and host the source code for this program somewhere on the Wireshark wiki. Comments from the developers regarding the merits of these ideas are appreciated. Cheers, Eloy Paris.- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] VoIP call -- RTP trace --
To use external applications (quicktime and rtpreplay) to replay rtp streams shouldn't be that complex. it needs - to extract all useful information from sdp, h245, and other media control protocols - write an sdp file that mimics the media (very easy for sdp, just rewrite addresses and ports) - call a command to have quick-time reading the sdp file - either write the rtddump files (the code is there already) and call rtpplay - or send a burst with all useful rtp packets from a tap on udp (display filter) and let quicktime's buffering take care On Thu, Apr 3, 2008 at 11:57 PM, [EMAIL PROTECTED] wrote: Yes it?s true. The thing is that I am working with codec G729 and I am not able to decode or play the trace ?cause this codec has a patent. G729 is a request from the customer I?ve found a code in C++, but I do not know how to compile it in Wireshark. Regards, Bruno. Citando Maria de Fatima Requena [EMAIL PROTECTED]: Can wireshark play files? I am working on smth similar, and I need an external tool to generate wav -Mensaje original- De: [EMAIL PROTECTED] en nombre de [EMAIL PROTECTED] Enviado el: jue 03/04/2008 17:38 Para: wireshark-dev@wireshark.org Asunto: [Wireshark-dev] VoIP call -- RTP trace -- Hi people, my name is Bruno from Portugal and I am working with SIP for PT. I did a trace with a VoIP call and I am not able to play it in my wireshark version 1.0.0. Can you please help me to play this file, or to save it in *wav? Best regards and thank you, Bruno Nunes. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] callin simple_dialog in my dissector
You might be surprised but someone has thought about the need reporting errors by dissectors before... The propper way reporting an error you want to call report_failure() from epan/report_err.h. In wireshark (GUI) report_failure() will pop a window with the error message while in tshark it will printout the error . No need to render tshark unusable. report_failure(An error happened because: %s, err_str); On 31-Mar-2008 12:55:00 ZE5B, Praveen Kumar Jha [EMAIL PROTECTED] wrote: Hi, Yeah! I am 100 % sure that I am going to use WIreshark in GUI mode ( and not the Tshark). I am using proto_reg_handoff_xxx() function as call-back for the preferences. e.g. xxx_module = prefs_register_protocol(proto_xxx, proto_reg_handoff_xxx); registering a preference of uint type with xxx_module (say for example, port number). In the function proto_reg_handoff_xxx(), i would like to have some check on the user entered uint value i.e. the port number, and depending on its value I would like to popup an error message in GUI. hope that the situation is clear! thanks Praveen *** Aricent-Unclassified *** DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Install of AAA dictionaries, DTDs and MIBS should be made optional
As we all know the init time consumed by the initilaization of RADIUS, DIAMETER, XML and SNMP makes up for a good part of the initialization time. Since more users do not require these I guess these shouldn't be loaded at initialization. My first thought was at a delayed initilalization (initialize just them when needed, right when the dissector gets called for the first time), but this has a major drawback not being there at initialization the dynamic fields from these protocols could not be used in tshark (or in wireshark up until when the first packet is dissected). i.e. something like: tshark 'radius.UserName == pippo' would not be possible. So my guess is that the MSI installer and ./configure scripts should give the user the posssibility to choose whether to install or not these files (if there are no dictionaries, dtds etc. the init time will be much shorter). ANy thoughts? -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Okay to dissect more than one packet at the same time?
I think you won't get very far that way... There's a lot of static variables used to keep state, so what's likely to happen is that the second call to epan_dissect_new() will render the results of the first call unusable. I do not know for sure when and where ep_allocated memory gets released but my guess is that the other danger you face is that the second call to epan_dissect_new() will move the pointer back to the start of the ep memory pool and will overwrite all the allocated memory. Your requirements do what you want are preety much the same we have for going multithreaded (http://wiki.wireshark.org/Development/multithreading)... which is a huge job for 600K lines of code, considering that most of it should be refactored. Luis On Thu, Mar 27, 2008 at 4:06 PM, Eloy Paris [EMAIL PROTECTED] wrote: Hello, Is it possible to dissect more than one packet at the same time. Or asked another way, is it okay to keep in memory the result of more than one packet dissection? I haven't looked at what wireshark does (and perhaps that is why I don't know the answer to this) but I did look at what tshark does and it calls epan_dissect_run() in a serialized manner, i.e. read packet, dissect packet, output result, read next packet, dissect, output result, and so on. In terms of code, what I would like to do is something like this: epan_dissect_t *edt1, *edt2 edt1 = epan_dissect_new(...); epan_dissect_run(edt1, pseudo_header1, packet1, fdata1, NULL); edt2 = epan_dissect_new(...); epan_dissect_run(edt2, pseudo_header2, packet2, fdata2, NULL); do_something_with_dissection_results(edt1, edt2); epan_dissect_free(edt1); epan_dissect_free(edt2); Is the above an okay thing to do? Any gotchas and/or things to avoid? Thanks in advance. Eloy Paris.- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
