Re: [Wireshark-dev] GtkCritical On Fedora Linux referencinggtk_toolbar_set_style...
Hi, Can you try revision 30185 and see if it has any side effects. Regards Anders -Ursprungligt meddelande- Från: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] För Bill Meier Skickat: den 28 september 2009 03:14 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] GtkCritical On Fedora Linux referencinggtk_toolbar_set_style... Anders: I'm getting the following running Wireshark on Fedora Linux after a build from a recent SVN. (lt-wireshark:8501): Gtk-CRITICAL **: gtk_toolbar_set_style: assertion `GTK_IS_TOOLBAR (toolbar)' Might this be related to SVN #30136. I didn't see anything obvious during a quick inspection of the code Bill ___ 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 ___ 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] GtkCritical On Fedora Linux referencinggtk_toolbar_set_style...
Anders Broman wrote: Hi, Can you try revision 30185 and see if it has any side effects. Regards Anders AFAIKT it works AOK: No more Gtk-Critical message and changing the filter toolbar style still works; (I tested both with and without the Filter Toolbar being visible). Bill ___ 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] Modifying the Decode of Previous Packets
All- I have developed many dissectors, but have not run up against this problem before. I am looking for a solution that will work inside a plugin dissector. The issue is that I have some secure traffic that I cannot decode until I learn some state that is only periodically advertised. This means that during the first pass through the packets that I will fail to decode many packets, but that by the end of the first pass I will have (likely) learned enough to decode the previous packets. I believe (and will shortly test) that any secondary decodes (as clicking on the undecoded packet) will magically cause the column info to update and the packet to display decoded (assuming that my learned state is associated with my conversation, which it is). My question is whether it is possible to indicate to Wireshark that certain packets (or, worst case, all packets) should be rechecked. If it is only the all packets case I would likely not do anything (as I deal with large capture files). If selected packets could be redone then that might be interesting, as I know which packets are mine and if I learn later that I can decode them then I would know the frame numbers to re-parse. Thoughts? Thanks. -Bryant Panasonic Electric Works Laboratory of America - SLC Lab 4525 So. Wasatch Blvd., Suite 100, 84124 Salt Lake City, UT 84124 T 801.993.7124 F 801.993.7260 beast...@pewla.us.pewg.pansonic.com Bryant Eastham Chief Architect ***CONFIDENTIALITY NOTICE***: This e-mail and any attachments may contain information which is confidential, proprietary, trade secret, privileged or otherwise protected by law. The information is the property of Panasonic Electric Works Laboratory of America, Inc., and is solely intended for the named addressee (or a person responsible or delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender and the Office of General Counsel at generalcoun...@us.pewg.panasonic.com mailto:generalcoun...@us.pewg.panasonic.com immediately by return e-mail and delete it from your computer. image001.gifimage003.gifimage004.pngimage005.png___ 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] switch statement in proto_register
What is the preferred method for supporting multiple versions of a protocol within a dissector? I have setup a protocol preference and was using that in a switch statement structure but the proto_register function doesn't seem to like the switch statement. Dissect_ doesn't might the switch statement and that part seems to be working but the dissector complains with the switch statement in proto_register. Ideas? Thoughts? Thank you ___ 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] Modifying the Decode of Previous Packets
Hi, Le lundi 28 septembre 2009 à 14:20 -0600, Bryant Eastham a écrit : All- I have developed many dissectors, but have not run up against this problem before. I am looking for a solution that will work inside a plugin dissector. The issue is that I have some secure traffic that I cannot decode until I learn some state that is only periodically advertised. This means that during the first pass through the packets that I will fail to decode many packets, but that by the end of the first pass I will have (likely) learned enough to decode the previous packets. I believe (and will shortly test) that any secondary decodes (as clicking on the undecoded packet) will magically cause the column info to update and the packet to display decoded (assuming that my learned With the 'old packet list' clicking on an undecoded packet will not update the column info, only filtering will do. With the new packet_list (SVN current) the column is only updated once. If you load a file it works, for live capture some packets may have the wrong column info. The tree would be ok though, it's redissected each time. state is associated with my conversation, which it is). I think it only works if you aren't using the new decoded state for desegmentation. It may have some other weird side effects if you're calling sub dissectors. My question is whether it is possible to indicate to Wireshark that certain packets (or, worst case, all packets) should be rechecked. If it is only the “all packets” case I would likely not do anything (as I deal with large capture files). If selected packets could be redone then that might be interesting, as I know which packets are “mine” and if I learn later that I can decode them then I would know the frame numbers to re-parse. Currently it's not possible. Didier ___ 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] switch statement in proto_register
Hi, See packet-m2pa.c for an example. Thanx, Jaap Cole, Richard L. (MSFC-ES53)[MTSI] wrote: What is the preferred method for supporting multiple versions of a protocol within a dissector? I have setup a protocol preference and was using that in a switch statement structure but the proto_register function doesn't seem to like the switch statement. Dissect_ doesn't might the switch statement and that part seems to be working but the dissector complains with the switch statement in proto_register. Ideas? Thoughts? Thank you ___ 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
