Re: [Wireshark-dev] [Wireshark-commits] rev 23446: /trunk/gtk/ /trunk/gtk/: summary_dlg.c
2007/11/14, Ulf Lamping [EMAIL PROTECTED]: Maybe this line needs *more* parentheses and not *less* ;-) I was looking at this, and found the same construction for the filtered bytes avg. which seems to work correctly. Now this line might work, but I actually have no real idea what the line is really doing ... Yup. Will fix :) -- Stig Bjørlykke ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 23446: /trunk/gtk/ /trunk/gtk/: summary_dlg.c
[EMAIL PROTECTED] schrieb: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=23446 User: stig Date: 2007/11/14 09:37 AM Log: From Shiang-Ming Huang: Removed unnecessary parentheses that make the average packets size calculated as an integer instead of a float. Directory: /trunk/gtk/ ChangesPath Action +1 -1 summary_dlg.cModified Maybe this line needs *more* parentheses and not *less* ;-) Now this line might work, but I actually have no real idea what the line is really doing ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is there a good way of handling per pdu info ?
Didier wrote: Not an expert either but if you use the same table for both directions you may have duplicate if TCP relative sequence number is set. cf bug: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1392 Thanks. I didn't go into that level of detail but I do maintain a different table for each direction, based on the address in the conversation. -Bryant ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Capturing to something else than files or humans
Hi WireShark developpers, I only recently came in touch with this awesome piece of software. I was wondering whether or not it is possible to make that the results of the capturing (after filtering, analysis) is being pushed out to another server instead of the current file saving or human user interface. e.g. to push out a constant stream of network protocol information for another systems to look at instead of people? Thanks in advance, Steven Defoort BT ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Capturing to something else than files or humans
[EMAIL PROTECTED] wrote: e.g. to push out a constant stream of network protocol information for another systems to look at instead of people? If XML will do, take a look at TShark's -T -V options. -- Regards, Marco. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] no interface listed using wireshark, vista home premium 32
Hi,
Wireshark is not able to list any interfaces on my Dell XPS 1330m laptop.
I have windows vista homepremium installed and windump are showing all my
interfaces.
windump.exe -D
1.\Device\NPF_{4F96DAAA-FF0C-4B61-8D83-9959FF22CB6C} (b57nd60x4 Broadcom NetXtre
me Gigabit Ethernet Driver)
2.\Device\NPF_{B6C860C8-92E8-4A46-83E2-65415BFE6BB0} (cp_scvna Check Point Virtu
al Network Adapter)
3.\Device\NPF_{8836B6EE-F09A-4C2C-80D1-D1790EA54A25} (NETw4v328 Microsoft)
4.\Device\NPF_{D9117324-83D0-458A-963D-FE06B10DAF9E} (MS Tunnel Interface Driver
)
Number 3 is my wlan if which I see that traffic are received and sent.
What can be wrong and what should I check for?
Best regards
Yngve Edvardsen
Senior System Expert
Tel / Sms : +47 99 25 56 48
E-Mail / IM : [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
N o r t h e r n L i g h t M o b i l e T e c h n o l o g i e s L t d
the next generation
mobile
-
w w w . n o r t h e r n l i g h t m o b i l e . c o m
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] no interface listed using wireshark, vista home premium 32
Hi,
do you start Wireshark with the needed capture privileges?
http://wiki.wireshark.org/CaptureSetup/CapturePrivileges
Regards,
Martin
On Nov 14, 2007 5:20 PM, Yngve Edvardsen [EMAIL PROTECTED] wrote:
Hi,
Wireshark is not able to list any interfaces on my Dell XPS 1330m laptop.
I have windows vista homepremium installed and windump are showing all my
interfaces.
windump.exe -D
1.\Device\NPF_{4F96DAAA-FF0C-4B61-8D83-9959FF22CB6C} (b57nd60x4 Broadcom
NetXtre
me Gigabit Ethernet Driver)
2.\Device\NPF_{B6C860C8-92E8-4A46-83E2-65415BFE6BB0} (cp_scvna Check Point
Virtu
al Network Adapter)
3.\Device\NPF_{8836B6EE-F09A-4C2C-80D1-D1790EA54A25} (NETw4v328 Microsoft)
4.\Device\NPF_{D9117324-83D0-458A-963D-FE06B10DAF9E} (MS Tunnel Interface
Driver
)
Number 3 is my wlan if which I see that traffic are received and sent.
What can be wrong and what should I check for?
Best regards
Yngve Edvardsen
Senior System Expert
Tel / Sms : +47 99 25 56 48
E-Mail / IM : [EMAIL PROTECTED]
N o r t h e r n L i g h t M o b i l e T e c h n o l o g i e s L t d
the next generation
mobile
-
w w w . n o r t h e r n l i g h t m o b i l e . c o m
___
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] Global configuration files are overwritten by Debian package
Hi, I think these questions are better asked to the Debian package maintainer, Frederic Peters ([EMAIL PROTECTED]). Thanx, Jaap Martin André wrote: Hello, I'm wondering if it is currently possible to keep global configuration file set for the whole system, for example custom system-wide color or display filters, during an upgrade of wireshark on debian. Since Wireshark does not store the default configuration files in the standard /etc location, files will be automatically overwritten during the upgrade of the software. It would help to flag these files as conffiles so we are asked what is the action to be done in order to not loose configuration. We could do that by adding these files to the wireshark-common.conffiles, WDYT? Or maybe there is a better place to store system wide custom filters? Also, just being curious, is there a particular reason to have 2 wireshark directories in the path where configuration files are stored (/usr/share/wireshark/wireshark)? Thanks for your answers, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is there a good way of handling bitfields withdifferent bitmask offsets ?
-Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of ronnie sahlberg Not tested! grab the hfinfo structure and modify the fields at runtime : header_field_info *hfinfo; hfinfo = proto_registrar_get_nth(hf_index); hfinfo-bitmask = new bitmask hfinfo-bitshift = new bit shift very ugly. it could work. I agree - but I'll try! please do not contribute any code to wireshark that does anything like this :-) That's a shame, because this is needed in order to extend the current gsm_a dissector to cope with half octet IE which can be in the upper or lower half of the octet. I did ask for an _good_ way ;-). I still reckon the general way is to add bit_offset to all the proto calls - but I guess that won't happen anytime soon ;-). Even more ugly hack: use the _top_ 3 bits of the current offset in those calls as a bit offset.. maybe not! Neil ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is there a good way of handling bitfields withdifferent bitmask offsets ?
I used the not-long-since-added proto_tree_add_bits_ret_val() in packet-umts_fp.c. There is also proto_tree_add_bits_item() which doesn't extract the value for you. Are these functions not suitable for your purpose? It certainly simplified the part of the code I needed it for. Martin On Nov 14, 2007 6:22 PM, Neil Piercy [EMAIL PROTECTED] wrote: -Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of ronnie sahlberg Not tested! grab the hfinfo structure and modify the fields at runtime : header_field_info *hfinfo; hfinfo = proto_registrar_get_nth(hf_index); hfinfo-bitmask = new bitmask hfinfo-bitshift = new bit shift very ugly. it could work. I agree - but I'll try! please do not contribute any code to wireshark that does anything like this :-) That's a shame, because this is needed in order to extend the current gsm_a dissector to cope with half octet IE which can be in the upper or lower half of the octet. I did ask for an _good_ way ;-). I still reckon the general way is to add bit_offset to all the proto calls - but I guess that won't happen anytime soon ;-). Even more ugly hack: use the _top_ 3 bits of the current offset in those calls as a bit offset.. maybe not! Neil ___ 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] what are the steps needed to add a plugin
Hi, See it as a tradeoff. Option 1 is to add your dissector build in. This means that you'll have to rebuild register.c and relink libwireshark every time you change your dissector. With a ton of dissectors this takes a while. Option 2 is to add your dissector as a plugin. This takes some work to setup, as you've seen, but build cycles are much faster. You only handle files that most likely are actually changed. So usually you start of with the plugin style and once things start to calm down (Win32: or you need stuff not exported yet) you consider moving the dissector build in. That is what we would like if you decide to submit the code for inclusion. Other considerations may be expected release cycles of your dissector vs Wireshark. If you release faster, it's easier to simply distribute a new plugin than a complete installer. So you see, enough stuff to think about. Thanx, Jaap jaydeep chokshi wrote: Greeting folks, I am a newbie to the wireshark development. I created a plugin *foo *(in Linux) that comes into action after Ethernet header has been dissected. In order to compile wireshark with the plugin, I had to make following additions/changes, 1. In the *foo* directory, 1.1 Edit Makefile.common to add entries of sources and headers. 1.2 Edit the Makefile.in http://Makefile.in to add entries of *.lo in am_objects_x 1.3 Add plugin entry in Makefile.am http://Makefile.am 2. In *plugin (../foo) *directory, 2.1 Edit Makefile to add an entry of foo 2.2 Edit the Makefile.in http://Makefile.in to add an entry of foo 2.3 Edit the Makefile.am http://Makefile.am to add an entry of foo 3. In *wireshark (../plugin)* directory, 3.1 Edit Makefile to add an entry of foo in am_DEPENDENCIES_2 variable. 3.2 Edit Makefile.in http://Makefile.in to add an entry of foo in am_DEPENDENCIES_1 variable. 3.3 Edit configure script to add entry of foo in ac_config_files variable. 3.4 Edit configure.in http://configure.in script to add entry of foo in AC_OUTPUT( variable. Having done all the above changes, I managed to attach the plugin to wireshark binary. My question cum confusion is, do we have to go through all the pain in order to make a plugin work? I mean, do we need to edit these many Makefiles every single time we add a new plugin? Let me know if I am doing something wrong here. I greatly appreciate it. Thanks, JD ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] displaying tree values 32 bits
Hi, The largest integer we handle at this moment is 64 bit. Thanx, Jaap Kevin Arruda wrote: Hello, I was having some trouble finding the answer to this: I would like to add an entry to my dissection table which handles a 128 bit value. For values 32 bits, must I forego the table entry altogether and simply do a manual call when constructing the tree, e.g. proto_tree_add_bytes_format_value(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint 2, gint 16, const guint8* start_ptr, “%s”, ...) Or is there a simpler way to do this so that a standard hf_register_info table can be used? Thanks, Kevin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The COPYING file (our license) is a mess!
Hi, Looking at the history the main part was added by Gerald in revision 21806. Yes, it should be clear to anyone what the GPLv2 means but in real life you get some *stupid* questions on it. (I'm all for the view that there are no stupid questions, only stupid answers, but here I make the exception, #@$%*$@ managers). So even though I'm not happy with this stuff it seems to be needed to keep *stupid* people of our lists. Thanx, Jaap Joerg Mayer wrote: One of the core reasons why the explanations were added was a rather regular stream of questions regarding the use of Wireshark. It started with me adding a section that emphasizes that libwireshark is covered by the GPL, not LGPL. Later on other stuff was added and I think that the amount of questions regarding the license has become noticably less sind the last batch of additions by Gerald (IIRC). On Sun, Nov 11, 2007 at 10:25:18PM +0100, Ulf Lamping wrote: This fact should be obviously by anyone knowing the GPL (and anyone still don't know won't care) so why repeating it? Are there any restrictions beyond the usual GPL conditions? Most parts of Wireshark are covered by a GPL version 2 or later LICENSE. Some files are covered by different licenses that are compatible with the GPLv2. What does this mean? Spread FUD? No, it's just stating that some source files are not covered by the GPL but by another license. As an alternative we could include all the different licenses into COPYING. Ah, ok, maybe I should have mentioned the fact that this was about source files. But then, I don't think that the mib files are actually covered by the GPL, so I don't think it is wrong with regards to the binary distribution either. As a notable exception the pidl utility at tools/pidl is covered by a GPL version 3 or later LICENSE. Note that only the tool itself is covered by this license, not the source code generated by it. The pidl authors do not consider that code a derived work of pidl. Who should understand this?!? Anyone who'd need/want to use pidl to create their own dissectors from .idl files. Parts of Wireshark can be built and distributed as libraries. These parts are still covered by the GPL, and NOT by the Lesser General Public License or any other license. Again, anyone who cares will be pretty much knowing it from the GPL - no need to repeat the license here. There were some misunderstandings in the past. If you create a combined work using all or part of Wireshark, then your combined work must be released under a license compatible with the GPL. That's just plain *wrong*. In addition what the author might had in mind, a combined work could be almost anything! From pressing it on a CD to make it available on a web collection. All this collection needs to be compatible with the GPL? I don't think so! You are correct. ...and don't get us started on trademarks. What does this mean? Spread FUD? No idea. Unfortunately, this text spreads a lot FUD and it is redundant. No, although some points may be incorrect, there is a reason for them to be there. IMHO, the GPLv2 is well understood today and needs no further explanations. IMHO instead of clarifying stuff, it makes understanding the License much more complicated to anyone outside the project. This is just plain wrong! Many people still don't understand the GPLv2 and the clarifications seem to have helped to reduce license specific questions. All in all, IMO this license text drives away anyone who takes licensing seriously and anyone who don't cares won't be addressed. So what is the benefit in complicating the GPL here? See above. Ciao Joerg ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Use of EXTERNALt
Anders, Tomas, Stig, RTSE should be changed to use EXTERNAL and put the callback in the asnctx. I have now checked in a change so that RTSE uses the packet-ber EXTERNAL decoding. (http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=23450) Tomas: I had to make some minor changes to packet-ber.c to make things work could you check? And if you could check packet-rtse.c to see if I have taken the right approach - that would be great. Anders: Is someone looking at doing something similar for ACSE (which still uses an EXTERNALt)? Stig: Can you check I haven't broken your x411 captures? The EXTERNAL handling in packet-ber.c does not decode octet-aligned encoding according to the direct-reference, like acse did (from r22308). I think your patch is correct - but should adopt Tomas suggestions: a) use the *_ref_present members; and b) try to do a presentation context lookup if an indirect reference is found. Graeme ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] lenght
Hi
On Wed, 14 Nov 2007 17:49:06 +, khalid habibi wrote
i m a beginner.
I have the following output:
DATA: 005F000103E5
I will spend it in HEX also 0x.
Because it has an variable length, I do not know how to do this?
proto_tree_add_item(application_tree, hf_data_nbyte, tvb, offset, -1,
pdu_ackd);
-1 means to the end of the tvb buffer.
In your case:
len = tvb_get_guint8(tvb, offset); // or tvb_get_ntohs(tvb, offset); if it's
16 bits and so on.
proto_tree_add_item(application_tree, hf_data_nbyte, tvb, offset, len,
pdu_ackd);
offset +=len;
or len +1, but you get the idea.
{ hf_data_nbyte,
{ DATA, lon.datum,
FT_BYTES, BASE_HEX, NULL, 0,
DATA, HFILL }
}
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Use of EXTERNALt
Anders: Is someone looking at doing something similar for ACSE (which still uses an EXTERNALt)? Not in the near future...and I don't know that protocol that well. Regards Anders ___ 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] proto_tree_add_bytes
hi Can someone tell me how I use the function,: proto_tree_add_bytes_format_value() and what do the individual variable. khalid www.jubii.fr c'est une seule interface pour communiquer. Email, téléphone gratuit, messagerie instantanée, 10 Go d'espace de stockage. Avec www.jubii.fr simplifiez-vous la vie !___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The COPYING file (our license) is a mess!
On Wed, Nov 14, 2007 at 10:20:12PM +0100, Jaap Keuter wrote: So even though I'm not happy with this stuff it seems to be needed to keep *stupid* people of our lists. I obviously think so too, but that doesn't mean we shouldn't add some not legally bindingexplanations/not legally bindingg around our additions. Also, the disambuguities and errors that Ulf pointed out should be fixed. It seems to me that there is still need for discussion, so I've attached a proposed change to the COPYING file instead of just checking it in. Feedback welcome. 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. Index: COPYING === --- COPYING (revision 23441) +++ COPYING (working copy) @@ -1,26 +1,40 @@ -Wireshark is distributed under the GNU GPL. There are no restrictions -on its use. There are significant restrictions on its distribution. +This file consists of two parts: +Part I: Consists of some remarks regarding the license given in +Part II: The actual license that coveres Wireshark. + +When in doubt: Part II is the legally binding part, Part I is just +there to make it easier for people that are not familiar with the +GPLv2. + + + +Part I: + +Wireshark is distributed under the GNU GPLv2. There are no restrictions +on its use. There are restrictions on its distribution in source or +binary form. + Most parts of Wireshark are covered by a GPL version 2 or later LICENSE. Some files are covered by different licenses that are compatible with the GPLv2. + As a notable exception the pidl utility at tools/pidl is covered by a GPL version 3 or later LICENSE. Note that only the tool itself is covered by this license, not the source code generated by it. The -pidl authors do not consider that code a derived work of pidl. +pidl authors do not consider generated code a derived work of pidl. -Parts of Wireshark can be built and distributed as libraries. These +Parts of Wireshark can be built and distributed as libraries. These parts are still covered by the GPL, and NOT by the Lesser General Public License or any other license. -If you create a combined work using all or part of Wireshark, then your -combined work must be released under a license compatible with the GPL. +If integrate all or part of Wireshark into your own application, then that +application must be released under a license compatible with the GPL. -...and don't get us started on trademarks. - The full text of the GNU GPL follows. +Part II: GNU GENERAL PUBLIC LICENSE Version 2, June 1991 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Generated items in frame dissector
Shouldn't everything in the frame dissector tree be marked as generated (with [ and ] brackets around it)? I was teaching a group about Wireshark this evening and noticed that while most items have brackets, a few don't: Arrival Time Frame Number Frame Length Capture Length Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Console error on startup: Diameter Dictionary: No Vendor: 3GPP
Recently, I started getting these console errors when starting Wireshark on Unix: Diameter Dictionary: No Vendor: 3GPPDiameter Dictionary: No Vendor: 3GPP Could someone familiar with that part of Wireshark take a look? Thanks. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Console error on startup: Diameter Dictionary: NoVendor: 3GPP
Hi, Is this still true on the latest SVN version? Regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Stephen Fisher Skickat: den 15 november 2007 06:17 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Console error on startup: Diameter Dictionary: NoVendor: 3GPP Recently, I started getting these console errors when starting Wireshark on Unix: Diameter Dictionary: No Vendor: 3GPPDiameter Dictionary: No Vendor: 3GPP Could someone familiar with that part of Wireshark take a look? Thanks. Steve ___ 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] Generated items in frame dissector
Ulf Lamping wrote: Stephen Fisher schrieb: ... Frame Number Is derived from the read sequence, you may argue it's generated. ...or that it's implicitly in the capture file, in that the Nth packet in the capture file has a frame number of N. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
