Re: [Wireshark-dev] The empty "Tools" menu toplevel item must be removed before the next release

2006-10-15 Thread Ulf Lamping
Gerald Combs wrote: > An alternative to keeping it hidden would be to add a default menu item > with the text "Why is this menu empty?", or "How to add items to this > menu", which takes the user to a help page describing how to add items. > Don't you think this is a very poor mans solution - in

Re: [Wireshark-dev] Cygwin Bash update breaks verify_tools

2006-10-15 Thread Ulf Lamping
Bill Meier wrote: > So: another option is just to stay with Bash v3.1-6 until the situation > further resolves itself. > I've looked at some of the discussion in the cygwin mailing lists and I'm impressed of the ignorance some cygwin developers take care about the problems that virtually thou

Re: [Wireshark-dev] The empty "Tools" menu toplevel item must be removed before the next release

2006-10-15 Thread Gerald Combs
An alternative to keeping it hidden would be to add a default menu item with the text "Why is this menu empty?", or "How to add items to this menu", which takes the user to a help page describing how to add items. LEGO wrote: > The menu is there just when compiled with Lua, and the current > init.

Re: [Wireshark-dev] Cygwin Bash update breaks verify_tools

2006-10-15 Thread Bill Meier
> > > It turns out that there's a fair amount of discussion on the Cygwin mailing > list about changes made in Cygwin Bash handling of \r\n in script files in > versions after v 3.1-6 to improve Cygwin Bash performance. > > See http://cygwin.com/ml/cygwin/2006-10/msg00079.html for the latest

Re: [Wireshark-dev] Writing a new packet dissector

2006-10-15 Thread Ulf Lamping
Daniel Griscom wrote: > Self-interest is a great motivator of open-source projects. > Yes, for sure. Unfortunately important things such as documentation that are not that interesting often falls down the edge :-( However, I notice that things are getting better at a lot of open source projec

Re: [Wireshark-dev] How the display tree gets built ?

2006-10-15 Thread Stephen Fisher
On Sun, Oct 15, 2006 at 12:32:48PM +0530, [EMAIL PROTECTED] wrote: > While going through the README.developer file , I was trying to > understand the tree concept but could not grasp much . Can anyone > please provide some inputs to help me understand how the tree nodes > are added and display

Re: [Wireshark-dev] Unaccounted bytes in USB header

2006-10-15 Thread Paolo Abeni
On Sun, 2006-10-15 at 20:10 +0200, Joerg Mayer wrote: > 00 00 00 04 00 00 00 01 00 00 00 01 00 00 00 00 > ^^^ > What do these bytes mean? ---| > > 0010 0d 20 .

Re: [Wireshark-dev] usb dissecotr: register_dissector question

2006-10-15 Thread ronnie sahlberg
yes On 10/15/06, Joerg Mayer <[EMAIL PROTECTED]> wrote: > When looking at the dissector, I wondered whether the following patch > would be ok/appropriate: > > Index: epan/dissectors/packet-usb.c > === > --- epan/dissectors/packet-usb.

Re: [Wireshark-dev] Unaccounted bytes in USB header

2006-10-15 Thread ronnie sahlberg
The last four bytes of the header represents the number of setup bytes present. If it is 0 it is not displayed. Maybe we whould change this so that the setup length is always displayed? There was a very recent fix for libpcap that solves the offset-by-one error for the data stored in each packet

[Wireshark-dev] Unaccounted bytes in USB header

2006-10-15 Thread Joerg Mayer
Hello Paolo, Frame 1 (18 bytes on wire, 18 bytes captured) Arrival Time: Jan 1, 1970 01:35:47.483647000 [Time delta from previous packet: 0.0 seconds] [Time since reference or first frame: 0.0 seconds] Frame Number: 1 Packet Length: 18 bytes Capture Length:

[Wireshark-dev] How the display tree gets built ?

2006-10-15 Thread jaiswal.vikash
Hi ,   While going through the README.developer file , I was trying to understand the tree concept but could not grasp much . Can anyone please provide some inputs to help me understand how the tree nodes are added and display tree gets built .   Regards , Vikash The information containe

[Wireshark-dev] usb dissecotr: register_dissector question

2006-10-15 Thread Joerg Mayer
When looking at the dissector, I wondered whether the following patch would be ok/appropriate: Index: epan/dissectors/packet-usb.c === --- epan/dissectors/packet-usb.c (revision 19541) +++ epan/dissectors/packet-usb.c (wor

Re: [Wireshark-dev] [PATCH] USB setup hdr

2006-10-15 Thread Ulf Lamping
ronnie sahlberg wrote: > USB packets probably arrive at such very slow rate anyway that a few > gettimeofday() calls are unlikely to cause any performance issues. > Sure? Think of a fully saturated 100MBit Ethernet adapter connected to the USB port. I'll guess that could really cause some perf

Re: [Wireshark-dev] [PATCH] USB setup hdr

2006-10-15 Thread ronnie sahlberg
On 10/15/06, Paolo Abeni <[EMAIL PROTECTED]> wrote: > Hello, > > On Sat, 2006-10-14 at 21:42 +, ronnie sahlberg wrote: > > In the example capture unplug_mouse2.cap > > it appears that the timestamp for the packet is not generated properly. > > All packets show up as JAN 1 1970. > > > > 1, Can y

Re: [Wireshark-dev] [PATCH] USB setup hdr

2006-10-15 Thread Paolo Abeni
Hello, On Sat, 2006-10-14 at 21:42 +, ronnie sahlberg wrote: > In the example capture unplug_mouse2.cap > it appears that the timestamp for the packet is not generated properly. > All packets show up as JAN 1 1970. > > 1, Can you have a look at the timestamp generation of packets when capturi

[Wireshark-dev] LIBPCAP offset by one bug when capturing USB

2006-10-15 Thread ronnie sahlberg
Paolo. Could you have a look at the USB memory stick network trace that is present on http://wiki.wireshark.org/SampleCaptures? When I look at these traces it looks to me there is something wrong with the captured data. The USB header is fine, as is the SETUP data but the actual data blob l