Re: [Wireshark-dev] Wireshark code review
On Wed, Mar 25, 2015 at 09:15:52AM +0100, Dario Lombardo wrote: Since you now have 2 changes submitted, you should abandon one of them (do it from the web interface), then follow Alexis' suggestion about sqashing and amending, then push the final revision into the survived change (do it using the correct change-id, read it from the web interface again). I don't know what happens if one push a change-x from a branch b1, then push the same change-x from another branch b2. Maybe the latter overwrites the first in gerrit? Anyone tried it? It is a valid use to have the same change-id in different branches. It makes it possible to easily find backports that way, for example. If a change was posted to the wrong upstream branch in Gerrit, you will need to abandon that change and post it to the correct branch. Posting a patch with a change-id that is already in a different branch, will not overwrite/abandon the already existing patch. HTH, Niels On Wed, Mar 25, 2015 at 7:10 AM, Anil anilkumar...@gmail.com wrote: Hi All -- I have done a mistake with submitting code for review. My initial review is https://code.wireshark.org/review/#/c/7751 https://code.wireshark.org/review/#/c/7751/1/epan/dissectors/packet-nstrace.c I fixed the issues reported there and have checked in the new changes. The problem is that the new changes are in a different branch than the original one. So it has created a new review https://code.wireshark.org/review/#/c/7802/ I need some help about what can be done now ? --Anil ___ 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 ___ 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 ___ 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] Set capture to TZ blah?
On Fri, Mar 13, 2015 at 11:33:43AM -0700, Richard Sharpe wrote: Hi folks, Lots of people use Wireshark to help with problems around the world. Sometimes they have a capture from another timezone and a log file from that same timezone. The capture has time in UTC while the logs are most likely in local time and it can be hard to reconcile the two. Can we have something added to the View-Time Display Formt menu that allows us to specify the actual offset from UTC that the capture was made in so that time can be displayed in local time for that Time Zone. That way it will be easier to work with a capture and a log file. When I have captures and logs that do not match the timezone, I use the TZ environment variable to read the captures in the timezone of the logs, like: $ TZ=America/New_York tshark -r /path/to/capture.pcap.gz or $ TZ=America/New_York wireshark /path/to/capture.pcap.gz HTH, Niels ___ 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] Set capture to TZ blah?
On Sat, Mar 14, 2015 at 11:16:07AM -0700, Guy Harris wrote: On Mar 14, 2015, at 8:00 AM, Niels de Vos nde...@redhat.com wrote: When I have captures and logs that do not match the timezone, I use the TZ environment variable to read the captures in the timezone of the logs, like: $ TZ=America/New_York tshark -r /path/to/capture.pcap.gz or $ TZ=America/New_York wireshark /path/to/capture.pcap.gz That would work on systems using the IANA tz database (and using the new tz naming scheme; I'm not sure whether Solaris does), so it'd work on, at minimum, most if not all Linux distributions, *BSD, and OS X. However, it doesn't work on, for example, Windows, which doesn't use the IANA tz database. (That's why I suggested that we might want to incorporate the tz database in Wireshark.) Oh, yes indeed. Some people might still run an operating system that does not support that... Thanks, Niels ___ 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] Can we move to Lua 5.2.3 only?
On Wed, Apr 02, 2014 at 07:03:36PM -0400, Hadriel Kaplan wrote: On Apr 2, 2014, at 6:07 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: In that case I'd vote no: Redhat EL 6 comes with 5.1.4 and it probably has a long lifetime ahead of it. How hard/painful would it be to install Lua 5.2.x? (I don't know the answer - just asking) It's a tiny little library compared to most of Wireshark's others, fwiw. Probably not too hard--I know Lua's small. But most users (who just do yum install lua) won't get it so we'll be losing Lua for 99% of the RHEL6 users. Maybe it's not that big a deal but it's worth some thought… Sadly, I know nothing about yum and RHEL6 other than as being an occasional user of it. It looks like there are plenty of yum repositories with Lua 5.2.x, but not for RHEL6. How does one go about requesting an upgrade of that - enter a ticket in Redhat as customer? (is that like crazy wishful thinking? I don’t know anything about their policies for such things) With RHEL being an Enterprise distribution, RHEL6 will likely try to stay at lua-5.1 for as long as it can. Likely until RHEL6 goes end-of-life. If lua-5.2 is completely backwards compatible (nothing deprecated, no behavior changes), a customer can open a support ticket and request an update for lua. But, these kind of requests are not granted often or easily. That said, most RHEL users will likely install Wireshark from the standard RHEL repositories on Red Hat Network. Even Wireshark as a 'leaf' package (nothing depends on it) is expected to be mostly backwards compatible (UI, commandline parameters, ...) when a version update is done. Wireshark in RHEL-6.5 has been updated to version 1.8 (RHEL-6.4 came with 1.6, iirc), and I see that as something out of the ordinary. Users that prefer/need a newer version of Wireshark, are probably building the binaries or packages themselves. They should not have much difficulties with building a lua update too. Alternatively, if you’re running RHEL6, can you try this: curl -R -O http://www.lua.org/ftp/lua-5.2.3.tar.gz # or 'wget http://www.lua.org/ftp/lua-5.2.3.tar.gz' instead tar zxf lua-5.2.3.tar.gz cd lua-5.2.3 make linux test If that works (and it should in theory), maybe it won’t be too painful to just add that to the install instructions or even write up a simple script to do it? (...just trying to think of a solution...) That surely is one possible solution :) Thanks, Niels -- Niels de Vos Sr. Software Maintenance Engineer Support Engineering Group Red Hat Global Support Services ___ 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.8.1 crashes
On Thu, Jan 17, 2013 at 08:49:23PM +0800, Danniel_zeng wrote: Hello all, It seems that the wireshark 1.8.1 will crash when my capture have the CCP packtet. when I open the that packet ,it is ok to display at the beginning ,but it then crash while I scroll down .And I find out that the first packet when I scroll down is the CCP packet.I believe it is the CCP packet get it down. Besides,if I open that capture with wireshark1.6.7,it is ok all the time. What should I need to do for that? This might be an issue that we have seen in Wireshark on Fedora too. There seem to be some issues with 1.8.0 - 1.8.4 and GTK3. Re-compiling with GTK2 works fine. For reference: https://bugzilla.redhat.com/show_bug.cgi?id=871091 Someone was going to test a subversion build and verify if it has been fixed already. No results known for that yet. Steps to reproduce this (and the .pcap) are found in comment #18 of that bug. Cheers, Niels Thanks Kindly Regards ___ 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 -- Niels de Vos Sr. Software Maintenance Engineer Support Engineering Group Red Hat Global Support Services ___ 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] ui/qt directory installed with gtk version(1.8rc1)
On 06/15/2012 10:33 AM, 阿超 wrote: Hi ALL: How to Sign out the group ? See the bottom of this, or any other email to the list. thanks. ChenChao -- Original -- From: Bill Meierwme...@newsguy.com; Date: Fri, Jun 15, 2012 09:45 AM To: Developer support list for Wiresharkwireshark-dev@wireshark.org; Subject: Re: [Wireshark-dev] ui/qt directory installed with gtk version(1.8rc1) On 6/14/2012 10:55 AM, Petr Sumbera wrote: Hi, why do I have installed ui/qt directory with all png files when I built 1.8.rc1 with gtk? Thanks, Petr The ui/qt directory (and contents) is part of the source tarball (I'm assuming you built from the tarball). When you build with gtk, nothing is actually built from/in the ui/qt directory... ___ Sent via:Wireshark-dev mailing listwireshark-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 ___ Sent via:Wireshark-dev mailing listwireshark-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 -- Niels de Vos Software Maintenance Engineer Global Support Services Red Hat ___ 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] Regarding additing a new protocol
Hi Anand, the sources contain a very well written doc/README.developer text file. You have checked out the sources, so you should have it there. It is also readable online from the SVN repository: - http://anonsvn.wireshark.org/wireshark/trunk-1.6/doc/README.developer On http://www.wireshark.org/develop.html a paragraph explains what is needed in order to provide your dissector for inclusion into a new Wireshark release. Cheers, Niels On 05/10/2012 08:02 AM, Singh, Anand wrote: Hi all, Greeting of the day. I am new in wireshark development, can anyone help me how to add a new protocol handling in existing wireshark source. I have downloaded the source. Please let me know code tree I need to go through for enhancement for a new protocol handling. I have download release 1.6.7 build for Fadora linux. Regards Anand P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. ___ Sent via:Wireshark-dev mailing listwireshark-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 ___ 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] Some questions on RPC dissectors (for a new Gluster dissector)
On 04/24/2012 08:39 AM, Kaul wrote: On Fri, Apr 20, 2012 at 6:08 PM, Niels de Vosnde...@redhat.com wrote: Hi all, Bug 5773 was opened as an RFE for implementing a dissector for Gluster. The Gluster 'protocol' consists out of several RPC-programs, each with their own set of procedures. There are some questions I would like to ask: ...snip... 2) The Gluster protocols use RPC-credentials with number 5. This number is currently not dissected in packet-rpc.c, but I also doubt IANA assigned this number to the Gluster protocols. What would be the best way to add an implementation to dissect the credentials in the RPC-header? a) just dissect any number 5 flavour as Gluster-credentials Google around to see if others may have (ab)used this number as well. If not, I'd just dissect it as Gluster's - with a comment in the code explaining it is non registered to Gluster (and worth shooting an email to the gluster dev list asking if they intend to register it). Thanks for the response! Okay, so I could not find any references to any RPC protocol that implements AUTH-flavor '5' (AUTH_RSA). I've informed the Gluster developers that they can/should register RPC numbers (programs and AUTH-flavor) at IANA. Bug 7190 contains the changes need to dissect AUTH_RSA as the format used by Gluster. I appreciate feedback about those changes in the Bug. Thanks again, Niels ___ 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] Some questions on RPC dissectors (for a new Gluster dissector)
Hi all, Bug 5773 was opened as an RFE for implementing a dissector for Gluster. The Gluster 'protocol' consists out of several RPC-programs, each with their own set of procedures. There are some questions I would like to ask: 1) I am not sure what the best practice is to group these related RPC-programs. At the moment, I have a packet-gluster.c file (and a header) that registers proto_gluster with proto_register_protocol(). Each dissector for an RPC-program registers its header-field-array with this proto_gluster handle. Some of the RPC-programs have their own file, to the proto_gluster handle is made non-static and exported in the packet-gluster.h file. Is this something that I should rather not do, and create complete separate dissectors for each RPC-program? There are some header-fields that are the same for several RPC-programs, should these just be duplicated? (Currently these are non-static as well, and listed in the header file too.) If I can keep using this structure, how can I guarantee that the proto_gluster handle has been initialized when other dissectors try to use it with proto_register_field_array()? 2) The Gluster protocols use RPC-credentials with number 5. This number is currently not dissected in packet-rpc.c, but I also doubt IANA assigned this number to the Gluster protocols. What would be the best way to add an implementation to dissect the credentials in the RPC-header? a) just dissect any number 5 flavour as Gluster-credentials b) add a preference-option to the RPC-dissector c) detect the credential-flavour based on flavour+program number d) something else, please specify That's it for now. I'm happy to provide more details if that would clarify my questions. Many thanks, Niels ___ 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
