[Wireshark-dev] wiki editor permissions
Hello developers, I'd like to write a wiki page about using the XSLT program to convert a PDML file into a HTML file. I'm thus requesting wiki editor permissions. My wiki username is "doj". -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Rename TVB captured length vs reported length
> You *can* continue dissecting the protocol. You just get an exception, so > that the user sees that the data was in the packet, but the snapshot length > was set too short to capture it. Stopping dissection just because the data > to be dissected was cut off by a snapshot length is entirely the wrong thing > to do, as it can make it look as if the packet didn't have the data in > question. That's my point. Not all of the code I have written will get executed, because data is missing. And if the next frame needs information from previous frames to dissect, my dissection of the protocol stops here. Of course there's nothing I can do about it. I just wanted to point out, that not only 5% is the dissector code requires access to all data to be useful. My main point is however to not use "tvb_length" any more at all, because different developers will interpret it differently. Use the longer, but explicit function names. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Rename TVB captured length vs reported length
> The problem is that 95% of the time the intended behaviour is best > achieved by the reported length, but 95% of the time people new to the > API pick up on tvb_length and friends and assume that's what they I disagree. I find it not intuitive that a function called tvb_length() (the propsed new version) would return a length, that the underlying data structure does *not* have. This would be contrary to any other API working with an array/buffer I know of. I also doubt that 95% of the use cases are asking for reported/captured length. Personally I typically work on code to show the user protocol (SSL, HTTP, DCE/RPC) and if a frame was truncated while capturing (captured_length < actual_length) I can often not continue with dissecting the user protocol, since I miss parts of the data. I understand that there are good reasons to know about the actual length of the frame and the captured length. I suggest that we simply state these lengths in the function name and *not* have an unqualified (shorter) name which will get misinterpreted. So my suggestion for a rename would be: tvb_actual_length() tvb_captured_length() -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Decrypting SSL in dissector
do you have a new_register_dissector("amp", ...) in the proto_register_amp()
function? Otherwise the SSL dissector can not match the "amp" string to a
dissector handle/function.
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
___
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] OSX 10.9 build procedures for latest source
> What is the easiest way to build Wireshark 1.10.3 on OSX 10.9 Mavericks? > I’ve tried macports and native build with no real luck - I keep getting > tripped up by dependencies. Any suggestions about the best way to build a > custom copy of Wireshark from source? I have not used OsX 10.9 yet, so I don't know if it requires any extra steps. You shouldn't use macports to install dependencies. What you need is Xcode + X11 packages, then use the macosx-setup.sh to install any dependencies into /usr/local/. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Val_to_str as a macro
the original function. I can use a single temp global, but that's just ugly and won't work if we ever do multithreading. It may be ugly, but using thread local storage for that global variable will make it safe for multi-threading. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Gerrit sandbox available for testing
> A few months ago we discussed migrating from SVN to Git + Gerrit. I > managed to get Gerrit[1] sandbox up and running at > > http://test.code.wireshark.org/review/ will this Git be kept in sync with SVN trunk? Or will it be just a snapshot for the time we're testing this system? -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Transport name resolution
Should we, instead, look the port number up in the "tcp.port" or "udp.port" (or "sctp.port") dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? I think this is more useful, since the dissector short name is typically used as the filter prefix. It is just confusing if slightly different strings are shown, because they come from some other list/database. Actually, the dissector *filter* name is typically used as the filter prefix - for example, for DNS, there's: name - Domain Name Service short name - DNS filter name - dns Are you recommending using the filter name instead of the short name? yes, I prefer the filter name, because if I want to dig into a problem I'll likely use filters. I think for most dissectors short and filter name just differ in capitalization and my brain typically wouldn't notice any difference, so it may not make any big difference. Side note: it may be worthwhile to add a recommendation to the check-api program that short name and filter name should case insensitive compare equal. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Transport name resolution
Should we, instead, look the port number up in the "tcp.port" or "udp.port" (or "sctp.port") dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? I think this is more useful, since the dissector short name is typically used as the filter prefix. It is just confusing if slightly different strings are shown, because they come from some other list/database. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 51169: / /trunk/epan/: app_mem_usage.c
If not, would an lseek() followed by a read() do just as well?
No. lseek() and read() modify the file position/offset. pread() however does
*not* modify it. So to emulate pread() you would need something like:
ssize_t my_pread(int fd, void *buf, size_t count, off_t offset)
{
const off_t old_offset = lseek(fd, 0, SEEK_CUR); // missing error handling
lseek(fd, offset, SEEK_SET); // missing error handling
const ssize_t ret = read(fd, buf, count);
lseek(fd, old_offset, SEEK_SET); // missing error handling
return ret;
}
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
___
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] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID
> I took a half-educated whack at fixing those in r51080. Thanks for pointing > it > out (and feel free to point out any mistakes I may have made). It all looks reasonable, thenk you for making those changes. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID
while you are renaming the displayed name of this variable, the rest of the SMB2
dissector is using the term "sequence number" in many places. It's now confusing
if source code comments talk about sequence numbers and use them in hash tables,
while the dissection shows it as Message ID. To really wrap this up, you might
want to rename hf_smb2_seqnum, but then also struct smb2_saved_info_t and code
using that struct.
On 2013-07-31 06:00, Richard Sharpe wrote:
> Hi folks,
>
> This patch needs to be applied:
>
> Index: epan/dissectors/packet-smb2.c
> ===
> --- epan/dissectors/packet-smb2.c (revision 51065)
> +++ epan/dissectors/packet-smb2.c (working copy)
> @@ -7100,8 +7100,8 @@ proto_register_smb2(void)
> { "NT Status", "smb2.nt_status", FT_UINT32, BASE_HEX,
> VALS(NT_errors), 0, "NT Status code", HFILL }},
> { &hf_smb2_seqnum,
> - { "Command Sequence Number", "smb2.seq_num", FT_INT64, BASE_DEC,
> - NULL, 0, "SMB2 Command Sequence Number", HFILL }},
> + { "Message ID", "smb2.msg_id", FT_INT64, BASE_DEC,
> + NULL, 0, "SMB2 Messsage ID", HFILL }},
> { &hf_smb2_tid,
> { "Tree Id", "smb2.tid", FT_UINT32, BASE_HEX,
> NULL, 0, "SMB2 Tree Id", HFILL }},
>
> See section 2.2.1.1. The field is called the Message ID, not the
> Command Sequence Number.
>
> That confusion has probably caused one of the WAN Accelerator
> companies to break SMB2 Signing by mishandling that field. Not sure
> which one it is, since the customer hasn't told me whose WAN
> Accelerator they use. (Hint, it is possible for those numbers to be
> out of order in a TCP stream.)
___
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] Code sharing between TLS and DTLS
On 7/4/2013 2:30 PM, Evan Huus wrote: There should be a way to refactor such that the hf_ fields are parameters, so that each user (ssl, dtls, etc) gets their own set of filter names. yes of course this can be done. I just don't know if this is really necessary. The Wireshark user will likely know if he is looking for SSL/TLS (on TCP connections) or DTLS (on UDP). If may be sufficient to use "tls.*" for both use cases. If we decide to unify filter names we shouldn't use the current "ssl.*" or "dtls.*". If the user doesn't know if he wants to examine SSL/TLS or DTLS (maybe studying something generic about these kinds of encryption protocols) the user would like to have a filter prefix that will match both use cases. -- ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Code sharing between TLS and DTLS
> I am writing this to the mailing list to get some opinions if this is > the right approach for this problem or if it should stay like it is now. > If I get positive feedback I will try to make dtls use more code from > the ssl dissector. The DTLS code was created from a copy of the SSL code some day in the past. It's true that they share a lot of common code and often changes in one of the files should be made in the other as well. However the problem with using common function is, that now the filter names would not have a common prefix any more. Your code change is showing this, since now when analyzing a DTLS packet some of the filters would start with "ssl." While I like the idea of refactoring both SSL and DTLS we should first think about a common nameing scheme for the filters, so that people using filters will not be surprised that some packets may not be matched. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Fileshark (AKA Dissecting Files with Wireshark)
> Thoughts? Comments? Suggestions? I like the idea of a sister application targetting files. I'm not concerned at this point how to structure dissectors, libraries and APIs. We should just get it started and re-evaluate after some months if we like the partition. If we plan to go through a review process after some time and plan time for re-organization we might get it started better, than trying to define the perfect partition right from the start. However we should agree which UI library to use: GTK2, GTK3, QT. Personally I vote for QT, espescially since the Wireshark QT is still in great flux we can probably have both applications benefit from each other in this early stage. We should also prepare ourself to get a bunch of new users and hopefully developers if we start a Fileshark. I can think that there are more people out there who like to analyze files than network packets. Also there are definately more file formats than network protocols. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] using C++, was: Notes from Sharkfest '13
> C++. It snuck in with Qt. Should we allow C++ in the rest of the code or > at least use C++ compilation everywhere? A tough call. If we go C++ we should have a plan to use the STL classes with our concept of memory (allocator scope). I've started a short discussion last year, but somebody found out, that using STL objects on the heap with the C++ allocators doesn't have the same semantics (and really doesn't work) with our packet or file lifetime scopes. However a second approach with C++ objects managed by smart pointers and those smart pointers being aware of the packet/file/application lifetime might work. We should research this, write guidelines how to use C++ objects in Wireshark and then make a decision if we want to allow C++ features everywhere. Another advantage would be that we can use real C++ exceptions. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] "Type-punned pointer... breaks anti-aliasing rules" in dfilter-macro.c
What should the fix ultimately be if one way breaks FreeBSD/gcc 4.2.1 compiles and if it introduces C++ compatibility issues (which I'm not familiar with since I haven't been following development for a while lately). maybe "&((void*)macros)" helps? -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 49995: /trunk/ /trunk/: macosx-setup.sh
The script doesn't work on Leopard *now*, and didn't work on Leopard even *before* your changes, because the versions of support libraries we download either don't configure or don't build on Leopard; I spent some time trying to make it work, but it looked as if it'd just be too much effort, so I quit. I suggest it is not worth investing time to support those non-working old versions, as nobody seems to have complained yet (and I don't think anybody will in the future). -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 49995: /trunk/ /trunk/: macosx-setup.sh
I've created https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8821 with my suggestion. We can continue to discuss there if/what/how we'd like to determine the optimum number of parallel make jobs. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] how does cmake know how to generate plugin.c
I'm studying cmake rules in the plugin/ directory. I can not find out, how cmake knows how to build the plugin.c file for each of the plugins. Where is this defined? -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 49995: /trunk/ /trunk/: macosx-setup.sh
How many processor cores does your machine have, and are they multi-threaded? I have a 4-dual-threaded-core machine (and a solid-state disk and a lot of memory), and "-j 8" seems to run the CPU at about 100%. I don't know whether "number of threads" would be a good default in all cases - what you really want is to keep cranking up the number of jobs until things don't get faster, but that's a pain - but, if it is a good default, then sysctl -n hw.logicalcpu would give cores*threads-per-core (tested on Snow Leopard, Lion, and Mountain Lion; the script doesn't work on Leopard, as the versions of at least some of the software won't configure and build, and I gave up trying to make them build). (I originally used -j 4, but then saw something about a multi-threaded version of the IBM System/360 Model 195 that noted that multi-threading can help deal with pipeline bubbles due to unpredicted or mispredicted branches, so I tried -j 8 and found the CPU was busier than with -j 4.) hmm, there are many points discussed here: - do we want to make a smart decision on the number of parallel make jobs, possibly derived from the number of cores? My personal opinion is yes. On OsX using the sysctl mentioned by Guy is probably a good starting point. Adding my own experience you'll want to oversubscribe the number of jobs over the number of cores a little bit, so that when jobs are waiting for I/O action another job can use the free CPU. With my personal experience calculating something like "number of cores"*1.5 seems reasonable, because if you're waiting for the long lasting build job on your desktop computer, you want some "juice" left over for web browsing, email reading or whatever. (This applies to all modern operating system, Windows, Linux, OsX) - the other question is, which versions of OsX are we targetting for developer support going forward. Personally I think no serious Wireshark user will use an earlier version of OsX than 10.6, so we should be safe. (personal note, my old MacBook Pro has two cores and no hyper-thread, so personally I'm fine with 3 make jobs [note that this was the default in the OsX build script for a long time]) -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 49995: /trunk/ /trunk/: macosx-setup.sh
> Very nice indeed! The only thing that should be done outside the script > is setting -j 3: On some systems it is too much, on others it is too > little. It should be set in the command line, not the script. I could change it to something like: if [ -z "$MAKE_BUILD_OPT" ] ; then MAKE_BUILD_OPT="-j 3" fi This way the user can set custom make options, but the script has a default. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] cast errors reported by a OsX cmake build
I just tried to use cmake to build current Wireshark SVN trunk source code. It fails early on with errors like: [ 5%] Building C object tools/lemon/CMakeFiles/lemon.dir/lemon.c.o /Users/djagdmann/ws-trunk/trunk/tools/lemon/lemon.c:443:8: error: cast from 'char *' to 'struct action *' increases required alignment from 1 to 8 [-Werror,-Wcast-align] ap = (struct action *)msort((char *)ap,(char **)&ap->next, ^ /Users/djagdmann/ws-trunk/trunk/tools/lemon/lemon.c:457:24: error: cast from 'char *' to 'struct state *' increases required alignment from 1 to 8 [-Werror,-Wcast-align] newaction->x.stp = (struct state *)arg; and many more of this type. Is somebody looking into cmake builds on OsX? -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] 1.10 branch + release schedule
After digging around Microsoft's various product lifecycle pages it might make sense to upgrade the XP builder to Windows Server 2003 instead of Vista. It will receive updates until July 2015 and would let us use a testing environment similar to XP. That would make 1.10 and possibly 1.10++ the "2003-but-you-can-probably-get-away-with-XP" fork. sounds good. I suggest we make the 1.10 release for WinXP, but not actively try to maintain it for the next releases. If the following release simply works with WinXP good, if not people with old computers will need to use some older Wireshark releases. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] 1.10 branch + release schedule
Note that we would still be committed to supporting OS X PPC and U3 users until Wireshark 1.10 reaches end of life in 2015. I suggest remove OsX PPC and U3 even for the 1.10 release. Your changes for GTK/QT sound reasonable. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
I dont think composite tvbs actually work. or at least they didnt work when we originally wrote the reassembly code. They have been fixed last year. They are working for me in 1.8.x code. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Icon Poll - is this OK?
> This makes zero sense to me. Why would you click on a "play" button to > capture packets? My ¢¢: I like the idea of using old tape recorder symbols for this. Starting a network capture is likely similar to starting the tape recording. In the old days, the button to start recording had two vertical bars: ||. The stop button had a square, the play button a triangle. Also note that if colors were used the recording bars were colored red, *not* the stop button. This also makes sense, because pressing that record button can overwrite your current data/tape, caution! pressing the stop button has to destructive effect. My suggestion: the record button should have to red vertical bars. The stop button a black or red square. Both buttons should have a circle sourrounding the bars and square in whatever color makes sense. Alternatively as Edwin suggested, a single toggle button, which probably has two advantages: - no confusion - one less button in the bar -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] read/write capture comments from the command line
Sadly, -j is already taken for Wireshark, so you couldn't run Wireshark from the command line with "-j", unless we go with either getopt_long() (pulling in a version from GNU libc for platforms that don't have it in the system library) or with g_option: I suggest using the glib functions. Otherwise we would just add more code to Wireshark and related tools for no real benefit. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] buildbot failure in Wireshark (development) on Windows-XP-x86
>> I'm still not having any luck (and I've reread >> https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html to >> no avail). I have two shells available: cygwin's bash and windows' >> cmd.exe. >> >> If I run cmd.exe and then run the vcvars32 script, I can build >> Wireshark correctly using nmake. This seems to be working fine. >> >> I I run cygwin then I do not have nmake available. Running the >> vcvars32 script from cygwin does not seem to change this (should it)? >> >> I cannot run test.sh from cmd.exe since cmd.exe will not interpret >> unix shell scripts. I cannot run test.sh from cygwin since it requires >> nmake, which I cannot get cygwin to recognize. > Are you starting bash from the Windows cmd env from which you executed the > vcvars script ? open a Windows cmd.exe, run the vcvars32.bat script, then add the path to your cygwin bin directory to your PATH. That should result in a shell which can run the Microsoft tools and the cygwin tools. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Simpifying exporting DLL symbols
I have tested it using autotools and CMake, but I could not give it a try on Windows or OS X. If you have some time and access to those platform please test the patch. I tested on OsX and it seems to work. I could compile Wireshark and run it. I think it's useful to have such a change if it works for all platform we care about. However we should also add a section to the developer README to explain the new macros. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] checkett.pl anyone?
Anyone able to create a checkett.pl script to check for this?
Note that checkAPI.pl contains code to check etts, but it is currently
disabled, because it generates lots of false positives. I've written a
naive approach to also check for etts (see attachment), but using it
with the dissector sources again produces a lot of false positives. Lots
of dissectors register more than one ett array. They often assign ett
values around into local variables, which will again report false positives.
Since the proto_item_add_subtree() function has a DISSECTOR_ASSERT() to
check for a valid ett value, that's probably a better approach. It is
not a static code analysis, but if our users report on issues, it's easy
to fix them.
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
#!/usr/bin/env perl
use strict;
die "usage: checkett.pl +" unless $#ARGV >= 0;
my $ret = 0;
foreach my $fn (@ARGV)
{
$ret += check_ett($fn);
}
exit !!$ret;
sub check_ett
{
my ($fn) = @_;
die "$fn not found" unless -f $fn;
# read complete file into $c without newlines
open(A, $fn) or die "could not open $fn: $!";
my $c='';
while ()
{
chomp; # remove newline characters
s!//.+$!!; # remove C++ comments, however this doesn't work if // is used inside a string
s!^#\s*line\s+\d+.*$!!; # remove #line ...
next if /^\s+$/; # skip empty lines
$c .= $_; # append to $c
}
close(A);
# remove C comments
$c =~ s!/\*.*?\*/!!g;
# remove #if 0
$c =~ s!#\s*if\s+0.*?#\s*endif!!g;
my %ett;
while ($c =~ /proto_item_add_subtree\s*\(\s*\w+\s*,\s*(\w+)\)/g)
{
$ett{$1}=1;
}
# get ett array variable name
$c =~ /proto_register_subtree_array\s*\((\w+)\s*,/;
my $ett_array_name = $1;
# get ett array
$c =~ /$ett_array_name\s*\[\d*\]\s*=\s*\{([\w\&,\s\[\]\(\)\.]+)\}/;
my $ett_array = $1;
$ett_array =~ s/\&|\s//g; # remove & and whitespace
# remove any ett variable used in the array from %ett
foreach my $e (split(/,/, $ett_array))
{
delete $ett{$e};
}
# if no entries left in %ett return success
return 0 if scalar(keys %ett) == 0;
foreach my $e (keys %ett)
{
print "$fn: uninitialized ett variable: $e\n";
}
return 1;
}
___
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] Google Summer of Code 2013 project
Hello developers, I'd like to explain a project I have been thinking about doing for a while, but of course it could also be done as a Google project (I could also mentor it). Let me first explain the situation at my work: We often have to debug network issues and have to follow packets/connections as they progress through the network. So we often create multiple capture files at multiple devices while running a test. To see how the packets are traversing the network we would then like to follow the packets through the multiple capture files. We open multiple instances of Wireshark, load the capture files and then try to add filters to find the packets we're interested in. The idea is that I can 1) remote control a Wireshark from another process to jump to a specific frame/packet, 2) lookup packets intelligently. I'll explain the two features some more. 1) I'd like to remote control a Wireshark process and for a start initiate a "goto frame". I don't expect the Wireshark processes to be all on the same computer, either because my capture file is large and I need more than one computer to load them, or because I'd like to discuss a capture file with a friend over the phone, each looking at this local Wireshark. Thus a remote control via network. Now I do expect for a first iteration that all those Wireshark hosts are on the same LAN, so I would like to use UDP multicast to send those remote control messages. With a preference setting a user can enable the feature and join a multicast group. This makes it also independent of the operating system Wireshark is running on, I could mix and match different combinations. For a first iteration security would not be mandatory, but the remote control protocol should have a provision to add it later. The idea is, two Wireshark processes load the same capture file, one they exchange some basic information on the current view. For a start I would like to see a "goto frame" command and a "apply filter" command. 2) Now that I can remote control two Wireshark processes, I'd like to extent that feature for an intelligent matching of network packets, if I load two different capture files. The idea is, that for certain parts of the protocols we calculate a hash sum and store the hash sum with the frame number in a global map. Then I would send a "goto hash" command and the remote Wireshark would check if its hash map contains the same hash to goto the corresponding frame. Each network packet can create multiple hashes, for example - TCP payload - IP src/dst address+TCP src/dst port (same for UDP) - ethernet src/dst address + payload length - specific protocol dissectors can create their own hashes, for example DCE/RPC dissector can use protocol type (UUID) + Call ID; HTTP dissector could use header key/value pairs, etc. Via a context menu on the packet I can select which of these hashes to use for the remote control command. -- ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Idle Thought - Compiling with C++
To me the biggest advantage of transitioning to a C++ compiler is the availability of std::string and std::list, std::set, std::map. They are so much more convinient to use than equivalents from the glib or the alternatives designed for Wireshark. Since the C++ STL classes allow a custom allocator we can write C++ allocators for our ep_ and se_ (or the new wmem_) paradigms and typedef Wireshark versions of the STL objects with these allocators. This would be my biggest immediate benefit. I don't advocate to redesign Wireshark into a C++ object/inheritance hell at once, although with those "features" available new developments can/might/will use them and over time we may have better code. Since the QT version is already using C++, I guess that simply building current Wireshark with a C++ compiler is a no brainer. If we agree that this route is worthwhile we could simply start building with C++ and develop some guidelines how to proceed with new code, restructuring old code and maintaining/bugfixing old code. The only caveat I can think of: if we build libdissectors with a C++ compiler that might force other users of that library to switch to C++ as well (name mangling etc). -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Get_cpu_info on platforms other than Windows?
On 06.02.2013 05:13, Anders Broman wrote: Hi, The included patch works on Ubuntu 64 bits but I guess it needs to be protected with more #if defined on say OSX ppc? #if defined(__i386__) || defined(__x86_64__) #if defined(_MSC_VER) // your windows version, compiled by a Microsoft compiler #elif defined(__GCC__) // your gcc version #else #error do_cpuid() not implemented for your compiler for the Intel processor #endif #elif defined(__ppc__) || defined(__powerpc64__) #error do_cpuid() not implemented for the PowerPC #else #error unknown platform: do_cpuid() not implemented #endif -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Reducing Autotools verbosity
maybe mention in the developer README how to bring back verbose build output. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 47188: /trunk/ui/gtk/ /trunk/ui/gtk/: main.c
the logical and is the very same in both revisions. But what makes this code
confusing is the use of "prefs.capture_device" in one place and then
"prefs_p->capture_device" in another. Maybe what you really want is
if ((global_capture_opts.num_selected == 0) &&
(prefs.capture_device != NULL) &&
(prefs.capture_device[0] != '\0')) {
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
___
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] RFD: The Future of Memory Management in Wireshark
> General thoughts from the list on whether or not this would be a good idea?
some general comments on the whole wmem idea:
memory allocation is done almost everywhere in Wireshark, also in somewhat
hidden places. For example all the proto_tree_add_* functions will need to
allocate memory. It will be a real pain to pass down the current allocator
object into each of those function invocations, you're looking at changing a
considerable amount of code. Also when thinking about writing dissector code,
it's probably not useful to mix different allocators while dissecting a
protocol.
An alternative idea (although a little more ugly) is to use a thread local
global variable which contains pointers to the current ep and se allocators. The
se_* and ep_* functions retrieve the allocator object from that thread local
global variable and do their allocations. If a function wants to change the
allocators for its own function calls, it can make a copy of the global variable
pointers to local variables, set it's desired new allocators and restore the
global pointers at the end, like:
__thread void* se_allocator;
__thread void* ep_allocator;
void my_special_func()
{
void* old_se = se_allocator;
void* old_ep = ep_allocator;
se_allocator = create_special_se();
ep_allocator = create_special_ep();
dissect_packet();
garbage_collect(se_allocator);
garbage_collect(ep_allocator);
se_allocator = old_se;
pe_allocator = old_ep;
}
Second point:
as you've noticed especially in dissector we pass large number of arguments into
almost every function (tvb, pinfo, tree). Bundling all of them into a struct
like dissect_context would make adding things like custom allocators way easier
to support, since we could add the required pointers to that context struct and
only pass that struct into all of the functions. However now you would need to
modify every line of code which was using the pointers for tvb, pinfo, tree and
in the dissectors that is a very large number of lines. Also it will be a
difficult decision how the API on the new allocation functions should look like?
Would we want to hand them the dissect_context struct or the allocator pointer?
struct dissect_context {
tvbuff_t* tvb;
packet_info* pinfo;
void* se_allocator;
void* ep_allocator;
};
void* se_alloc(dissect_context* ctx); // like this?
void* se_alloc(void* se_allocator); // or like this?
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
___
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] Asterisk AMI and FreeSWITCH ESL dissectors
> Has anyone investigated developing Asterisk AMI and FreeSWITCH ESL > Wireshark dissectors? They're both fairly simple protocols and the > current telnet dissector *kind of* works but I need TCP reassembly to > work properly for both. It seems like Wireshark dissectors would be > very useful to the Asterisk and FreeSWITCH communities. > > More information on the protocols: > > https://wiki.asterisk.org/wiki/display/AST/Asterisk+Manager+Interface+%28AMI%29 > > http://wiki.freeswitch.org/wiki/Mod_event_socket Those two protocols are indeed made to look like HTTP headers. Have you tried to make the following settings in the HTTP preferences: enable "Reassemble HTTP headers..." disable "Reassemble HTTP bodies..." and add the TCP ports you're interested to the list. Now of course those protocols will be shown as HTTP, but it should give some results. If that doesn't work well, you'll have to look into your own custom dissector. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] DND crash through all versions?
> This problem is now addressed through bug 7744. A fix was committed with > revision 45058, although this could not be tested on OS X. Anyone > willing to drop some pcap files onto an Wireshark main window on OS X? I compiled a GTK2/X11 Wireshark from trunk on OsX, but DnD is not working (for me) from the Mac finder to Wireshark. I don't know if DnD is supported with GTK2/X11 on Mac, but it may not be. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Wireshark Final Cleanup Function/Hook?
Hello Wireshark developers, is there a way to register a cleanup function in a dissector to be called when a file closed? I have a couple of hash tables allocated using g_hash_table_new() that I want to free when the user closes the file. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Is Python Still Considered Optional for the Build Process? What Should the Minimum Version Be?
> But not being familiar enough with the entire build process, I'm > wondering: is Python still optional or is saying so a vestige from > yesteryear? Is it time to re-evaluate Python as a hard prerequisite so we I think for a future stable release we can make a decision to make python a mandatory requirement for building. It's easy to install on every major platform we are supporting and not having to maintain the same program written is a step in the right direction. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] remote control Wireshark
Hello developers, I'm planning to develop a feature for two use cases. I'd like to control (or better select) the currently displayed packet from another process. I don't think Wireshark currently offers such a feature, so I'd like to get ideas how I should implement this. Let me first describe what I'd like to do. I often have multiple capture files made a different points in the network and I want to track certain packets as they showed up the the capture files. I can start multiple Wireshark processes and load a capture file into each of them. Now I want to add a "fingerprint" to each packet, probably in the packet_info structure. The different dissectors can then calculate a fingerprint of the payload and set the fingerprint variable. Of course the idea is that my multiple Wireshark processes with the multiple capture files will see the same packets and the dissectors will calculate the same fingerprints. When I now select a packet in one of the Wiresharks I can ask that Wireshark to send a "goto request" to any other running Wireshark. The goto request will include the fingerprint of the current packet. When a Wireshark receives such a goto request it will check if it knows about a packet with such a fingerprint and then goes to that packet. The second use case is correlating capture files with log files (webserver, syslog). The log files usually contain a timestamp information (only with second precision, but better than nothing). I want to write a log file viewer which for every line calculates the Unix timestamp. If I select a line in my log file viewer it send a "goto request" to all running Wiresharks. Here the goto request contains the unix timestamp and Wireshark will go to the first packet >= the timestamp. The idea is that I can select an interesting point in time in my log file and see packets from that time in Wireshark. Both use cases involve a sender and multiple receiver scenario. I don't need to send these requests to a different computer, so a local message bus is sufficient. In the KDE and Gnome world http://www.freedesktop.org/wiki/Software/dbus would be a natural choice, but I don't think that Wireshark uses dbus on Windows or OsX. So I'd like to get opinions what kind of technology for the inter process communication I should use, that will work on Windows, OsX and the Linux/BSD world. Did someone start such a project? Would we prefer a certain existing protocol/library? I could also think about simply using a multicast socket and send messages across. This would without further effort allow Wireshark control from different hosts. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 40352: /trunk/ /trunk/macosx-support-lib-patches/: glib-pkgconfig.patch /trunk/: macosx-setup.sh
> Configuring, building and installing takes ~45 seconds on my system. Add to > this > a 1 MB download. So if there are no objections, I'll leave it as is (and check > whether other packages also come in .xz format). Otherwise I'll change the > stuff > to bzip2. Even though it can be downloaded and build fast, I prefer to only install the minimum of support programs required to build a GTK on Mac. Since OsX tar can handle bzip2, I prefer to use that and not install the xz program. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] misleading description on Wireshark Download page
So today somebody at my company wanted to check the latest Wireshark. Looking at http://www.wireshark.org/download.html he read the description literally which said that the 1.6.0rc2 is the latest development release. So he figured it might be newer than the fresh 1.6.3 release... I think we can remove that old release candidate, or alternatively put a daily/weekly tarball of trunk on that page. ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item() using a script.
I'll hold off doing any changes until tomorrow to wait for any comments. Use ENC_ASCII. I suspect the majority of protocols currently available is so old, that they don't use anything more modern. And our users will tell us if ENC_ASCII is wrong for some protocols and we can fix them manually later. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item() using a script.
I propose to use a perl script to automate as much as reasonable the replacement of TRUE/FALSE in the encoding parameter of the proto_tree_add_item() calls in dissectors as follows: sounds good, but may be difficult to write. Because you would need to write a parser for C function calls in perl. regular expressions won't do the trick, as they can not reliably match parenthesi. Also keep in mind that those proto_tree_*() functions can use multiple lines. But just doing regular expression may give you 90% of the cases which would be good enough. For the next step is it simply a case of replacing the remaining TRUE/FALSE encoding parameter by ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN ? This sounds right. One thing I don't quite understand: In a number of the dissectors why do proto_tree_add_item() encoding parameters for hf items with type FT_STRING have ENC_ASCII *and* ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN ? Shouldn't this be ENC_ASCII | ENC_NA in this case ? Probably. Don't expect every developer of the various dissectors to have specified 100% correct parameters here, since a lot of combinations so far did just work. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 39143: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dvbci.c
> So that would be option (c) then? > c) Define ENC_NA differently from both ENC_LITTLE_ENDIAN and ENC_BIG_ENDIAN. > > The impact of this would imply these other changes: > > For every proto_tree_add_*() function: > -> Change the "const gboolean little_endian" argument to something like "gint > endian" > -> Verify "endian" is valid for the given FT_ and choke on invalid ones. > > And of course, change all the dissectors to use appropriate ENC_'s in the > proto_tree_add_*() function calls. Even if this is probably a lot of work, I vote for this approach. For the 1.8 release we should emit warnings if FT_ and ENC_ don't match, then for 1.10 emit error/exceptions, so that eventually all FT_ and ENC_ values express the real relationship. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Remove support for libpcre?
> Now that we require GLib 2.14 (which includes GRegex) we don't need libpcre. > Should we remove the support for libpcre completely? Away with it, less dependencies are always preferred. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Time shift patch causes compile error
> I'm not sure if my system config or the code is at fault. truncl isn't > defined anywhere in /usr/include/* except for C++ header files. > Apparently, it's a gcc builtin function. I have no idea what parameters > it expects. You're passing it long doubles, this is in line with the > manpage. > > If I enable your define for windows > > #define truncl(ld) floorl(ld) > > things work ok for me. Should that be enabled for older gccs as well or > are you aware of gcc settings that make it define truncl() in the standard > way? I put in this #define to make it work on Windows, but did not check too much where the trunc() function is available elsewhere. I also think that if truncl() is not present on other non-Windows platform, we should simply use floorl(), as it should be available on every C compiler. floor() and trunc() only return a different result for negative arguments. (truncl always rounds down, floorl round towards 0) Would could also declare the offset_float variable as "double" and use "floor()" instead, possibly being more compatible if a platform does not support the "long double" format. And 64bit of double should be enough for a nanosecond precision. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] [Bug 6086] How does it work?
Well, I guess your expectations are a bit off. > 1. It would work on all protocols that had a FT_ABSOLUTE_TIME item > (satisfying most of bug 1381) It changed the date parser. It should work on any FT_ABSOLUTE_TIME item. > 2. Missing date/time fields in the filter would be set to 0 and considered > "don't care" (ie "frame.time == 2011-08-02" would filter all frames received > on Aug 2, 2011, regardless of hour/minute/second values) missing fields are set to 0, but you still get a timestamp, meaning a point in time. If you want to display all frames captures today, you'll write a filter as "frame.time>='2011-08-02 00:00:00' && frame.time<='2011-08-02 23:59:59'" -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] How to build on MACOS (with revised instructions)
> Would it be useful to have scripts such as this for other platforms, e.g.: I have shell script for Debian/Ubuntu and RedHat/CentOS which use their package systems to install the dependencies to build a Wireshark. I can send then to a committer via email or attach to a bug. We should also document that these scripts exists and move them to a common directory (probably below the tools/ directory), so people can find them easily. At least for your mac script you should review the README.macos file, since it probably contains outdated content as well. ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] How to build on MACOS (with revised instructions)
>> I'm working on getting the script to work; I'll check it in, along with the >> patches, when I have it working. > > OK, I've checked them in. I called the script "macosx-setup.sh". you could remove the packaging/macosx/native-gtk/ directory. It contains a similar script to install gtk and dependencies, but is no longer working. ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Presenting WireViz
> As part of my GSoC project I'm writting WireViz plugin. looks really nice. I don't have a good idea yet, how to go from Wireshark filter language to graphviz syntax (it is a kind of compilation though), but that said try to use some approaches learned from writing interpreters/compilers and not some ad-hoc string match/replace. ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Increase minimum GLib and GTK+ versions?
Gerald Combs wrote: > Is there any reason we shouldn't make GLib 2.14.0 and GTK+ 2.12.0 the > minimum required versions to build Wireshark? This would let us get rid I don't see any reason. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] About Dead Store in clang Analysis
> (Aside: my attitude to dead stores is that eliminating them is a job > for the compiler. The programmer's job is not to micro-optimize things > that can be done better by machine, but to structure the code so as to > make the semantics as clear as possible. And I think that includes, as > already pointed out, leaving things in a clean state for when the next > field is added to the end of that tag.) If only I could have expressed this so good... -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] About Dead Store in clang Analysis
> What it the official solution to fix this ? > 1) Remove the code > 2) Ignore this warning > 3) Comment the code add a > /* offset += 1; Remove Clang Dead increment */ I would say configure clang to not emit this warning. This idiom of adding a proto_item and then incrementing the offset is well proven throughout the code. Having that additional integer increment will not result in wasted CPU cycles. And if you have an incomplete dissector if the correct offset increment is used, you will not introduce a bug when adding additional proto_items. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] malformed packet for no reason
I guess the packet you are trying to dissect is shorter than your two loops over i and j assume. In your inner loop you do something like: *plen += data_size; So plen will be greater than num_of_data_arrs*num_of_data_chunks*data_size bytes. Then you do a val_ptr = tvb_get_ptr(tvb, *plen, data_size); But tvb_get_ptr() can return NULL when out of bounds of the current packet. I guess this condition is reached on your 6th iteration. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] bitmask handling in wireshark
> #define MYPROTO_FLAG_SAMPLING 0xf0 A better name would be #define MYPROTO_MASK_SAMPLING 0xf0 since it is a bitmask you're defining here. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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 35213: /trunk/docbook/wsdg_src/ /trunk/docbook/wsdg_src/: WSDG_chapter_build_intro.xml WSDG_preface.xml
> It seemed like a good idea to me. I find trying to read > README.developer rather tedious, altho I do agree that a plain text file > can be grep'ed and etc. > > If there's feeling that README.developer should be left as is, then I > can certainly revert the changes. I think having one concise document which shows the way how new development should be made is a good thing. The WSDG from the website looks like generated from docbook. So we could generate a plain text file from that and put it a README.developer into the sources. ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] How to avoid dissection based on port defined by a different dissector?
> Sorry, I didn't make it clear that "what RFC that is" is "what RFC - if any - > says that ephemeral ports should be handed out by default", not "what RFC > explains what SHOULD and MUST mean". *Is* there an RFC that describes > well-known, registered, and ephemeral ports? The first two of them are > mentioned in the IANA port number assignment list: > http://www.iana.org/assignments/port-numbers > but that doesn't mention ephemeral ports. There probably is not RFC to define that, and remember that different operating systems have different default ranges and you can typically override those defaults. See http://en.wikipedia.org/wiki/Ephemeral_port -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] How to avoid dissection based on port defined by a different dissector?
> The problem I have with this is that 3503 is registered to MPLS Echo so that > dissector shouldn't have to be changed to essentially become a heuristic one > to > accommodate this port-stealing protocol. It's essentially the same situation > as There is no port stealing. The IANA list is just a list, it does not enforce anything or forbid other developers to choose one of these ports for his service. In addition not nearly every TCP/UDP application out there has tried to register their port with IANA. If you've read the rules to do this and have tried to register something with them, you might know that it is often not worth the hassle. Wireshark already has the perfect solution with 1) heuristic dissector, 2) manual selection which dissector to use for a TCP conversation. I don't think we should go ahead a pro-actively change all dissectors which are not heuristic, but if a port clash occurs the developer who wants to submit a new dissector should convert the existing one to heuristic and make his new one heuristic as well. Or simply live with the fact, that some other dissector might "win the lottery" which one gets choosen for a packet. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Enhancement-Request: RTP-MIDI dissector
> MIDI has something that is called "running-status" where some commands > are abbreviated by ommiting the first octet if that is the same in > the consecutive commands. > > I really don't know how I could do the MIDI-dissection without knowing > where the actual Status-Byte comes from (in RTP-MIDI each packet still > contains a "phantom" running-status at the beginning of the command > section). This might not be the case for all ip-based MIDI-protocols... I didn't know about the phantom status, but of course it makes sense for a "non serial cable distribution". I guess your approach is fine then. Does it work with your earlier applemidi dissector? -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Enhancement-Request: RTP-MIDI dissector
Tobias Erichsen wrote: > Hi everyone,is there anyone who can give me some feedback on the time it will > take,until someone takes a look at my enhancement > request:https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5451Thanks a > lot...Best regards,Tobias So far I have only looked at your code and it looks fine. However there are some other MIDI over network (on different layers) protocols out there. Since you have made such a nice general MIDI dissector, how about factoring out that into a separate "module", which can be called from other/future dissectors, so that we don't need to have a new MIDI dissection implementation for other protocols. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Problems creating the OsX App
>> Next I tried a "make osx-app". This is also making without errors and then I >> see a Wireshark.app directory is created in packaging/macosx/. However I can >> not start it. Trying to start it with the "wireshark" script in >> packaging/macosx/Wireshark.app/Contents/Resources/bin/ results in: > > This is fixed in trunk in revision 34583, I'll add it to the roadmap > for released versions. > Try the attached patch. that patch is working for me. ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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] Problems creating the OsX App
Hello Wireshark Developers, I'm completely new to Apple development. I want to test my changes to Wireshark and want to compile on the three major platforms: Linux/BSD, Windows and now Mac. So I have a OsX 10.6, installed Xcode 3 and have used MacPorts 1.9.2 to install the gtk environment. Everything worked fine and I can compile the Wireshark 1.2.12 source code just fine. I can also start the compiled wireshark and it is working. Next I tried a "make osx-app". This is also making without errors and then I see a Wireshark.app directory is created in packaging/macosx/. However I can not start it. Trying to start it with the "wireshark" script in packaging/macosx/Wireshark.app/Contents/Resources/bin/ results in: [djagdm...@macuser ~/wireshark/packaging/macosx/Wireshark.app/Contents/Resources/bin] $ ./wireshark 2010-11-17 23:34:29.422 defaults[13353:903] The domain/default pair of (kCFPreferencesAnyApplication, AppleAquaColorVariant) does not exist 2010-11-17 23:34:29.440 defaults[13354:903] The domain/default pair of (kCFPreferencesAnyApplication, AppleHighlightColor) does not exist (process:13344): Gdk-WARNING **: locale not supported by C library (process:13344): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Xlib: extension "RANDR" missing on display "/tmp/launch-P9sieC/org.x:0". (wireshark-bin:13344): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks", (wireshark-bin:13344): GdkPixbuf-WARNING **: Error loading XPM image loader: Unable to load image-loading module: /Users/djagdmann/wireshark/packaging/macosx/Wireshark.app/Contents/Resources/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: dlopen(/Users/djagdmann/wireshark/packaging/macosx/Wireshark.app/Contents/Resources/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so, 1): image not found (wireshark-bin:13344): GdkPixbuf-WARNING **: Error loading XPM image loader: Unable to load image-loading module: /Users/djagdmann/wireshark/packaging/macosx/Wireshark.app/Contents/Resources/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: dlopen(/Users/djagdmann/wireshark/packaging/macosx/Wireshark.app/Contents/Resources/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so, 1): image not found (wireshark-bin:13344): Gdk-CRITICAL **: gdk_pixbuf_render_pixmap_and_mask_for_colormap: assertion `GDK_IS_PIXBUF (pixbuf)' failed Segmentation fault Looking at the loaders/ directory in lib/ I indeed see no libpixbufloader shared libraries. The MacPorts GTK install did not build those. Then I removed the MacPorts and tried native-gtk/build-gtk.sh, but even after a lot of debugging and fixing some bourne shell problems this file has too many problems, because it is referencing no longer accessible URLs and probably pretty outdated versions anyway. So after all this long text the question: Does anybody have set up a OsX compilation environment lately and maybe has hints how to resolve all dependencies for an Application (and eventually Package) creation? ---> Dirk Jagdmann ^ doj / cubic > http://cubic.org/~doj -> http://llg.cubic.org ___ 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
