Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h
2013/10/14 didier > Hi, > Le dimanche 13 octobre 2013 à 16:43 -0400, Evan Huus a écrit : > > On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki > > wrote: > > > About tvb_offset_exists() comment, compute_offset() is not returning > > > exception when offset == tvb->length. > > > > Ah, OK. Should it? When offset == tvb->length I would think that > > should be an exception, since no bytes exist at that location. There > > are other places that call compute_offset and don't check the == case > > that maybe should... > On the other hand is doing parsing with tree NULL and flags.visited > false or colinfo not null worth it? There's so many bugs, Personally I > gave up on it. > > One example with tshark, without a tree tcp flags aren't set anymore in > colinfo (cf packet-tcp.c around line 4228, since > dfa2156e301539929a12dda54752c778c3ee7a39 remove 'check_colinfo') > and so on... > Hi Didier, this is fixed in r52597. If you spotted other regressions, please notify us. Thanks! Pascal. ___ 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] Status Cmake Win32 support
On Sat, Oct 12, 2013 at 1:22 AM, Joerg Mayer wrote: > On Fri, Oct 11, 2013 at 03:48:32PM -0700, Gerald Combs wrote: > > > - qtshark on win *requires* that gtk includes are present to build: > > > file_dlg_win32.c:#include > > > > This should be fixed in r52542-52545. > > Wow, that was fast! > > > > - Determine what else is missing to get rid of the old nmake > infrastucture > > > > The NSIS and PortableApps packaging depends on nmake. > > I still have to look at cpack for packaging, but getting it to build a > source > package was "trivial" when I tried that some years ago - of course not so > trivial > that I would be able to reproduce it within half an hour... > cpack has an NSIS module by the way - but I never packaged more than > source. > May also look Wix ? (to replace NSIS...) > > > > - Other build platforms (there seems to be at least some interest in > VS). > > > > Xcode? > > If someone uses and knows Xcode and wants to work on this: Sure. > > Ciao > Jörg > > > -- > Joerg Mayer > We are stuck with technology when what we really want is just stuff that > works. Some say that should read Microsoft instead of technology. > ___ > 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] Idea for process image dissection
Hi, On Sun, Oct 13, 2013 at 10:17:45AM +0200, Roland Knall wrote: > I just wanted to bring something by you guys, if it would be worth > implementing. > > I work on the openSAFETY and EPL dissectors. Both are fieldbus > specific implementations. As such the communicate process images as > payloads. This is the same with nearly all other fieldbus > implementations i know (CanOpen, Profinet, SercosIII, ...). > > As such, to a unknown user this displays simply as a byte payload. Now > it may be useful, to dissect the payload in some cases, as such we may > be able to search for specific fields triggering in the payload. > > For such a dissection, we need to tell a dissector, how to dissect a > specific payload. Have you checked decode as dialog implementation? If you want to make it generic great for me. ___ 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] Idea for process image dissection
On Oct 13, 2013, at 1:17 AM, Roland Knall wrote: > For such a dissection, we need to tell a dissector, how to dissect a > specific payload. > > I would like to implement a new field type (FT_PIMAGE) and allow the > user using a dialog, to specify a filter and a mapping to dissect the > field. Would the payload consist either of one big FT_PIMAGE field or a sequence of nothing but FT_PIMAGE fields? If so, then... > For instance one definition might be: ...another definition might be http://wsgd.free.fr if the goal is to avoid requiring C/C++ code to be written to dissect the payload. Adding a UI to allow construction of wsgd descriptions would be useful here. > The definition for each field mapping must be also session specific, > as it will definitely change between dissections. Multiple registered wsgd descriptions, and a session-specific selection of a description, should handle that. ___ 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] r52604: Adding to col info is probably useless as next dissector will overwrite it.
Hi Anders, Please revert it, dissectors after vlan can be disabled. If we want to have some lazy COL_INFO calculation - that's fine for me, but selectively disabling col_add_fstr is NACK for me. Cheers, Jakub. ___ 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] r52604: Adding to col info is probably useless as next dissector will overwrite it.
Jakub Zawadzki skrev 2013-10-14 21:26: Hi Anders, Please revert it, dissectors after vlan can be disabled. Done in revision 52608 even tough I don't think the entry is useful. If we want to have some lazy COL_INFO calculation - that's fine for me, but selectively disabling col_add_fstr is NACK for me. Cheers, Jakub. ___ 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] [Wireshark-commits] rev 52608: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-vlan.c
Why not add a fence so it's always visible then? -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of etx...@wireshark.org Sent: Monday, October 14, 2013 5:51 PM To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 52608: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-vlan.c http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52608 User: etxrab Date: 2013/10/14 09:50 PM Log: Reverting as requested by Jakub, eventhoug I don't think this prticular entry is useful as it's duplicated in the tree and almost certanly never vissible. Directory: /trunk/epan/dissectors/ ChangesPath Action +0 -3 packet-vlan.cModified -- CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your system and notify the sender by replying to this email. Thank you. ___ 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 52607: /trunk/ui/qt/ /trunk/ui/qt/: follow_stream_dialog.cpp follow_stream_dialog.h follow_stream_dialog.ui main_window_slots.cpp
On Oct 14, 2013, at 2:17 PM, ger...@wireshark.org wrote: > Get rid of the group box -- the OS X and Windows HIGs > discourage its use and I'm not sure if it fits the GNOME HIG in this > case either. ...and there's another HIG at least as relevant to Qt applications, if not more so: http://techbase.kde.org/Projects/Usability/HIG/GroupBox The list * Always try to use a group box to arrange related controls. * Use a frame to arrange related controls that cannot be labeled. * Do not group single controls. * Consider to communicate relationship by layout only. from there seems to limit the places where group boxes should be used. ___ 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] follow_stream_dialog.cpp warning turning error
[ 71%] Building CXX object ui/qt/CMakeFiles/qtui.dir/follow_stream_dialog.cpp.o
/home/jmayer/work/wireshark/svn/trunk/ui/qt/follow_stream_dialog.cpp: In member
function ‘virtual void FollowStreamDialog::keyPressEvent(QKeyEvent*)’:
/home/jmayer/work/wireshark/svn/trunk/ui/qt/follow_stream_dialog.cpp:519:65:
error: suggest parentheses around ‘&&’ within ‘||’ [-Werror=parentheses]
if (event->key() == Qt::Key_F3 || event->key() == Qt::Key_N &&
event->modifiers() & Qt::ControlModifier) {
^
cc1plus: all warnings being treated as errors
make[2]: *** [ui/qt/CMakeFiles/qtui.dir/follow_stream_dialog.cpp.o] Error 1
make[1]: *** [ui/qt/CMakeFiles/qtui.dir/all] Error 2
--
Joerg Mayer
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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 52608: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-vlan.c
Maynard, Chris skrev 2013-10-15 00:47: Why not add a fence so it's always visible then? My point is that I don't want to write column info in the VLAN dissector to speed up dissection. If it could be arranged to only write the "last" entry that will actually be in the packet list or written out by tshark it would be much more efficient. One option is to only write to columns if next dissector isn't found in the cases where that is possible. In the reference trace I'm pursuing col_add_fstr() costs 7.52 is called 4,7 million times, where of 2.8 million times is from the VLAN dissector. Regards Anders -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of etx...@wireshark.org Sent: Monday, October 14, 2013 5:51 PM To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 52608: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-vlan.c http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52608 User: etxrab Date: 2013/10/14 09:50 PM Log: Reverting as requested by Jakub, eventhoug I don't think this prticular entry is useful as it's duplicated in the tree and almost certanly never vissible. Directory: /trunk/epan/dissectors/ ChangesPath Action +0 -3 packet-vlan.cModified ___ 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
