Re: [Wireshark-dev] [Wireshark-commits] rev 38522: /trunk/gtk/ /trunk/gtk/: capture_dlg.c
On Sun, Aug 14, 2011 at 1:03 PM, Michael Tüxen wrote: > * I get wrong link-layer for some of my remote (rpcap) devices. This > used to work before. I'm still having issues with this one. The link-layer is now correct in the interfaces list, but the one listed is not the one used when starting capture. Going into the interface settings and pressing Ok sets correct link-layer for the device. This only happens for interfaces which does not have link-layer 'Ethernet', as this is the link-layer used by default. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list 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] Wireshark-commits: [Wireshark-commits] rev 38542: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-gsm_a_rr.c
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=38542 [1] User: etxrab Date: 2011/08/14 09:39 PM Log: From Jeremy Quirke: misdecoding 3G Neighbour Cell Information Element in SI2quater message due to a coding typo https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6237 [2] Directory: /trunk/epan/dissectors/ Changes Path Action +1 -1 packet-gsm_a_rr.c Modified He Anders, Please don't forget to check for applicability for trunk-1.4 backport. My guess it is. Thanks, Jaap Links: -- [1] http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev|+|amp|+|revision=38542 [2] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6237 ___ Sent via:Wireshark-dev mailing list 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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
This call: gtk_quit_add_destroy(gtk_main_level(), GTK_OBJECT(streamwindow)); Appears to tell GTK to destroy the object "streamwindow" if Wireshark is being closed entirely. This then calls the signal that was connected a few lines earlier: g_signal_connect(streamwindow, "destroy", G_CALLBACK(follow_destroy_cb), NULL); Which calls the function "follow_destroy_cb" when the object "streamwindow" is destroyed. That "follow_destroy_cb" deletes the temporary file used by the Follow TCP Stream feature (the Follow TCP feeds the data into a temp file whereas Follow UDP and Follow SSL both feed it via a tap). So I think something needs to be substitued if they've gotten rid rid of gtk_quit_add_destroy() in GTK 3.. On Mon, Aug 15, 2011 at 02:42:02PM +, etx...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=38546 > > User: etxrab > Date: 2011/08/15 07:42 AM > > Log: > gtk_quit_add_destroy() is deprecated in GTK 3.0. > (I hope tis is the right thing to do). > > Directory: /trunk/gtk/ > ChangesPath Action > +6 -2 follow_stream.cModified > > ___ > Sent via:Wireshark-commits mailing list > Archives:http://www.wireshark.org/lists/wireshark-commits > Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits > > mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list 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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
On 8/15/2011 12:21 PM, Stephen Fisher wrote: This call: gtk_quit_add_destroy(gtk_main_level(), GTK_OBJECT(streamwindow)); Appears to tell GTK to destroy the object "streamwindow" if Wireshark is being closed entirely. This then calls the signal that was connected a few lines earlier: g_signal_connect(streamwindow, "destroy", G_CALLBACK(follow_destroy_cb), NULL); Which calls the function "follow_destroy_cb" when the object "streamwindow" is destroyed. That "follow_destroy_cb" deletes the temporary file used by the Follow TCP Stream feature (the Follow TCP feeds the data into a temp file whereas Follow UDP and Follow SSL both feed it via a tap). So I think something needs to be substitued if they've gotten rid rid of gtk_quit_add_destroy() in GTK 3.. I agree. I was looking at this a couple of days ago and ran a simple test. Exiting Wireshark (with no gtk_quit_destroy()) in the follow_stream code left a file in the temp directory. I was thinking about using "destroy_with_parent" but but then I starting going down the rathole about modal windows and etc and having to re-remember details about how GTK works. There's also some discussion on the net about gtk_quit (which I didn't really understand) about the difficulties of substituting other code for this feature. In any case, I ran out of time (and patience) to dig in further. (I did remove two instances of the use of gtk_quit_destroy() in SVN #38415 which AFAIKT weren't needed since there was no special action taken when the window was destroyed). Bill ___ Sent via:Wireshark-dev mailing list 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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
On Aug 15, 2011, at 10:47 AM, Bill Meier wrote:
> Exiting Wireshark (with no gtk_quit_destroy()) in the follow_stream code left
> a file in the temp directory.
Is there some reason why we don't delete the file when the "{TCP,SSL} Stream"
window is destroyed? Presumably that window gets destroyed when the app quits,
but it also gets destroyed if you just close the window.
___
Sent via:Wireshark-dev mailing list
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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
On 8/15/2011 2:28 PM, Guy Harris wrote:
On Aug 15, 2011, at 10:47 AM, Bill Meier wrote:
Exiting Wireshark (with no gtk_quit_destroy()) in the follow_stream
code left a file in the temp directory.
Is there some reason why we don't delete the file when the "{TCP,SSL}
Stream" window is destroyed? Presumably that window gets destroyed
when the app quits, but it also gets destroyed if you just close the
window.
That's what I assumed & expected, but it seems that the "destroy"
callback for the window doesn't get called when the app exits since the
file didn't get removed when I simply exited Wireshark by clicking the
upper right corner of the main window.
Maybe something about the window is a dialog window ?
___
Sent via:Wireshark-dev mailing list
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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
On 8/15/2011 2:54 PM, Bill Meier wrote:
On 8/15/2011 2:28 PM, Guy Harris wrote:
On Aug 15, 2011, at 10:47 AM, Bill Meier wrote:
Exiting Wireshark (with no gtk_quit_destroy()) in the follow_stream
code left a file in the temp directory.
Is there some reason why we don't delete the file when the "{TCP,SSL}
Stream" window is destroyed? Presumably that window gets destroyed
when the app quits, but it also gets destroyed if you just close the
window.
That's what I assumed & expected, but it seems that the "destroy"
callback for the window doesn't get called when the app exits since the
file didn't get removed when I simply exited Wireshark by clicking the
upper right corner of the main window.
Maybe something about the window is a dialog window ?
Code from dlg_window_new()
* On Windows, making the dialogs transient to top_level behaves
strangely.
* It is not possible any more to bring the top level window to
front easily.
* So we don't do this on Windows.
*/
#ifndef _WIN32
if (top_level) {
gtk_window_set_transient_for(GTK_WINDOW(win),
GTK_WINDOW(top_level));
}
#endif /*_WIN32*/
Now I remember why I lost the energy to pursue this further :)
___
Sent via:Wireshark-dev mailing list
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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
On Aug 15, 2011, at 11:54 AM, Bill Meier wrote: > That's what I assumed & expected, but it seems that the "destroy" callback > for the window doesn't get called when the app exits since the file didn't > get removed when I simply exited Wireshark by clicking the upper right corner > of the main window. > > Maybe something about the window is a dialog window ? It shouldn't be - I'd call it a "Primary Window" in GNOME's terminology: http://developer.gnome.org/hig-book/2.32/windows-primary.html.en rather than a "Dialog": http://developer.gnome.org/hig-book/2.32/windows-dialog.html.en However, it's created with dlg_window_new() in follow_stream(). Perhaps it shouldn't be. If you close the current capture, or quit Wireshark, the window should be destroyed. ___ Sent via:Wireshark-dev mailing list 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 38522: /trunk/gtk/ /trunk/gtk/: capture_dlg.c
On Aug 15, 2011, at 9:20 AM, Stig Bjørlykke wrote: > On Sun, Aug 14, 2011 at 1:03 PM, Michael Tüxen > wrote: >> * I get wrong link-layer for some of my remote (rpcap) devices. This >> used to work before. > > I'm still having issues with this one. The link-layer is now correct > in the interfaces list, but the one listed is not the one used when > starting capture. Going into the interface settings and pressing Ok > sets correct link-layer for the device. > > This only happens for interfaces which does not have link-layer > 'Ethernet', as this is the link-layer used by default. Hmm. Can you retest with r38548? I hope it fixes the issue. If not, can you set the console.log.level in the preferences to 255 and provide the output for the two cases: One time when it is OK, one time when the problem shows up. Thanks! Best regards Michael > > > -- > Stig Bjørlykke > ___ > Sent via:Wireshark-dev mailing list > 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 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] https access to anonsvn/viewvc?
On 8/9/11 10:38 AM, Jeff Morriss wrote: > Hi Gerald, > > I accidentally ended up looking at anonsvn via https and I noticed that > the format looks different. For example, compare: > > https://anonsvn.wireshark.org/viewvc?revision=38430&view=revision > > to: > > http://anonsvn.wireshark.org/viewvc?revision=38430&view=revision > > The "Diff to previous" ends up different too--the https version lacks > the colors and is thus hard to use. The https had an older CGI-based version of ViewVC configured. I tried using the newer configuration (which uses WSGI) but it it kept generating errors. For the time being I'm redirecting ViewVC URLs on the https site to the http site. ___ Sent via:Wireshark-dev mailing list 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] buildbot failure in Wireshark (development) on OSX-10.6-x64
The Buildbot has detected a new failure on builder OSX-10.6-x64 while building Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/OSX-10.6-x64/builds/3616 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: osx-10.6-x64 Build Reason: scheduler Build Source Stamp: 38549 Blamelist: etxrab BUILD FAILED: failed compile sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list 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] Timeshift dialog default button: OK instead of Apply?
I'm not sure what the best workflow for using the Edit -> Time Shift dialog is, but it seems like once you type something in such as +1000 in the first "shift all packets" section, shouldn't pressing hit the OK button instead of Apply button? Or would the user want to keep using the dialog after trying a time shift? ___ Sent via:Wireshark-dev mailing list 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] buildbot failure in Wireshark (development) on OSX-10.5-x86
The Buildbot has detected a new failure on builder OSX-10.5-x86 while building Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/4095 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: osx-10.5-x86 Build Reason: scheduler Build Source Stamp: 38549 Blamelist: etxrab BUILD FAILED: failed compile sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list 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] Compiling Wireshark for Win32
On 8/12/11 1:25 AM, Helge Kruse wrote: > @Gerald, > the ZIP file with the PDBs are ~13 Megabyte in size. Would it be possible to > add the import libraries to the archive in one of the next versions? The > libwireshark.lib has only 266kByte while the PDB has 10MByte. I added libwireshark.lib, libwsutil.lib, and wiretap-1.7.0.lib to the archive along with libwsutil.pdb. ___ Sent via:Wireshark-dev mailing list 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] Compiling Wireshark for Win32
On 8/11/11 1:45 PM, Jeff Morriss wrote: > > That being, said, for the *NIX builds "warnings as errors" (-WX in the > Windows case) are normally turned off for the releases. > > Gerald et al, is there any reason that's not done for the Windows > builds? (-WX is set in trunk-1.2, trunk-1.4, trunk-1.6.) We're now > seeing that there are differences in the warnings coming out of the > various Windows compilers... We disable warnings-as-errors for Autotools and for CMake in the releases; -WX should definitely be disabled for Visual C++. I've checked in a change to do so in r38552 and updated the release checklist. ___ Sent via:Wireshark-dev mailing list 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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
On Aug 15, 2011, at 1:38 PM, Guy Harris wrote: > If you close the current capture, or quit Wireshark, the window should be > destroyed. Annoyingly, I couldn't find, at least in any of the official guidelines for any desktop environment I looked at (OS X, GNOME, KDE, Windows) any discussion of, for example, a "derived" window, where you have a main window with a document (or a data store of some sort, e.g. a mailbox), and, for example, ask the application for a statistical analysis of the document,w which pops up in a separate window. Does that get destroyed if you close the window for the document from which it's derived? Does it get minimized if you minimize the document window? (And what happens, at least in OS X Lion, if you make the document window full-screen? Lion's full-screen is a bit more full-screen than the Windows/KDE/GNOME/etc. full-screen, in that it's supposed to be sort of like iOS, where the document window is all you have.) Neither Excel (at least on OS X) and Numbers pop up graphs as separate windows - that was the obvious example I came up with. I tried getting document statistics with both Word and Pages; Word pops up a *modal* window with document statistics, and you can't close the document window or do anything else with it until you close the statistics window, and Pages pops up an "inspector"-style window, which isn't modal, but you have only one of them, and it displays the statistics for whichever document window you've just selected and goes blank if there are no document windows. So I thought "hey, what does Network Monitor do?" It doesn't seem to have any obvious built-in statistics, but it has "Experts", which appear to be like our statistics taps. So, after downloading and installing one of the "Experts" (a bit of a clunky procedure), starting it (a bit of a clunky procedure - I had to save the capture to a file first), discovering that I needed to install a .NET widget for the "Expert" (a bit of a clunky procedure, as the dialog telling me that didn't pop up on top the first time I tried it), and installing the widget (a bit of, well, you know the drill), it popped up a statistcs window - which remains behind even after you close the window, and even after you quit Network Monitor (probably because it's running in a separate process. ___ Sent via:Wireshark-dev mailing list 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 38546: /trunk/gtk/ /trunk/gtk/: follow_stream.c
And then there's View Source in both Safari and Internet Explorer, where the page source window remains open even if you close the window with the page. So I'd say "*don't* close the Follow Stream window if you close the capture file, but *do* catch whatever the appropriate signals are on the Follow Stream window and *do* remove the temporary file when the window goes away". ___ Sent via:Wireshark-dev mailing list 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] Time shift patch causes compile error
> I'm not sure if my system config or the code is at fault. truncl isn't > defined anywhere in /usr/include/* except for C++ header files. > Apparently, it's a gcc builtin function. I have no idea what parameters > it expects. You're passing it long doubles, this is in line with the > manpage. > > If I enable your define for windows > > #define truncl(ld) floorl(ld) > > things work ok for me. Should that be enabled for older gccs as well or > are you aware of gcc settings that make it define truncl() in the standard > way? I put in this #define to make it work on Windows, but did not check too much where the trunc() function is available elsewhere. I also think that if truncl() is not present on other non-Windows platform, we should simply use floorl(), as it should be available on every C compiler. floor() and trunc() only return a different result for negative arguments. (truncl always rounds down, floorl round towards 0) Would could also declare the offset_float variable as "double" and use "floor()" instead, possibly being more compatible if a platform does not support the "long double" format. And 64bit of double should be enough for a nanosecond precision. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ Sent via:Wireshark-dev mailing list 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] Compiling Wireshark for Win32
Am 16.08.2011 00:01, schrieb Gerald Combs: On 8/12/11 1:25 AM, Helge Kruse wrote: @Gerald, the ZIP file with the PDBs are ~13 Megabyte in size. Would it be possible to add the import libraries to the archive in one of the next versions? The libwireshark.lib has only 266kByte while the PDB has 10MByte. I added libwireshark.lib, libwsutil.lib, and wiretap-1.7.0.lib to the archive along with libwsutil.pdb. Great! In which version's pdb ZIP archive will we find the libs? Currently there are only PDBs in http://www.wireshark.org/download/win32/all-versions/wireshark-pdb-win32-1.6.1.zip Thank you, Helge ___ Sent via:Wireshark-dev mailing list 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] REPLY ASAP:Extensions to wireshark
Hi all, I'm Nikitha Malgi working for IP Infusion India currently. I and a colleague of mine have both worked on extending the wireshark to support TRILL and MPLS-TP payloads and we have been successful in doing it. We are now planning it to contribute to the open source. Can any of you tell the exact procedure to be followed in doing so asap. Thanks and regards, Nikitha and Krishnamurthy(IP Infusion,India) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
