ah, a misunderstanding.
ok.so the dtls stuff does not require linking with openssl then
there wont be any problem at all.
thanks for clarifying.
please also see wiki.wireshark.org/SSL
i just checked in a change to the preference syntax that is not
backward compatible for ssl decryption.
hi,
in wiki you could make :
Secure Socket Layer (SSL)
SSL provides communication security between two hosts. It provides
integrity, authentification and confidentiality. It is used most of
time in web navigator but can be used for any protocol under TCP.
History
SSL is originally a Netscape
I did it a while ago.
On 6/29/06, Bálint Réczey (IJ/ETH) [EMAIL PROTECTED] wrote:
Hi,
Could someone apply the patch to the svn repository?
Regards,
Balint
-Original Message-
From: Bálint Réczey (IJ/ETH)
Sent: Tue 6/27/2006 18:24
To: wireshark-dev@wireshark.org
Subject: [patch]
The default colorfilters file in Wireshark has an entry titled IPX. It
matches ipx || stp which should probably be ipx || spx.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Added the dissection of a field that wasn't being picked up during NDMP MD5 authentication.The NDMP_CONFIG_GET_AUTH_ATTR message response was using the function dissect_auth_attr_msg() which dissects an auth_attr struct. However, the specification includes and error field previous to that struct.
Can you check ndmp versions 2 to 5 that this is true for all versions of ndmp?if not you have to add a switch statement to manage the difference between versions.On 6/30/06,
Aaron Christensen [EMAIL PROTECTED] wrote:
Added the dissection of a field that wasn't being picked up during NDMP MD5
ok,ill check it in in a few hours.by the way, do you have access to ndmp captures you can share and upload to the wiki page?we do not have any public sample captures of NDMP yet.
On 6/30/06, Aaron Christensen [EMAIL PROTECTED] wrote:
Hi, Ronnie,I initally checked this against the specification for
Sure. Done:http://wiki.wireshark.org/Network_Data_Management_ProtocolA couple of images of captured packets (including one that works after the patch) and a sample packet capture. The NDMP client/server I was using had some extensions not recognized, so there's some extra traffic that is NDMP-ish
checked in
On 6/30/06, Aaron Christensen [EMAIL PROTECTED] wrote:
Added the dissection of a field that wasn't being picked up during NDMP MD5
authentication.
The NDMP_CONFIG_GET_AUTH_ATTR message response was using the function
dissect_auth_attr_msg() which dissects an auth_attr struct.
great stuff.
thanks
On 6/30/06, Aaron Christensen [EMAIL PROTECTED] wrote:
Sure. Done:
http://wiki.wireshark.org/Network_Data_Management_Protocol
A couple of images of captured packets (including one that works after the
patch) and a sample packet capture. The NDMP client/server I was
We're overdue for an official Wireshark release. A couple of people
have pointed out that the code in /trunk is in better shape than
/trunk-1.0, and that we might be better off using it for future
releases. I agree.
I'd like to make the following changes in the repository, which would
address
On Jun 30, 2006, at 12:27 PM, Bryant Eastham wrote:
I now understand the problem, and have found the problem in the code.
I should have mentioned that I am running tshark from a build, not
an installed, directory. It appears that tshark.c is missing the call
init_progfile_dir(argv[0]);.
Would not it be better to make /trunk-1.0 as late as we have implemented all
features planned for 1.0.0?
Then the /trunk-1.0 would continue only with bug fixies.
I am affraid when we make /trunk-1.0 now we will come to the same conclusion
during next release, i.e. to forgot /trunk-1.0 and use
Kukosa, Tomas wrote:
Would not it be better to make /trunk-1.0 as late as we have implemented all
features planned for 1.0.0?
Then the /trunk-1.0 would continue only with bug fixies.
I am affraid when we make /trunk-1.0 now we will come to the same conclusion
during next release, i.e. to
hi wireshark developers,
attached a patch for the BGP dissector for correct display of
VPLS NLRIs as per the latest spec (draft-ietf-l2vpn-vpls-bgp-08).
in rev 18189 the label-block size was missing.
/hannes
Index: packet-bgp.c
Dear wireshark developers,
After running same test trace files I noticed a lot of non-utf8 error messages
from wireshark.
The attached patch fixes this and converts the sms content (7 bit encoded, gms
03.38 alphabet) into utf8.
The only difficutily I had is how to handle the platforms
Hi list,
My FC5 (SVN 18636) compile fails here:
gcc -DINET6 -D_U_=__attribute__((unused)) -Wall -Wpointer-arith -W -g -O2
-I/usr/local/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
Hi,
checked in
i changed the indentation to be more consistent with the rest of wireshark
i removed a few if(tree) tests and initialized exec_tree to NULL instead
i removed the memcopy and the array of character for username/command
and replaces if with a pointer and se_strdup()
I dont know
Hi,
Mike Oliveras has indicated that for MGCP voip calls, 2 seconds may be a
better timeout for still matching DLCX requests to a hung-up endpoint,
as in this patch.
Regards,
Martin
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
Maybe, but where?
If it was added as a protocol preference to the MGCP dissector (which is
a plugin), will that variable be available to voip_calls.c ?
Regards,
Martin
Anders Broman (AL/EAB) wrote:
Hi,
Should this time be configurable?
Brg
Anders
-Original Message-
From: [EMAIL
Hi List!
There was still an open point about copying over the old preferences
and alike files from Ethereal to Wireshark.
I had a look at the current implementation. The problem to my previous
proposal is, that not only the files that we read and write are located
in that dir, but probably
Checked in.
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Willem Dekker
Skickat: den 2 juli 2006 23:07
Till: wireshark-dev@wireshark.org
Ämne: [Wireshark-dev] Patches for gsm-packet_sms dissector
Dear wireshark developers,
After running same
Checked in.
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Martin Mathieson
Skickat: den 4 juli 2006 11:49
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] [Patch] to voip_calls.c (bug 892 again)
This time with patch
Hi,
--
Authesserre Samuel
12 rue de la défense passive
14000 CAEN
FRANCE
06-27-28-13-32
[EMAIL PROTECTED]
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
On Thu, 06 Jul 2006 06:00:27 -0600, Johnathan Nightingale wrote:
I've seen several articles in the past little while talking about
getting started with wireshark or ethereal basics and, while every
decent product out there gets a couple of those, I think part of the
message I'm left with is
Hi,
I've updated my wireshark project (windows) using SVN, and now I get the
following error:
packet.cops.c
packet-cops.c(72) : fatal error C1083: Cannot open include file:
'net-snmp/net-snmp-config.h': No such file or directory
packet-snmp.c
packet-snmp-template.c(70) : fatal error C1083:
Hi List!
The current release situation is unsatisfying IMHO.
The last official release is the Ethereal 0.99.0 version from April 24,
2006 which is about 10 weeks ago and contains some frequently reported
(and quite annoying) bugs in the win32 export functions (and obviously
elsewhere).
The
A friend sent me a trace with this packet:
Frame 1 (78 bytes on wire, 78 bytes captured)
Arrival Time: Jul 9, 2006 13:58:01.527266000
Time delta from previous packet: 0.0 seconds
Time since reference or first frame: 0.0 seconds
Frame Number: 1
Packet
Jaap Keuter wrote:
Hi,
No one has had the time to get the ethereal/wireshark configuration
reading stuff sorted out. Anyone have any idea how invasive that would be?
Maybe a waiting point for 0.99.2 branch, which cannot be released without
this anyway, IMHO.
I've already committed stuff
No one has had the time to get the ethereal/wireshark
configuration
reading stuff sorted out. Anyone have any idea how
invasive that would be?
Maybe a waiting point for 0.99.2 branch, which cannot be
released without
this anyway, IMHO.
I don't see that as a pre-requisite. IMHO
Anders Broman (AL/EAB) wrote:
Alejandro I think your proposed plugin looks realy good and something we
would have use for.
From the recent mails I'm a bit confused to where we stand on this. I
think Guy had some comments
on the implementation, is that beeing worked on or is further
Hi,
In my opinion it depends on how big the problem you are trying to solve
realy is and how complicated it will be
To design a well working solution, sometimes the cure is worse than the
illnes.
For Windows it seems like we have reasonable solution, how complicated
will it be to do a solution
Hi,
I was looking through the wireshark code to find a
way to set the label in a GtkButton with Gtk1.x and I've found this (in
gtk\simple_dialog.c):
#if GTK_MAJOR_VERSION = 2
/* XXX - find a way to set the GtkButton label in GTK 1.x
*/ gtk_button_set_label(GTK_BUTTON(ask_cb),
Anders Broman (AL/EAB) wrote:
In my opinion it depends on how big the problem you are trying to solve
realy is and how complicated it will be
To design a well working solution, sometimes the cure is worse than the
illnes.
Is there any reason why
when trying to open a file in the
Hi,
Fixed some typos and checked it in.
Thanx,
Jaap
On Thu, 13 Jul 2006, Gerhard Gappmeier wrote:
Hi Jaap and Ulf
I have added a new chapter about tcp_dissect_pdu
to WSDG_chapter_dissection.xml (revision 18722).
Can you please review that and check it in.
regards,
Gerhard
On
Neil Piercy wrote:
Hi,
I follow what has been done to the SVN fine, but I'm still confused
about what is intended in the future for the separate trunks:
Will a new trunk be produced for every release ?
If so, do they represent a snapshot which is then left frozen ? If not
frozen,
On Jul 13, 2006, at 3:58 PM, Gerald Combs wrote:
Yes, and yes. Right now in the repository root we have:
/trunk - The repository everyone should be using for development.
Which could be thought of as the equivalent of CVS top of tree.
/trunk-0.99.2 - What will eventually be
Chjecked in.
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Martin Mathieson
Skickat: den 14 juli 2006 16:21
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] More Diameter [patches]
Hi,
These patches
- add a few more
Hi all,
Im writing a dissector for a protocol that has an
HTTP payload that I would like to dissect, But when I call find_dissector(http);
it returns NULL. I dont think that its my syntax, because I get
a valid handle when I call it for ip. Is there a good reason why
I cant do this?
Steve Grinwis wrote:
I’m writing a dissector for a protocol that has an HTTP payload that I
would like to dissect, But when I call find_dissector(“http”); it
returns NULL.
Are you calling this in the register routine or the register-handoff
routine? There's no guarantee that any given
Hello,
http://www.wireshark.org/security/wnpa-sec-2006-01.html lists several
vulnerabilities and announces affected versions range from 0.8.16 up
to and including 0.99.0.
However the detailed listing of vulnerabilities doesn't list any one
for 0.99.0. Perhaps the 'Versions affected' info should
Gerald Combs wrote:
Have been updated to include ranges. I'll try to include ranges in
future documentation as well.
Many thanks,
Frederic
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
This section of code prevents disassembly of the data field of RSN Key-Data
packets that are flagged as Protected. From what I can tell the first
comment is wrong and all group key key data fields are encrypted, not just
WPA. The chained IE fields have a null terminating IE of 0 length to
On Wed, Jul 19, 2006 at 11:52:43AM +0100, Martin Mathieson wrote:
This patch:
- adds headers found in later versions of the msrp drafts
- fixes a problem where wrong length values were used while parsing the
request/status line and it was going beyond linelen
- Transaktion - Transaction
-
Hi,
Here is a DTD for xcap-caps and changes needed to install it (nsi change
is untested).
Regards,
Martin
? wireshark:protocol
proto_name=xcap-caps
description=XML Configuration Access Protocol Server Capabilities
hierarchy=yes ?
!--
$Id: reginfo.dtd 18248 2006-05-29 20:44:06Z
The enclosed patch extends the way in which the xml dissector loads DTD
definitions. Rather than loading only a single dtd directory this patch
will cause the contents of *both* the ~/.wireshark/dtds (user) and the
/usr/local/share/wireshark/dtds (built-ins) to be loaded.
The current dtd
Checked in.
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Martin Mathieson
Skickat: den 19 juli 2006 15:50
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] [Patch] to MSRP dissector
Joerg Mayer wrote:
On Wed, Jul 19, 2006
Checked in.
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Martin Mathieson
Skickat: den 19 juli 2006 18:12
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] New DTD (xcap-caps)
Hi,
Here is a DTD for xcap-caps and changes needed
The Debian package approval process turned up several source files in
the Wireshark distribution that don't have explicit licenses. With the
exception of in_cksum.h, is there any reason these shouldn't be GPLed?
epan/in_cksum.h:
no license info (but most probably BSD, like in_cksum.c)
Hi,
The attached file should fix the following two bugs in the AJP dissector.
1) The dissector doesn't know about CPING/CPONG
2) The dissector misinterprets multiple requests in one connection if a
prior request has a Body request part.
Yours,
Ian
--
Ian Abel [EMAIL PROTECTED]
Systems
Hi list,
I've been trying to get a running Wireshark 0.99.2 on Solaris 9 for a
couple days now; recently I switched to working from SVN and I'm still
having issues. They all seem to be related to dtd or dfilter stuff.
For example, trying to run SVN 18769 gives:
firebird
On 7/19/06, Gerald Combs [EMAIL PROTECTED] wrote:
The Debian package approval process turned up several source files in
the Wireshark distribution that don't have explicit licenses. With the
exception of in_cksum.h, is there any reason these shouldn't be GPLed?
tap-funnel.c: no license
On 7/19/06, Gerald Combs [EMAIL PROTECTED] wrote:
The Debian package approval process turned up several source files in
the Wireshark distribution that don't have explicit licenses. With the
exception of in_cksum.h, is there any reason these shouldn't be GPLed?
snprintf.h:
no license
can you type
$ lex -V
$ flex -V
and see what comes out. I think you might be using sun's lex (for
which I never tested the code) instead of flex.
On 7/20/06, Jeff Morriss [EMAIL PROTECTED] wrote:
Hi list,
I've been trying to get a running Wireshark 0.99.2 on Solaris 9 for a
couple days now;
Martin Mathieson wrote:
Joerg Mayer wrote:
On Wed, Jul 19, 2006 at 06:51:26PM +, [EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=18766
User: etxrab
Date: 2006/07/19 06:51 PM
Log:
From Martin Mathieson:
This patch:
- adds headers found
Gerald Combs wrote:
merge.c: missing license info, but based on ethereal work
mergecap.c: idem
Ok, I had a look at editcap.c, mergecap.c and merge.c
editcap.c was implemented by Richard Sharpe and Guy Harris, later
improved by others.
On Thu, Jul 20, 2006 at 09:45:37PM +0100, Daniel Drake wrote:
The barker preamble bit is set when a station associates which does not
support
short preambles. When it is 0, short preambles are allowed.
Committed revision 18777.
Thanks!
Joerg
--
Joerg Mayer
On Jun 27, 2006, at 5:51 AM, Martin Mathieson wrote:
Looking at frame 170 in the trace, it looks like
tvb_get_ephemeral_text() struggles with the null character in the
middle of the 4th parameter (in the WWW-Authenticate header) and
returns NULL.
That shouldn't happen -
Well, I have these:
firebird [~/] flex -V
flex version 2.5.4
firebird [~/] lex -V
lex: Software Generation Utilities (SGU) Solaris-ELF (4.0)
but it appears to be using 'flex':
checking for flex... /usr/local/bin/flex
I upgraded to flex 2.5.31 but still hit the problem.
So I updated SVN
Hopefully, all files should have a GPL compatible License. If not, then
we need to fix this. Otherwise, the default license is valid. I don't
understand the debian paranoia team here: either they have a valid
complaint (i.e. an *incompatible* license), then that's fine (I mean the
complaint).
Guy Harris wrote:
On Jun 27, 2006, at 5:51 AM, Martin Mathieson wrote:
Looking at frame 170 in the trace, it looks like
tvb_get_ephemeral_text() struggles with the null character in the
middle of the 4th parameter (in the WWW-Authenticate header) and
returns NULL.
That shouldn't
Title: Plugin architecture requires
I've been using Ethereal / Wireshark for a few years now, but recently needed to add a custom protocol. In learning about developing for this app, it seems that Ethereal plugins are not based on an API and require the full source to be around to compile
On Jul 21, 2006, at 12:57 PM, Martin Mathieson wrote:
I think I wouldn't have created this bug in the first place if the
function
was instead called proto_tree_add_text_format(). I didn't realise
the last
arg was a format string - I'm used to those function names having the
_format
checked in
maybe you can add a nice wiki page for this protocol and donate some
sample captures?
On 7/19/06, Ian Abel [EMAIL PROTECTED] wrote:
Hi,
The attached file should fix the following two bugs in the AJP dissector.
1) The dissector doesn't know about CPING/CPONG
2) The dissector
thanks,
checked in
it would be nice with example captures on the wiki for H1 and SKINNY
On 7/21/06, Jeff Morriss [EMAIL PROTECTED] wrote:
Hi list,
Thomas Boehne wrote:
On Thursday 20 July 2006 12:06, Jeff Morriss wrote:
If I set the TCP preference Try heuristic dissectors first? then
checked in
On 7/20/06, Martin Mathieson [EMAIL PROTECTED] wrote:
Hi,
This patch allows FT_NONE items to be built into filter expressions
(i.e. testing for their presence or absence rather than comparing with a
value) using the Apply|Prepare a Filter menus. What drove me to add
this was
Joerg Mayer wrote:
Hopefully, all files should have a GPL compatible License. If not, then
we need to fix this. Otherwise, the default license is valid. I don't
understand the debian paranoia team here: either they have a valid
complaint (i.e. an *incompatible* license), then that's fine (I
Frederic Peters wrote:
This is about those files:
epan/epan.c
epan/exceptions.h
epan/dfilter/gencode.h
epan/dfilter/glib-util.c
epan/dfilter/glib-util.h
I think Gilbert Ramirez contributed the original versions of those; I
think all the rest of his contributions are GPL'ed -
I did the original NLM stuff.
Ill update packet-nlm.h
On 7/22/06, Guy Harris [EMAIL PROTECTED] wrote:
Frederic Peters wrote:
This is about those files:
epan/epan.c
epan/exceptions.h
epan/dfilter/gencode.h
epan/dfilter/glib-util.c
epan/dfilter/glib-util.h
I think
they are all under gpl compatible licences.
On 7/22/06, Frederic Peters [EMAIL PROTECTED] wrote:
Joerg Mayer wrote:
Hopefully, all files should have a GPL compatible License. If not, then
we need to fix this. Otherwise, the default license is valid. I don't
understand the debian
Hello,
Please find attached a patch with updates to l2tpv3's l2_sublayer_vals
and pw_types_vals numbers (and pw type decoding).
Please check in; comments and corrections are welcome.
Thanks!
--
--Carlos Pignataro.
Escalation RTP - cisco Systems
Index: epan/dissectors/packet-l2tp.c
Hi All,
I have a capture file which i am interested in showing on the Wireshark GUI. My capture file has info about only *one* protocol (proprietery) and no other protocol.I am planning to write a dissector for my file.I am confused as to how ethereal will call my dissector. My file has no data
I noticed that when I build --with-ssl wireshark cannot read any file.
If I compile without it works OK.
We had a similar report on Solaris where WS crashed when reading the
DTDs as soon as the reporter build it --without-ssl it worked.
I did not further dig into the issue.
My question is
Guy Harris wrote:
gtk/win32-file-dlg.h
Gerald? That one's yours, I think
Fixed.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
On Mon, Jul 24, 2006 at 05:56:56PM +0200, LEGO wrote:
My question is what is OpenSSL used for?
1) net-snmp (and ucd-snmp). IIRC, they are only needed to resolve OIDs to
MIB names by now, but I may be wrong.
2) mit kerberos5 support probably needs it as well.
Can we replace it with GnuTLS?
I modified the makefile by hand. Esentially all I did was remove all
instances of Ethereal and replaced it with Wireshark. Is there more to
do?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter
Sent: Tuesday, July 25, 2006 9:22 AM
To:
My makefile didn't have any of the python plugin.c stuff. I essentially
copied the sbus makefile and pasted it overtop of mine I did notice
that I had to manually add all of the *.obj files to the objects list
myself or it wouldn't compile correctly meaning that the line:
DISSECTOR_OBJECTS =
Hi,
No, these are not important for compilation on Win32. You do compile in a
Win32 command window, do you. I mean, not in a cygwin window.
Another thing to watch for is using nmake, not make.
Other than this I can't give you more advice.
Thanx,
Jaap
On Tue, 25 Jul 2006, Steve Grinwis wrote:
I missed out a patch to add the new header file to
epan/dissector/Makefile.common
Thanks,
Martin
Martin Mathieson wrote:
Hi,
These patches:
- allow SDP to parse the IP address + port for the MSRP session from
the path attribute
- setup an MSRP conversation using this address, whose data
On Mon, Jul 24, 2006 at 02:21:47PM -0600, Dale Carstensen wrote:
I browsed a bit in the gmane archive for the problems I'm seeing
building wireshark 0.99.2 on OpenBSD 3.9, and all I found was a note
about adding @GCRYPTLIBS@ to Makefile.am in 3 places, so I'm thinking
the problems I see
I rebuilt Wireshark to see if I could find any errors in the build. I
came across a few things.
xcopy gryphon\*.dll 0.99.2 /d
gryphon\gryphon.dll
1 File(s) copied
xcopy h223\*.dll 0.99.2 /d
stats_tree\stats_tree.dll
1 File(s) copied
xcopy v5ua\*.dll 0.99.2 /d
(... more
On Mon, Jul 24, 2006 at 02:21:47PM -0600, Dale Carstensen wrote:
I browsed a bit in the gmane archive for the problems I'm seeing
building wireshark 0.99.2 on OpenBSD 3.9, and all I found was a
note about adding @GCRYPTLIBS@ to Makefile.am in 3 places, so I'm
thinking the problems I see
Guys,
Thanks for your efforts, as I am not a developer, I await 0.99.3 with
interest.
Keith French.
- Original Message -
From: Martin Mathieson [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Tuesday, July 25, 2006 10:47 AM
Subject: Re:
[Moving this to the dev list...]
Richard van der Hoff wrote:
Has wireshark stopped supporting capture from a fifo recently?
I'm sure I used to be able to do things like the following:
$ mkfifo fifo
$ (cat cap; sleep 5; cat cap) fifo
$ tshark -i fifo
But it now dies after the first
Richard van der Hoff wrote:
[tshark from a fifo]
Ulf - I notice you made the relevant change here (r16787) - is there any
reason why tshark shouldn't use capture_loop_dispatch to do its
processing, rather than attempting to use cap_pipe_dispatch or
pcap_dispatch directly?
well, there
This patch fixes a couple of comments in capture_sync.c.
--
Richard van der Hoff [EMAIL PROTECTED]
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
Index: capture_sync.c
===
--- capture_sync.c
An error message has been changed, such that the commandline options
test doesn't work any more.
This patch fixes the test accordingly.
--
Richard van der Hoff [EMAIL PROTECTED]
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
Index: test/suite-clopts.sh
Richard van der Hoff wrote:
Richard van der Hoff wrote:
[tshark from a fifo]
Ulf - I notice you made the relevant change here (r16787) - is there
any reason why tshark shouldn't use capture_loop_dispatch to do its
processing, rather than attempting to use cap_pipe_dispatch or
Hey all,
Using the install-deps build target fixed the problem. It works
like a charm (well... it loads the plugin). Now the only problems that
I have are ones with my code. And I can deal with my code. Thanks so
much!
-Steve
-Original Message-
From: [EMAIL PROTECTED]
The fact that you have to do an install-dep isn't documented anywhere...
It might not be a bad thing to add to readme.win32.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
Johansson
Sent: Wednesday, July 26, 2006 6:19 AM
To: Developer support
Hi,
You could write something up and post a patch.
You may also consider an addition in the developer guide, very usefull for
Win32 development.
Thanx,
Jaap
On Wed, 26 Jul 2006, Steve Grinwis wrote:
The fact that you have to do an install-dep isn't documented anywhere...
It might not be a
Martin Mathieson wrote:
name [A-Za-z][-a-z0-9_]*[-a-zA-Z0-9_]*
Wouldn't
[A-Za-z][-a-zA-Z0-9_]*
suffice? ([...]* matches zero or more occurrences, and [-a-zA-Z0-9_] is
a superset of [a-z0-9_].)
___
Wireshark-dev mailing list
One have to remember though to run nmake with the install-deps build
target after every recompilation of the source (for any change you
make). Otherwise Wireshark is started with the old compiled code. I
can't remember the amount of times I have been trying to debug my code
and it just does
Steve,
Can you please post the appropriate changes to README.bsd to describe what
you did so other users can try that, too?
Thanks,
--john
On Wed, 26 Jul 2006 03:11:06 -0600, [EMAIL PROTECTED]
wrote:
On Tue, Jul 25, 2006 at 08:40:38AM -0700, Stephen Fisher wrote:
On Mon, Jul 24, 2006 at
I'm going to work up a path to the readme.win32 to include this
information. I think it would be a good idea to include standard build
instructions something like this:
To get a standard build working:
To start setup and download all the required packages:
Nmake -f Makefile.nmake setup
To
You may want to include: nmake -fmakefile.nmake distclean
as the first step. This will get rid of auto generated files that may
cause initial Win32 build to fail.
-Tim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Steve Grinwis
Sent: Wednesday,
Hello,
anyone who knows his way around Wiresharks exception code (or C's
setlongjmp
etc statements). If so, please have a look at bug 1001.
thanks
Joerg
On Wed, Jul 26, 2006 at 01:55:11PM +, [EMAIL PROTECTED] wrote:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1001
---
If you could send a capture showing the problem to the list (or directly to
me if you'd prefer), I'll take a look.
Martin
- Original Message -
From: Keith French [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: 25 July 2006 21:48
Subject: Re:
Martin Mathieson wrote:
name [A-Za-z][-a-z0-9_]*[-a-zA-Z0-9_]*
Wouldn't
[A-Za-z][-a-zA-Z0-9_]*
suffice? ([...]* matches zero or more occurrences, and [-a-zA-Z0-9_] is
a superset of [a-z0-9_].)
That would have been the obvious fix to make in the first place, I was
lazily
Ok. Please find attached my patch for readme.win32. It should
hopefully be a good starting point for people trying to build Wireshark
on windows for the first time.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cook, Timothy
Sent: Wednesday, July
1 - 100 of 37294 matches
Mail list logo
