Re: [Wireshark-dev] Update to the COPYING file
Gerald Combs wrote: Ulf Lamping wrote: I'm really unhappy with this preamble at all. This sounds to me like we have a special variation of the GPL. What your basically do is to personally interpret the GPL, in a way that is NOT covered by the GPL, e.g.: There are significant restrictions on its distribution. This is simply misleading! Distribution of the WS code from wireshark.org is *not* limited in any way - only variants are. There _are_ significant restrictions on its distribution -- if you provide someone with a copy of Wireshark, even if it's straight from the wireshark.org download site, you still have to comply with section 3 and provide either the source code or a way to retrieve it. I regularly get emails from people wanting to include Wireshark with a product or service they're providing, and that requirement is always in my response. There are even heftier restrictions on distributing Wireshark as part of a combined work, since the work has to be GPL-compatible. Ok, you got me here ;-) Although I know the GPL, I did another interpretation which was wrong (or at least unclear what I've meant). This might show that adding some explanation to the GPL - even in the right spirit - might make it much worse ... Adding another interpretation of the GPL doesn't make anything better - in fact it make things much worse! ...then why did we have the bit of text that was there before? Well, I was asking myself the same question. The problem with these extensions to the license is as follows: If you take licensing serious (otherwise the license text is of no interest), you'll need to read and understand every license of each and every program you want to use. I've often looked at larger programs license which have multiple licensing for multiple parts of the program (e.g. library x is licensed under MIT, lib y is licensed under Apache, ...), which makes it hard to get. In addition, seeing the keyword GPL in the license text is not enough - you need you to read the license text completely. So adding anything to the GPL text in effect just unclarifies the license IMO - there could be ugly details that you'll need to know. When I remember the topic correct, this was due to the time when companies started to see Wireshark / Ethereal as a dissection library for their proprietary sniffer products. Either because they just don't cared about the license text at all or the GPL restrictions in special - so clarifying the text won't help. Or they know the GPL license and simply ignored it - in which case clarifying the GPL text won't help either. Keep in mind, at that time the GPL violations court decisions wasn't there. Stopping a company from breaking the GPL rules by adding some extensions to the license text is probably even a bit naive ;-) P.S: BTW: Why do you add two spaces after a dot? IMHO this is incorrect, however, I'm not a native speaker/writer! Because doing otherwise got points deducted in school. A quick search on the subject turns up style guides that range from always to if you like to never: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/writing-style.html http://www.fontsite.com/Pages/RulesOfType/ROT0997.html http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo02.html The teachers doing the deducting are either retired or deceased now, so it's probably safe to start using a single space after periods. Interesting reading, as I've never seen this double spaces until I start to read mailing lists :-) My english teacher never mentioned something like this, or at least I can't remember it ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Save ... before ... dialogs: Yes/No/Cancel buttons for all ?
Bill Meier wrote: List: Wireshark has a number of Save before ... ? dialogs. One has Yes/No/Cancel buttons; Most have Save/Continue/Cancel buttons; One has OK/Cancel buttons.. I propose to have these dialogs all use Yes/No/Cancel buttons since I think this would be more intuitive. If there are no concerns or other suggestions, I'll commit the change in a day or so. Bill --- Save/Continue/Cancel main.c: Save capture file before program quit? capture_dlg.c: Save capture file before starting a new capture? capture_file_dlg.c: Save capture file before opening a new one? capture_file_dlg.c: Save capture file before closing it? drag_and_drop.c: Save capture file before opening a new one? airpcap_dlg.c: Save settings before closing? ... before closing what will be closed? A file, the program? - that's a very generic term before program quit might be better here - if that's what will happen :-) airpcap_dlg.c: Save settings before changing interface? OK/Cancel capture_file_dlg.c: Save the capture file before merging to another one? Yes/No/Cancel menu.c: Save capture file before opening a new one? First of all, thanks for putting this together! I agree that this should be more consistent, but please don't do this change in the way you've mentioned, it's against human interface guidelines! HIG tells you that the action should be on the button - it makes it much faster to handle. People tend to scan the button texts first, so they should give you an idea what will happen. At least use the Save/Continue/Cancel combination here, as it's a lot better than Yes/No/Cancel. There's already a bug report, that even the Save/Continue/Cancel is not the right text for the program quit question, see http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1427. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Save ... before ... dialogs: Yes/No/Cancel buttons for all ?
Ulf Lamping wrote: HIG tells you that the action should be on the button - it makes it much faster to handle. More than one HIG, to be precise: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_6.html#//apple_ref/doc/uid/2961-CJECBHJE Buttons for addressing the alert. Button names should correspond to the action the user performs when pressing the button—for example, Erase, Save, or Delete. http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html#alert-button-order Button Phrasing. Write button labels as imperative verbs, for example Save, Print. This allows users to select an action with less hesitation. An active phrase also fits best with the button's role in initiating actions, as contrasted with a more passive phrase. For example Find and Log In are better buttons than than Yes and OK. http://developer.kde.org/documentation/standards/kde/style/dialogs/simple.html Although Yes-No questions have an appealing simplicity, they do have a downside. While the implications of the Yes answer are usually very clear, the implications of the No answer are often not clear at all. The question Do you want to save your changes? serves as a good example. Pressing Yes will get the changes saved, but what happens when the user presses the No button? Rephrasing the question as an Either-Or question will help make this more clear: Do you want to save or discard your changes?. Now there can be buttons labeled Save and Discard, and the consequences of both are equally clear. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/UxGuide/UXGuide/Windows/DialogBoxes/DialogBoxes.asp Prefer specific responses to Yes and No buttons. While there's nothing wrong with using Yes and No, specific responses can be understood more quickly, resulting in efficient decision making. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] asn1_ctx_t introduced in more BER functions
Anders, I have done some regression tests with my CMS, X509*, X411, X420, S4406, DAP, DISP, DOP, LDAP and RTSE captures. No discernable problems. Thanks, Graeme _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman Sent: 13 May 2007 23:03 To: 'Developer support list for Wireshark' Subject: [Wireshark-dev] asn1_ctx_t introduced in more BER functions Hi, asn1_ctx_t has been introduced in more BER functions as this affects many dissectors something may have been broken. If you have BER encoded traces please do some regression tests. Regards Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] questions about conversations
On Wed, 16 May 2007 15:48:36 -0700 Guy Harris [EMAIL PROTECTED] wrote: On May 16, 2007, at 12:58 PM, Tomasz Noiński wrote: Did I get this wrong? Is it possible to create Wireshark frames from inside a dissector? No. Perhaps we need to have the key for the protocol data routines be a frame number and an offset within the frame, so that there can be multiple protocol data items within a link-layer frame. I think offset within a frame might be not enough: For example, in my case, I decode the packets first, creating a nev tvb with tvb_new_real_data(). So, unless there's some tvb-magic I don't know about, simple offset just isn't enough. Numbering packets manually inside a frame (for example, as an alternative to providing an offset, as Steve suggested) might be the best solution... Noix ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Developer cmd.exe shortcut
Ulf, Something you may want to add to: http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupPre pareCommandCom -- You can create a shortcut to prepare the cmd.exe environment for building wireshark. Right click on the desktop and choose New/Shortcut In the resulting wizard, enter the following for the location of the item: C:\WINDOWS\system32\cmd.exe /E:ON /V:ON /T:0E /S /K C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat Press Next . Choose an appropriate Name for the shortcute.g. WSDevShell. Select Finish. Then right click on the new shortcut and choose Properties. Change the Start in field to C:\Wireshark and press OK. Graeme ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] redback dissector update #2
On Tue, May 08, 2007 at 01:10:04PM -0700, Stephen Fisher wrote: Subject: Re: [Wireshark-dev] redback dissector update #2 On Tue, Apr 17, 2007 at 03:18:25PM +0200, Florian Lohoff wrote: Hi, here is another round - Now we see ISIS again correctly together with PPPoE PPP handshakes handed from the Packet Forwarding Asic. Do you want this patch, dated the 17th, applied instea of the one dated the 13th or in addition to? Instead - its a patch against svn current. Sorry it took so long. Should i resend the patch ? Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Save ... before ... dialogs: Yes/No/Cancel buttons for all ?
Ulf Lamping wrote: HIG tells you that the action should be on the button - it makes it much faster to handle. Guy Harris wrote: More than one HIG, to be precise: OK: Very good feedback. How about Save / Don't Save / Cancel ?? This also handles Save capture file before program quit?. Re: Save settings before closing? in airpcap_dlg.c The additional text in the window is: If you close the window without saving, changes you made will\nbe discarded. so I think this should be Save settings before closing window? Bill --- (The dialogs being discussed: Save capture file before program quit? Save capture file before starting a new capture? Save capture file before opening a new one? Save capture file before closing it? Save capture file before opening a new one? Save settings before changing interface? Save the capture file before merging to another one? Save capture file before opening a new one? Save settings before closing? ) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Save ... before ... dialogs: Yes/No/Cancel buttons for all ?
Bill Meier wrote: How about Save / Don't Save / Cancel ?? That sounds much better! Even better than what we currently have :-) This also handles Save capture file before program quit?. Re: Save settings before closing? in airpcap_dlg.c The additional text in the window is: If you close the window without saving, changes you made will\nbe discarded. so I think this should be Save settings before closing window? Yes, also sounds better. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Developer cmd.exe shortcut
Graeme Lunt wrote: Ulf, Something you may want to add to: http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupPre pareCommandCom -- You can create a shortcut to prepare the cmd.exe environment for building wireshark. Right click on the desktop and choose New/Shortcut In the resulting wizard, enter the following for the location of the item: C:\WINDOWS\system32\cmd.exe /E:ON /V:ON /T:0E /S /K C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat Press Next . Choose an appropriate Name for the shortcute.g. WSDevShell. Select Finish. Then right click on the new shortcut and choose Properties. Change the Start in field to C:\Wireshark and press OK. Well, instead of adding this to the quick setup, I think about adding something like this as a batch file to the subversion sources. In the meantime, using the MSVC2005(EE) and the SDK seems to become common, so adding such a batch file might make sense now. Obviously, you'll have to edit both solutions if the path settings are different than the defaults. And I guess it's easier to install, than the shortcut thing. You can then easily add a shortcut to this batch file on the desktop or where you like ... It's called quick setup guide, so making it larger should be justified ;-) Or are there real advantages of the shortcut solution that I just don't see? Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Developer cmd.exe shortcut
Ulf Lamping wrote: Graeme Lunt wrote: Ulf, Something you may want to add to: http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupPre pareCommandCom -- You can create a shortcut to prepare the cmd.exe environment for building wireshark. Right click on the desktop and choose New/Shortcut In the resulting wizard, enter the following for the location of the item: C:\WINDOWS\system32\cmd.exe /E:ON /V:ON /T:0E /S /K C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\SetEnv.Cmd C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat Press Next . Choose an appropriate Name for the shortcute.g. WSDevShell. Select Finish. Then right click on the new shortcut and choose Properties. Change the Start in field to C:\Wireshark and press OK. Well, instead of adding this to the quick setup, I think about adding something like this as a batch file to the subversion sources. In the meantime, using the MSVC2005(EE) and the SDK seems to become common, so adding such a batch file might make sense now. Obviously, you'll have to edit both solutions if the path settings are different than the defaults. And I guess it's easier to install, than the shortcut thing. You can then easily add a shortcut to this batch file on the desktop or where you like ... It's called quick setup guide, so making it larger should be justified ;-) Or are there real advantages of the shortcut solution that I just don't see? Does VS2005 EE not install a Visual Studio 2005 Command Prompt entry in the Visual Studio Tools menu of VS? VS 2005 Professional certainly does. The advantage of this is the paths will be correct. All you need to do is copy it and change the Start in directory. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] asn1_ctx_t introduced in more BER functions
Hi, Thanks a lot! Regards Anders _ Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Graeme Lunt Skickat: den 17 maj 2007 10:56 Till: 'Developer support list for Wireshark' Ämne: Re: [Wireshark-dev] asn1_ctx_t introduced in more BER functions Anders, I have done some regression tests with my CMS, X509*, X411, X420, S4406, DAP, DISP, DOP, LDAP and RTSE captures. No discernable problems. Thanks, Graeme _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman Sent: 13 May 2007 23:03 To: 'Developer support list for Wireshark' Subject: [Wireshark-dev] asn1_ctx_t introduced in more BER functions Hi, asn1_ctx_t has been introduced in more BER functions as this affects many dissectors something may have been broken. If you have BER encoded traces please do some regression tests. Regards Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Win32 buildslave failure
No that's simply a bug introduced into the GTK/GDK code of WS by someone. The buidlbot test fails with: -- (wireshark.exe:2228): Gtk-WARNING **: unable to find signal handler for object(GtkEntry:02A251F8) with func() and data(02978E78) (wireshark.exe:2228): Gtk-WARNING **: unable to find signal handler for object(GtkEntry:02A251F8) with func() and data(02978E78) (wireshark.exe:2228): Gtk-CRITICAL **: gtk_box_pack_start: assertion `child-parent == NULL' failed (wireshark.exe:2228): Gtk-CRITICAL **: gtk_box_pack_start: assertion `child-parent == NULL' failed -- These Warnings/Criticals didn't appeared in former WS versions and AFAIK the test weren't changed recently. My belief is that this is not a bug in GTK/GDK but rather an attempt by wireshark to output an error message (pop up window ?) during one of the unit tests. Wireshark is being run from a shell command line for the unit tests and maybe this test setup doesn't quite work well for the gui. OK: I've investigated further: 1. I stepped through wireshark startup and found that the Gtk-WARNINGS and Gtk-CRITICAL messages are all related to what appears to be airpcap GUI initialization. The messages are presumably benign and are *not* the reason the 'run tests' step was failing. (Note: It seems that these messages appear in the console window only when running wireshark with (stdout ?) (stderr ?) redirected to a file. I don't understand all this and haven't pursued it). 2. I've lengthened the timeout for the capture tests from 20 seconds to 60 seconds. The capture tests currently seem to be runing OK in the windows buildbot. We'll see if they continue to run OK. I don't know whether the Capture Buffer Size too Large message observed by Gerald was related to the test failures. Time will tell Bill ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Save ... before ... dialogs: Yes/No/Cancel buttons for all ?
Bill Meier wrote: OK: Very good feedback. How about Save / Don't Save / Cancel ?? That's the OS X convention for that case. The example in the GNOME HIG (figure 3.17 on the GNOME HIG page linked from my previous message) offers Close without Saving, Cancel, and Save; that seems to be their recommendation. The KDE HIG offers Save, Discard, and Cancel. Microsoft's Commit buttons for indirect dialog boxes example offers Save, Don't Save, and Cancel. One slight problem I have with the OS X/Windows convention is that, at least early on using OS X applications, it wasn't *immediately* obvious that Don't Save meant close the window anyway, without saving. From a quick look at the three styles, I might have a *slight* preference for the KDE wording, as it arguably most strongly emphasizes in the text of the button that you're throwing out the data the app has. However, it might well be that, after you've used a desktop environment for a while, you respond to the wording sub-consciously, and you'd have to stop and think (even if only for a second) when confronted with an unfamiliar button label, so the label used for other apps in the same environment would be best. Were we to do that, we could do that on Windows (as we can find out whether we're running on Windows at compile time), and (sort-of) do that on OS X (sort-of because, for now, we're building with the X11 version of GTK+, so, in theory, it could be running on OS X but displaying on a GNOME or KDE desktop), but KDE vs. GNOME vs. some other environment is trickier. For now, we can pick one convention, and worry about getting fancier later. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] New Wimax plugin
I am a software engineer at Intel. We have developed a WiMax plugin for Wireshark and wish to contribute the source to the community. The source consists of two plugins, each in its own directory. There is really nothing to patch, except maybe the Makefiles. I would assume that you would not want to include our plugin with the normal distribution, since Wimax is a wireless protocol. This plugin is primarily of interest to Wimax developers who are using an Ethernet-based Mac to Mac protocol for test purposes, or those who are building wireless Wimax sniffer hardware. Anyone who uses this is probably going to need to modify it to work with their own Ethernet-based carrier protocol, so it's not really useful to casual users. So how do I upload this? We were thinking of just providing a tarball that would not be part of the standard distro, but which could be downloaded as an add-on from the wireshark repository. (We have tested the plugin to make sure it builds on Windows, Linux, and 64-bit Linux; that it can be built by simply dropping into the plugins (source) directory and modifying a couple of makefiles; and that the resulting *.so files can be simply dropped into an existing Wireshark 0.99.X plugins (binary) dir and used.) Thanks, Mike ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] PAD file and automatic version checking
Jaap Keuter wrote: Hi Gerald, On the Wireshark download page a PAD file can be found that can be used for version checking. Version checking is an item on the release list for .6 (Win32). What I can't figure out is how the update is being checked on the client PC? How/by what software is the PAD file being checked and an update handled? The PAD file is used by download sites such as Softpedia and SnapFiles to update their Wireshark entries automatically. It isn't being used by Wireshark presently. We might be able to use it for automatic updates. The PAD file format is extensible, and it allows for things like digital signatures. Details can be found at http://www.asp-shareware.org/pad/specs.asp . ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New Wimax plugin
On May 17, 2007, at 4:41 PM, Harvey, Michael wrote: I am a software engineer at Intel. We have developed a WiMax plugin for Wireshark and wish to contribute the source to the community. The source consists of two plugins, each in its own directory. There is really nothing to patch, except maybe the Makefiles. I would assume that you would not want to include our plugin with the normal distribution, since Wimax is a wireless protocol. This plugin is primarily of interest to Wimax developers who are using an Ethernet-based Mac to Mac protocol for test purposes, or those who are building wireless Wimax sniffer hardware. Anyone who uses this is probably going to need to modify it to work with their own Ethernet-based carrier protocol, so it's not really useful to casual users. There's a *lot* of stuff in Wireshark already arguably not useful to casual users - most users probably don't need, for example, the Gryphon plugin (most users probably don't have Dearborn Group hardware for plugging into cars), or the DOCSIS plugin (most users probably aren't working with Cisco equipment at the cable company head end), or As such, I don't see any reason why a WiMax plugin wouldn't be something we'd want to distribute as part of Wireshark. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
