Re: [Wireshark-dev] RTP Player
Do we have a plan for the Qt equivalent of this UI? Yes. If nothing interested in port it, than I will do that. It is used for replay Bluetooth A2DP music. But I someone else want to do that please do generic player (component/class), because I have a plan to add player for next Bluetooth layer that is not over RTP - SCO. One thing that player in Wireshark is fine is you can go to frame around so position in stream (like choppy, delays, etc.) PS. I feel that I do not do that before next year. So I hope somebody port it. On 19 June 2014 03:22, Bálint Réczey bal...@balintreczey.hu wrote: 2014-06-18 18:07 GMT-07:00 Evan Huus eapa...@gmail.com: We have at least 30 bugs to do with RTP and the analysis/audio player: https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=rtp Do we have a plan for the Qt equivalent of this UI? Is it worth doing, or should we hand it off to the OS's media player (gstreamer or similar) or...? I would really like to WONTFIX a lot of these, unless somebody plans to spend any time fixing it... I think we did a great job in visiting/updating and sometimes even fixing many bugs in the las days, but we don't have a strong reason for reaching zero with the bug backlog. I like the concept that bugs are part of the documentation and having them open does not really hurt anyone. I think we are starting to cross the line where are closing bugs for the sake of having them closed instead of using them as (valid) reminders... All the users reporting those 30 bugs were interested in having the feature and we can't tell the number of users who did not open new bugs because they saw the open ones and went back to their jobs knowing that the problem they were facing will be fixed eventually. Cheers, Balint ___ 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 -- Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ 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] master 14824e6: Revert Fixup: tvb_* - tvb_captured
On Thu, Jun 19, 2014 at 9:18 PM, Evan Huus eapa...@gmail.com wrote: We were not bulk-converting them so that we could catch the ones that really should have been tvb_reported_length and tvb_reported_length_remaining from the beginning. If you look at the code in epan/tvbuff.h:228,237,244 you can find those defines #define tvb_length tvb_captured_length #define tvb_length_remaining tvb_captured_length_remaining #define tvb_ensure_length_remaining tvb_ensure_captured_length_remaining This means that tvb_length doesn't go to the compiler, since it's changed to tvb_captured_length by the preprocessor. What about a change that replaces only these? This should be safe. ___ 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] master 14824e6: Revert Fixup: tvb_* - tvb_captured
On 06/20/14 03:46, Dario Lombardo wrote: On Thu, Jun 19, 2014 at 9:18 PM, Evan Huus eapa...@gmail.com wrote: We were not bulk-converting them so that we could catch the ones that really should have been tvb_reported_length and tvb_reported_length_remaining from the beginning. If you look at the code in epan/tvbuff.h:228,237,244 you can find those defines #define tvb_length tvb_captured_length #define tvb_length_remaining tvb_captured_length_remaining #define tvb_ensure_length_remaining tvb_ensure_captured_length_remaining This means that tvb_length doesn't go to the compiler, since it's changed to tvb_captured_length by the preprocessor. What about a change that replaces only these? This should be safe. It's not a question of what gets to the compiler, it's a question of going through each one to make sure the dissector is using the one they really meant to use. IOW the reason these functions were renamed was because a large portion of the time dissector-writers would use tvb_length() when they really should have been using tvb_reported_length(). By renaming the functions and adding a macro--which is listed as deprecated by checkAPIs--for backwards compatibility we can know which calls have yet to be audited/checked for correctness. That is, the whole point is to *not* systematically replace tvb_length() but rather check each call and replace it with the correct one. ___ 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] RTP Player
On 06/18/14 21:07, Evan Huus wrote: We have at least 30 bugs to do with RTP and the analysis/audio player: https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=rtp Do we have a plan for the Qt equivalent of this UI? Is it worth doing, or should we hand it off to the OS's media player (gstreamer or similar) or...? My impression is that it is a very popular feature. I would guess that a port or equivalent functionality would be needed before dropping the Gtk UI (unless we want people sticking with 1.12 longer than otherwise necessary). I would really like to WONTFIX a lot of these, unless somebody plans to spend any time fixing it... Personally I'd suggest leaving them there until the *are* fixed: probably/hopefully with a Qt port or alternative. ___ 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] master 14824e6: Revert Fixup: tvb_* - tvb_captured
On Fri, Jun 20, 2014 at 4:33 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: IOW the reason these functions were renamed was because a large portion of the time dissector-writers would use tvb_length() when they really should have been using tvb_reported_length(). By renaming the functions and adding a macro--which is listed as deprecated by checkAPIs--for backwards compatibility we can know which calls have yet to be audited/checked for correctness. That is, the whole point is to *not* systematically replace tvb_length() but rather check each call and replace it with the correct one. Well, thank you, I've got the point now. ___ 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] Windows target OS
Currently the NMake and CMake Windows builds set the target OS version as Windows 2000 via the defines NTDDI_VERSION and _WIN32_WINNT. I would like to move these to at least XP, if not Vista. Changing these defines doesn't immediately prevent a current build running on Win2K but does allow us, in the future, to use newer Windows API functions that aren't present on Win2K, and if\when we do so, then that build won't run on Win2K. Comments? -- Graham Bloice ___ 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] Windows target OS
2014-06-20 18:35 GMT+02:00 Graham Bloice graham.blo...@trihedral.com: Currently the NMake and CMake Windows builds set the target OS version as Windows 2000 via the defines NTDDI_VERSION and _WIN32_WINNT. I would like to move these to at least XP, if not Vista. Changing these defines doesn't immediately prevent a current build running on Win2K but does allow us, in the future, to use newer Windows API functions that aren't present on Win2K, and if\when we do so, then that build won't run on Win2K. Comments? +1 for moving it to XP (1.12 and 1.99 still run on XP for now despite the warning during installation). Pascal. ___ 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] Windows target OS
On 6/20/14 9:35 AM, Graham Bloice wrote: Currently the NMake and CMake Windows builds set the target OS version as Windows 2000 via the defines NTDDI_VERSION and _WIN32_WINNT. I would like to move these to at least XP, if not Vista. Changing these defines doesn't immediately prevent a current build running on Win2K but does allow us, in the future, to use newer Windows API functions that aren't present on Win2K, and if\when we do so, then that build won't run on Win2K. No objections here (either XP or Vista). ___ 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] RTP Player
2014-06-20 7:38 GMT-07:00 Jeff Morriss jeff.morriss...@gmail.com: On 06/18/14 21:07, Evan Huus wrote: We have at least 30 bugs to do with RTP and the analysis/audio player: https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=rtp Do we have a plan for the Qt equivalent of this UI? Is it worth doing, or should we hand it off to the OS's media player (gstreamer or similar) or...? My impression is that it is a very popular feature. I would guess that a port or equivalent functionality would be needed before dropping the Gtk UI (unless we want people sticking with 1.12 longer than otherwise necessary). I would really like to WONTFIX a lot of these, unless somebody plans to spend any time fixing it... Personally I'd suggest leaving them there until the *are* fixed: probably/hopefully with a Qt port or alternative. +1 ___ 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] New contrib page for scripts, colouring rules, etc.
One of the things we discussed at Sharkfest this year was providing a common location for users to share their lua scripts, colouring rules, display filter macros, and other useful plugins. Discussion is still on-going as to whether we will provide a proper git repository or some other management site, but in the mean-time (and partly to judge the popularity of the idea) we've created a simple wiki page where people can upload their contributions: http://wiki.wireshark.org/Contrib If you have such useful items to contribute, please share them and make everyone's Wireshark experience better :) Cheers, Evan ___ 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
[Wireshark-dev] Deprecated APIs
Hi list I'm having a look at obsolete APIs and I've got those lines from checkAPI.pl Warning: Found soft-deprecated APIs in packet-bacapp.c: ep_address_to_str Warning: Found soft-deprecated APIs in packet-umts_fp.c: se_new0 but I can't find how those func should be changed. Can anyone help me? Dario ___ 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] Deprecated APIs
On Jun 17, 2014, at 9:09 AM, Dario Lombardo lom...@gmail.com wrote: Hi list I'm having a look at obsolete APIs and I've got those lines from checkAPI.pl Warning: Found soft-deprecated APIs in packet-bacapp.c: ep_address_to_str Warning: Found soft-deprecated APIs in packet-umts_fp.c: se_new0 but I can't find how those func should be changed. Can anyone help me? For ep_address_to_str(), you might want to ask the guy who contributed this change: commit 7fea55a0541bcc5059f767970b6f6291f81d7b9c Author: Dario Lombardo lom...@gmail.com Date: Wed Jun 18 12:18:58 2014 +0200 Fixup: ep_address_to_str - address_to_str Change-Id: Id49ba07e32a71357b50b32de7cecfd80e412d508 Reviewed-on: https://code.wireshark.org/review/2379 Reviewed-by: Anders Broman a.broma...@gmail.com ___ 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] Deprecated APIs
On Jun 20, 2014, at 6:24 PM, Guy Harris g...@alum.mit.edu wrote: On Jun 17, 2014, at 9:09 AM, Dario Lombardo lom...@gmail.com wrote: Hi list I'm having a look at obsolete APIs and I've got those lines from checkAPI.pl Warning: Found soft-deprecated APIs in packet-bacapp.c: ep_address_to_str Warning: Found soft-deprecated APIs in packet-umts_fp.c: se_new0 but I can't find how those func should be changed. Can anyone help me? For ep_address_to_str(), you might want to ask the guy who contributed this change: commit 7fea55a0541bcc5059f767970b6f6291f81d7b9c Author: Dario Lombardo lom...@gmail.com Date: Wed Jun 18 12:18:58 2014 +0200 Fixup: ep_address_to_str - address_to_str Change-Id: Id49ba07e32a71357b50b32de7cecfd80e412d508 Reviewed-on: https://code.wireshark.org/review/2379 Reviewed-by: Anders Broman a.broma...@gmail.com ...although note that the only places where it should be replaced by address_to_str(wmem_packet_scope(), ...) (as you did in that change) are places where it's called *when dissecting packets*. Not all routines in a packet-XXX.c file are called only when dissecting packets; most of your changes were reverted and then put back in, as they were safe, but some others were changed to use a scope of NULL, meaning must be manually freed, and to manually free the items when they're not needed. ___ 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
