[Wireshark-dev] Community/Developer support list for Wireshark ()?
http://blog.gmane.org/gmane.network.wireshark.user http://blog.gmane.org/gmane.network.wireshark.devel It seems strange to me that there are parentheses following Wireshark. Compare to http://blog.gmane.org/gmane.network.wireshark.announce and http://blog.gmane.org/gmane.network.wireshark.bugs where they are not present. - Chris ___ 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] pcapng, must opt_commentstring?be?0-terminated?
Martin Kaiser writes: > I hope that at FOSDEM, we can discuss my proposed > approach for getting the comment from pcapng->wiretap->capture_file, see > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3096 I won't be able to attend FOSDEM, but no matter; there will be far more talented core developers who will be attending with whom you can discuss this and other topics of interest with. To you and everyone attending, have a productive and enjoyable FOSDEM! - Chris ___ 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] Conference room before FOSDEM
Graham Bloice writes: > As the “FOSDEM Friday beer event”, http://fosdem.org/2012/beerevent takes place at Delirium I’m not intending to miss it. Unfortunately, I will be unable to attend ... but I'll try to enjoy a Belgian beer or two from RI instead. :) I'm sure the event will be terrific and everyone will have a great time. Cheers, Chris ___ 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] Recursive Heuristic Dissectors calls
Alex Lindberg writes: > I have a custom protocol that uses a well know TCP port and a such have connected a heuristic dissector to tcp.My dissector works fine if there is only my custom protocol in the packet, but I have run into a case where the first part of the packet has several groups of my protocol, but at the end is a normal h248 chunk of data.How should I handle this? I would like for the TCP dissector to try a heuristic dissector look up after each chuck of custom data. After a quick look at the TCP dissector, it appears that "dissector_try_heuristic", defined in epan/proto.c, is called only once per packet. Any ideas? Thanks as always.Alex Lindberg I didn't see anyone follow up with this and I meant to earlier but it slipped through the cracks ... I think perhaps what might be needed are "new-style" heuristic dissectors, similar to the new-style regular dissectors. Instead of simply returning TRUE/FALSE, it would return the number of bytes it consumed so that the calling dissector can keep looping with the remaining bytes to be dissected, rather than only calling one heuristic dissector per packet. - Chris ___ 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 40644: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-pgm.c
Tony Trinh writes: > Try using mintty, which Cygwin recommends. It can copy/paste UTF-8 into vim without any configuration. > > I modified Cygwin.bat as follows: > > @echo off > > C: > chdir C:\cygwin\bin > > REM here lies the old line... > REM bash --login -i > > REM ...and here's the new > set PATH=C:\cygwin\bin;%PATH% > start mintty Tony, that works great! I can also use normal keyboard shortcut keys again for copying/pasting, scrolling, etc. BTW, the characters also display correctly using Windows PowerShell with either the Consolas or Lucida Console fonts. Thanks! - Chris ___ 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] pcapng, must opt_commentstring be?0-terminated?
Martin Kaiser writes: > I was wondering why we need a static buffer at all. It looks like the > intention is to keep using the same buffer for each option that we > parse. When reading an option, how about checking the length first and > then allocating the buffer dynamically? We could then remove the > g_strdup() as well and use the allocated buffer to pass the option on to > wiretap etc. Your suggestion sounds good to me. > My understandig is that g_strdup() allocates a copy that the caller must > free. I don't think that at the moment, anybody is freeing the copy for > the comment (or for any other option). If there's a leak, then that should be fixed. Care to open a bug report and submit a patch? - Chris ___ 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 do display filters work internally?
Maynard, Chris writes: > an "ip.addr" filter and it matched IP addresses in the IP protocol, but also with some bootp traffic. Apologies - the "ip.addr" filter works for the IP addresses in the IP header, but not for the bootp IP address fields, so there's still something else going wrong here that needs fixing. ___ 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] Iteration in dissectors?
Tyson Key writes:
OK, what about this:
for (rwe_pos = 0; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos++) {
proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb, 14 +
2*rwe_pos, 1, ENC_BIG_ENDIAN);
}
... or if you want the 0x80 bytes highlighted, try this:
for (rwe_pos = 0; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos++) {
proto_tree_add_uint(felica_tree, hf_felica_block_nbr, tvb, 13 +
2*rwe_pos, 2, tvb_get_guint8(tvb, 14 + 2*rwe_pos);
}
- Chris
___
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] Iteration in dissectors?
Tyson Key writes:
> My (partially working) iteration code looks like:
>
>/* Start counting from 13 */
>for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 13); rwe_pos++) {
> proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
> rwe_pos + 1, 1, ENC_BIG_ENDIAN);
>}
How about something like this:
/* Start counting from 14 */
for (rwe_pos = 14; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb, rwe_pos, 1,
ENC_BIG_ENDIAN);
}
... or if you want the 0x80 byte highlighted as part of the block number
(instead of skipping it), then do something like:
/* Start counting from 13 */
for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
proto_tree_add_uint(felica_tree, hf_felica_block_nbr, tvb, rwe_pos, 2,
tvb_get_guint8(tvb, rwe_pos + 1));
}
- Chris
___
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] pcapng, must opt_comment string be 0-terminated?
Martin Kaiser writes: > It's not that critial we but know the correct length and could do > > opt_comment = g_strndup(option_content, oh.option_length) > > instead. > > If you agree, I can open a bugzilla item with a patch and sample capture > that has an unterminated comment. To avoid the possibility of reading past the end of option_content in the case when oh.option_length > sizeof(option_content), I think it would be safer to do this instead: wblock->data.packet.opt_comment = g_strndup(option_content, MIN(oh.option_length, sizeof(option_content))) Note that this can't happen today because if the option length is greater than sizeof(option_content), then we never get there, but I think the implementation would work better to read as much as will fit into the buffer as possible, in this case the 1st 99 characters of the string (plus the NULL-terminator), rather than skipping it altogether. The comment next to option_content indicates, "XXX - size might need to be increased, if we see longer options", so it's apparently a somewhat arbitrary limit. I think as pcapng sees more and more use, it's only a matter of time before longer and longer strings are added (or desired to be added). Even the examples shown at the end of section 2.5 of the pcapng spec illustrate some strings approaching that limit, and those strings do not seem overly long to me: "This packet is the beginning of all of our problems" / "Packets 17-23 showing a bogus TCP retransmission, as reported in bugzilla entry 1486!" / "Captured at the southern plant" / "I've checked again, now it's working ok" / ... ___ 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] pcapng, must opt_comment string be 0-terminated?
Michael Tuexen writes: > On Jan 2, 2012, at 3:53 AM, Guy Harris wrote: > > I'll send the spec maintainers a note asking about this, and suggesting that the spec indicate that all > strings are counted (but shouldn't contain a null byte). > Hmm, I wouldn't mind if they are 0-terminiated, I even thought they are. However, it would be great > if it would be described explicitly in the spec. In section 3.6[1], there is specific mention of the dns entries being zero-terminated in Table 2. While not part of the options[2] section, it could lead one to believe that other strings should be zero-terminated as well. Should the mention of the dns entries being zero-terminated be changed as well? And although the strings are counted, should that necessarily mean that strings shouldn't be null-terminated, or only that they need not be null-terminated? [1]: http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionnrb [2]: http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionopt ___ 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] Problem with tools/win-setup.sh
Weir, Alan writes: > Suspecting a path issue I compared the win-setup.sh from the 1.4 and 1.7 > releases and found that the four lines of the form: > > DEST_PATH=`cygpath --dos "$2"` > > Had been modified in 1.7 to remove the –dos flag. I > added this flag back in and re-ran the setup phase without any errors. > > Why was this flag removed? The log message for r34375 explains why the change was made. See: http://anonsvn.wireshark.org/viewvc?view=revision&revision=34375 ___ 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] Decode As... support
Akos Vandra writes:
> I would like to ask how does the Decode As... functionality work in wireshark?
> I have a CAN network, and on top of it there may be different
> higher-level protocols, depending on application.
> There is no identifier which would say that this belongs to protocol
> A, or protocol B.
>
> I think the best solution would be for the user to say that this
> network has proto A or proto B on top of CAN, and then it would pass
> the whole traffic to dissector B.
> I guess this would be the puprose of the Decode As... option, but how
> can I use it from within the CAN dissector code?
>
Akos Vandra writes:
> I guess this would be the puprose of the Decode As... option, but how
> can I use it from within the CAN dissector code?
I think one way would be for the CAN dissector to be modified so it registers a
dissector table that proto A, proto B, ... can then add their handle to. For
example (warning - untested pseudocode):
packet-socketcan.c:
proto_register_socketcan() {
...
can_dissector_table = register_dissector_table("can_somename", "CAN
some_ui_name", FT_SOMETYPE, BASE_SOMEBASE);
...
}
protoA.c:
proto_reg_handoff_protoA() {
...
protoA_can_handle = create_dissector_handle(dissect_protoA, proto_protoA);
dissector_add_handle("can_somename", protoA_can_handle);
...
}
Look in the Wirehshark sources at other dissectors for more/better examples.
- Chris
___
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] happy birthday, bug 5531!
Ed Beroset writes: > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531 > > It's been a year since it was originally submitted. As always, if there's anything I can do to help get this > into the main code, please let me know. I know a number of people that are waiting for it. And thanks again for > a mighty handy tool! > > Ed I know it can be frustrating when waiting for something so thanks for your continued patience. If it makes you feel any better, some bugs are over 6 years old. :) - Chris ___ 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 can I use the dissector of wireshark in my program?
Gisle Vanem writes: > The mainpage is at: > http://sourceforge.net/projects/packetyzer/ Network Expect is another tool that comes to mind which uses libwireshark. The home page is here: http://netexpect.org/wiki Or check out the list of other tools on the wiki: http://wiki.wireshark.org/Tools - Chris ___ 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] debuging with MVS 2008
Yosi Saggi writes: > Any help wil be greatly appreciated Generally, I just compile Wireshark and then run it directly from the wireshark-gtk2\ directory then attach to Wireshark from your debugger. If you've built your plugin correctly with all the right makefile,etc., changes, your dll should be copied to the wireshark-gtk2\plugins\ver\ directory automatically with all the other plugins. ___ 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] Deteccting minor version at compile time for plugin
Colin Helliwell writes: > Is there a mechanism already built into the build structure to detect the minor version at compile time? Not yet. See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6134 ___ 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] Simplifying (and fixing) tvbuff [Long]
Bill Meier writes: > I think the long description boils down to the following: > > Consider the collection of tvbs (chain) as a stack of tvbs. > > packet.c pushes the initial tvb onto the stack then calls next > dissector; After the dissection is complete, the stack is eventually > free'd via a call to tvb_free_chain in epan_dissect_cleanup. > > A dissector: > - can add new tvbs (real, subset, composite) to the stack handed to it; >(Subset and Composite tvbs should reference only tvbs which are > towards the beginning of the same stack). > - must not save a pointer to a tvb from that stack (handed to it) >for use when dissecting another frame (since a >higher level function may very well free the stack); > - can create its own tvb stack which the dissector is free to manage >as desired. Bill, this information, plus the recent post entitled, "buffer to tvb", got me wondering if there is perhaps enough useful information here worthy of a separate doc/README.tvbuff? - Chris ___ 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] Using regular expression match as custom column
William writes: > Hello,With Wireshark, I can't seem to be able to do either of these: > 1. Export to file the exact contents of the columns that are displayed and nothing more You should be able to do this using 'File -> Export -> File -> as "Plain Text" file ...', then deselect the Packet details box. Or you could try to export to CSV. > 2. Create a custom column that contains the results of a matched regular expression This is not currently supported. ___ 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] Console Window option moved?
Akos Vandra writes: > I can find references to a console window within wireshark that could > be used to debug dumpcap, but I cannot find the option on the place it > is supposed to be. > In the wireshark tips it sais that it should be under > edit->preferences->user interface, but it's nowhere to be found. > I am using the trunk version. Has it been moved somewhere? I cannot > find on any tab in edit->preferences. That's its location, but it would only be present for the Windows version. But I don't see how that would help you debug dumpcap. ___ 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] tap_queue_packet() simple question
Some taps, such as tap-comparestat.c and tap-rtp-common.c, make use of pinfo->iphdrlen, so shouldn't tap_queue_packet() be called *after* all the pinfo data is assigned by the dissector? I had already changed this to be the case for IPv4 (see line 2079), but I just found the same thing in IPv6 (line 1976), so now I just want to be sure I'm doing this right, or maybe there's some reason this wasn't being done for both of them? Thanks. - Chris ___ 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] Win32 build from 1.6.3 source tarball: svnversion.h missing and not generated?
Gerald Combs writes: > On 11/18/11 9:08 AM, Pascal Quantin wrote: > > Since Gerald's commit in revision 39924 everything is back to normal > > (plugin folder is named 1.7.1) :) > > The release revision mismatch should be fixed. I can't duplicate it > here, at least. In the current /trunk and /trun-1.6 revisions you can > set the release revision with "make-version.pl --set-release" and clear > it with "make-version.pl --set-version". I don't think we've ever > handled outdated SVN-x directories. The buildbots take care of them > either by deleting the entire source directory before a checkout or by > purging any non-versioned files. I have to remove them by hand locally. Ah yes, an "svn revert config.nmake" was needed. My file is normally modified in order to properly set the MSVC_VARIANT so I didn't think anything of it being modified. Thanks. ___ 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] Win32 build from 1.6.3 source tarball: svnversion.h missing and not generated?
Gerald Combs writes: > I updated make-version.pl to clarify the different things that it does. > It can now store the SVN revision in config.nmake, which can then be > used to rebuild svnversion.h. Updating config.nmake was a lot easier > than a post-commit hook since we were storing other version information > there. I compiled r39937 on Windows XP SP3 (32-bit), but the plugins directory created was wireshark-gtk2\plugins\1.7.1-SVN-39921. Is this to be expected? If so, when exactly would the directory name change to reflect the actual revision? Also, unless a distclean is done, when it does change, will you be left with outdated SVN-x directories? If so, should a modification be made to wipe out any stale directories that might be present? Thanks. - Chris ___ 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] Buildbots stuck?
The Windows-XP-x86 and Ubuntu-10.04-x64 buildbots both appear to be stuck. Their status indicates "building", but there's been no activity for some time. ___ 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] Clang warnings in packet-csn1.c - how to fix?
The following clang warnings look legit to me and are the result of pui8 not being initialized before being used in the CSN_RECURSIVE_TARRAY, CSN_RECURSIVE_TARRAY_2 and CSN_RECURSIVE_TARRAY_1 cases. Anyone know what pui8 should be initialized to in those cases? Line 12: packet-csn1.c:1395:21: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage Line 13: packet-csn1.c:1332:23: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage ___ 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] packet-rlc.c problems
Gisle Vanem writes: > Ok, good. Similar problem with packet-spice.c; > epan/dissectors/packet-spice.c(588) : error C2371: 'POINT' : redefinition; different basic types > g:\VC_2010\SDK\include\windef.h(343) : see declaration of 'POINT'. > > So I suggest we rename 'POINT*' to 'SPICE_POINT*'. Attached 'svn diff packet-spice.c'. I prefer to use xyz_t for typedefs, so I checked in a different patch. It also makes it a little clearer (I think) the difference between a POINT and a POINT16, i.e., the new names are point32_t and point16_t, respectively. If there's still a naming conflict somewhere after this, then I guess we can prepend spice_ to them. - Chris ___ 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] packet-rlc.c problems
Gisle Vanem writes: > Can we rename 'PCCH' to something more sensible? Should be fixed in r39865. Hopefully the names I've chosen are sensible enough. ___ 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] Debugging on Windows
Stephen Fisher writes: > In 2008? It used to work for me, but didn't the other day. I didn't > spend too much time troubleshooting though. In 2010, they took the > feature out. Can you check your Tools -> Settings? Is it set to "Basic Settings"? If so, try selecting "Expert Settings". ___ 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] Debugging on Windows
Stephen Fisher writes: > On Mon, Nov 14, 2011 at 05:34:22PM +0000, Chris Maynard wrote: > > > Hmm, I've had no problems doing that, running on either Windows XP SP3 > > (32-bit) or Windows 7 64-bit. > > In 2008? It used to work for me, but didn't the other day. I didn't > spend too much time troubleshooting though. In 2010, they took the > feature out. I successfully use it fine with either 2008EE or 2010EE. It's under Tools -> Attach to Process ... (Ctrl+Alt+P), for both. I'm running with 2010EE Service Pack 1 (KB983509). Maybe you're running w/out the service pack and that's the reason??? Here is some additional information from my installation: Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel Microsoft .NET Framework Version 4.0.30319 SP1Rel Installed Version: VC Express Microsoft Visual C++ 2010 x-xxx-xxx-x <= redacted Microsoft Visual C++ 2010 Express - ENU Service Pack 1 (KB983509) KB983509 This service pack is for Microsoft Visual C++ 2010 Express - ENU. If you later install a more recent service pack, this service pack will be uninstalled automatically. For more information, visit http://support.microsoft.com/kb/983509. ___ 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] Debugging on Windows
Stephen Fisher writes: > On Sat, Nov 12, 2011 at 11:12:07AM -0500, Bill Meier wrote: > > > (Note: Wireshark builds with VC2008 but VC2010 should also be OK). > > VC2010EE doesn't let you use the debugger to attach to a running process > anymore like VC2008EE lets you do (although I couldn't get it to > properly debug the other day using attach to process when I switched > back to 2008EE). Hmm, I've had no problems doing that, running on either Windows XP SP3 (32-bit) or Windows 7 64-bit. ___ 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] misleading description on Wireshark Download page
Gerald Combs writes: > It's easy enough to disable the "Development Release" section of the > download widget until a development snapshot or release candidate is > ready. We could also replace the download list with a link to > http://www.wireshark.org/download/automated/ but that would require a > bit of navigation on the part of the user. Do you think it would help users to more easily try out the automated releases if we built and posted versioned packaging_zip files along with the installers? - Chris ___ 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] misleading description on Wireshark Download page
Balint Reczey writes: > We already provide automated development builds at > ftp://ftp.wireshark.org/automated/ . > I think those are enough. Distributions are also free to package svn > snapshots. That's true, but those automated builds aren't announced on the wireshark- mailing list(s) when they're made, nor do they appear center-stage on http://www.wireshark.org/ with the other other stable releases, so I suspect that there are a lot of users out there that aren't even aware of them. The other thing about the development release is that it's sort of an indication from the development team that, "yeah, this is a development release and you might encounter some problems with it, but we believe it's at least in reasonable enough shape that you should find it useful for most purposes". Contrast that with automated releases which could contain features in just about any state of development. Unless you're following along closely to wireshark-dev, wireshark-bugs, etc., you probably don't have a good sense of which automated release is likely OK to use and which you should probably avoid. Well, I don't have any particularly strong opinion on this matter either way, but I'm just presenting some counter-arguments as food for thought. - Chris ___ 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] misleading description on Wireshark Download page
Balint Reczey writes: > > Why not release a new dev release (based on trunk) to each new release > > of 1.6.x/1.4.x ? > Why should we? The svn repository is public. Perhaps so more people could try the development releases without requiring them to build it themselves? But that said, I'm not sure a 1-1 development-to-stable release schedule is necessarily the right way to go either since there may be features in progress on the development branch that aren't ready for prime-time when a new stable release is made. - Chris ___ 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] Ordinary LUA dissector.
Eliot Blennerhassett writes: > Is there any interest in including a more "ordinary" dissector example > on the wiki, or with the wireshark install for that matter? Lua dissectors/examples are not currently being distributed with the installer, not that that couldn't change in the future, but there is apparently enough interest so you might want to post it on the wiki. Likely locations are http://wiki.wireshark.org/Lua/Dissectors or http://wiki.wireshark.org/Lua/Examples. Thanks. - Chris ___ 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] Looking for h248/asn1 packet traces
Alex Lindberg writes: > I am looking for examples of h248/asn1 based packet captures to validate my my custom plugins for h248. All h248 versions (1, 2 and 3).The only examples on the sample captures page only include MEGACO (text based) examples. http://wiki.wireshark.org/SampleCapturesIf you have any you wish to share please post them to the above wiki or you may send them to me directly. alind...@yahoo.com Thanks for your help.Alex Lindberg There seem to be a number of possibly useful h248-related capture files in the Wireshark menagerie. I wonder if some automated method for producing a summary of protocols contained within each capture file or at least allowing one to execute a protocol query against the menagerie could be added somewhere/somehow and then easier access to them given instead of having to search bugzilla for them ... perhaps by anonymous ftp or some other more convenient method? ___ 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.
Anders Broman writes: > > Should we use ENC_NA here too to prevent confusion? > My preference is the opposite use ENC_BIG_ENDIAN as that is the > "natural" encoding for the > protocol and ENC_BIG_ENDIAN is less confusing in my opinion. For what it's worth, I agree with Anders here. I tend to think of the endian as being associated more with the protocol than with each individual field, so I would prefer a consistent BIG (or LITTLE as the case may be) endian used throughout. I think this also has other potential advantages, e.g., if a multi-byte field is incorrectly coded as a 1-byte field then later fixed, or if a single-byte field is later expanded to a multi-byte field through a protocol update, the endianness won't have to be changed from ENC_NA to ENC_[BIG|LITTLE]_ENDIAN. And of course, the fact that ENC_NA is the same as ENC_BIG_ENDIAN only introduces more potential problems for little-endian protocols. - Chris ___ 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.
Bill Meier writes: > In this case, given the specifics, I found it fairly simple to do what I > needed in Perl. Should these functions be modified to take an encoding argument instead of a little_endian argument, then the Perl script run on them as well to convert TRUE/FALSE to ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN? tvb_fake_unicode() tvb_get_ephemeral_faked_unicode() proto_tree_add_bitmask() proto_tree_add_bitmask_text() proto_item_add_bitmask_tree() <= static in epan/proto.c only - Chris ___ 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] modelines
Guy Harris writes: > On Sep 28, 2011, at 2:21 PM, Bill Meier wrote: > > > On 9/28/2011 4:57 PM, Jeff Morriss wrote: > >> > >> I'll argue that *tab*stops should be 8 until someone shows me how to > >> tell all the various terminal programs I end up using that the file I'm > >> currently looking at (in 'less' or 'grep' or plain old 'cat') that the > >> file in question is using an alternative tabstop. (Or until I'm blue in > >> the face or dead or whatever .) > >> > > > > +5 ! > > +10^(10^100) > > The UNIX tty driver, the default tab settings you get from e.g. tset, and the default tab settings in most if > not all UN*X terminal emulators do 8-space tabs. (Xcode didn't get the memo, which is why > > http://www.opensource.apple.com/source/autofs/autofs-207/autofs.xcodeproj/project.pbxproj > > has a bunch of entries that say "indentWidth = 8".) Gerald has a table of "official" coding standards posted at http://www.wireshark.org/tools/modelines.html, and it looks like in the Microsoft world, 4 is the standard. But no matter, I took a chance that the defaults generated from that online tool were the preferred settings, so that's what I used in the r39178 commit to README.developer. Those defaults, by the way, are: shiftwidth=4 tabstop=8 and expandtab. In case those settings aren't actually preferred then we might want to decide quickly what we do want and make the change(s) soon before lots of people start submitting dissectors using that as the standard. - Chris ___ 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] modelines
Stephen Fisher writes: > Since I started coding for Wireshark in 2006, the convention wisdom (as > I understood it) has always been to stick with the formatting method > that the file already has, whatever that may be. Right, but what if there's a file already consistently using tabs throughout, but with no current modelines? (Example: packet-igmp.c) What value to use for the tabstop, for example? It would seem that tabstop=8 is preferred, judging by the number of epan/dissectors/packet-*.c files using that value (54) as opposed to using tabstop=4 (3); however, I am wondering if 8 is simply used more than 4 because that's what the Wireshark modeline generation tool happens to default to, so I just wanted to check if that was in fact the recommendation or if it was just a somewhat arbitrary choice, and if arbitrary, then what the actual recommendation would be. > Emacs is pretty good > about keeping the same indentation as the line above the one you're > inserting, although it may differ in spaces vs. tabs. Hence the inquiry about adding setq tab-width, [and implicitly indent-tabs-mode too). As more and more modelines get added, I was just thinking that it might be nice to have as many common editors covered as reasonably possible instead of adding some now and having to go back again to add more later. >I'm one of the > few fans of actual tabs. Whatever the preference, I think having mode > lines is a great choice so we don't have to bother (we can be lazy) > changing our editor/remembering to format it a certain way to keep it > consistent :). I really like the modelines too; I guess I'm also lazy. ___ 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] modelines
A couple of questions/thoughts on modelines[1]: 1) Should emacs (and other) modelines be added to the generated modelines at [1], e.g., setq as mentioned by Zawinski[2]? 2) In the absence of any other user preference, what is the Wireshark recommendation on modeline settings, if any? The following seems to be the default settings generated at [1], so am I right to assume that would be the recommendation - at least for files with all (or mostly) spaces and tabs? /* * Editor modelines - http://www.wireshark.org/tools/modelines.html * * Local variables: * c-basic-offset: 4 * tab-width: 8 * indent-tabs-mode: nil * End: * * vi: set shiftwidth=4 tabstop=8 expandtab: * :indentSize=4:tabSize=8:noTabs=true: */ And for files with all (or mostly) tabs instead of spaces, would the recommendation be to stick with tabs and adjust the modelines above slightly as follows: /* * Editor modelines - http://www.wireshark.org/tools/modelines.html * * Local variables: * c-basic-offset: 4 * tab-width: 8 * indent-tabs-mode: t * End: * * vi: set shiftwidth=4 tabstop=8 noexpandtab: * :indentSize=4:tabSize=8:noTabs=false: */ Thanks. - Chris [1] http://www.wireshark.org/tools/modelines.html [2] http://www.jwz.org/doc/tabs-vs-spaces.html ___ 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 from the Email List
Wang, Xiaodong writes: > I had one question: How can my email be removed from the > group? See: https://www.wireshark.org/mailman/listinfo/wireshark-dev ___ 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] catching [Malformed Packet]
Roland Knall writes: > On a similar topic, how can you mark a package as malformed? > Especially generated packages often fail the openSAFETY dissector, and > marking them as malformed seems to make sense in such cases. Many dissectors make use of the expert infos for this. Search for expert_add_info_format and PI_MALFORMED for examples. ___ 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] catching [Malformed Packet]
writes: > Is it possible to setup a display filter to catch all malformed packets (those noted as [Malformed Packet] in Info column)? I'm working with a dissector that could probably use a little more "graceful" error checking and I have a few large capture files that I'd like to use to catch any malformed packets created by the current dissector. malformed ___ 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] Reassembling Packets need some help plz
Marcel Haas writes: > Nobody an idea ? Hi Marcel, I'm sorry to say that I don't have any helpful advice for you. The problem is that reassembly can be very complicated, as you've discovered I'm sure. My personal experience with reassembly is limited, and fortunately for me, I've been lucky enough to able to make use of tcp_dissect_pdus() to do the most difficult work for me. In your case however, you're apparently not so lucky. But please don't be discouraged by the lack of feedback from the list. I think it only means that your situation is complicated and nobody has a very good solution for you or the time to really think through it thoroughly enough to provide you with some meaningful enough assistance. I hope you are able to work through your problem and come up with a solution. And if you do, you might even be so gracious as to share your results so that others can benefit from your experience. - Chris P.S. This same message also goes out to Martin Kaiser, who queried about similar complicated reassembly back in August ... although I *think* Martin was able to resolve his issue as I no longer find an open DVB-related bug with his name on it. (See http://www.wireshark.org/lists/wireshark-dev/201108/msg00243.html) ___ 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] Buildbot error messages
Gerald Combs writes: > In order to reduce the volume of messages on wireshark-dev, error > messages from buildbot.wireshark.org are now being delivered to > wireshark-commits. > > Unfortunately, due to a misconfiguration on my part, buildbot error > messages for the last 10 days have been lost. My apologies for any > inconvenience. Inexcusable. Oh wait, you mean you're human after all? :) ___ 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] Problem in building Plugin
Chris Maynard writes: Or are you trying to get your new plugin to work with an older version of Wireshark, one prior to the following change? http://anonsvn.wireshark.org/viewvc/trunk/epan/reassemble.h?r1=32933&r2=35705 ___ 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] Problem in building Plugin
Rajesh P S writes:
> Refer Example 9.17. Reassembling fragments - Data . I am using the same code.
Also I have compiled this code so many times before[about an year ago with
wireshark 1.2.6]. But that time it worked fine. On this occasion it is giving me
this error.
Yes, you're right. I hadn't actually looked at reassemble.h and assumed it was
meant to be a comment.
Did you happen to modify reassemble.h, possibly deleting one of the int *
members of fragment_items? Can you verify that your epan/reassemble.h file
contains a fragment_items typedef that looks like the following?
typedef struct _fragment_items {
gint*ett_fragment;
gint*ett_fragments;
int *hf_fragments;
int *hf_fragment;
int *hf_fragment_overlap;
int *hf_fragment_overlap_conflict;
int *hf_fragment_multiple_tails;
int *hf_fragment_too_long_fragment;
int *hf_fragment_error;
int *hf_fragment_count;
int *hf_reassembled_in;
int *hf_reassembled_length;
const char *tag;
} fragment_items;
___
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] Problem in building Plugin
Rajesh P S writes: > I am getting this error [error C2220: warning treated as error - no 'object' file generated, warning C4133: 'initializing' : incompatible types - from 'char [18]' to 'int *] even though I haven't used char [18] or int*. Yes, you have: > "Message fragments" I think you probably meant: /* "Message fragments" */ ___ 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] AthTek NetWalk
I saw this today: http://www.giveawayoftheday.com/athtek-netwalk-packet-monitor/ Maybe others would be interested in checking it out? By the way, they also offer a free personal edition if you decide not to install the enterprise edition or miss the deadline: http://www.athtek.com/netwalk/free.html Their product is not [yet] listed on http://en.wikipedia.org/wiki/Comparison_of_packet_analyzers, so I thought I'd pass this information along. I am not affiliated with them, but I do find it interesting to see what features other sniffers provide. I'm not so sure about their claim though: "AthTek NetWalk is the ONLY network analysis tool to offer full integration with Wireshark, and it performs better than using Wireshark. It has better speed, enables large trace files, and is more stable than Wireshark." ___ 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] OpenSafety bug - how to fix?
Roland Knall writes: > > The fix is correct. Are there any other Coverty hits for openSafety, > or just the one? Hi Roland, There are 6 in total. Besides 1204, there are these 5 more reported: CID 1215: NULL RETURNS: In stringToBytes(), strtok() could return NULL at line 418, but the return value is not checked against NULL as it is in other places, even further down in the same function at line 427. CID 1224: SIZEOF MISMATCH (2 instances): In dissect_opensafety_ssdo_message() at lines 932 and 951, Coverity reports, "suspicious_sizeof: Passing argument "sizeof (guint8 *) /*8*/ * payloadSize" to function "ep_alloc" and then casting the return value to "guint8 *" is suspicious." These 2 seem benign to me and can probably be ignored? CID 1246/1247: FORWARD NULL/REVERSE INULL: In opensafety_package_dissector(), pinfo is checked for being non-NULL at line 1374, implying that it could be NULL; yet it is passed to functions that dereference it before checking against NULL (such as add_new_data_source() at lines 1278 and 1284, call_dissector() at line 1370, etc.) Can pinfo really ever be NULL? If not, the easiest thing to do might be just to remove the check at line 1374. If you could submit a patch fixing all these, it would be appreciated. Thanks, - Chris ___ 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] OpenSafety bug - how to fix?
Coverity reports the following in CID 1204 against the OpenSafety dissector:
1466firstByte = ( tvb_get_guint8(message_tvb, 0) << 1 );
Event missing_parentheses: !firstByte & 0x40 is always 0 regardless of the
values of its operands (non-specific value). Did you intend to apply '&' to
firstByte and 64? If so, parentheses would be required to force this
interpretation.
1467if ( ( (!firstByte) & 0x40 ) != 0x40 )
1468{
1469result =
opensafety_package_dissector("openSAFETY/SercosIII", "sercosiii",
1470FALSE, FALSE, message_tvb, pinfo, tree);
1471}
So, should line 1467 read something like this instead?:
1467if ( !((firstByte & 0x40) == 0x40) )
Can someone with knowledge of the OpenSafety dissector confirm if this is the
right fix?
- Chris
___
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] Capture filter
Tharaneedharan Vilwanathan writes: > $ tshark -i pipe_to_tshark -w test.pcap -f 'udp port 1900' > $ tshark -i pipe_to_tshark -S -f 'udp port 1900' > $ tshark -i pipe_to_tshark -w test.pcap -S -f 'udp port 1900' > > In all the above cases, packets dont seem to be filtered. From the > documentation, it looks like capture filter is valid only for live > traffic. See bug 1814: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1814 ___ 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] Ready to remove all non-ui-manager code?
Joerg Mayer writes: > would it be OK to remove the non-UI-MANAGER code in gtk/? > I haven't seen any ongoing work in that area, so what (if anything) is > missing from the UI-MANAGER codebase? > The only things that come to my mind are the proto_help stuff and the > gtkvumeter stuff. The proto_help stuff isn't really cared for by its > original author and so far nobody has stepped up to convert it. If I > remember the discussion about gtkvumeter correctly, it may be either > removed or replaced by some other vumeter. > Are there any other points? > If there are no convincing arguments and nobody beats me to it, I'll remove > the old stuff about a week from now. Personally, I'd like to see the proto_help stuff be supported again, but unfortunately I don't have enough gtk knowledge to accomplish this myself in the near future. My interest is not so much with Inacon (although their freely available protocol help is very good, in my opinion), but more with being able to provide at least some free apropos protocol help whether it's from Inacon, Wireshark's wiki, or from elsewhere. To that end, I opened bug 4870[1]. What I still don't know is how to best integrate/distribute the free Inacon and alternate help files I provided with Wireshark, assuming of course that they would be useful to others as well - perhaps not so much to those monitoring this list, but in particular to Wireshark and protocol analysis newcomers. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4870 ___ 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] For TShark, provide a way to control the output format. E.g., 'tshark -e "ip udp tcp.port"' would expand the IP and UDP sections, and display the TCP port information.
Guy Harris writes: > On Sep 13, 2011, at 4:05 PM, Yee Man Bergstrom wrote: > > > From http://wiki.wireshark.org/WishList > > For TShark, provide a way to control the output format. E.g., 'tshark -e "ip udp tcp.port"' would expand > the IP and UDP sections, and display the TCP port information. > > > > This is already done in trunk as of revision 38990 unless I am missing something. > > > > You can perform the above scenario with > > Ø tshark –T fields –e ip –e udp –e tcp.port > > Well, not exactly. The wish list request was for "-T text" (which is the default), not "-T fields". > Expanding the IP and UDP sections can be done in that format with -O, but partially expanding the TCP > section to show only the port can't be done that way. But the -e option isn't valid without -T fields, so that implies that -T fields was erroneously omitted in the wish list request, does it not? Regardless, it's not currently possible to simultaneously specify -V -O along with -T fields -e . The inclusion of -T fields -e overrides the -V -O options. ___ 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] For TShark, provide a way to control the output format. E.g., 'tshark -e "ip udp tcp.port"' would expand the IP and UDP sections and display the TCP port information.
Yee Man Bergstrom writes: > Can someone familiar with when this was done update the wiki page http://wiki.wireshark.org/WishList? I updated the page. ___ 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] text2pcap regression starting from revision 38679
Pascal Quantin writes: > Hi all,since the commit for bug 1723 (done in revision 38679), I'm facing issues with text2pcap for really small packet dumps. > > I guess this is unexpected behavior and should be considered as a bug. Do you agree ? I do and have reopened bug 1723 as a result. Hopefully, the author of the text2pcap patch submitted in that bug report is able to fix it. ___ 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] Wireshark 1.6.1 improperly parsing 802.11 Beacon
Alexis La Goutte writes: > Hi Daniel,Please open a bug in Bug Tracker ( https://bugs.wireshark.org/bugzilla/ ) with your sample.There is big change between Wireshark 1.2.x and 1.6.x in 802.11 dissector FYI ... bug 6264 has been filed on Daniel's behalf. ___ 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] can I generate windows-used plugin on Linux?
John x writes: > Hi, folks,I developed wireshark plugin for Linux (which is .so). I am wondering whether I can generate plugin for windows(which is .dll) from Linux?If yes, how to do that?Thanks The only way I can think of is if you install Windows in a VM on your Linux box and build it from there, but it's not possible to build a Windows .dll from Linux directly, at least not any way that I'm aware of. ___ 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] Problem compiling Wireshark 1.6.1
Andreas writes: > Am 23.08.2011 22:30, schrieb Chris Maynard: > > Andreas writes: > > > >> Yes, I tried. I need only libwireshark. That's why I reduced the make > >> targets to build. But, alas, I get exactly the same result, when I > >> "nmake all". > > > > Can you verify that MSVC_VARIANT is set correctly in config.nmake? > > MSVC_VARIANT=MSVC2008 matches with my compiler. Just to be sure, you might try another: nmake distclean nmake all [fail] nmake all (again) If you still don't progress any further and can live w/out zlib support temporarily just so you can get on with the rest of your work, you could try commenting out ZLIB_DIR in config.nmake. Also, you may want to recheck that you followed all steps in the developer's guide: http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html One other thing that *might* be a problem (whether it's related or not, I don't know) is that you have python 2.7 installed and the notes in config.nmake indicate the following: # NOTE: The Python library must have been compiled with the same # compiler (MSVC_VARIANT) as Wireshark. Known python.org Python # CRT versions: # # Python versionCRT (32-bit)CRT (64-bit) # 2.4.4 7.1 ? # 2.6.1 9.0 ? # 2.6.2 9.0 ... so this tells me you should probably be using 2.6.1 or 2.6.2. ___ 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] Problem compiling Wireshark 1.6.1
Andreas writes: > Yes, I tried. I need only libwireshark. That's why I reduced the make > targets to build. But, alas, I get exactly the same result, when I > "nmake all". Can you verify that MSVC_VARIANT is set correctly in config.nmake? ___ 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] Crash in gtk/conversations_table.c
Gisle Vanem writes: > "Guy Harris" wrote: > > >> and pressing the "Follow stream" button, > > > > It let you press "Follow stream"? I did a capture on the loopback interface, and got > > a window with no conversations, and the "Follow stream" button was grayed > > out > > Not greyed out here. No idea why. It should. I committed your patch in r38677. Until the button is fixed so it's grayed out or greyed out or graid out or grade out, then at least we'll avoid crashing. ___ 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] No postings to wireshark-dev in July?
Chris Maynard writes: > http://www.wireshark.org/lists/wireshark-dev/ or to -users: http://www.wireshark.org/lists/wireshark-users/ or to -commits: http://www.wireshark.org/lists/wireshark-commits/ or to -bugs: http://www.wireshark.org/lists/wireshark-bugs/ or to -announce: http://www.wireshark.org/lists/wireshark-announce/ ... although there really might not have been any to -announce. ___ 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] No postings to wireshark-dev in July?
http://www.wireshark.org/lists/wireshark-dev/ ___ 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] PATCH: btl2cap extended window shows wrong bit
Jaap Keuter writes: > We're not the Linux kernel, hence we have to find our own way forward. > We found that too many patches were lost in the email archives for > various reasons. > > On Fri, Aug 19, 2011 at 6:49 PM, Stephen Fisher > > wrote: > > > >> Please submit patches by opening a bug at > >> https://bugs.wireshark.org/ > >> so they don't get lost? Thanks. FYI: I filed bug 6257 on Andrei's behalf: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6257 ___ 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] Problem compiling Wireshark 1.6.1
Andreas writes: > 7. nmake -f Makefile.nmake config.h tools image codecs wsutil epan Did you try "nmake -f Makefile.nmake all" as documented in the developer's guide? See: http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#id505663 ___ 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] Store a string in temporary tvb buffer and read it using function proto_tree_add_item
Jeff Morriss writes: > On 08/18/2011 12:41 PM, Mrunal Upadhyay wrote: > > Dear All, > > > > Is there a way to store a string in a temporary tvb buffer and then in > > the dissection logic use this tvb buffer in the in order to read this > > temporary string using function proto_tree_add_item and assign it to one > > of the filter fields. > > Sure, use tvb_new_real_data() to create a TVB which points to some > memory. Do be aware that the memory has to stick around for a while so > you may also need to use tvb_set_free_cb() so you can know when to free it. I don't know, but my guess is that you probably don't really want to do that. Try looking at the proto_tree_add_string*() functions instead. ___ 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] can't filter field in wireshark
writes: > I put the result in Wireshark with the > "proto_tree_add_text" > function, but it's impossible > to filter this field because it's a text ! > can someone help-me ??? > regards Don't use proto_tree_add_text(). To quote doc/README.developer: proto_tree_add_text() is used to add a label to the GUI tree. It will contain no value, so it is not searchable in the display filter process. This function was needed in the transition from the old-style proto_tree to this new-style proto_tree so that Wireshark would still decode all protocols w/o being able to filter on all protocols and fields. Otherwise we would have had to cripple Wireshark's functionality while we converted all the old-style proto_tree calls to the new-style proto_tree calls. In other words, you should not use this in new code unless you've got a specific reason (see below). ___ 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 increase length of display filter drop down list?
eymanm writes: > It looks like when I use display filter drop down list, Wireshark lists ten most recently used filters. I'd like to increase this number to let's say 20 lines. Can somebody suggest how to do it? Edit -> Preferences -> Filter display max. list entries: 20 ___ 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] CaveBear's Ethernet link is dead
Ed Beroset writes: > Joerg Mayer wrote: > http://www.cavebear.com/archive/cavebear/Ethernet/Ethernet.txt > > > > If this file has been static for so long, how about integrating its content > > into our template file? > > That's probably the best idea, and then just have the link as > documentation. In fact, if anybody's interested, I'll do a delta of the > IEEE and CaveBear list and only extract the unique bits for exactly that > kind of inclusion. Well, the output of make-manuf displays those added from cavebear (see the 27 entries below) ... but if this list is so old, can these really be relied upon anymore? Fetching http://www.cavebear.com/archive/cavebear/Ethernet/Ethernet.txt. 00:48:54 - "Digital SemiConductor21143/2 based 10/100" 00:4F:49 - "Realtek" 00:4F:4B - "Pine Technology Ltd." 00:55:00 - "Xerox" 02:04:06 - "BBN internal usage (not registered)" 02:60:60 - "3Com" 02:A0:C9 - "Intel" 02:E0:3B - "Prominet Corporation Gigabit Ethernet Switch" 04:88:45 - "Bay Networks token ring line card" 08:00:10 - "AT&T [misrepresentation of 800010?]" 10:00:E0 - "Apple A/UX (modified addresses for licensing)" 2E:2E:2E - "LAA (Locally Administered Address) for Meditech Systems" 40:00:03 - "Net Ware (?)" 44:46:49 - "DFI (Diamond Flower Industries)" 47:54:43 - "GTC (Not registered!)(This number is a multicast!)" 48:44:53 - "HDS ???" 48:4C:00 - "Network Solutions" 48:54:E8 - "winbond?" 4C:42:4C - "Information Modes software modified addresses (not registered?)" 52:54:00 - "Realtek (UpTech? also reported)" 52:54:4C - "Novell 2000" 52:54:AB - "REALTEK (a Realtek 8029 based PCI Card)" 56:58:57 - "Aculab plc audio bridges" 80:AD:00 - "CNET Technology Inc. (Probably an error, see instead 0080AD)" C0:00:00 - "Western Digital (may be reversed 00 00 C0?)" EC:10:00 - "Enance Source Co., Ltd. PC clones(?)" E2:0C:0F - "Kingston Technologies" ___ 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] CaveBear's Ethernet link is dead
Chris Maynard writes: > Ed Beroset writes: > > > That seems actually to be the last revision. The "current" CaveBear > > link is: > > > > http://www.cavebear.com/archive/cavebear/Ethernet/Ethernet.txt > > ... except that page has the same dead link back to > http://www.cavebear.com/archive/cavebear/Ethernet/index.html, which is really > what we need. OK, my mistake. I was expecting the format of the page to be more like http://standards.ieee.org/develop/regauth/oui/oui.txt, but that's the right one. I updated the script with the new link. Thanks. ___ 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] CaveBear's Ethernet link is dead
Ed Beroset writes: > That seems actually to be the last revision. The "current" CaveBear > link is: > > http://www.cavebear.com/archive/cavebear/Ethernet/Ethernet.txt ... except that page has the same dead link back to http://www.cavebear.com/archive/cavebear/Ethernet/index.html, which is really what we need. ___ 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] CaveBear's Ethernet link is dead
The tools/make-manuf script attempts to gather Ethernet codes from IEEE, but also from CaveBear at http://www.cavebear.com/CaveBear/Ethernet/Ethernet.txt, but unfortunately this link is dead. I could not find any meaningful contact information to Karl Auerbach on the site other than Santa Cruz, CA, which isn't all that helpful. CaveBear's, "Ethernet Codes Master Page" contains Ethernet code links to other sites and mirrors, but the only one that seems to work is the MIT one, namely http://www.mit.edu/~map/Ethernet/Ethernet.txt. From what I can tell though, that page hasn't been updated since 1999/03/09, so that's also not very helpful. So ... should we use the MIT link instead, try to contact Karl somehow, or just eliminate the CaveBear URL altogether and stick with IEEE? I was about to commit a change to remove it, but I figured I'd check here first. ___ 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] Custom dissector and info column issue
Graham Bloice writes: > I added your dissector to my build, cut down the capture file to only include > frames 1 & 3 and attached a debugger to see what was happening. > > This might be a bug. Graham, I had come to the same conclusion. It seems like a bug to me and would suggest opening a bug report for it. The comments surrounding the "if(another_pdu_follows)" seem to make sense; however, it seems that somewhere the columns need to be made writable again before handing off the next reassembled packet. And for Chris Miller, a little more feedback on your dissector: 1) You are using port for your dissector. If possible, you shouldn't use that port since it is reserved for personal-agent. See http://www.iana.org/assignments/port-numbers for the list of registered ports. If you must use , then consider adding a port preference to your dissector so you change it later, if needed. 2) You probably want to use BASE_DEC instead of BASE_HEX for some fields. 3) Running tools/checkhf.pl against your dissector produces errors that should be fixed. 4) Running tools/checkAPIs.pl against your dissector produces errors that should be fixed. ___ 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] calc row in wireshark graphs
sagar Guledagudda writes: > I found out generating graphs from statistics->IO graphs, when i tried to generate graphs with advanced version i found a row wirh label "calc" and i saw options like AVG(*), SUM(*), COUNT(*), MIN(*) etc, can any body help me understanding what they represent according to the graph ? how graph varies depending on these options ? Ideally this topic would be covered in the user guide, but unfortunately it hasn't been added yet. For now, you can find an explanation on the Wireshark man page under the "Statistics:IO Graphs" section: Ref: http://www.wireshark.org/docs/man-pages/wireshark.html ___ 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] Undefined symbol tvb_find_tvb
Jeff Morriss writes: > Remember that since r35145 (and probably some other revs as the kinks > got worked out), libtool-based builds only export the listed symbols. > (Hmmm, I wonder if cmake has that same functionality.) Ah, OK; I guess I missed that. Thanks for pointing it out. ___ 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] Undefined symbol tvb_find_tvb
Jeff Morriss writes: > Mariusz Okrój wrote: > > Hi, > > I'm getting "Couldn't load module > > /home/marok/wireshark/lib/wireshark/plugins/1.6.0/xmpp.so: > > /home/marok/wireshark/lib/wireshark/plugins/1.6.0/xmpp.so: undefined > > symbol: tvb_find_tvb" during the wireshark startup. > > > > What may cause this problem? I'm using many functions from tvbuff.h, > > but only using this one the problem occurs. > > I don't see a response to this, but the problem is/was that this > function is not in epan/libwireshark.def (so the function is not > exported from libwireshark). > > Chris fixed that in this revision: > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=38169 Sorry I forgot to respond. Thanks Jeff. I actually wasn't sure if this was the problem or not in Mariusz's case because wouldn't this only be a problem for a Windows plugin (i.e., xmpp.dll)? Well in any case, the function wasn't exported, so I added it, and since the problem was observed with 1.6.0, I just scheduled this change to be backported to 1.6.2. ___ 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] Showing FCS under Ethernet
kahou lei writes: > It is Ethernet FCS. I have checked that preference but 1.6.0 doesn't show any > FCS. > I don't think it is the same bug as my packet is just regular Eth/IPv4 header. Well, it's possible you've encountered a new bug. I suggest filing a new bug report, attaching the capture file in question, or at least a small subset of relevant packets from that capture file. ___ 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] error using proto_tree_add_time
sagar sg writes: > Hi, When i use the function proto_tree_add_time ( my_tree, hf_variable, tvb, 0, end_len, time_variable ) ; I get an error as "expected primary-expression before ',' token" .. I am compiling my code on linux. and i did not get any such error while compiling on windows. Any idea about this ?? How are all your proto_tree_add_time() arguments declared? ___ 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] Showing FCS under Ethernet
kahou lei writes: > I was debugging a packet via wireshark. I notice that version 1.6.0 doesn't show FCS info but version 1.4.2 does. > > Just wonder how can I enable showing FCS option in 1.6.0? Which FCS, Ethernet, IEEE 802.11, or something else? If Ethernet or IEEE 802.11, have you tried selecting the dissector's "Assume packets have FCS" preference? It might also be that you've encountered bug 3657: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3657 ___ 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 1.6.1 release notes question regarding libsmi
I was reading the 1.6.1 release notes from http://www.wireshark.org/docs/relnotes/wireshark-1.6.1.html, and noticed the following under "Known Problems": The 64-bit Windows installer does not ship with libsmi. (Win64 development page) Is this still applicable? I'm still working on 32-bit Windows, so I don't know for certain, but I seem to recall someone compiling libsmi for Windows 64-bit. Plus, it is mentioned as supported under http://wiki.wireshark.org/Development/Win64 and it's available in the latest packages directory here: http://anonsvn.wireshark.org/wireshark-win64-libs/tags/2011-06-27/packages/ Also under "Known Problems" is this: Character echo pauses in Capture Filter field in Capture Options. (Bug 5356) ... yet that same item is also listed under the "Bug Fixes section. - Chris ___ 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] Bad developer guide link
At the bottom of http://www.wireshark.org/develop.html under the "Get Help" section is a supposed link to the "Developer's Guide". It incorrectly brings you to http://www.wireshark.org/docs/ instead of somewhere more reasonable like http://www.wireshark.org/docs/wsdg_html_chunked/. ___ 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] proto_help.c
Alexander Koeppe writes: > Ah thanks. Sorry but I wasn't aware of it. > Unfortunately I receive an "Access Denied" page for some protocols e.g. > IPv6. I think this is some kind of the business model of INACON, isn't it? Right. They only provide some protocol help for free. For the rest, you need to purchase one of their licenses to access them. More details here: http://www.inacon.de/protocolhelp/det_content.php. But this is why I created the wireshark.ini help file submitted in bug 4870. For IPv6, wireshark.ini's help would bring you to http://wiki.wireshark.org/IPv6. This is nowhere near as good as Inacon's help would be, I'm sure, but it's better than no help at all, in my opinion. I had actually considered adding other protocol help files as well, such as networksorcery.ini and rfc.ini, but I was waiting to hear back about wireshark.ini first, and well, there didn't appear to be any interest, so I never went any farther with them. If you've never visited Network Sorcery's protocol help though, it's pretty good for being free, and they have a lot more protocols available for help than Inacon offers (for free at least). IPv6 is described on their page here: http://www.networksorcery.com/enp/protocol/ipv6.htm. The idea behind the rfc.ini protocol help file would be to bring you directly to the relevant RFC. So, for IPv6, it would bring you here: http://tools.ietf.org/html/rfc2460. Of course not all protocols are described by RFC's; so it might be better to name the protocol help file as spec.ini or something more generic like that, or just keep them separated as rfc.ini, 3gpp.ini, ansi.ini, ... ___ 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] Procedure to compile wireshark dissector on linux
Tony Trinh writes: > I like the CMake build better (easier to use and 'pretty') except for the verbose output, which is masochistically enabled by default. There's a comment that suggests the verboseness was meant to be temporary: > # Disable this later. Alternative: "make VERBOSE=1" > set(CMAKE_VERBOSE_MAKEFILE ON) > > Can we change the default to OFF? (especially since there's a command-line to turn it on but not off). I have yet to use CMake myself, but this seems like a reasonable request, so I committed this change in r38103. ___ 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] proto_help.c
Chris Maynard writes: > There is nothing to commit. Just to clarify, when I wrote that, I mean there is nothing to commit in order to support multiple help files. The bug I opened contains a sample wireshark.ini file, which could be committed if folks think there's any merit in doing so. > I don't know the order they get loaded though - alphabetical? I'm not sure. > I > can look at Wireshark's source code tomorrow though to see how they get > processed ... OK, I was able to look at this. Basically, there is no guaranteed order as the files are read using g_dir_read_name(), and according to the glib documentation: The order of entries returned from this function is not defined, and may vary by file system or other operating-system dependent factors. Reference: http://developer.gnome.org/glib/unstable/glib-File-Utilities.html#g-dir-read-name - Chris ___ 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] proto_help.c
Joerg Mayer writes: > Did you commit the code to suport several help files? How is the order of > the help entries decided if you have entries in more than one .ini file? There is nothing to commit. Just dump as many valid help.ini files in the protocol_help directory as you want and then start up Wireshark. Anytime you have help for a protocol in a frame, the option to get help from that file will be available. If there are multiple files supplying help, you'll get multiple help entries to choose from. If you make changes such as add a new help file, you'll need to restart Wireshark, as these files are only processed once. I don't know the order they get loaded though - alphabetical? I'm not sure. I can look at Wireshark's source code tomorrow though to see how they get processed ... ___ 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] proto_help.c
Joerg Mayer writes: > Btw, do we want to distribute and install the protocol_help stuff of the > light version with Wireshark? Personally I think their help is pretty darn good, so I would be in favor of it. ___ 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] proto_help.c
Joerg Mayer writes: > Just a question regarding the download: The download will only provide the > protocol_help/ph.ini file and to use it I need to be online? Or are the > pages also available offline? By default, inacon's protocol help is available at http://www.inacon.de/ph/data/, since that's the location specified at the top of the ph.ini file. But if you want help available even if not connected online, then all you need to do is download all their help to a local directory on your PC and change the location reference in the ph.ini file. I have done this myself, and it works, at least with version 1.4.4. I also renamed their generic ph.ini file to inacon.ini so I know which help file is which since I have three: protocol_help\ myhelp.ini inacon.ini wireshark.ini ... where myhelp.ini is help for my company's proprietary protocols, inacon.ini is the former ph.ini file, and wireshark.ini is essentially the help file I submitted with bug 4870. ___ 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] proto_help.c
Alexander Koeppe writes: > Are the protocol help files still maintained? > I can't find any on my system. > > ~/.wireshark$ find -name protocol_help > ~/.wireshark$ find ~/build/wireshark -name protocol_help > ~/.wireshark$ > > Why then keeping it? Inacon supplied their help files in bug 3045: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3045. But, my understanding is that since they were never incorporated into Wireshark, Inacon supplies those help files themselves; however, they rely on the support being there for it. But, Inacon is not the only set of help files possible. In fact, I opened bug 4870 to supply an alternate set of help files in addition to Inacon's. See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4870. Internally, I also supply help files for our proprietary protocols. ___ 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] Makefile for wireshark dissector
sagar sg writes: > Hi, I have written a dissector plug in in windows and it works fine, now i want to compile it in linux to get the .so file Try reading doc/README.plugins. ___ 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] Why isn't this a bug?
Chris Maynard writes: > Jaap Keuter writes: > > > Why isn't this a bug? > > It sure looks like a bug to me. Committed a change to correct this in r37957. ___ 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] Why isn't this a bug (2)?
Jaap Keuter writes:
> static gboolean
> check_msrp_header(tvbuff_t *tvb)
> {
> ...
> linelen = tvb_find_line_end(tvb, 0, -1, &next_offset, FALSE);
> /* Find the first SP */
> space_offset = tvb_find_guint8(tvb, 0, -1, ' ');
>
> ...
> }
>
> Why find the line length first, then to start searching to the end of the TVB?
> A comment suggests that tvb_get_ptr() was used previously, so this might be a
> botched rework of that code?
Currently neither linelen nor next_offset are used in that function after
assignment, so there's clearly something amiss here. To me, it looks like
"linelen = tvb_find_line_end(tvb, 0, -1, &next_offset, FALSE);" is just
superfluous, unneeded code that was probably due to "copy-and-paste" or rework
by the original author, as the code has been that way since day 1. See
http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-msrp.c?revision=14491&view=markup
___
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] Conversation and endpoints byte counts
Guy Harris writes: > What exactly do people want with those byte counts? I don't presume to know what one might want to use that data for. I am merely trying to report the most meaningful information possible. > ...which means that you can't get a link-layer byte count that pertains to what was actually sent out over > any network link. It was just an example. I have similar Ethernet captures, so substitute a 14 byte Ethernet header for a 16-byte Linuxed cooked capture. The point and question remains. What is the most accurate/desirable/expected number to report? ___ 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] Conversation and endpoints byte counts
With my recent commit in r37945, it is now possible to view GRE-encapsulated IP conversations and endpoints, which also include any other supported conversations such as UDP and TCP as well. However, when looking at the bytes being counted as part of those conversations, I noticed that they were all the same and in fact included the byte count for the entire packet rather than only for the Layer3/4 that the conversation pertained to. For example, I have a Linux Cooked encapsulated packet as follows: Linux cooked header: 16 bytes IP header: 20 bytes GRE: 8 bytes (normally 4 bytes, but it includes the optional 4 byte key field) IP header: 20 bytes UDP header: 8 bytes UDP Payload: 52 bytes TOTAL: 124 bytes So given the above example, all conversations at all layers show the number of bytes being transferred as 124 bytes. I believe this to be in error. The outer IP conversation encompasses only 108 bytes, the GRE-encapsulated inner IP conversation encompasses only 80 bytes, and the UDP conversation encompasses only 60 bytes. I started making changes to the gtk/conversation*.c and gtk/hostlist*.c files, but thought that I should check with the other developers first to be sure this is the right thing to do. Thoughts? Thanks. ___ 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] my dissector breaks with updated 1.6 source and libs
Brian Oleksa writes: > I have updated to the latest sources today as well as the latest libs. > I put my dissector in place and it crashes. It ran just fine on 1.4.X So you previously built a plugin dissector against 1.4.x and dropped it into the 1.6.0 plugins directory expecting it to work? This has never been supported because we have yet to lock down the API/ABI, but even if we did, there's no reason to expect a 1.4 plugin to work against 1.6. I don't think we'd ever go so far as to guarantee binary compatibility across anything other than micro versions. You will simply have to recompile your plugin against the 1.6 sources if you intend to use it with 1.6.x. > What are the major changes...?? Read the release notes for the major changes. > WHY is this always a problem. Where can I get help with fixing my > problems..?? Why? Because Wireshark continues to evolve. Where can you get help? -wireshark-devel, ask.wireshark.org, README.developer, the Wireshark source code, your colleagues, someone you pay for help, etc. Basically, the usual places. ___ 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] Why isn't this a bug?
Jaap Keuter writes: > From the packet-giop.c source code: > > if (*offset > header->message_size) >return FALSE; >} > > Why isn't this a bug? It sure looks like a bug to me. ___ 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] Unable to reach www.wireshark.org
Gerald Combs writes: > I added an record last week (on the 30th). Other than that there > haven't been any recent changes (that I'm aware of) that should affect > connectivity. Thanks (Jason too), but I guess it was something on my end. Our helpdesk has cleared things up. ___ 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] Getting data extracted by my dissector into another
Colin Helliwell writes:
> I’ve developed a number of dissectors which dissect payload from those below
and decode their own protocol. Now I want to pass my payload ‘ownward’ to
another (the JSON dissector). I’d appreciate any tips on how to
initialise/register my protocol such that the JSON dissector sees it and/or how
to pass the payload on to it. A summary of the calls used would probably do –
enough to get me going in the right direction.
You may want to make use of find_dissector() and call_dissector(). ie.,
something like:
static dissector_handle_t json_handle;
static void
dissect_yourproto(...)
{
tvbuff_t *next_tvb;
...
/* All done processing your stuff, so hand off dissection to json,
* (assuming you know the payload is for the json dissector) */
next_tvb = tvb_new_subset(tvb, offset, length, length);
/* ... or next_tvb = tvb_new_subset_remaining( ... ); */
call_dissector(json_handle, next_tvb, pinfo, some_tree);
}
void
proto_reg_handoff_yourproto(void)
{
json_handle = find_dissector("json");
}
___
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] Unable to reach www.wireshark.org
I can reach www.wireshark.org via my mobile phone, but not from any computer behind my corporate proxy. Has anything changed that would prevent this or should I be contacting our IT group about it? Thanks, Chris ___ 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] Windows GTK Broken / Linux OK
Alex Lindberg writes: > My custom build of Wireshark includes a the ability to read a new file type. When the system is build on a Linux (Debian) system, all works as it should, however when building on a Windows PC (XP x32) using either vc2008EE-sp1 or vc2010EE, the system complies and starts, but the "Open" dialog won't. A brief flash occurs, but nothing opens. I think it will be very difficult to help without looking at the code. Can you post a patch? ___ 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] Bugzilla not sending e-mails?
Chris Maynard writes: > I am no longer receiving any e-mail updates from bugzilla. Just checking if > this is isolated to me or if there might be something wrong with bugzilla. OK, I guess they are being sent, but for some reason there seems to be a really long delay before I receive them. ___ 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
