Re: [Wireshark-dev] can't compile wireshark version 4.0
On Thu, Oct 20, 2022 at 6:54 PM Fulko Hew wrote: > My guess as to what could be wrong according to the error is that > ba[i] < '\0' is 'always false' because ba (although declared as a > QByteArray) is probably > an unsigned byte array, and as such a value can never be less than zero. > It's documented as char here: https://doc.qt.io/qt-6/qbytearray.html#at I never had any issues compiling this code on my RPi. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] On MR 4428
On Wed, Oct 6, 2021 at 12:58 PM Jaap Keuter wrote: > Looking at MR 4428 > <https://gitlab.com/wireshark/wireshark/-/merge_requests/4428> (cherry > picked from commit 96cfaf67 > <http:///wireshark/wireshark/-/commit/96cfaf67a383cd3676a7dba61040e8c4b7a47b12>) > it introduces a new symbol in the wiretap 11 library > (wtap_uses_lua_filehandler). The debian symbols file contains the addition > of "wtap_uses_lua_filehandler@Base 3.5.1", which refers to a later > version (3.5.1) than this release is of (3.4.x). I could see this being a > problem somewhere. Maybe we need to reconsider inclusion of the MR in > release-3.4 > This issue is already fixed in MR . Maybe we should add a sanity check to the Debian builder? -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Compilation on Windows taking a very long time?
On Tue, Oct 5, 2021 at 7:43 AM Anders Broman via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Is it just me or is compilation time on Windows much longer now? > I don't know about the Windows build, but I recently discovered that changes in one ui/qt/*.cpp file triggers a build of all (or many) ui/qt/*.cpp files. This does not happen in the release-3.4 branch. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ISO 7816 vs GSM SIM dissector
Thank you Pascal and Martin. I will update the gsm_sim dissector for my needs for now, merging these two looks like a complex and time consuming task. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ISO 7816 vs GSM SIM dissector
Hi, Does anyone know the difference between the ISO 7816 dissector and the GSM SIM dissector? For me it looks like they are handling the same PDUs, but both are incomplete in different ways. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Unregistered header fields in packet-fcdns.c
Hi Christian, Do you have a sample capture file to show this issue? -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Qt issue with first section not movable
Hi, If we don’t enforce the first column to always be a Number column then I > would consider this as a bug. > It’s possible to change this column in preferences, or by manually editing the config file, and existing profiles may have different columns which the user wants to move around. Not being able to move the first column is strange and inconsistent behaviour in Wireshark. That’s what I think. Stig -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] macOS dark mode in 3.0.0
On Thu, Mar 21, 2019 at 3:09 PM Lori Jakab wrote: > Did anyone manage to build a dark mode enabled version successfully? Dark mode was disabled in 81c4f74a1921e8c89fcf200beb6892b78a7297d9 Remove this two lines from packaging/macosx/Info.plist.in NSRequiresAquaSystemAppearance -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] macOS dark mode in 3.0.0
On Thu, Mar 21, 2019 at 9:43 AM Lori Jakab wrote: > I'm on macOS Mojave using dark mode, and my understanding was that > Wireshark 3 does support it. Is there anything that needs to be done > to activate it? For me it still shows up with light color palette. Have a look at this bug report: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15511 -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Overriding a builtin dissector
On Thu, Apr 26, 2018 at 10:13 PM, Dario Lombardo <lom...@gmail.com> wrote: > What about using proto_deregister_protocol? This function was designed to work with reloading Lua plugins and I don't know how well it will work for disabling builtin dissectors. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 2.5.0, 2.6, and 3.0 release planning
On Fri, Feb 2, 2018 at 11:45 PM, Gerald Combs <ger...@wireshark.org> wrote: > I think we've fixed the major issues identified by Stig, Jim, and others so > I'd like to release 2.5.0 on February 6. Maybe not a show stopper the release, but selecting a byte in the ByteView does not expand the corresponding tree item as it does in 2.4. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ThreadSanitizer issue in RecentFileStatus()
On Fri, Feb 2, 2018 at 7:33 PM, Gerald Combs <ger...@wireshark.org> wrote: > That's correct -- the main and RecentFileStatus threads could operate on the > filename at the same time. I think the data race is harmless in this case, > but it's easy enough to create a local copy of the filename. Fix inbound at > https://code.wireshark.org/review/#/c/25572. I'm still getting a similar race condition report from RecentFileStatus. Even if it's harmless it would have been good to fix this to make it possible to run with TSAN and "Pause on issues". == WARNING: ThreadSanitizer: data race (pid=4733) Read of size 8 at 0x7e800059edb0 by main thread: * #0 QString::QString(QString const&) qstring.h:906 (Wireshark:x86_64+0x100039256) #1 QString::QString(QString const&) qstring.h:907 (Wireshark:x86_64+0x100038498) #2 WiresharkApplication::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) moc_wireshark_application.cpp:239 (Wireshark:x86_64+0x1000bb990) #3 QObject::event(QEvent*) (QtCore:x86_64+0x211b80) #4 QApplicationPrivate::notify_helper(QObject*, QEvent*) (QtWidgets:x86_64+0x119ac) #5 start (libdyld.dylib:x86_64+0x1114) Previous write of size 8 at 0x7e800059edb0 by thread T14: * #0 QString::QString(QString const&) qstring.h:906 (Wireshark:x86_64+0x10003926d) #1 QString::QString(QString const&) qstring.h:907 (Wireshark:x86_64+0x100038498) #2 RecentFileStatus::run() recent_file_status.cpp:32 (Wireshark:x86_64+0x1005000cc) #3 non-virtual thunk to RecentFileStatus::run() recent_file_status.cpp (Wireshark:x86_64+0x10050020c) #4 (QtCore:x86_64+0x27b6d) Issue is caused by frames marked with "*". Location is stack of thread T14. Thread T14 (tid=1194099, running) created by main thread at: #0 pthread_create (libclang_rt.tsan_osx_dynamic.dylib:x86_64h+0x2a34d) #1 QThread::start(QThread::Priority) (QtCore:x86_64+0x2b5cb) #2 main wireshark-qt.cpp:667 (Wireshark:x86_64+0x1000366cd) SUMMARY: ThreadSanitizer: data race qstring.h:906 in QString::QString(QString const&) == -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ThreadSanitizer issue in RecentFileStatus()
When running with ThreadSanitizer I constantly get this race condition report from a QString in RecentFileStatus. Anyone else seen this? I can't figure out the issue... == WARNING: ThreadSanitizer: data race (pid=41949) Read of size 8 at 0x7b0c000c0dd0 by thread T18: * #0 QString::QString(QString const&) qstring.h:906 (Wireshark:x86_64+0x100039756) #1 QString::QString(QString const&) qstring.h:907 (Wireshark:x86_64+0x100038998) #2 RecentFileStatus::run() recent_file_status.cpp:33 (Wireshark:x86_64+0x1004ffbec) #3 non-virtual thunk to RecentFileStatus::run() recent_file_status.cpp (Wireshark:x86_64+0x1004ffd2c) #4 :8575680 (QtCore:x86_64+0x27b6d) Previous write of size 8 at 0x7b0c000c0dd0 by main thread: * #0 QString::QString(QString const&) qstring.h:906 (Wireshark:x86_64+0x10003976d) #1 QString::QString(QString const&) qstring.h:907 (Wireshark:x86_64+0x100038998) #2 RecentFileStatus::RecentFileStatus(QString, QObject*) recent_file_status.cpp:13 (Wireshark:x86_64+0x1004ff8b3) #3 RecentFileStatus::RecentFileStatus(QString, QObject*) recent_file_status.cpp:14 (Wireshark:x86_64+0x1004ffac0) #4 WiresharkApplication::refreshRecentCaptures() wireshark_application.cpp:256 (Wireshark:x86_64+0x10079a3b6) #5 WiresharkApplication::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) moc_wireshark_application_Debug.cpp:234 (Wireshark:x86_64+0x1000bbceb) #6 QMetaObject::activate(QObject*, int, int, void**) :8575680 (QtCore:x86_64+0x2194ba) #7 main wireshark-qt.cpp:852 (Wireshark:x86_64+0x100037b0c) Issue is caused by frames marked with "*". Location is heap block of size 48 at 0x7b0c000c0db0 allocated by main thread: #0 operator new(unsigned long) :8575712 (libclang_rt.tsan_osx_dynamic.dylib:x86_64h+0x6ba8e) #1 WiresharkApplication::refreshRecentCaptures() wireshark_application.cpp:256 (Wireshark:x86_64+0x10079a36a) #2 WiresharkApplication::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) moc_wireshark_application_Debug.cpp:234 (Wireshark:x86_64+0x1000bbceb) #3 QMetaObject::activate(QObject*, int, int, void**) :8575712 (QtCore:x86_64+0x2194ba) #4 main wireshark-qt.cpp:852 (Wireshark:x86_64+0x100037b0c) Thread T18 (tid=17501933, running) created by main thread at: #0 pthread_create :8575760 (libclang_rt.tsan_osx_dynamic.dylib:x86_64h+0x2a34d) #1 QThread::start(QThread::Priority) :8575760 (QtCore:x86_64+0x2b5cb) #2 main wireshark-qt.cpp:667 (Wireshark:x86_64+0x100036bcd) SUMMARY: ThreadSanitizer: data race qstring.h:906 in QString::QString(QString const&) == -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 2.5.0 release on January 16
On Wed, Jan 17, 2018 at 2:05 AM, Gerald Combs <ger...@wireshark.org> wrote: > On 1/13/18 4:16 AM, Stig Bjørlykke wrote: >> - Qt: Missing string translations after source code was moved to >> utils/models/manager/widgets subdirectories > > Do you know what's missing? This shouldn't be too hard to fix. I haven't investigated this, but I'm thinking that the generation of the *.ts files should also include the source subdirectories. The translations was lost just after the move to separate directories. >> - ByteView: Hovering bytes does not highlight the field as it used to do >> - ByteView: Vertical white and horisontal black lines issues >> - ByteView: Color issue when clicking a byte multiple times > > The 2.4 byte view didn't distinguish between hovered and a locked bytes. > I initially tried to do so by drawing an overline+undlerline over hovered > bytes > and coloring locked bytes. Change 25348 draws a full outline instead of an > overline+undlerline. The change makes this issues better. I'm still not sure about the "blue text on yellow background" when locked, this does not look so good with the macOS colour schemes. Maybe this could be changed to a red thicker outline? Or maybe use our "marked packet" colours? Or a combination. I never understood the white vertical lines, but now it seems like it's a bug when drawing the background colour. Have a look at the attached picture. When locking a byte the first time all bytes within a protocol has grey background colour but this grey background colour is not added on subsequent locks within the same protocol byte range. And selecting a byte does not expand the corresponding tree item as it does in 2.4. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 2.5.0 release on January 16
We still have some regression issues after 2.5 refactoring which should be fixed. Does anyone work on this? Qt/UI regression issues after refactoring: - Qt: Missing string translations after source code was moved to utils/models/manager/widgets subdirectories - Qt: Plurality does not work for strings in utils/models/manager/widgets files - I/O Graph does not work - PacketList: Markers in "Number" columns are gone - PacketDetails: Only top-level node-expansion is remembered when switching between packets - PacketDetails: Link colours in links are gone - ByteView: Wrong font size on startup and profile change (if using other size than default) - ByteView: Hovering bytes does not highlight the field as it used to do - ByteView: Vertical white and horisontal black lines issues - ByteView: Color issue when clicking a byte multiple times - Help/About: Issues reported in https://code.wireshark.org/review/24570/ -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Compiling with or without extcap
On Sat, Jan 6, 2018 at 7:15 PM, Dario Lombardo <dario.lombardo...@gmail.com> wrote: > What about an environment variable that disable extcap interfaces loading? > Or even better; a UI configurable preference to enable/disable extcap interfaces. This should be default on. When turned on or off it will automatically run a "Refresh Interfaces" to load/unload extcap interfaces without having to manually restart or "Refresh Interfaces". -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 2.5.0 release on January 16
Running with TSan on macOS shows some thread issues during startup which should have been fixed before this release. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] File load timing
On Tue, Nov 14, 2017 at 10:14 AM, Paul Offord <paul.off...@advance7.com> wrote: > I don't get that option on WS 2.4.0 or 2.4.2 on Windows: > > It's not possible to turn off "Load time" in version 2.4.x, currently only in the development version. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] File load timing
On Sat, Nov 11, 2017 at 8:05 PM, Paul Offord <paul.off...@advance7.com> wrote: > Ah - we should spread the word. A couple of people mentioned it at #sf17eu It's stated in the release notes under "New and Updated Features", so when using the development version a good tip would probably be to regularly read the constantly updated release notes. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] File load timing
On Sat, Nov 11, 2017 at 7:28 PM, Paul Offord <paul.off...@advance7.com> wrote: > While we are on the subject of stuff disappearing, what's happened to the > file load timing thing in the status line? It's default turned off. Preferences -> Appearance -> Layout -> Status Bar settings -> Show file load time -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Who did this to master?
On Wed, Nov 8, 2017 at 10:43 AM, Richard Sharpe <realrichardsha...@gmail.com> wrote: > My changes have not touched packet-btmesh.c > > CC packet-btmesh.lo > packet-btmesh.c: In function 'uat_btmesh_record_update_cb': > packet-btmesh.c:939:9: error: implicit declaration of function > 'create_master_security_keys' [-Werror=implicit-function-declaration] > create_master_security_keys(rec); Try this fix: https://code.wireshark.org/review/#/c/24296 -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders
On Wed, Aug 2, 2017 at 10:03 PM, Sultan, Hassan via Wireshark-dev <wireshark-dev@wireshark.org> wrote: > Regarding tcp.payload, I don't think tcp.payload in itself has any problems. > I think the issue lies in tcp showing a length of 32 only, even though it has > tcp.payload as its child. The tcp.payload field was recently added, have a look at https://code.wireshark.org/review/22374 I do agree that this is displayed wrong and should be fixed. Increasing the length of the TCP header would be wrong because the payload is dissected by upper protocols and does belong with the TCP header. Putting it at top level would also be wrong because it's not a protocol. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Go to Qt 5.9 on Windows build bots?
On Wed, Jun 14, 2017 at 1:49 PM, Anders Broman <anders.bro...@ericsson.com> wrote: > I think Stig has tried it on MAC OS too if we want to update that too. I even committed fixes to the Qt code in 5.9 to allow us to use -Wshorten-64-to-32 for C++. I have not seen any issues so far. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] wireshark 2.2.7 compilation failure on ubuntu 16.04.2
On Fri, Jun 2, 2017 at 12:49 PM, Conor Lennon <conorlen...@eircom.net> wrote: > CXX simple_dialog.o > simple_dialog.cpp: In constructor ‘SimpleDialog::SimpleDialog(QWidget*, > ESD_TYPE_E, int, const char*, __va_list_tag*)’: > simple_dialog.cpp:93:54: error: ‘setTextInteractionFlags’ was not declared > in this scope > setTextInteractionFlags(Qt::TextSelectableByMouse); > ^ > Makefile:1790: recipe for target 'simple_dialog.o' failed The call to setTextInteractionFlags should not have been used when compiling with Qt version < 5.1. You can safely remove this call in simple_dialog.cpp until the next release. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] CMake COMMON_WARN_FLAGS -Wframe-larger-than=16384
Hi, When building with Xcode we have now reached a frame larger than 16384 bytes in the generated Qt Ui_MainWindow::setupUi(). Should the limit be increased or is it possible to exclude individual methods from this warning? In file included from /Users/stig/Development/wireshark/ui/qt/main_window.cpp:23: /Users/stig/Development/wireshark-xcode/ui/qt/ui_main_window.h:355:10: error: stack frame size of 16760 bytes in function 'Ui_MainWindow::setupUi' [-Werror,-Wframe-larger-than=] void setupUi(QMainWindow *MainWindow) ^ 1 error generated. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Extcap version
On Mon, Feb 27, 2017 at 11:42 AM, Dario Lombardo <dario.lombardo...@gmail.com> wrote: > "help" seems to be in the same position: lives in extcap_info and in > extcap_interface at the same time. I don't think we need both: I hardly > figure out how we'd need to different help pages/files for 2 different > intefaces of the same extcap. What about removing the help in the interface? "help" is set in info but used from interface, if you remember this bug: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13218 -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] extcap slowing down start of WS
On Tue, Jan 3, 2017 at 5:56 PM, Anders Broman <anders.bro...@ericsson.com> wrote: > It now seems like extcap_register_preferences is the thing taking the > longest time when starting up Wireshark, at least on Window. One issue is that extcap_register_preferences is called before loading the interfaces, and therefore all extcap binaries are run twice because of multiple calls to extcap_reload_interface_list(). One in extcap_register_preferences() and one in fill_in_local_interfaces(). This should be improved. Loading extcap could be done in the background after Wireshark has started, like is done in "Refresh Interfaces". -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] proto.h extension (unit strings)
On Fri, Dec 16, 2016 at 4:14 PM, Michael Mann <mman...@netscape.net> wrote: > Also wanted to mention that I think Stig volunteered to add support on the > Lua end (another area that I'm not familiar enough with to add support). > Yes, I will have a look at the Lua support. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Highlight fields
On Tue, Feb 23, 2016 at 9:11 PM, Jeff Morriss <jeff.morriss...@gmail.com> wrote: > (A first--and useful--step would be to highlight the tree item when > searching with a display filter. Or maybe that's the whole solution?) > I'm already thinking about doing this in Find Packet with a display filter, so this could be common functionality. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://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] Mac Build Error
On Wed, Jan 20, 2016 at 3:48 PM, David Morsberger <d...@morsberger.com> wrote: > My current workaround is the following change to CMakeLists.txt : > > -if(NOT CMAKE_C_COMPILER_ID MATCHES "MSVC") > +if(NOT (CMAKE_C_COMPILER_ID MATCHES "MSVC" OR XCODE)) > set(WIRESHARK_LD_FLAGS > -Wl,--as-needed > > This is more like fixing the symptom, right? The real issue here is that CMake finds support for the flags while building with Xcode does not. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://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] Mac Build Error
On Wed, Jan 20, 2016 at 3:28 AM, David Morsberger <d...@morsberger.com> wrote: > I am trying to create support and possibly instructions for Xcode. > The only issue I have with using Xcode is https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11816 -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://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] Mac Build Error
On Mon, Jan 18, 2016 at 4:04 PM, David Morsberger <d...@morsberger.com> wrote: > Not exactly sure how the outdated file showed up in the wireshark source > (not build) hierarchy. > Have a look at the timestamp for some of the other generated files to find when this happened. Maybe you did a build with this source directory before this change: commit b255d8a1a19cb40a9d04f33e483aa18c3e0a38c8 Author: Gerald Combs <ger...@wireshark.org> Date: Sat Mar 7 10:43:45 2015 -0800 CMake: Update wslua build and test. Process wslua/CMakeLists.txt using add_subdirectory instead of include. Generate files in the build directory instead of the source directory. Is there a simple way to clean out my source directory so I can truly start > from scratch? > You can safely delete all files listed as ignored because they are generated. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://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] Mac Build Error
On Mon, Jan 18, 2016 at 6:27 AM, David Morsberger <d...@morsberger.com> wrote: > I have been unable to resolve the following build errors on my Mac with > 10.11. > Maybe you have a outdated declare_wslua.h in your source directory? Try deleting this. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Reload Lua plugins
This is news for those of you writing Lua plugins. The latest development automated night build[1] now have the ability to reload Lua plugins without the need for restarting Wireshark. It even reloads the capture file and stays at the selected packet. This is a brand new feature and bugs exists. Please try it out and report problems in bugzilla[2]. Known limitations: - Having Lua fields in a custom column will crash at reload - Reloading FileHandler is not supported yet - “Show Packet in New Window” will not update after a reload and may crash [1] https://www.wireshark.org/download/automated/ [2] https://bugs.wireshark.org/bugzilla/ -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://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] enum preferences vs Go Fish
On Tue, Apr 7, 2015 at 2:52 AM, mman...@netscape.net wrote: So are you thinking along the lines of prefs_register_dissector_preference that would create a dropdown list (like an enum preference) based on dissector table entries? Yes. Nothing controlled by the dissector, only available for convenience. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://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] enum preferences vs Go Fish
On Sat, Apr 4, 2015 at 3:30 AM, mman...@netscape.net wrote: I may have gone a little overboard, but I tried to remove all enumerated preferences that really should be Decode As. There were enough nuances to each situation, that I made them all separate patches. https://code.wireshark.org/review/7901 (P_MUL) For P_Mul I want the decode-as option to be available from the P_Mul preferences, and from (currently only in gtk) second-click in the packet details pane and selecting Protocol Preferences - Decode Data PDU as. This because I don't think the users will think about the global Decode As when trying to configure P_Mul (or any other protocol). Is this possible with the decode-as changes? Or do we have to implement something more? -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://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] enum preferences vs Go Fish
On Sat, Apr 4, 2015 at 1:31 PM, mman...@netscape.net wrote: Right now there is no way to include a Decode As protocol list as a specific preference of a dissector. If we add this I'm happy with a global Decode As functionality. And it may be an added feature to have this in the preferences for TCP and UDP too. But I can find some issues while trying the p_mul patch: 1. The Value and Type columns makes no sense for P_Mul (and maybe others). The tooltip does not give any hints. 2. The text in Current column is more descriptive in the current P_Mul preferences (not only the protocol short name) 3. It's possible to add more than one entry for P_Mul (in GUI). It seems like only the latest entry is used. This happens when selecting Decode As... on a P_Mul entry when already having a preference. I would expect the current entry to be highlighted. 4. My Wireshark does hang after changing the decode-as for P_Mul while having a capture file loaded. I don't know if this is related to your patch. -- Stig Bjørlykke ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://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 44812: /trunk/ /trunk/: configure.ac version_info.c
On Sat, Sep 8, 2012 at 9:46 AM, g...@wireshark.org wrote: Log: We no longer use Gestalt(), so there's no need to check for it. We *do*, however, use CFPropertyListCreateWithStream(), so we need to check for it, and, if we're able to use the OS X frameworks at all, use CFPropertyListCreateFromStream() if we don't have CFPropertyListCreateWithStream(). Now that OS X Yosemite is released we also should check for this in CMake. -- Stig Bjørlykke ___ 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] Thanks for the Manual
On Wed, Oct 15, 2014 at 1:35 AM, Emre Baris emre.bar...@ceng.metu.edu.tr wrote: Some typos In 1.2. System Requirements, files no mor than a few hundred MB In 4.9.2. Remote Capture Settings, an interface other then the interface connecting back to Wireshark Thank you for the report. This will be fixed in the next release. -- Stig Bjørlykke ___ 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 44802: /trunk/epan/ /trunk/epan/dissectors/: packet-6lowpan.c packet-atalk.c packet-bacapp.c packet-batadv.c packet-ber.c packet-btobex.c packet-capwap.c pa
On Fri, Sep 7, 2012 at 4:10 AM, morr...@wireshark.org wrote: tcp.data already exists for exposing a single TCP segment's payload as a byte array. It would be handy to have something similar for a single application layer PDU when TCP segment reassembly is involved. I propose tcp.reassembled.data, named and placed after the already existing field tcp.reassembled.length. What is the functional difference between tcp.segments and tcp.reassembled.data? They both provide the reassembled data, and I think this looks like a duplicate field. Or do I miss something here? The reason I ask is because I was thinking about this when implementing reassembled.length, but found the existing field (hf_fragments) sufficient for all practical use. And yes, I know this question is a bit late :) -- Stig Bjørlykke ___ 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/dissectors/packet-ssl-utils.h fails compilation at commit b642a280cb74b94e62
On Fri, Apr 11, 2014 at 9:27 PM, Shu Shen shu.s...@gmail.com wrote: It appears this latest change has mishandled the case when both HAVE_LIBGNUTLS and HAVE_LIBGCRYPT are undefined. I'm sorry about that. I'll fix in a short moment. -- Stig Bjørlykke ___ 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 53090: /trunk/ /trunk/asn1/acse/: acse.cnf packet-acse-template.c /trunk/asn1/cmip/: cmip.cnf packet-cmip-template.c /trunk/asn1/disp/: packet-disp-template
On Tue, Nov 5, 2013 at 7:47 PM, mm...@wireshark.org wrote: Log: In an effort to reduce the use of pinfo-private_data (and some true global variables), I converted the ASN.1 dissectors that use pinfo-private_data to exchange a SESSION_DATA_STRUCTURE to instead only exchange it in the context of ASN.1. This meant converting dissectors to the new style to pass the SESSION_DATA_STRUCTURE as well as providing a pointer to it in asn1_ctx_t.private_data. Yes, it's still private data, but it's not used by all dissectors like pinfo-private data is. This commit introduced a bug where I always get [Malformed Packet: PRES] in X.400 traffic. Have a look at this sample capture, frame 20: http://wiki.wireshark.org/SampleCaptures?action=AttachFiledo=gettarget=p772-transfer-success.pcap -- Stig Bjørlykke ___ 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 53090: /trunk/ /trunk/asn1/acse/: acse.cnf packet-acse-template.c /trunk/asn1/cmip/: cmip.cnf packet-cmip-template.c /trunk/asn1/disp/: packet-disp-template
On Fri, Jan 10, 2014 at 12:56 PM, Stig Bjørlykke s...@bjorlykke.org wrote: This commit introduced a bug where I always get [Malformed Packet: PRES] in X.400 traffic. Reassembly in RTSE is a bit special. The reassembly is done when receiving a SES MAJOR SYNC POINT, as this indicates the end of the COTP DT Data stream. The payload for this pdu is empty, which results in a empty tvb being sent to RTSE (which then reassemble all previous received payloads). Updating the RTSE dissector to a new-style was done by returning tvb_length(tvb), which in this case is always 0. Returning 0 from a new-style dissector means this package was not for us, which is wrong in this case. I've added a fix for this in 54693. -- Stig Bjørlykke ___ 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 54310: /trunk/epan/wslua/ /trunk/epan/wslua/: wslua_tvb.c
On Fri, Dec 20, 2013 at 9:29 PM, g...@wireshark.org wrote: Add new string_enc and stringz_enc methods that take an encoding value as an argument, just as the add_packet_field method for a tree does. Why not just add an optional encoding argument to the existing string and stringz, whith the default value ENC_ASCII|ENC_NA ? -- Stig Bjørlykke ___ 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 51775: /trunk/tools/ /trunk/tools/: asn2wrs.py
On Thu, Sep 5, 2013 at 9:38 AM, jma...@wireshark.org wrote: Adapt generated output to always print paths relative to the asn1/proto/ subdir. This makes cmake generated builds look identical to autotools generated builds. 1. You are using TAB as indent, which does not always work very well. 2. I get this diff for all generated files when doing make in asn1 (automake): -/* ../../tools/asn2wrs.py -b -p cmp -c ./cmp.cnf -s ./packet-cmp-template -D . -O ../../epan/dissectors CMP.asn */ +/* /../tools/asn2wrs.py -b -p cmp -c ./cmp.cnf -s ./packet-cmp-template -D . -O /../epan/dissectors CMP.asn */ -- Stig Bjørlykke ___ 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 51775: /trunk/tools/ /trunk/tools/: asn2wrs.py
Issues should be fixed in revision 51776. -- Stig Bjørlykke ___ 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 50560: /trunk/ /trunk/packaging/macosx/Resources/bin/: wireshark /trunk/packaging/macosx/: osx-app.sh /trunk/: configure.ac
On Sun, Jul 14, 2013 at 12:43 AM, g...@wireshark.org wrote: On OS X, set the rpath for executables to include @executable_path/../lib as well as /usr/local/lib, so we can use @rpath in the install names in the executables and libraries in the application bundle. I get this warning when running dumpcap from /opt/local/bin, which makes dumpcap unusable for wireshark: dyld: warning, LC_RPATH @executable_path/../lib in /opt/local/bin/dumpcap being ignored in restricted program because of @executable_path I don't get the warning when running from build dir. -- Stig Bjørlykke ___ 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 50560: /trunk/ /trunk/packaging/macosx/Resources/bin/: wireshark /trunk/packaging/macosx/: osx-app.sh /trunk/: configure.ac
On Mon, Jul 29, 2013 at 12:06 PM, Guy Harris g...@alum.mit.edu wrote: One solution to this is not to have dumpcap be set-UID or set-GID on OS X. It's not that way by default; instead, the ChmodBPF startup item is installed and run to make the BPF devices readable and writable by the access_bpf group, and the user who installs Wireshark is put into that group. Removing --enable-setuid-install from my configure was the solution. Thank you. -- Stig Bjørlykke ___ 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 50935: /trunk/epan/ /trunk/epan/dissectors/: packet-collectd.c /trunk/epan/: proto.c proto.h value_string.c value_string.h
On Fri, Jul 26, 2013 at 11:51 PM, eapa...@wireshark.org wrote: Add 64-bit value strings and the appropriate tooling (including yet another overloaded use of the DISPLAY field). While looking at adding 64-bit value strings support for Lua I found that the tree entry contains double name entry: Value: Something (Value: 42) The correct entry should be (like it is for 32-bit): Value: Something (42) The bug is in fill_label_number64(), where the format should be without the leading %s: and hfinfo-name. -- Stig Bjørlykke ___ 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] GTK warnings with 1.10.0
Hi. I'm getting this GTK warnings when setting a capture filter (Edit Interface Settings) on a device from the welcome page: (wireshark:30153): GLib-GObject-CRITICAL **: gpointer g_object_get_data(GObject *, const gchar *): assertion `G_IS_OBJECT (object)' failed (wireshark:30153): Gtk-CRITICAL **: void gtk_toggle_button_set_active(GtkToggleButton *, gboolean): assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed (wireshark:30153): GLib-GObject-CRITICAL **: gpointer g_object_get_data(GObject *, const gchar *): assertion `G_IS_OBJECT (object)' failed (wireshark:30153): Gtk-CRITICAL **: void gtk_combo_box_text_insert_text(GtkComboBoxText *, gint, const gchar *): assertion `GTK_IS_COMBO_BOX_TEXT (combo_box)' failed (wireshark:30153): GLib-GObject-CRITICAL **: gpointer g_object_get_data(GObject *, const gchar *): assertion `G_IS_OBJECT (object)' failed (wireshark:30153): Gtk-CRITICAL **: void gtk_combo_box_set_active(GtkComboBox *, gint): assertion `GTK_IS_COMBO_BOX (combo_box)' failed -- Stig Bjørlykke ___ 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] Lua converting a UINT64 to hex
On Mon, Nov 19, 2012 at 5:07 PM, Zadik, Maayan mza...@qti.qualcomm.com wrote: Local s = string.format(%X, data.value) and get the following error: bad argument #2 to 'format' (number expected, got userdata) Just try converting data.value with tostring first, like this: local s = string.format(%X, tostring(data.value)) -- Stig Bjørlykke ___ 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] Warnings when loading preferences
Hi. After upgrading my local wireshark to latest trunk I get some warnings from my preferences. I suspect someone rewrote the preference format without handling / converting old values? The user should not loose the preferences when upgrading, just because we changed the format. 12:33:02 Warn /Users/stig/.wireshark/preferences line 113: No such preference gui.version_in_start_page (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 221: Syntax error in preference name_resolve (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 225: Syntax error in preference name_resolve_concurrency (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 229: Syntax error in preference name_resolve_load_smi_modules (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 233: Syntax error in preference name_resolve_suppress_smi_errors (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 239: No such preference taps.update_interval (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 243: No such preference taps.rtp_player_max_visible (applying your preferences once should remove this warning) 12:33:02 Warn /Users/stig/.wireshark/preferences line 249: No such preference packet_list.display_hidden_proto_items (applying your preferences once should remove this warning) -- Stig Bjørlykke ___ 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] Warnings when loading preferences
On Wed, Aug 1, 2012 at 2:50 PM, Anders Broman anders.bro...@ericsson.com wrote: Is it worth it when you can just resave your preferences? The user may have several profiles with different settings, and will have to update all profiles with new settings again. I think we should try preserving the preferences instead of giving warnings. We also mark removed dissector preferences (prefs_register_obsolete_preference) and protocols (prefs_register_protocol_obsolete) as obsolete. -- Stig Bjørlykke ___ 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] Warnings when loading preferences
On Wed, Aug 1, 2012 at 3:29 PM, mman...@netscape.net wrote: Technically the prefences aren't obsolete, they are just renamed for (internally) optimized code. We already handle a lot of renamed preferences in set_pref(). -- Stig Bjørlykke ___ 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] Warnings when loading preferences
On Wed, Aug 1, 2012 at 3:38 PM, Anders Broman anders.bro...@ericsson.com wrote: And as a consequence we have a few of these cluttering up the code, should those live forever or Can the be removed after a suitable amount of time? We should at least support one major upgrade :) -- Stig Bjørlykke ___ 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 41242: /trunk/ /trunk/ui/gtk/: edit_packet_comment_dlg.c edit_packet_comment_dlg.h main_statusbar.c /trunk/: file.c file.h summary.c /trunk/wiretap/: wtap.c
On Wed, Feb 29, 2012 at 5:51 PM, etx...@wireshark.org wrote: Help with a different color LED possibly with Jeff's (c) in it apreceated. Should the LED be placed elsewhere or the whole thing done differently? Some ideas: - What about a document-with-a-pen icon, with different color when having comments? Or maybe a post-it-note icon? - What about displaying a list of comments, both the capture comment and all packet comments in one window? Just like we have for the expert info list. This way it's easy to see all comments in one capture file. - What about having a severity for each packet comment, with a matching color? Some notes are important while some are just for info or clarification. -- Stig Bjørlykke ___ 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] dumpcap does not recognize option -t (usethreads)
Hi. I committed a corrected fix in revision 39775. Joerg: did your grep ever finish? ;) -- Stig Bjørlykke ___ 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] Making threads mandatory
On Mon, Nov 7, 2011 at 9:13 PM, Gerald Combs ger...@wireshark.org wrote: Is there any reason we shouldn't remove the thread options from configure.in and CMakeOptions.txt along with USE_THREADS and hard-code thread support? Sounds reasonable to me. -- Stig Bjørlykke ___ 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] Ordinary LUA dissector.
On Fri, Nov 4, 2011 at 5:16 AM, Robert G. Jakabosky bo...@sharedrealm.com wrote: Also for people that want to make Lua dissectors may want to checkout this patch that I submitted: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5575 Please note that I have added some requests for you regarding this patch. -- Stig Bjørlykke ___ 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 1.6.3 won't run without threads support
On Thu, Nov 3, 2011 at 10:46 PM, Gerald Combs ger...@wireshark.org wrote: Weird. Are you using autotools or CMake? According to config.log and otool -L on my machine Wireshark is linked with libgthread even though I haven't explicitly enabled threads. On the machine it fails I'm using autotools and GLib 2.22.2 (and other older libraries). I works with GLib 2.28.8 and other updated libraries. Wireshark is linked with libgthread on both machines. But g_mutex_new() requires g_thread_init() so if we don't init I suppose someone else does? -- Stig Bjørlykke ___ 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] Wireshark 1.6.3 won't run without threads support
Hi. I get an error when trying to start wireshark 1.6.3 (default built without threads): GLib-ERROR **: The thread system is not yet initialized. This is because we call g_mutex_new() without a USE_THREADS guard in main_welcome.c. This was fixed in revision 38045 on trunk, but not back ported to 1.6.3. According to the GLib documentation g_mutex_new() will abort if g_thread_init() has not been called. I have tried installing the binary from the buildbot but that version does work, even without threads support. Can this be because some thirdparty libs already have initialized threads for us? Or do I miss something? -- Stig Bjørlykke ___ 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] Is tcp.len -1 a valid display filter?
On Thu, Oct 27, 2011 at 9:12 PM, Stephen Fisher st...@stephen-fisher.com wrote: Is there a problem with accepting -1 in that filter? It's not a problem, but it's a bug in the logic because the filter does not do what it's supposed to. If so, should the filter be checked against possible values of the value, i.e. tcp.len is a FT_UINT32 so only accept unsigned 32-bit values and mark the background as red / bad filter if not? The previously attached patch does check for signed/unsigned issues, and will mark the filter as bad/red. I think it would be nice to check all values if they are valid for the given field. -- Stig Bjørlykke ___ 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] Is tcp.len -1 a valid display filter?
On Fri, Oct 28, 2011 at 7:06 PM, Stephen Fisher st...@stephen-fisher.com wrote: On Fri, Oct 28, 2011 at 09:00:59AM +0200, Stig Bjørlykke wrote: The previously attached patch does check for signed/unsigned issues, and will mark the filter as bad/red. I think it would be nice to check all values if they are valid for the given field. Good idea. I wonder how much work that would be... never thought of that. It's pretty simple to do in ftype-integer.c (I already have the code), but we will get an error message from mk_fvalue_from_val_string() stating that hfinfo-abbrev cannot accept strings as values because we indicate an error when converting the value. I'm not sure how we can avoid this yet. The checks will introduce more conversions from string to integer, but that may not be an issue? -- Stig Bjørlykke ___ 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] Is tcp.len -1 a valid display filter?
Hi. On a 32-bit system the display filter tcp.len -1 seems to be valid, and does return all TCP packets. This happens because we use strtoul() to convert the string -1 to a unsigned long, and the documentation states that the string is converted to an unsigned long value in the obvious manner. I suppose this means that the value is casted from signed to unsigned without a warning. The attached patch fixes this, but can we do this check in a simpler manner? -- Stig Bjørlykke signed-unsigned-integer.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] [Wireshark-commits] rev 39559: /trunk/epan/ /trunk/epan/: proto.c
On Tue, Oct 25, 2011 at 6:21 PM, Guy Harris g...@alum.mit.edu wrote: Log: Allow signed integers displayed as DEC_HEX. So should a 32-bit -1 be displayed as 0x or -0x1? I was thinking more like -1 (0x), which would be the case for DEC_HEX. -- Stig Bjørlykke ___ 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 39559: /trunk/epan/ /trunk/epan/: proto.c
On Tue, Oct 25, 2011 at 6:48 PM, Guy Harris g...@alum.mit.edu wrote: On Oct 25, 2011, at 9:40 AM, Stig Bjørlykke wrote: I was thinking more like -1 (0x), which would be the case for DEC_HEX. That's BASE_DEC_HEX; if that's what they wanted, that's what they should have specified. Yes. And that's what I enabled in this commit. But now I don't understand the question... -- Stig Bjørlykke ___ 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 39559: /trunk/epan/ /trunk/epan/: proto.c
On Tue, Oct 25, 2011 at 7:56 PM, Guy Harris g...@alum.mit.edu wrote: We should probably allow BASE_HEX_DEC as well. I was thinking about it. It may make as much sense as allowing BASE_DEC_HEX. -- Stig Bjørlykke ___ 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 39559: /trunk/epan/ /trunk/epan/: proto.c
On Tue, Oct 25, 2011 at 8:43 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: If that's done we may as well let in BASE_HEX and BASE_OCT too. Do you think? This would abandon the sign on negative values, and may not be what the user expects? -- Stig Bjørlykke ___ 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 39495: /trunk/ /trunk/gtk/: capture_dlg.c capture_dlg.h capture_if_dlg.c capture_if_dlg.h main.c main.h main_welcome.c main_welcome.h prefs_capture.c /trunk
On Thu, Oct 20, 2011 at 8:17 PM, tue...@wireshark.org wrote: Log: This patch does not provide any new functionality, [...] Try hiding the first interface in the interface list and double click an interface in the welcome page or in the capture options. I get Edit Interface Settings for a wrong interface. -- Stig Bjørlykke ___ 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] FW: [Wireshark-commits] buildbot failure in Wireshark (development) on Ubuntu-10.04-x64
On Mon, Oct 10, 2011 at 10:45 AM, Anders Broman anders.bro...@ericsson.com wrote: Could some one try this patch? Committed in revision 39334. -- Stig Bjørlykke ___ 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 39318: /trunk/epan/ /trunk/epan/: filesystem.c
On Sun, Oct 9, 2011 at 6:28 PM, Guy Harris g...@alum.mit.edu wrote: Code that calls file_exists() should have detected the null pointer before that, and reported the appropriate error to the user or chosen a default file name or whatever would be appropriate in that case; what code was passing a null pointer to file_exists()? I found that file_exists() returned true for a NULL pointer, so i added the test for NULL while adding some changes in uat_get_actual_filename(). I could have checked the file name before calling file_exists(), but figured out that adding the test for NULL could not do any harm. -- Stig Bjørlykke ___ 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 39280: /trunk/ /trunk/epan/dissectors/: packet-ipv6.c /trunk/docbook/: release-notes.xml /trunk/epan/: geoip_db.c geoip_db.h libwireshark.def /trunk/gtk/: h
On Thu, Oct 6, 2011 at 12:27 AM, ger...@wireshark.org wrote: Add GeoIP IPv6 database support. Tested with GeoIP 1.4.7, but older versions *should* be supported. My GeoIP 1.4.7 does not have GEOIP_NETSPEED_EDITION_V6, but it does have all the others. -- Stig Bjørlykke ___ 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 dissectors implementation with LUA
On Sat, Oct 1, 2011 at 10:59 AM, Helge Kruse helge.kruse-nos...@gmx.net wrote: Where do I find good samples or tutorials to get a glimpse of Lua dissectors? You can have a look at this presentation: http://sharkfest.wireshark.org/sharkfest.09/DT06_Bjorlykke_Lua%20Scripting%20in%20Wireshark.pdf -- Stig Bjørlykke ___ 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 39149: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-daap.c packet-dcp-etsi.c packet-dec-bpdu.c packet-dec-dnart.c packet-dhcp-failover.c packet-d
On Mon, Sep 26, 2011 at 4:51 PM, etx...@wireshark.org wrote: Log: Get rid of check_col, while at it set ENC. Directory: /trunk/epan/dissectors/ Changes Path Action +35 -37 packet-dmp.c Modified The remaining check_col in packet-dmp.c was left on purpose, because we do not need this calculations if not having COL_INFO. Should we really remove all occurrences of check_col? -- Stig Bjørlykke ___ 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 38937: / /trunk/epan/: CMakeLists.txt Makefile.common filter_expressions.c filter_expressions.h libwireshark.def prefs.c prefs.h /trunk/gtk/: CMakeLists.txt
I did not intend to commit changes in services. Do we need to execute make-services.pl during a regular build? -- Stig Bjørlykke ___ 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] Built-in dissector depends on a plugin dissector in 1.6.x
I think we have an issue in 1.6.x where the built-in dissector opensafety depends on the plugin dissector sercosiii. In packet.c:heur_dissector_add() we crash (assert) if the dissector does not exist, and the plugin sercosiii may not exist. This problem is fixed in trunk where sercosiii is changed to be a built-in dissector. -- Stig Bjørlykke ___ 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] RFC: Add fallback path to get_datafile_dir
On Mon, Aug 29, 2011 at 8:48 PM, Joerg Mayer jma...@loplof.de wrote: I think I haven't built Wireshark in tree for a few years. Are you able to build docbook out of tree? -- Stig Bjørlykke ___ 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] Win buildbot
Hi, Anyone able to help with the win32/win64 build problems? -- Stig Bjørlykke ___ 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] Win buildbot
On Wed, Aug 31, 2011 at 1:22 PM, Anders Broman anders.bro...@ericsson.com wrote: Should we use function calls instead of macros accesing local data structures? Good idea, I'll try that. -- Stig Bjørlykke ___ 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] Win buildbot
On Wed, Aug 31, 2011 at 2:14 PM, Andreas andreassand...@gmx.net wrote: There are buildbot reports failure reports on several platforms today. So I assume you refer to an older build, don't you? For which buildot failure report you would like to get support? I think we have figured out the build problems for now. -- Stig Bjørlykke ___ 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 38800: /trunk/ /trunk/epan/crc/: Makefile.am Makefile.common Makefile.nmake crc-16-plain.c crc-16-plain.h /trunk/epan/crypt/: airpdcap.c airpdcap_wep.c /tru
I have reverted the crc move for now. I have to split the crc files into crc and crc_tvb routines, I think. -- Stig Bjørlykke ___ 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 38673: /trunk/gtk/ /trunk/gtk/: io_stat.c
On Mon, Aug 22, 2011 at 4:22 PM, etx...@wireshark.org wrote: Log: From Akos Lukovics: Calculate moving averages in IO Graphs. I don't really like the placement of the filter combobox in the GUI. We don't have the standard 6 pixel border in the IO Graph because we want the window to be as small as possible, and the filter expands the window size. And we get a large unused area below the Graph controls which does not look nice. We only have one filter, called M.avg, which does not tell me anything what it does. We need some clarification in the GUI, and this feature needs to be documented in the user guide. It seems like a bug in the calculation of the leftmost values. Try having a large capture (or set a small tick interval) to get a scrollbar. When scrolling the graph the graph changes, which makes it non reliable. The filtered data has to be calculated for the whole data set, not only the displayed ones. -- Stig Bjørlykke ___ 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] Remove support for libpcre?
Hi, Now that we require GLib 2.14 (which includes GRegex) we don't need libpcre. Should we remove the support for libpcre completely? -- Stig Bjørlykke ___ 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] Complete the switch to UIManager driven menubar?
On Tue, Aug 23, 2011 at 10:19 AM, Anders Broman anders.bro...@ericsson.com wrote: I think all menus work now with MAIN_MENU_USE_UIMANAGER, LUA? The Lua menus are not available due to issues in funnel_stat.c -- Stig Bjørlykke ___ 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 38640: /trunk/ /trunk/epan/: enterprise-numbers /trunk/: manuf services
On Sun, Aug 21, 2011 at 4:04 PM, ger...@wireshark.org wrote: Directory: /trunk/ Changes Path Action +104602 -17320 services Modified Whops, IANA changed the file format. -- Stig Bjørlykke ___ 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] gtk/capture_dlg.h
On Sat, Aug 20, 2011 at 9:22 PM, Gisle Vanem gva...@broadpark.no wrote: Building w/o HAVE_PCAP_REMOTE or HAVE_PCAP_SETSAMPLING, I got this error from MSVC: What about the attached patch? -- Stig Bjørlykke have-pcap-remote.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] [Patch] wsutil/file_util.c
On Wed, Aug 17, 2011 at 9:40 PM, Gisle Vanem gva...@broadpark.no wrote: Here is another patch for a missing WINAPI: Committed r38592. -- Stig Bjørlykke ___ 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] localtime_r() in gtk/timeshift_dlg.c
On Tue, Aug 16, 2011 at 12:17 AM, Gisle Vanem gisle.va...@gmail.com wrote: This: #ifdef _MSC_VER #define localtime_r(a, b) memcpy((b), localtime((a)), sizeof(struct tm)); #endif doesn't look so safe. We should maybe use the localtime_r() in wsutil/strptime.c? Or simply just use localtime, check the return value and then copy the values. Like in revision 38569. -- Stig Bjørlykke ___ 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 38522: /trunk/gtk/ /trunk/gtk/: capture_dlg.c
On Sun, Aug 14, 2011 at 1:03 PM, Michael Tüxen michael.tue...@lurchi.franken.de 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 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] Time shift patch causes compile error
On Sun, Aug 14, 2011 at 12:34 AM, Joerg Mayer jma...@loplof.de wrote: At least when compiling with UI_MANAGER set, I get the following compile error: Should be fixed in revision 38523. Other issues with Time Shift should be put in bug 6179: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6179 -- Stig Bjørlykke ___ 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 38522: /trunk/gtk/ /trunk/gtk/: capture_dlg.c
On Sun, Aug 14, 2011 at 1:34 AM, g...@wireshark.org wrote: Log: Don't map no interfaces to none and then back to an empty string; just map it to an empty string. Try opening Capture Options a second time, and none is back in the list. -- Stig Bjørlykke ___ 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 38522: /trunk/gtk/ /trunk/gtk/: capture_dlg.c
On Sun, Aug 14, 2011 at 12:42 PM, Michael Tüxen michael.tue...@lurchi.franken.de wrote: On Aug 14, 2011, at 11:27 AM, Stig Bjørlykke wrote: Try opening Capture Options a second time, and none is back in the list. Is that still true in the current version? I can't reproduce that... Fixed with the addresses count change. -- Stig Bjørlykke ___ 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] Time shift patch causes compile error
On Sun, Aug 14, 2011 at 3:11 PM, Martin Kaiser li...@kaiser.cx wrote: 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 don't know this code, or truncl() vs. floorl(), but maybe we just should use floorl() on all platforms? Then we at least get the same behavior. -- Stig Bjørlykke ___ 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] Time shift patch causes compile error
On Sun, Aug 14, 2011 at 8:34 PM, Martin Kaiser li...@kaiser.cx wrote: floorl() may be the better choice... I've fixed this in revision 38536. We should fix this anyway, to avoid using different functions on different platforms. -- Stig Bjørlykke ___ 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 37487: / /trunk/epan/dissectors/: Makefile.common packet-opensafety.c /trunk/epan/: CMakeLists.txt /trunk/: AUTHORS
On Tue, May 31, 2011 at 9:31 PM, g...@wireshark.org wrote:
Log:
From Roland Knall: openSAFETY dissector.
In packet-opensafety.c I find this code:
/* pinfo is NULL only if dissect_opensafety_message is called from
dissect_error cause */
if (pinfo)
{
col_set_str(pinfo-cinfo, COL_PROTOCOL, protocolName);
col_clear(pinfo-cinfo,COL_INFO);
}
Coverity complains (in CID 1246) that some other functions will fail
(dereferences it) if pinfo == NULL.
Is this comment still valid? If so I think we have to rewrite the
code som pinfo never is NULL.
--
Stig Bjørlykke
___
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 38515: /trunk/gtk/ /trunk/gtk/: capture_dlg.c capture_if_dlg.c
On Sat, Aug 13, 2011 at 9:21 PM, g...@wireshark.org wrote: Log: Say none rather than unknown if there are no IP addresses; in most if not all cases, it's not that we don't know the IP addresses, it's that there are no IP addresses to know. What about displaying nothing in the interface list, and none in the details? Like in the attached patch. BTW, why do we build the same string (b%s/b\nspan size='small'%s/span) 4 different places? -- Stig Bjørlykke interface-list-no-none.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] Compiling Wireshark for Win32
On Wed, Aug 10, 2011 at 6:18 PM, news.gmane.com andreassand...@gmx.net wrote: I am a bit surprised about a problem with compiling Wireshark 1.6.0 with Visual Studio 2005 for Win32. Why do you build 1.6.0 when we have released 1.6.1? The issues you have are fixed in 1.6.1. -- Stig Bjørlykke ___ 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 38350: /trunk/ /trunk/gtk/: capture_dlg.c capture_dlg.h capture_if_dlg.c capture_if_dlg.h main_welcome.c main_welcome.h menus.c menus.h /trunk/: capture.c c
On Sun, Aug 7, 2011 at 11:24 PM, Guy Harris g...@alum.mit.edu wrote: On Aug 7, 2011, at 2:00 PM, Stig Bjørlykke wrote: * Capture all in promiscuous mode can be checked even if not all interfaces have this. There is no API in libpcap to inquire whether an interface supports promiscuous mode; before Michael and Irene's changes, Capture in promiscuous mode could be checked regardless of whether promiscuous mode actually works. Hmm, I have to rephrase this issue. This is what I really wanted to say: * The global Capture all in promiscuous mode can be checked even if some interfaces have promiscuous mode turned off. I think the global checkbox should be turned off if some of the interfaces has promiscuous mode turned off. -- Stig Bjørlykke ___ 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 38350: /trunk/ /trunk/gtk/: capture_dlg.c capture_dlg.h capture_if_dlg.c capture_if_dlg.h main_welcome.c main_welcome.h menus.c menus.h /trunk/: capture.c c
On Fri, Aug 5, 2011 at 11:05 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: thank you... Comments are really welcome. The easiest part is to report the bugs :) * Multiple IP addresses should be separated with comma in the Edit Interfaces Settings window, I think. Need to see how this haves with a lot of addresses. If not separated by comma I think we should align the addresses below each other. Right now they are aligned with Interface: and IP address. * Should we use only one line in headings used in the interface list? This to save space for more interfaces in the list. I wanted to see all IP-addresses, but showing only one line would save space. Not sure. I was thinking about the headers, not the entries. Shorten the heading names and adding tooltips could be a solution. * The Wireless Settings button is not always enabled for my AirPcap device, and is sometimes enabled for my Ethernet device. We don't have AirPcap devices and that support is most likely broken. I can have a look at the code changes. And something not related to this: * My AirPcap device lists unknown as IP address. Should this simply be removed? Do we know if devices don't have an IP address? Not sure. Maybe not showing unknown is the same as showing no addresses. I think we should not show anything if we know the device has no IP address, but I don't know if we know. * Capture packets in monitor mode is enabled for devices not supporting this. If there is a way to figure out if it is supported, we should handle that correctly, I agree. The old code used to work. While looking at the new code I find something which makes me think something is obvious broken: row.monitor_mode = caps-can_set_rfmon; row.monitor_mode is true if monitor mode is turned on. caps-can_set_rfmon is true if the interface supports monitor mode. * When manually selecting all interfaces in the list, should the checkbox Capture on all interfaces be automatically checked? Hmm. Not sure. Does this help? This would required counting. But it could be done. It would be more user friendly, as it leads to an inconsistent state. * I get wrong link-layer for some of my remote (rpcap) devices. This used to work before. Hmm. This needs to be fixed. Can you provide some hints what is going wrong? We haven't seen this in our testing. I'm starting rpcapd on the same machine and use 'localhost' as host. I'll have a closer look to see if I can find more clues. And I have some more issues: * The welcome page is not refreshed after change in interface options preferences (changing description etc.) * The Start button is sometimes disabled even when selected an interface, and sometimes enabled even when no interfaces are selected. Try this to observe the issue: Select Capture Options from the welcome page, turn on Capture on all interfaces and turn off Capture on all interfaces again, then select capture for a simple interface. * Capture all in promiscuous mode can be checked even if not all interfaces have this. The checkbox should be un-toggled. * Tooltips for ok button in Edit Interfaces Settings is wrong, it does not start a capture process. -- Stig Bjørlykke ___ 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 38350: /trunk/ /trunk/gtk/: capture_dlg.c capture_dlg.h capture_if_dlg.c capture_if_dlg.h main_welcome.c main_welcome.h menus.c menus.h /trunk/: capture.c c
On Fri, Aug 5, 2011 at 9:19 AM, tue...@wireshark.org wrote: Log: Add support for multiple interfaces to the capture options dialog. Really nice! Some initial comments after short time testing: * The Edit Interfaces Settings should default to the OK button when pressing enter in Capture filter and any other widget. * Enlarging the Capture Options window should only enlarge the interfaces table and not put space anywhere else. * Multiple IP addresses should be separated with comma in the Edit Interfaces Settings window, I think. * Should we use only one line in headings used in the interface list? This to save space for more interfaces in the list. * The Wireless Settings button is not always enabled for my AirPcap device, and is sometimes enabled for my Ethernet device. * Maybe we should have a Remove Remote Interfaces button? * We no longer have a list of previous used remote servers (with settings) And something not related to this: * My AirPcap device lists unknown as IP address. Should this simply be removed? Do we know if devices don't have an IP address? -- Stig Bjørlykke ___ 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
