Re: [Wireshark-dev] Feedback about Multipath TCP support
On Sun, Dec 28, 2014 at 1:58 PM, Matt matta...@gmail.com wrote: Thanks for the comments. I will try to proceed as suggested by alexis via pushing to gerrit smaller (cleaned) patches. Waiting your patches ;-) I have a question about the rules one attribute I added should conform to. I've added a mptcp.stream attribute to dissection, similar to tcp.stream with the difference that currently attributed numbers can be disjoint (ie you have packets matching mptcp.stream == 0 or mptcp.stream == 3 but not packets for values 1,2 for instance) and I wonder if this is a problem (I believe it is) ? This is due to the fact that - according to my implementation - some TCP flows are first attributed an mptcp.stream as soon as wireshark sees an MPTCP option. When later on they are associated with another MPTCP connection, all tcp flows adopt/share the mptcp.stream of that connection (referring to the previous example, a TCP flow first got attributed mptcp.stream 1 while unassociated, then later it was associated to another TCP flow with mptcp.stream == 0, thus giving up mptcp.stream 1, for which there is now 0 packets). I don't see any easy to have the mptcp.stream in order except if: - I don't give numbers to unassociated mptcp streams (which is wrong in my opinion, they should still be considered as streams) - I attribute mptcp.stream to unassociated flows at the end of dissection (when last packet get parsed), but I don't know how to do it. TCP flows can remain unassociated when wireshark didn't capture the interface on which the first TCP subflow of the MPTCP connection started. Hope it's clear x) I wonder if there was a similar problem with SCTP associations dissections and how it got solved ? Do you have look how to SCTP assoc works ? Also Wireshark have 2 pass analysis, may be it will be help ! 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 ___ 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] Improving TCAP session matching
On Sun, Jan 4, 2015 at 1:32 AM, Luke Mewburn l...@mewburn.net wrote: Hi all. I've observed that Wireshark's TCAP session (transaction) matching (enabled with tcap.srt:TRUE) doesn't operate correctly in various cases. I've been working on improving Wireshark's TCAP session handling, and have some questions about the best way to do this as a new contributor to the Wireshark development community. I'm not sure if it's preferable to describe all of the issues in one 'wall of text' email or split up the discussions across multiple messages; I've gone with the former :) Please let me know if the issues should be split out into separate discussions, or if there's a better forum for this (e.g. bugzilla tickets). regards, Luke. Specific fixes -- 1. SCCP GT not set if route-on-SSN. DETAILS:: When sccp.set_addresses is TRUE, the GT isn't used if present when the SCCP route-on-SSN bit is set (i.e not route-on-GT). The GT is still useful for TCAP matching even in this case. PROPOSAL: I've submitted a change for this at: https://code.wireshark.org/review/#/c/6053/ (The second patch attempt is a minor improvement to the wording of the preference after the changes in the original patch). 2. TCAP session matching incomplete. DETAILS: TCAP session matching doesn't cope with TCAP dialogue confirmation. (See TCAP background below for more information about dialogue confirmation). This is because the current implementation uses the destination address for TCAP BEGIN matching (tcaphash_begin_info_key_t.dpc_hash), and origin address for TCAP END matching (tcaphash_end_info_key_t.opc_hash). When TCAP sessions (transactions) aren't correctly matched, then higher level dissectors can mistakenly decode packets part-way through the session because of assumptions about protocol versions (etc). There are existing Wireshark bugs in TCAP (and higher layer) that may be fixed by addressing this PROPOSAL: I have some changes to be submitted for review which resolves this, and greatly improves transaction matching when sccp.set_addresses:TRUE and tcap.srt:TRUE, even when the destination address of the TCAP BEGIN changes as part of dialogue (transaction) confirmation. Future proposals (These could be moved into separate discussions). 1. SCCP addresses not set by default. DETAILS: By default, the SCCP GT is not set as the source and destination addresses for higher layer protocols. The MTP3 (or M3UA) point codes (PCs) are left as these addresses. This can be changed with the preference option sccp.set_addresses. For TCAP transaction matching, the SCCP GT is more correct than the MTP3 PC. PROPOSAL: The sccp.set_addresses default could change to TRUE (and possibly the SUA equivalent, although I haven't any experience with SUA), but I'm not sure what ramifications that this has on protocols other than TCAP that use SCCP. 2. TCAP filters for party addresses. DETAILS: I've experimented with adding new filter nodes to contain the (SCCP GT) addresses of the original calling party (from TCAP BEGIN), the original called party (from TCAP BEGIN), and the confirmed party (from first TCAP CONTINUE or END-after-BEGIN). These depend upon the SCCP addresses set (see above) and the session matching fixed. PROPOSAL: Add new filters. I have a work in progress for this which could be submitted for review. 3. TCAP session matching not enabled by default. DETAILS: The session matching isn't enabled by default. I suspect that this is because it has a performance impact and that it doesn't work reliably (without my fixes :). PROPOSAL: Once the session matching is fixed, it could be enabled by default. 4. TCAP converted to conversation.h (after the latter is enhanced) DETAILS: TCAP uses its own session matching logic. If the standard conversation.h implementation was used, then there may be other benefits such as following conversation flows. I've experimented with this in a private branch, but ran into issues in the current conversation.h implementation that need to be addressed for TCAP. I implemented a new port type - PT_TCAP - to contain the TCAP transaction ID (TID). As described below in TCAP background: - TCAP BEGIN contains a src addr, otid (src port), and dst addr. The dst addr may change in the first CONTINUE. We have to create the conversation with NO_ADDR2 as well as NO_PORT2, which results in the conversation added to conversation_hashtable_no_addr2_or_port2. - TCAP CONTINUE contains src addr, otid, dst addr, dtid. Looking this up with find_conversation() seems to work; if it's the first CONTINUE the conversation is moved from conversation_hashtable_no_addr2_or_port2 to conversation_hashtable_exact. - TCAP END ABORT contains the dst addr, dtid (dst port), and src addr without src port (otid). The dst addr may change in the first CONTINUE or an END after BEGIN.
Re: [Wireshark-dev] Update Windows Build Instructions
Hi, I simply copied the following file (coming from older Dev Kit) Win32.mak to the Windows Kits (either 8.0 or 8.1) C:\Program Files(x86)\Windows\Kits\8.[0|1]\Include\Um Regards Robert From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Graham Bloice Sent: Sunday, January 04, 2015 11:09 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Update Windows Build Instructions On 4 January 2015 at 03:58, Stephen Fisher sfis...@sdf.org mailto:sfis...@sdf.org wrote: On Sat, Jan 03, 2015 at 06:52:56PM +, Graham Bloice wrote: OK, it seems that even after all the complaints MS still haven't updated VS 201x to provide it. IIRC it went missing in VS2010. See here for at least one complaint about it: https://connect.microsoft.com/VisualStudio/feedback/details/771247/win32-mak-is-missing-from-vs-2012-win-8-sdk-install Which installs don't have it? I just installed VC 2013 Community Edition at home (the Win7 machine was at work), this time a32-bit Win8 and it also has the file, but I again needed to update the INCLUDE path: SET INCLUDE=%INCLUDE%;C:\Program Files\Microsoft SDKs\Windows\v7.1A\Include Maybe your Win7 SDK came from an earlier install of the Platform SDK? I think mine did, I do have a separate entry for it in the Add\Remove Programs list. I don't think VS2013 installs that SDK, only the Win 8 ones which are missing the file. I really should try removing VS2013, removing the Win 7 SDK, checking for detritus and re-installing VS2013 CE again. I wish we could distribute it ourselves, but it has an MS copyright notice on it. Can we ask someone about it? Do we really need it? It says on the top: # Win32.Mak - Win32 application master NMAKE definitions file for the # Microsoft Windows SDK programming samples Which makes it sound like its intended for the programming samples and just setups up a bunch of variables/options. I think we do need some of the vars. I suppose we could replicate the bits we need in our own makefile. However, if I ever (or someone else assists) get the Windows CMake build fully operational, all this will go away as we can drop the nmake support. -- Graham Bloice # Win32.Mak - Win32 application master NMAKE definitions file for the # Microsoft Windows SDK programming samples # Copyright (C) Microsoft Corporation # - # This files should be included at the top of all MAKEFILEs as follows: # !include Win32.Mak # - # # Define APPVER = [ 4.0 | 5.0 | 5.01 | 5.02 | 6.0 | 6.1] prior to including win32.mak to get # build time checking for version dependencies and to mark the executable # with version information. # # Define TARGETOS = [ WIN95 | WINNT | BOTH ] prior to including win32.mak # to get some build time checking for platform dependencies. # # Define TARGETLANG = [ LANG_JAPANESE | LANG_CHINESE | LANG_KOREAN ] prior # to including win32.mak to getcompile link flags for building # applications to run on Far-East Windows. (This is an optional parameter. # The system locale is the default.) # # Define _WIN32_IE = [ 0x0300 | 0x0400 | 0x0500 | 0x0600 | 0x0700 | 0x0800] prior to including win32.mak to # get compile and link flags for building applications and components to # run on Internet Explorer. (This is an optional parameter. IE 4.0 is # the default.) # # - # NMAKE Options # # Use the table below to determine the additional options for NMAKE to # generate various application debugging, profiling and performance tuning # information. # # Application Information Type Invoke NMAKE # # For No Debugging Infonmake nodebug=1 # For Working Set Tuner Info nmake tune=1 # For Call Attributed Profiling Info nmake profile=1 # # Note: The three options above are mutually exclusive (you may use only # one to compile/link the application). # # Note: creating the environment variables NODEBUG, TUNE, and PROFILE is an # alternate method to setting these options via the nmake command line. # # Note: TUNE and PROFILE do nothing for 64bit compilation # # Additional NMAKE Options Invoke NMAKE # # For No ANSI NULL Compliance nmake no_ansi=1 # (ANSI NULL is defined as PVOID 0) # # = # Build Rules Quick Start # # To build one of the following types of executables, use the specified # compiler and linker command-line options. # # --- # To build: | Compiler
Re: [Wireshark-dev] Update Windows Build Instructions
On 4 January 2015 at 03:58, Stephen Fisher sfis...@sdf.org wrote: On Sat, Jan 03, 2015 at 06:52:56PM +, Graham Bloice wrote: OK, it seems that even after all the complaints MS still haven't updated VS 201x to provide it. IIRC it went missing in VS2010. See here for at least one complaint about it: https://connect.microsoft.com/VisualStudio/feedback/details/771247/win32-mak-is-missing-from-vs-2012-win-8-sdk-install Which installs don't have it? I just installed VC 2013 Community Edition at home (the Win7 machine was at work), this time a32-bit Win8 and it also has the file, but I again needed to update the INCLUDE path: SET INCLUDE=%INCLUDE%;C:\Program Files\Microsoft SDKs\Windows\v7.1A\Include Maybe your Win7 SDK came from an earlier install of the Platform SDK? I think mine did, I do have a separate entry for it in the Add\Remove Programs list. I don't think VS2013 installs that SDK, only the Win 8 ones which are missing the file. I really should try removing VS2013, removing the Win 7 SDK, checking for detritus and re-installing VS2013 CE again. I wish we could distribute it ourselves, but it has an MS copyright notice on it. Can we ask someone about it? Do we really need it? It says on the top: # Win32.Mak - Win32 application master NMAKE definitions file for the # Microsoft Windows SDK programming samples Which makes it sound like its intended for the programming samples and just setups up a bunch of variables/options. I think we do need some of the vars. I suppose we could replicate the bits we need in our own makefile. However, if I ever (or someone else assists) get the Windows CMake build fully operational, all this will go away as we can drop the nmake support. -- 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
[Wireshark-dev] Protocol stats list in GUI
With the addition of another protocol statistic [1], I noticed the list of the various stats is growing long and ugly in the Statistics menu of the GUIs (both GTK and Qt). It's also a jumble of generic things such as 'Flow Graph' and 'Compare...', and protocol-specific stats. And some of those protocol-specific ones are arguably niche protocols - i.e., ones that only a very small population of Wireshark users would ever use. Perhaps the protocol-specific ones should be moved to a Protocol sub-menu of Statistics? Or we could leave HTTP, TCP StreamGraph, and WLAN Traffic at the Statistics menu level, and move the other protocol-specific ones to a Other Protocols sub-menu? And Flow Graph isn't really a statistic - perhaps move it to the Analyze menu? -hadriel [1] for DNS in https://code.wireshark.org/review/#/c/6236/ ___ 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] Update Windows Build Instructions
On Sun, Jan 04, 2015 at 10:08:53AM +, Graham Bloice wrote: Maybe your Win7 SDK came from an earlier install of the Platform SDK? My Win8 32-bit machine at home is a fresh install, so VC 2013 CE is the only VC I've ever installed. The Win7 64-bit install at work install may have had something left over from an older VC install hough. However, if I ever (or someone else assists) get the Windows CMake build fully operational, all this will go away as we can drop the nmake support. CMake on Windows would still use the Microsot compiler tools, just without the nmake part? ___ 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] Script used to automatically delete unused #includes
Hi, I have attached the script that I used over the past week or 2 to detect and delete unneeded #includes. I am not sure whether it is fit for submitting to the tools folder in its current state. By my count it deleted 1400 #includes, although: - not all source files were scanned (e.g. plugins, epan other than dissectors) - a few includes later needed to be restored The script works by attempting to build without each #include, and permanently removing all that seem not to be needed. Ideally, a script like this would be run in the least forgiving environment available and any added warnings seen after a deletion would be treated as failure. I am currently building under VS 2010 EE, which is maybe the most forgiving environment we support. The Ubuntu build done by the Petri Dish definitely helped, but new errors were still seen after committing the changes. My reluctance to commit the script in its current form is because: - while I hope it was worth running once, I'm not sure it'll be worth doing again. Having said that, the script has some cowardly rules for not deleting includes that a better version on a less forgiving build environment could discard. I doubt you could even measure the difference it makes to a clean build time, but hopefully removing some clutter was helpful. - it is hard-coded to build with nmake. I'm not sure how best to choose between make/Makefile and nmake/Makefile.nmake - the results always need to be treated with care, and I wouldn't want someone to run the script for several hours to find that they can't commit the result. I'd be very happy if someone wants to further develop and run the script, but unless someone feels differently I'll assume that it shouldn't be committed as it stands. Best regards, Martin delete_includes.py 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
