Hi,
I tried to build the 0.99.4 (latest Version
http://www.wireshark.org/download.html)from source in my win XP.
After using
nmake -i Makefile.nmake
It does a lot of stuff and seems to work for a long time but then suddenly
stops with
LINK : fatal error LNK1181: cannot open input file
Hi,
Where do you get the -i from in nmake -i Makefile.nmake. Doesn't that
cover up build problems earlier on? My guess is that the build of
capture_if_details_dlg.c failed but it scrolled off screen. The linker
then couldn't find the object to build the libui.lib, which by itself is a
target that
Hi,
Does some have an idea on how to implement proto_tree_add_item() with a
range_string?
That would be really useful.
BR
Anders
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Wireshark Wiki - Do not reply wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on The Wireshark Wiki
for change notification.
The following page has been changed by nickvlas:
http://wiki.wireshark.org/FrontPage
Hi,
I've just updated Wireshark for Win32 to build 20405 and I get this error:
ssl-dlg.c(155) : error C2039: 'app_data' : is not a member of
'SslPacketInfo'
..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of
'SslPacketInfo'
ssl-dlg.c(173) : error C2039: 'app_data' : is not
Hi,
I found out that much.
The -i option I got from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/U1077.asp
maybe that wasn´t a good idea.
I found out, that the problem started with the libui.lib (in GTK) which
couldn´t be build.
There seems to be another
Hi,
it is caused by my changes in SSL.
Unfortunately ssl-dlg.c was not recompiled on my PC and did not catch
this error.
I will fix it.
Tomas
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Giorgio Tino
Sent: Friday, January 12, 2007 1:28 PM
To:
Jan Kokott wrote:
Hi,
I found out that much.
The -i option I got from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/U1077.asp
maybe that wasn´t a good idea.
It depends. -k or -i can get as much as possible compiled in one run.
You then run (n)make again
Hello!
I just tried to migrate an old (working) etherreal plugin following the
guide in doc/README.plugins to the wireshark-0.99.4 source.
I followed all steps, but unfortunately the ./configure tool generates
no Makefile (and no config.status: creating plugins/xxx/Makefile line).
Is the
Tomas,
thanks, now it compiles!
Giorgio!
- Original Message -
From: Kukosa, Tomas [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Friday, January 12, 2007 1:40 PM
Subject: Re: [Wireshark-dev] Win32 build broken?
Hi,
it is caused by my
Hi,
Yeah, that would be nice, having stuff like this:
static const range_string rs_value[] = {
{ 0, 49, Little },
{ 50, 99, Some },
{100,199, Considerable },
{200,255, High },
{ 0, 0, NULL }
};
proto_tree_add_item(tree, hf_proto_value, tvb, offset, 1, FALSE);
Hi,
I think you missed some steps in chapter 3. These are for pointing
configure and make to your new plugin directory.
Thanx,
Jaap
On Fri, 12 Jan 2007, Armin Wasicek wrote:
Hello!
I just tried to migrate an old (working) etherreal plugin following the
guide in doc/README.plugins to the
Hi,
I had a brief look some time ago and it looked
To me like it would require new FT_x:s or
That the macros VAL and TFS would have to be changed to supply
the needed functions. Is there a better way to do it?
BR
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL
Hi,
My first impression is that the RS() macro (refer to code sample below)
needs to be implemented to work with the range_string type. I've got
really no idea what is involved with that.
Thanx,
Jaap
On Fri, 12 Jan 2007, Anders Broman wrote:
Hi,
I had a brief look some time ago and it looked
Hi,
I'm developing a dissector plugin for the Connect:Direct file transfer
protocol, the protocol itself can contain a SSL payload. Until recently
i didn't have too many problems with my dissector identifying it's own
data, adding some information to the tree and then passing the SSL
payload
Hi,
If I'm not wrong, the VALS(x), TFS(x) are affected to a const void *
in hf_register_info which in fact are enumerated types. range_string is
not an enumerated type. You then have to decide in proto_tree_add_item,
in fact, a little bit later in fill_label_enumerated_(u)int which is the
type
Hello GV -
Thanks for the reply!
It's interesting to see how people work around the limitations in the
current pcap format. One I'm is thinking of doing is utilizing the
Ethernet Trailer (which you almost /never/ see anymore) to associate a
lot of the data that pcap-ng would provide in a more
Ok I found the problem, in the SSL debug log I saw;
association_add TCP port 1364 protocol tls handle
association_add could not find handle for protocol 'tls', try to find
'data' dissector
Checking the SSL preferences I had an entry for RSA keys list;
127.0.0.1,1364,tls,c:\ssltest.key
On Fri, Jan 12, 2007 at 06:50:31PM +, Martin Warnes wrote:
Checking the SSL preferences I had an entry for RSA keys list;
127.0.0.1,1364,tls,c:\ssltest.key which specified this port so it was
correctly attempting to dissect this packet as SSL after all.
It sounds like you are trying to
- Original Message -
From: Benn Bollay [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Friday, January 12, 2007 9:43 AM
Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
Hello GV -
Thanks for the reply!
It's interesting to
- Original Message -
From: Guy Harris [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Friday, January 12, 2007 10:21 AM
Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
Benn Bollay wrote:
How difficult will the integration
Gianluca Varenni wrote:
1) the existing libpcap API, which will handle as much of pcap-ng as it
can (ignoring some records, discarding some data in others, failing as
soon as it sees a link-layer type other than the first one it saw);
I think the main problem here is how to deal with
Hi all.
I noticed that the version 1 of the roofnet header has got additional
fields, as one might understand from the srpacket.hh file i posted
some email ago.
In particular, there are 6 and a half more lines in the header than
in version 2.
Can you modify the dissector in order to
Hi,
I will try to do it this WE.
Regards,
Sebastien Tandel
Nicola Arnoldi wrote:
Hi all.
I noticed that the version 1 of the roofnet header has got additional
fields, as one might understand from the srpacket.hh file i posted
some email ago.
In particular, there are 6 and a half more
On Fri, Jan 12, 2007 at 01:05:45PM -0800, Guy Harris wrote:
Changing SHAREDLIB_LDFLAGS to LDFLAGS_SHAREDLIB seems to work in the
test I did on OS X, at least, so I checked it in.
Looks good here on FreeBSD. Thanks!
Steve
___
Wireshark-dev
Ulf Lamping wrote:
Wireshark Wiki - Do not reply wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on The Wireshark Wiki
for change notification.
The following page has been changed by nickvlas:
http://wiki.wireshark.org/FrontPage
On Jan 12, 2007, at 2:02 PM, Sebastien Tandel wrote:
As I was not totally satisfied by my solution, I'm not totally with
your
neither. With VALS and TFS (and, in fact, also NULL :)), as you said,
this field 'display' is usually defined to know which base to use
(dec,
hex, dec_hex, ...)
27 matches
Mail list logo
