Re: [Wireshark-dev] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis
Chris Maynard wrote: Stephen Fishersteve@... writes: packet-vnc.c(1970) : warning C4018: '' : signed/unsigned mismatch Any ideas? I added a cast that fixes it. I'm not 100% sure why the warning, but I think it might be because the multiplication operation promotes the guint8's to int's. Yes, that's exactly right. Since the original code just passed the product of two guint8 quantities into a macro, the compiler is, at least according to my understanding of C99, free to promote that product to either a signed or unsigned int if either would be sufficiently large to hold the result (which is the case for 32-bit ints or uints). Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] libwireshark.lib is missing some proto_registrar_* methods
Andreas wrote: Am 11.02.2011 00:06, schrieb Guy Harris: They weren't omitted on purpose. They were probably omitted because they were added by a UN*X user; by default, UN*X dynamic shared libraries export every non-static symbol, unlike Windows DLLs. I think this is a strong argument to move away from the export definition in DEF file to a decoration in the header file. With the prefix like i.e. WIRESHARK_API(1) you can decorate any function that is intended to be public available. I wonder if there's a way to do this by looking at whether the function is declared static or not. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Updates to Wireshark Windows Makefiles (SVN #35747)
Jaap Keuter wrote: Are these changes compatible with *all* Windows Compiler / SDK combinations we support (http://www.wireshark.org/docs/wsdg_html_chunked/ChToolsMSChain.html)? I can't verify that Bill's changes are compatible with *all* combinations, but I can verify that I encountered no problems with build 35755 using Visual C++ 2008 Express Edition SP1. That was with starting with a nmake -f Makefile.nmake distclean so I think it's a fair test. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Utility to convert -V text files to pcap??
Christopher Maynard wrote: Alex Lindberg alindber@... writes: Has anyone created a utility to convert the output of tshark -V to pcap files? I think text2pcap is the logical utility to do this. Unfortunately, it doesn't work if the summary information is present, but if you can strip out that stuff, then it should work. There is a bug open for enhancing text2pcap to deal with the summary information: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1636 I've done something similar with a different kind of text-based dump. In that, I wrote a python script to perform a minimal transformation to the input file to make it palatable to text2pcap and then converted the timestamps and added fake TCP (and underlying) headers like so: C:\python26\python.exe mydump2pcap.py %1 |C:\Program Files\Wireshark\text2pcap -t %%Y-%%m-%%dT%%H:%%M:%%S. -T ,4 - %1.pcap That's the Windows batch file version. The bash script is a little cleaner syntax, but essentially the same thing. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] proto_tree_add_bits_ret_val() BUG
George Deprez wrote: *proto_tree_add_bits_ret_val*() displays incorrect values when num_bits is 32 If I ask for 16 bits and adjust the offset by 16 and ask for 16 more I get the correct bits. If I ask for 64 bits from the base offset I get the correct bits. But if I ask for 32 bits from the same base offset I get all zero. Using the same bit offset, I tried different tests with FT_UINT16,FT_UINT32 and FT_UINT64. Has anybody had this problem? I haven't had that problem, and I'm not where I can check it out quickly, but I wonder if it might be an endian-ness problem. Are you on a 64-bit machine by any chance? It might be worth posting your platform and build details. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] inclusion of bug 5531?
I know the target release is Monday, 10 Jan 2011, so I'm guessing it may be too late for the inclusion of the patch I submitted with bug 5531. When's the next release? Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ASN.1 dissector makefiles under Windows
I notice that when I modify an ASN.1 dissector source code file, that it fails to cause the Windows makefile to rerun asn2wrs. Is there a reason for this? Is there a reason I shouldn't attempt to address this and submit a patch? In searching around, I haven't found any other references to this problem nor any mention of attempts to address it. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Question about tcp window scaling value
Douglas Wood wrote: In Wireshark 1.4.2, export to PDML from tshark sometimes results in a different value for tcp window size compared to doing the same export from the Wireshark GUI. The different value reflects multiplying the tcp window value with the current window scaling size for tshark and not taking window scaling into account for Wireshark. Is this a bug? No, it's a feature. :) If not, how can I tell the difference between the two outputs? I'd rather not write code that cares if tshark generated the output or Wireshark. There is a TCP preference Window scaling that controls this. Note that you must also have the Analyze TCP sequence numbers enabled for this to take effect. As always, you can also specify an option override on the command line as -o tcp.window.scaling:TRUE Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] bitmask handling in wireshark
Andrei Emeltchenko wrote:
I want to check what is the best way to convert code below to value_string
proto_tree_add_text(tree, tvb, offset, 1,
%s%s%s%s,
(buf 0x80)? 16kHz : ,
(buf 0x40)? 32kHz : ,
(buf 0x20)? 44.1kHz : ,
(buf 0x10)? 48kHz : );
proto_tree_add_text(tree, tvb, offset, 1,
%s%s%s%s,
(buf 0x08)? Mono : ,
(buf 0x04)? DualChannel :
,
(buf 0x02)? Stereo : ,
(buf 0x01)? JointStereo :
);
offset++;
Here's how I'd do that. First, the field definition (I'm only showing your
first field):
#define MYPROTO_FLAG_SAMPLING 0xf0
static int hf_myproto_flags_sampling_rate = -1;
static const value_string myproto_sampling_rates[] = {
{ 0x01, 48kHz },
{ 0x02, 44.1kHz },
{ 0x04, 32kHz },
{ 0x08, 16kHz },
{ 0, NULL }
};
Then in your field definitions add this:
{ hf_myproto_flags_sampling_rate,
{ MyProto Sampling Rate, myproto.flags.sampling_rate,
FT_UINT8, BASE_HEX,
VALS(myproto_sampling_rates), MYPROTO_FLAG_SAMPLING,
NULL, HFILL }
},
Finally, in the same place you'd have the code above, instead you would do this:
proto_tree_add_item(flag_tree, hf_myproto_flags_sampling_rate, tvb, offset,
1, FALSE);
A few things to note here. First, the values in the myproto_sampling_rates[]
array are already shifted so although your original code uses 0x40 to identify
a 32kHz rate, you'll see that this code uses 0x04. That's deliberate and not a
typo.
Second, you'll see that I've added this item to a flag_tree variable. This
is a way to preserve the structure of the original packet by showing the
individual subfields in a subtree. For a complete example of this, see the tcp
flags.
Ed
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] bitmask handling in wireshark
Andreas wrote: So far I've seen only lots of boolean values. You might want to take a look at proto_tree_add_bitmask(). See doc/README.developer, which describes it and illustrates its use by taking an example from the SCSI dissector. Where can I get a sample capture file to see how this will look like? The easiest thing might be to look at epan/dissectors/packet-tcp.c for the code and pretty much any capture file with TCP. In the code, look for hf_tcp_flags and in a capture file, just look at the TCP flags. Also, looking at doc/README.developer is highly recommended. It's how I learned. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] problem with gtk/rtp_player.c
Under Windows, the recent changes made to gtk/rtp_player.c cause the 2008
version of VC++ to die with a warning that assigning a double to time_t could
cause a loss of precision. I changed it by adding an explicit cast to guint64.
This is the old problem with doing math on time -- time_t is an unspecified
kind of numerical type. My Linux box accepts either version.
Index: gtk/rtp_player.c
===
--- gtk/rtp_player.c(revision 35292)
+++ gtk/rtp_player.c(working copy)
@@ -1377,7 +1377,7 @@
rci-draw_area-allocation.height-HEIGHT_TIME_LABEL+4);
if(GTK_TOGGLE_BUTTON(cb_view_as_time_of_day)-active) {
- seconds =
nstime_to_sec(rci-start_time_abs) + i * MULT / SAMPLE_RATE;
+ seconds =
(guint64)(nstime_to_sec(rci-start_time_abs) + i * MULT / SAMPLE_RATE);
timestamp = localtime(seconds);
g_snprintf(label_string,
MAX_TIME_LABEL, %02d:%02d:%02d, timestamp-tm_hour, timestamp-tm_min,
timestamp-tm_sec);
} else {
Ed
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] problem with gtk/rtp_player.c
Stephen Fisher wrote: Thanks. I've committed SVN revision 35293 which removes the call to nstime_to_secs() entirely - since the code only needs one second precision as it is, I'm using the secs portion (time_t) of the nstime structure directly now. All of my compilers are now happy with that version. Thanks! Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Problem Compiling Wireshark under Win32
Fox-Moore Ben wrote: I had a vcredist_x86.exe is missing error which I fixed by download vcredist_x86.exe and putting it in C:\wireshark-win32-libs, however I now get another error: tools/win32-setup.sh: line 10: sed: command not found Here's the problem. If you look at tools/win32-setup.sh you'll see that it requires sed. Easily fixed by using cygwin's setup facility and installing sed. Also, for what it's worth, I came across a similar kind of problem recently in which I ultimately discovered that the problem was that I had recently installed WinARM (ARM processor tools for Windows) and because of where it was in the path, win-setup.sh was attempting to use the mkdir facility in that toolchain (which would seem to work but not actually create a directory!). I found that pretty quickly by using which mkdir at the Windows command line and then manually altering the path. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Usage of MS protocol documentation in Wireshark
-Original Message- From: Eloy Paris pe...@chapus.net Sent: Sep 7, 2010 3:11 PM To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] Usage of MS protocol documentation in Wireshark On 09/07/2010 02:20 PM, Stephen Fisher wrote: [...] Microsoft folks would probably find it useful to troubleshoot their software anyway ;) Don't know if things have changed recently but a couple of years ago a co-worker went to teach a networking class at the Microsoft Redmond campus and he was not allowed to use open source tools (including Wireshark) during the training. Back then the use of open source tools was frowned upon. I understand they are more open with regards to open source these days so things may have changed a little ;-) There is some evidence that suggests they were never as allergic to open source as some of their executives would like you to believe. If you look at files shipped with the Windows operating system, including ftp.exe, finger.exe, nslookup.exe and others, you'll see that outwardly they have a Microsoft copyright, but in the text inside them, one finds text indicating Copyright 198x The Regents of the University of California. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] type punning error in packet-gtpv2.c
I just updated and attempted to build Wireshark on a 32-bit Linux box using gcc
4.1.2 and I find that I get an error in the epan/dissectors/packet-gtpv2.c file:
packet-gtpv2.c: In function 'proto_register_gtpv2':
packet-gtpv2.c:2136: warning: dereferencing type-punned pointer will break
strict-aliasing rules
packet-gtpv2.c:2161: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Line 2136 contains the VALS() macro invocation:
{ hf_gtpv2_cause_type,
{Cause Type,gtpv2.cause_type,
FT_UINT8, BASE_DEC|BASE_EXT_STRING,
VALS(gtpv2_cause_type_vals_ext),0x0f,
NULL, HFILL}
},
The problem is with the VALS() invocation, but before I dive into it, I thought
I'd see if anybody else is seeing this or is already working on it.
If I back up to version 33350 of packet-gtpv2.c, I don't get any errors and it
builds just fine. As an interesting point of reference, I don't get this error
on my 64-bit Linux box (gcc 4.4.3), nor on the Windows machine (MSVC Express
2008). I wonder if this might be a compiler version issue. This box is
running Fedora Core 8 (yes, I know it's old).
Ed
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Creating a Wireshark installer with my dissector in it
Brian Oleksa olek...@darkcornersoftware.com wrote: When I create my installer...my plugin is included...so everything installs and looks right. But when I go to start up wireshark, I get the following error: C:\Program Files\Wireshark\wireshark.exe I infer from this that we're talking about Windows. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem. I tried to reinstall... but that did not help. There is no error that is pointing me to a specific file... so where would I start at..?? Ah, the joys of Windows programming. One place to look is the system event logs. Open the Event Viewer and you'll be able to find out from there what particularly it is looking for (and not finding.) One reason for such an error is that you're not using the redistributable that matches your particular compiler. When I had this issue, I was using the redistributable without SP1, but it turns out I needed to include the redistributable *with* SP1. See http://www.wireshark.org/docs/wsdg_html_chunked/ChToolsMSChain.html for lots more details. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Printing?
Shawn Mayer wrote: Do I have to use something other than printf to print from Wireshark? I have the console set to always open, but still am not seeing anything. It works just fine under Linux, so I assume you must be on a Windows machine. Try this: http://dslweb.nwnexus.com/~ast/dload/guicon.htm Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] basic question
But what if I just wanted to make this dissector available as decode
as and not by the port it broadcasts on..??
[...]
Just wanted to see what the best thing to do is here. I was just simply
going to pick a port that it would never be on...such as 1.
You don't want to do that unless port 1 was actually assigned by IANA.
Instead, what you can do is assign it to port 0 and then do this:
void proto_reg_handoff_myproto(void)
{
static gboolean initialized = FALSE;
static dissector_handle_t myproto_handle;
static guint myproto_port;
if (!initialized) {
myproto_handle = new_create_dissector_handle(dissect_myproto,
proto_myproto);
dissector_add_handle(tcp.port, myproto_handle);
initialized = TRUE;
} else {
if (myproto_port != 0) {
dissector_delete(tcp.port, myproto_port, myproto_handle);
}
}
if (global_myproto_port != 0) {
dissector_add(tcp.port, global_myproto_port, myproto_handle);
}
myproto_port = global_myproto_port;
}
Then within your proto_register_myproto(void) function, do this:
myproto_module = prefs_register_protocol(proto_myproto, NULL);
prefs_register_uint_preference(myproto_module, tcp.port,
My Protocol port,
My Protocol port,
10,
global_myproto_port);
That way, the myproto dissector will be available as a decode as choice but
not falsely claim a port it doesn't really own.
Ed
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] INTERLINK dissector plugin added
Aniruddha A aniruddh...@gmail.com wrote: How to decide whether a dissector has to be a plugin or a build-in ? Is it based on the code size ? I have also created a plugin (based on a protocol which is in draft state in IETF) and the code size is small, I was about to raise patch request on bugzilla, but after seeing this post, I am wondering whether to add it to epan/dissectors as a single file and then upload the patch. I once had the same question, but then I found the answer in the Wireshark Developers Guide ( http://www.wireshark.org/docs/wsdg_html/#ChSrcCodeRequirements ) Submit dissectors as build-in whenever possible. Developing a new dissector as a plugin is a good idea because compiling is quicker, but it's best to convert dissectors to the build-in style before submitting for checkin. This reduces the number of files that must be installed with Wireshark and ensures your dissector will be available on all platforms. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] minor correction to Developer's Guide
I was looking at the Developer's Guide today in section 9.4.2. How to reassemble split TCP Packets and I think I spotted an omission, but I wanted to check with others to make sure it's not my error. The section is here: http://www.wireshark.org/docs/wsdg_html/#TcpDissectPdus The correction I think may be needed is to add another include to the code. Specifically, unless I add #include epan/dissectors/packet-tcp.h to the list of includes in the sample code, the compiler complains that it doesn't know anything about tcp_dissect_pdus(). Also, I've been doing a lot of fiddling with ASN.1 code lately and think it would be nice to add a section on ASN.1-based dissectors to the developer's guide, since the only information I've found so far is the asn2wsr wiki developer pages, and even that leave a lot unstated. I think I could make a start at writing that. Should that be submitted in the form of a patch? Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] support for INSTANCE OF in ASN.1
I've been working on a dissector which uses ASN.1 and for the moment I am using type EXTERNAL, but I would prefer to define my own CLASS and use INSTANCE OF instead. In looking through all existing ASN.1 dissectors, it seems that INSTANCE OF seems only to be supported when it's INSTANCE OF TYPE-IDENTIFIER and not of any user-defined class. Is that correct? I'm not that adept with ASN.1 yet, so I'm not certain of the syntax. Any examples showing the successful use of INSTANCE OF with a class other than TYPE-IDENTIFIER would be most helpful. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] plugin made from asn.1 generated sources
Petr Kovář wrote: Hello, I've tried to use C sources generated after building the asn.1-based dissector to create own dll for this protocol. Do you mean this? http://wiki.wireshark.org/ASN1_plugin I prepared Makefiles and other needed files, built the dll succesfully, but after Wireshark startup appears error dialog Could'nt load module... .dll ...specified procedure could not be found. Can anyone give me a hint where could be the fault ? One thing I hadn't yet gotten around to was to fix up the Makefile for Windows. I only had the Linux stuff working so far, but if you've fixed up the nmake Makefile, perhaps we can collaborate on finishing that? Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] plugin made from asn.1 generated sources
Petr Kovář wrote: OK, I've send you the Makefile.nmake and few questions from my corporate e-mail. Thanks. I have it now and will work on it as soon as I get to my Windows machine. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RTP Muxing with compressed header
This is the error... sour...@debian:~/wireshark-1.3.1/epan/dissectors$ make Makefile:: *** commands commence before first target. Stop. That's a classic symptom of having a tab character in front of a non-command line. Make sure there are no tabs on any of the empty lines, e.g. line 6656 and 6663 and that none of the non-command lines start with a tab (lines 6657 and 6664). Also, make sure that you haven't mixed Unix-mode and DOS-mode line endings in any of the files (CR vs CRLF). If none of that helps, run automake and configure (from the top directory) to force things to be regenerated from Makefile.am and Makefile.common. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ASN1-based dissector as plugin
OK, I have added a page and some code to show how it works. The new page is http://wiki.wireshark.org/ASN1_plugin and it works under Linux, but I'm still working on a Windows version. The makefiles are somewhat byzantine. Comments, complaints, suggestions welcome. Ed Anders Broman wrote: Hi, Additions to the Wiki on how to build asn2wrs generated plugins or dissectors are most welcome :-) Regards Anders -Ursprungligt meddelande- Från: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] För Ed Beroset Skickat: den 7 februari 2010 19:31 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] ASN1-based dissector as plugin I've been working on an ASN.1-based dissector lately and got impatient with the slow modify-compile-test cycling, so I have changed it to be an ASN.1-based plugin dissector. I am thinking this technique might be of general use to those building such dissectors, so perhaps a simple sample along these lines would be something I could contribute. So I have two questions for the group: 1. is this of interest to anyone but me? 2. would an addition to the wiki be the best way to contribute this? Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ASN1-based dissector as plugin
I've been working on an ASN.1-based dissector lately and got impatient with the slow modify-compile-test cycling, so I have changed it to be an ASN.1-based plugin dissector. I am thinking this technique might be of general use to those building such dissectors, so perhaps a simple sample along these lines would be something I could contribute. So I have two questions for the group: 1. is this of interest to anyone but me? 2. would an addition to the wiki be the best way to contribute this? Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Couldn't unpack C:\WIRESH~1/zlib123ws.zip -- with solution
I encountered a problem building Wireshark today on a Windows XP box that seems to have been encountered before, but searching on the web yielded no answer. For that reason, I thought I'd describe both the symptoms and the fix so that the next individual to encounter this might be able to find this solution a little easier. The problem manifests itself like this: Extracting C:\WIRESH~1/zlib123ws.zip into C:\WIRESH~1/zlib123 ERROR: Couldn't unpack C:\WIRESH~1/zlib123ws.zip NMAKE : fatal error U1077: 'C:\cygwin\bin\bash.EXE' : return code '0x1' Stop. When I unzipped the file from within a cygwin shell, everything worked just fine. Eventually, I figured it out and it turned out to be quite simple. I had another (old) version of unzip in the C:\WINDOWS directory. By coincidence, the older version worked just fine on all of the library files before that one, but failed on zlib123ws.zip because it happened to use the enhanced deflate compression scheme which the old version of unzip could identify but not use. If anyone has this problem in the future, there are a few things to try that may help them out. First, the output of verify_tools pointed to the version it was actually using, had I read it more carefully. With an up-to-date cygwin, the line *should* show: unzip: /usr/bin/unzip Second, one can temporarily change the tools/win-setup.sh file from this pair of lines: unzip -oq $DEST_PATH/$PACKAGE || err_exit Couldn't unpack $DEST_PATH/$PACKAGE to something like this: unzip -o $DEST_PATH/$PACKAGE $DEST_PATH/zip.log || err_exit Couldn't unpack $DEST_PATH/$PACKAGE Then the contents of the zip.log file will contain the error messages relevant to the failure. I leave it to you all to decide whether such a change is worth making in the main line build. Ed Beroset ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
