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,
errors while trying to compile wireshark with gtk1.2
epan/.libs/libwireshark.so: undefined reference to `uri_str_to_bytes'
epan/.libs/libwireshark.so: undefined reference to `byte_array_dup'
collect2: ld returned 1 exit status
both are defined in strutil.c (only for GTK2) and used, at least, by
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
>>
>> ---
This should be fixed in r20397.
Douglas Pratley wrote:
> Looks like this is related to revision 20388 - changing decryption keys
> to use GByteArray rather than GString for SSID in
> epan\crypt\airpdcap_user.h. Not sure why it only affects Windows.
> Nothing to do with MSVC version (as stated alre
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 mail
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 mo
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 make
Hi,
thx for the advice, I indeed didn't notice it. Modification done and
patch attached (FT_BOOLEAN not working) but ...
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 d
Guy Harris wrote:
> Or perhaps it should be changed to LDFLAGS_SHAREDLIB or, if necessary,
> SHAREDLIB_LOADER_FLAGS; it appears from
>
> http://sources.redhat.com/ml/automake/2001-08/msg00046.html
>
> that variable names shouldn't end with LDFLAGS. I'll try
> LDFLAGS_SHAREDLIB - I forge
Stephen Fisher wrote:
> I keep running into a gmake problem on FreeBSD after I svn up for the
> last week or so. It gives an error about SHAREDLIB_LDFLAGS. I then
> have to run autogen.sh and configure again before gmake before it will
> work again. When I run autogen.sh, I get this error:
>
I keep running into a gmake problem on FreeBSD after I svn up for the
last week or so. It gives an error about SHAREDLIB_LDFLAGS. I then
have to run autogen.sh and configure again before gmake before it will
work again. When I run autogen.sh, I get this error:
configure.in:269: invalid unus
Sebastien Tandel wrote:
> If you want something cleaner ... one of the solution may be a
> intermediate structure which is mandatory with well-defined values to
> determine which structure it encapsulates. => need changes then in the
> macros VALS, TFS and even in the dissectors using VALS, TFS
T
- Original Message -
From: "Guy Harris" <[EMAIL PROTECTED]>
To: "Developer support list for Wireshark"
Sent: Friday, January 12, 2007 11:59 AM
Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
> Gianluca Varenni wrote:
>
>> I would prefer to have a separate API set (being
Stephen Fisher wrote the following on 12/01/2007 19:34:
> On Fri, Jan 12, 2007 at 07:19:59PM +, Martin Warnes wrote:
>
>
>> The Connect:Direct protocol in this case is just a header record:
>>
>> 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2
>> 0050 80 00 00 00 38 00
Gianluca Varenni wrote:
> I would prefer to have a separate API set (being it NTAR or anything else)
> to deal with capture files.
>
> One of the things I like less about libpcap is that the API to read/write
> files is too much tied to the capture one without any specific reason.
That somewha
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
Here is the patch to have a more precise idea of what has changed (and
if you want to try it :)) ... and the example of Jaap modified to work
with the patch provided :
static const range_string rs_value[] = {
{ 0, 49, "Little" },
{ 50, 99, "Some" },
{100,199, "Considerable" },
{
- Original Message -
From: "Guy Harris" <[EMAIL PROTECTED]>
To: "Developer support list for Wireshark"
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 into the std tools
- Original Message -
From: "Benn Bollay" <[EMAIL PROTECTED]>
To: "Developer support list for Wireshark"
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 see how people wo
On Fri, Jan 12, 2007 at 07:19:59PM +, Martin Warnes wrote:
> The Connect:Direct protocol in this case is just a header record:
>
> 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2
> 0050 80 00 00 00 38 00 00 00
>
> and the SSL payload:
>
> 16 03 01 00 04 0
We carry SSL within the Connect:Direct file transfer protocol:
00 00 03 04 00 00 00 50 ba da b4 6c 00 00 08 00 ...P...l
0010 45 00 00 51 0e 48 40 00 40 06 aa be c0 a8 00 28 [EMAIL
PROTECTED]@..(
0020 c0 a8 00 28 05 54 86 0b 35 13 e0 4d 35 3a 86 3d ...(.T..5..M5:.=
0030
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 t
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
Benn Bollay wrote:
> How difficult will the integration into the std tools (tcpdump,
> Wireshark, et al) be once a consistent API is implemented? One wonders
> if it would be possible to provide a pcap interface to a pcap-ng file,
> and circumvent a lot of the immediate compatibility issues.
Tha
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 el
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
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 o
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 looke
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 PROT
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 t
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);
Tomas,
thanks, now it compiles!
Giorgio!
- Original Message -
From: "Kukosa, Tomas" <[EMAIL PROTECTED]>
To: "Developer support list for Wireshark"
Sent: Friday, January 12, 2007 1:40 PM
Subject: Re: [Wireshark-dev] Win32 build broken?
> Hi,
>
> it is caused by my changes in SSL.
> U
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 gu
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 agai
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: Develo
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 declara
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
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,
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
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 t
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 'captu
41 matches
Mail list logo
