Re: [Wireshark-dev] proto_tree_add_item() with range_string
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, ...) to display a value. If you want a range_string
> displayed with base dec, hex, ... you have to duplicate
> BASE_RANGE_STRING values as for example BASE_RANGE_STRING_DEC,
> BASE_RANGE_STRING_HEX, ...
...or have a BASE_RANGE_STRING flag that you OR with BASE_xxx.
That means that the value in the structure isn't one of the enum
values, so the debugger won't be able to prettyprint it, though.
> VALS and TFS are independent from the base
> chosen (or in general display field) and RVALS won't be.
>
> What do you think of an hybrid solution between mine and your defining
> an additional field (i.e. convertfield_type) in head_register_info
> which
> identifies which type of structure is in CONVERTFIELD (strings)?
> - It would bring the independence from the base avoiding us to
> duplicate the fields (BASE_RANGE_STRING_DEC,
> BASE_RANGE_STRING_HEX, ...)
> - this field could be hidden by the HFILL macro when you don't have to
> use it (and use another, HFILL2(?), when you have to use this field)
We might want to define macros to expand to definitions of fields of
particular types, with particular options; that'd also handle the
HFILL stuff, without having to have multiple HFILL macros. Keep the
old HFILL and have it initialize that additional field to a default
value, and use the macros to create definitions that set it (and
convert existing definitions to use the new macros over time as
desired).
> - it would be scalable for the current and future implementation if
> you
> create another structure à la range_string without changing anything
> in
> the code of the existing dissectors.
...which means preserving binary compatibility as well.
> - would be possible to use FT_BOOLEAN as well
> - it's clean (from the syntax point of view and from the semantic as
> well) :)
Adding an additional field *does* make the structure a bit bigger,
which might worsen the memory and cache footprint of Wireshark;
whether it'd make a significant difference is another matter.
Note also that other display options might be useful to attach to
fields, e.g. units, so you could define something such as
HF_UINT_WITH_UNITS(hf_xxx_data_rate, "Data rate", "xxx.data_rate",
FT_UINT64, BASE_DEC, NULL, 0x0, "", "bytes/s")
(as an example of the new type of macro I mentioned), which might
expand to something such as
{ &hf_xxx_data_rate,
{ "Data rate", "xxx.data_rate", FT_UINT64, BASE_DEC, NULL, 0x0, "Data
rate, in bytes/s", "bytes/s", HFILL }},
so that the field would be displayed as "Data rate: %u bytes/s" rather
than just "Data rate: %u". That might let us get rid of a number of
proto_tree_add_xxx_format() calls. (Arguably, every time somebody
calls proto_tree_add_xxx_format(), it means we failed to anticipate a
need, although some might be sufficiently infrequently used that it's
not worth adding another display feature for it.)
I'm not sure whether there's a way to, for example, bundle all the
display information in a single structure, e.g. one with an optional
value_string or true_false_string or range_string table *and* a units
string and possibly even the base.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] compile problem with gtk1.2
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 airdpcap.c and airpcap_loader.c Regards, Sebastien Tandel ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [The Wireshark Wiki] Update of "FrontPage" by nickvlas
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 >> >> -- >>* ["Preferences"]: Preference settings controlling the behaviour of >> Wireshark and TShark >>* ["Statistics"]: Statistics range from general capture file information >> to protocol specific statistics >>* ["Security"]: how to use Wireshark as securely as possible >> + * [http://freeclips.adrenalinbet.com free porn clips] Preference settings >> controlling the behaviour of Wireshark >>* ["Performance"]: how to "fine tune" Wireshark's performance >>* ["Timestamps"]: Accuracy, precision, and resolution >>* ["Tools"]: tools and scripts that relate to the use of Wireshark and >> TShark >> >> > Hi Gerald! > > Someones spamming the frontpage repeatedly :-( > > Maybe it's time to lock write access to a few known developers? Done. Editing is now restricted to the users listed on the AdministratorGroup page. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Microsoft Visual C Version 6support isa bitoutdated ...
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 already). > > As I'm not using airpdcap I "fixed" this for my build by changing > gtk\airpcap_gui_utils.c line 338 to > > s2 = g_strndup(curr_key->ssid->data, curr_key->ssid->len) > > which should be safe, but possibly not what the patcher intended, so I'm > not going to call it a real fix. > > Cheers > > Doug > > > > *From:* [EMAIL PROTECTED] [mail > > to:[EMAIL PROTECTED] *On Behalf Of *Anders > Broman (AL/EAB) > *Sent:* 11 January 2007 10:13 > *To:* Developer support list for Wireshark > *Subject:* SV: [Wireshark-dev] Microsoft Visual C Version 6support > isa bitoutdated ... > > Hi, > The buildbot has the same problem so it's not related to MSVC... > BR > Anders > > > *Från:* [EMAIL PROTECTED] genom Alfred Alinazar > *Skickat:* to 2007-01-11 09:43 > *Till:* Developer support list for Wireshark > *Ämne:* Re: [Wireshark-dev] Microsoft Visual C Version 6support isa > bitoutdated ... > > Ulf Lamping wrote: > > Should be fixed now, I simply messed up the line copying the file "if > > exist copy zlib1.dll.manifest ..." :-( > > > > I've done some more, all MSVC variants shouldn't give a NSIS warnings > > now :-) > > > > Regards, ULFL > Ulf, > I managed to build my wireshark yesterday. > But it failed again today after I update the source with the latest SVN. > > Here is the error: > --- > Microsoft (R) Program Maintenance Utility Version 7.00.8882 > Copyright (C) Microsoft Corp 1988-2000. All rights reserved. > > cl -DWIN32 -DNULL=0 -D_MT -D_DLL -DHAVE_CONFIG_H /I.. > /I../wiretap /IC:\ > wireshark-win32-libs\glib\include\glib-2.0 > /IC:\wireshark-win32-libs\glib\lib\g > lib-2.0\include /IC:\wireshark-win32-libs\gtk+\include > /IC:\wireshark-win32-libs > \gtk+\include\gdk /IC:\wireshark-win32-libs\gtk+\lib\gtk+\include > /IC:\wireshar > k-win32-libs\gnutls-1.6.1-1\include /DNOCRYPT > /IC:\wireshark-win32-libs\WPdpack > \WPCAP\LIBPCAP /IC:\wireshark-win32-libs\WPdpack\WPCAP\LIBPCAP\bpf > /IC:\wiresha > rk-win32-libs\WPdpack\WPCAP\LIBPCAP\lbl > /IC:\wireshark-win32-libs\WPdpack\inclu > de /IC:\wireshark-win32-libs\net-snmp-5.4\include > /IC:\wireshark-win32-libs\net- > snmp-5.4\win32 /Zm800 -D_U_="" -D_NEED_VAR_IMPORT_ /Zi /W3 /MD > /D_CRT_SECURE_NO > _DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE > /IC:\wireshark-win32-libs\portaudio_v19\ > include /IC:\wireshark-win32-libs\portaudio_v19\src\common-Fd.\ -c > airpcap_g > ui_utils.c > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 > for 80x86 > Copyright (C) Microsoft Corporation. All rights reserved. > > airpcap_gui_utils.c > airpcap_gui_utils.c(338) : error C2039: 'str' : is not a member of > '_GByteArray' > > C:\wireshark-win32-libs\glib\include\glib-2.0\glib/garray.h(45) > : see de > claration of '_GByteArray' > airpcap_gui_utils.c(338) : error C2198: 'g_strdup' : too few arguments > for call > airpcap_gui_utils.c(837) : warning C4133: '=' : incompatible types - > from 'GStri > ng *' to 'GByteArray *' > NMAKE : fatal error U1077: 'cl' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Platform SDK for > Windows > Server 2003 R2\Bin\nmake.exe"' : return code '0x2' > Stop. > - > > > regards, > > -Alfred- > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > > This message should be regarded as confidential. If you have received > this email in error please notify the sender and destroy it immediately. > Statements of intent shall only become binding when confirmed in hard > copy by an authorised signatory. The contents of this email may relate > to dealings with other companies within the Detica Group plc group of > companies. > > Detica Limited is registered in England under No: 1337451. > > Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, > England. > > > > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://ww
Re: [Wireshark-dev] autogen.sh: configure.in:269: invalid unused variable name: `SHAREDLIB_LDFLAGS'
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 mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] roofnet v1
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 lines in the header than in
> version 2.
>
> Can you modify the dissector in order to make it able to decode both
> v1 and v2 packets?
>
> Thanks
>
> Nicola
>
> Il giorno 10/gen/07, alle ore 16:48, Nicola Arnoldi ha scritto:
>
>> Was the pcap file enough?
>>
>> Bye
>>
>> Nicola
>>
>> Il giorno mar, 09/01/2007 alle 12.34 +0100, Sebastien Tandel ha scritto:
>>> Hi,
>>>
>>>Can you send a pcap file for testing purpose, please?
>>>
>>>
>>> Regards,
>>>
>>> Sebastien Tandel
>>>
>>> Nicola Arnoldi wrote:
Hi everybody.
The great work Sebastien did about Roofnet dissectors was related to
Version 2, which is still far from stable.
It should be implemented the V 1 as well, which has some differences
between V2.
I attach the c++ header, hoping it would be sufficient for you to
modify
the dissector accordingly.
Note that ETHTYPES, which in V2 all started with a 6 (6xx) now start
with number 9. (9xx)
The message I receive when I try to decode V1 datagrams with the old
dissector is something like.
Bogus IP header, more payload than told by roofnet...and others.
Bye.
Nicola
#ifndef CLICK_SRPAKCET_HH
#define CLICK_SRPAKCET_HH
#include
#include
CLICK_DECLS
#define max(a, b) ((a) > (b) ? (a) : (b))
#define min(a, b) ((a) < (b) ? (a) : (b))
enum SRCRPacketType { PT_QUERY = 0x01,
PT_REPLY = 0x02,
PT_TOP5_RESULT = 0x03,
PT_DATA = 0x04,
PT_GATEWAY = 0x08
};
enum SRCRPacketFlags {
FLAG_ERROR = (1<<0),
FLAG_UPDATE = (1<<1),
FLAG_TOP5_REQUEST_RESULT = (1<<2),
FLAG_TOP5_BEST_ROUTE = (1<<3),
FLAG_SCHEDULE = (1<<4),
FLAG_SCHEDULE_TOKEN = (1<<5),
FLAG_SCHEDULE_FAKE = (1<<6),
FLAG_ECN = (1<<7)
};
static const uint8_t _sr_version = 0x0b;
// Packet format.
CLICK_SIZE_PACKED_STRUCTURE(
struct srpacket {,
uint8_t _version; /* see _srcr_version */
uint8_t _type; /* see enum SRCRPacketType */
uint8_t _nlinks;
uint8_t _next; // Index of next node who should process this
packet.
uint16_t _ttl;
uint16_t _cksum;
uint16_t _flags;
uint16_t _dlen;
/* PT_QUERY
* _qdst is used for the query destination in control packets
* and a extra 32 bit seq number in data packets
*/
uint32_t _qdst;
uint32_t _seq; // seq number
uint32_t _seq2; // another seq number
/* uin32_t ip[_nlinks] */
/* uin32_t metrics[_nlinks] */
/* ip */
/* fwd */
/* rev */
/* seq */
/* ip */
uint32_t _random_from;
uint32_t _random_fwd_metric;
uint32_t _random_rev_metric;
uint32_t _random_seq;
uint16_t _random_age;
uint32_t _random_to;
void set_random_from(IPAddress ip) {
_random_from = ip;
}
void set_random_to(IPAddress ip) {
_random_to = ip;
}
void set_random_fwd_metric(uint32_t m) {
_random_fwd_metric = m;
}
void set_random_rev_metric(uint32_t m) {
_random_rev_metric = m;
}
void set_random_seq(uint32_t s) {
_random_seq = s;
}
void set_random_age(uint32_t s) {
_random_age = s;
}
IPAddress get_random_from() {
return _random_from;
}
IPAddress get_random_to() {
return _random_to;
}
uint32_t get_random_fwd_metric() {
return _random_fwd_metric;
}
uint32_t get_random_rev_metric() {
return _random_rev_metric;
}
uint32_t get_random_seq() {
return _random_seq;
}
uint32_t get_random_age() {
return _random_age;
}
void set_link(int link,
IPAddress a, IPAddress b,
uint32_t fwd, uint32_t rev,
uint32_t seq,
uint32_t age) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
ndx[0] = a;
ndx[1] = fwd;
ndx[2] = rev;
ndx[3] = seq;
ndx[4] = age;
ndx[5] = b;
}
uint32_t get_link_fwd(int link) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
return ndx[1];
}
uint32_t get_link_rev(int
Re: [Wireshark-dev] roofnet v1
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 it able to decode both
v1 and v2 packets?
Thanks
Nicola
Il giorno 10/gen/07, alle ore 16:48, Nicola Arnoldi ha scritto:
Was the pcap file enough?
Bye
Nicola
Il giorno mar, 09/01/2007 alle 12.34 +0100, Sebastien Tandel ha
scritto:
Hi,
Can you send a pcap file for testing purpose, please?
Regards,
Sebastien Tandel
Nicola Arnoldi wrote:
Hi everybody.
The great work Sebastien did about Roofnet dissectors was related to
Version 2, which is still far from stable.
It should be implemented the V 1 as well, which has some differences
between V2.
I attach the c++ header, hoping it would be sufficient for you to
modify
the dissector accordingly.
Note that ETHTYPES, which in V2 all started with a 6 (6xx) now start
with number 9. (9xx)
The message I receive when I try to decode V1 datagrams with the old
dissector is something like.
Bogus IP header, more payload than told by roofnet...and others.
Bye.
Nicola
#ifndef CLICK_SRPAKCET_HH
#define CLICK_SRPAKCET_HH
#include
#include
CLICK_DECLS
#define max(a, b) ((a) > (b) ? (a) : (b))
#define min(a, b) ((a) < (b) ? (a) : (b))
enum SRCRPacketType { PT_QUERY = 0x01,
PT_REPLY = 0x02,
PT_TOP5_RESULT = 0x03,
PT_DATA = 0x04,
PT_GATEWAY = 0x08
};
enum SRCRPacketFlags {
FLAG_ERROR = (1<<0),
FLAG_UPDATE = (1<<1),
FLAG_TOP5_REQUEST_RESULT = (1<<2),
FLAG_TOP5_BEST_ROUTE = (1<<3),
FLAG_SCHEDULE = (1<<4),
FLAG_SCHEDULE_TOKEN = (1<<5),
FLAG_SCHEDULE_FAKE = (1<<6),
FLAG_ECN = (1<<7)
};
static const uint8_t _sr_version = 0x0b;
// Packet format.
CLICK_SIZE_PACKED_STRUCTURE(
struct srpacket {,
uint8_t _version; /* see _srcr_version */
uint8_t _type; /* see enum SRCRPacketType */
uint8_t _nlinks;
uint8_t _next; // Index of next node who should process this
packet.
uint16_t _ttl;
uint16_t _cksum;
uint16_t _flags;
uint16_t _dlen;
/* PT_QUERY
* _qdst is used for the query destination in control packets
* and a extra 32 bit seq number in data packets
*/
uint32_t _qdst;
uint32_t _seq; // seq number
uint32_t _seq2; // another seq number
/* uin32_t ip[_nlinks] */
/* uin32_t metrics[_nlinks] */
/* ip */
/* fwd */
/* rev */
/* seq */
/* ip */
uint32_t _random_from;
uint32_t _random_fwd_metric;
uint32_t _random_rev_metric;
uint32_t _random_seq;
uint16_t _random_age;
uint32_t _random_to;
void set_random_from(IPAddress ip) {
_random_from = ip;
}
void set_random_to(IPAddress ip) {
_random_to = ip;
}
void set_random_fwd_metric(uint32_t m) {
_random_fwd_metric = m;
}
void set_random_rev_metric(uint32_t m) {
_random_rev_metric = m;
}
void set_random_seq(uint32_t s) {
_random_seq = s;
}
void set_random_age(uint32_t s) {
_random_age = s;
}
IPAddress get_random_from() {
return _random_from;
}
IPAddress get_random_to() {
return _random_to;
}
uint32_t get_random_fwd_metric() {
return _random_fwd_metric;
}
uint32_t get_random_rev_metric() {
return _random_rev_metric;
}
uint32_t get_random_seq() {
return _random_seq;
}
uint32_t get_random_age() {
return _random_age;
}
void set_link(int link,
IPAddress a, IPAddress b,
uint32_t fwd, uint32_t rev,
uint32_t seq,
uint32_t age) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
ndx[0] = a;
ndx[1] = fwd;
ndx[2] = rev;
ndx[3] = seq;
ndx[4] = age;
ndx[5] = b;
}
uint32_t get_link_fwd(int link) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
return ndx[1];
}
uint32_t get_link_rev(int link) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
return ndx[2];
}
uint32_t get_link_seq(int link) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
return ndx[3];
}
uint32_t get_link_age(int link) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
return ndx[4];
}
IPAddress get_link_node(int link) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
return ndx[0];
}
void set_link_node(int link, IPAddress ip) {
uint32_t *ndx = (uint32_t *) (this+1);
ndx += link * 5;
ndx[0] = ip;
}
// How long should the packet be?
size_t hlen_wo_data() const { return len_wo_data(_nlinks); }
size_t hlen_with_data() const { return len_with_data(_nlinks,
ntohs(_dlen)); }
static size_t len_wo_data(int nlinks) {
return sizeof(struct srpacket) +
sizeof
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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 defined to know which base to use (dec,
hex, dec_hex, ...) to display a value. If you want a range_string
displayed with base dec, hex, ... you have to duplicate
BASE_RANGE_STRING values as for example BASE_RANGE_STRING_DEC,
BASE_RANGE_STRING_HEX, ... VALS and TFS are independent from the base
chosen (or in general display field) and RVALS won't be.
What do you think of an hybrid solution between mine and your defining
an additional field (i.e. convertfield_type) in head_register_info which
identifies which type of structure is in CONVERTFIELD (strings)?
- It would bring the independence from the base avoiding us to
duplicate the fields (BASE_RANGE_STRING_DEC, BASE_RANGE_STRING_HEX, ...)
- this field could be hidden by the HFILL macro when you don't have to
use it (and use another, HFILL2(?), when you have to use this field)
- it would be scalable for the current and future implementation if you
create another structure à la range_string without changing anything in
the code of the existing dissectors.
- would be possible to use FT_BOOLEAN as well
- it's clean (from the syntax point of view and from the semantic as
well) :)
Regards,
Sebastien Tandel
Guy Harris wrote:
> 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
>>
>
> That's one way to do it.
>
> Another is to note that there's a field "display" in the
> header_field_info structure. It currently just holds a base indication
> for numbers, but it could be treated as a general "how to display this
> field" indicator, with additional information such as, for numbers,
> "display this as a numerical value"/"display this as a numerical value
> and a symbolic interpretation using a value_string table"/"display this
> as a numerical value with a range-based description"/etc..
>
> Unfortunately, that won't work for FT_BOOLEAN, as, for Boolean
> bitfields, "display" holds the value of the bigger item in which the
> bitfield is packed.
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
Index: epan/proto.c
===
--- epan/proto.c(révision 20350)
+++ epan/proto.c(copie de travail)
@@ -4028,9 +4028,15 @@
value = fvalue_get_integer(&fi->value);
/* Fill in the textual info */
- ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
+ if (hfinfo->display == BASE_RANGE_STRING) {
+ ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
format, hfinfo->name,
+ rval_to_str(value, hfinfo->strings, "Unknown"), value);
+ } else {
+ ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
+ format, hfinfo->name,
val_to_str(value, cVALS(hfinfo->strings), "Unknown"),
value);
+ }
if ((ret == -1) || (ret >= ITEM_LABEL_LENGTH))
label_str[ITEM_LABEL_LENGTH - 1] = '\0';
}
@@ -4096,9 +4102,15 @@
value = fvalue_get_integer(&fi->value);
/* Fill in the textual info */
- ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
+ if (hfinfo->display == BASE_RANGE_STRING) {
+ ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
format, hfinfo->name,
+ rval_to_str(value, hfinfo->strings, "Unknown"), value);
+ } else {
+ ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
+ format, hfinfo->name,
val_to_str(value, cVALS(hfinfo->strings), "Unknown"),
value);
+ }
if ((ret == -1) || (ret >= ITEM_LABEL_LENGTH))
label_str[ITEM_LABEL_LENGTH - 1] = '\0';
}
@@ -4195,6 +4207,7 @@
switch(hfinfo->display) {
case BASE_DEC:
case BASE_DEC_HEX:
+ case BASE_RANGE_STRING:
format = "%s: %s (%u)";
break;
case BASE_OCT: /* I'm lazy */
@@ -4319,6 +4332,7 @@
switch(hfinfo->display) {
case BASE_DEC:
case BASE_DEC_HEX:
+ case BASE_RANGE_STRING:
format = "%s: %s (%d)";
break;
case BASE_OCT: /* I'm lazy */
Index: epan/proto.h
===
--- epan/proto.h(rév
Re: [Wireshark-dev] autogen.sh: configure.in:269: invalid unused variable name: `SHAREDLIB_LDFLAGS'
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 forget whether I tried that, found that auto* > didn't like it, and tried SHAREDLIB_LDFLAGS, or not. Changing SHAREDLIB_LDFLAGS to LDFLAGS_SHAREDLIB seems to work in the test I did on OS X, at least, so I checked it in. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] autogen.sh: configure.in:269: invalid unused variable name: `SHAREDLIB_LDFLAGS'
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: > > configure.in:269: invalid unused variable name: `SHAREDLIB_LDFLAGS' > > It seems related to Guy's recent addition of: > > SHAREDLIB_LDFLAGS="-Wl,-single_module" > > Perhaps the AC_SUBST(SHAREDLIB_LDFLAGS) should be within the case/esac > block so it only takes effect if the OS is Darwin? I'm not that good > with autotools yet to know for sure. 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 forget whether I tried that, found that auto* didn't like it, and tried SHAREDLIB_LDFLAGS, or not. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] autogen.sh: configure.in:269: invalid unused variable name: `SHAREDLIB_LDFLAGS'
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 unused variable name: `SHAREDLIB_LDFLAGS' It seems related to Guy's recent addition of: SHAREDLIB_LDFLAGS="-Wl,-single_module" Perhaps the AC_SUBST(SHAREDLIB_LDFLAGS) should be within the case/esac block so it only takes effect if the OS is Darwin? I'm not that good with autotools yet to know for sure. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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 That's one way to do it. Another is to note that there's a field "display" in the header_field_info structure. It currently just holds a base indication for numbers, but it could be treated as a general "how to display this field" indicator, with additional information such as, for numbers, "display this as a numerical value"/"display this as a numerical value and a symbolic interpretation using a value_string table"/"display this as a numerical value with a range-based description"/etc.. Unfortunately, that won't work for FT_BOOLEAN, as, for Boolean bitfields, "display" holds the value of the bigger item in which the bitfield is packed. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
- 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 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 somewhat collides with WinPcap's pcap_open(), which can either open > a capture device or a capture file. Right. And strictly speaking I never liked that API too much (as much as I love pcap_next_ex, instead). The problem is always the same. If you have a single API to open files and capture devices, you are somewhat limited to the operations you can do on files. And worse, the problem in the pcap API is that you use a pcap_t handle to read a file, and a pcap_dumper_t handle to write a file. Why? GV > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL dissector conflicting with dissector plugin
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 00 00
>>
>> and the SSL payload:
>>
>> 16 03 01 00 04 0e 00 00 8...
>> 0060 00
>>
>
> In this case, your dissector should call the SSL dissector once its done
> processing its own data. See epan/dissector/packet-eap.c for an example
> of calling SSL as a sub-dissector (look for each instance of "ssl_handle"
> and how it builds next_tvb before calling it).
>
>
> Steve
>
That's what I thought I was doing, from my code:
if (isSSL)
{
if (cdirect_ssldissection)
{
next_tvb =
tvb_new_subset (tvb, tvb_get_ntohs (tvb, 6) + rhlen,
tvb_get_ntohs (tvb, 10), -1);
}
call_dissector (ssl_handle, next_tvb, pinfo, cdirect_tree);
}
}
}
The actual dissection of the SSL data works fine, it's just that when I
select "Follow SSL stream" I always get a empty panel. I always assumed
it was because the SSL was not atop TCP, I'll take a closer look when I
get a spare moment.
Thanks .. Martin
--
Scanned by ClamAV antivirus system - http://www.clamav.net
Virus signatures last updated: Fri Jan 12 18:33:21 2007
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
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 somewhat collides with WinPcap's pcap_open(), which can either open a capture device or a capture file. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
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 multiple capture > interfaces within a section and multiple sections. The alternatives I see are 1) fail as soon as a second capture interface or a second section header is seen; 2) fail as soon as a capture interface with a link-layer type or snapshot length different from the first interface's link-layer type is seen, and don't worry about section headers. >> 2) a newer API, which exposes the full capabilities of pcap-ng, and >> also transparently supports reading old-style libpcap files. > > 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. Requiring the loop that reads a saved file to be different from the loop that captures live packets wouldn't bother me too much. However, there are capture APIs that should be tied to the file format; for example, the APIs that return interface properties (there should be "enumerate all interfaces" and "get interface property" APIs) should return something very much like an Interface Description Block, and the API to get capture statistics should return something very much like an Interface Statistics Block. (The current APIs for both suck because they're not extensible, which is an issue for both - we'd have to change a data structure to add properties such as link-layer addresses to the interface properties returned by pcap_findalldevs(), and not only is there no way to add new statistics to what you get from pcap_stats() without changing the data structure, there's no way to indicate that some statistics are unavailable without changing the data structure.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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" },
{200,255, "High" },
{ 0, 0, NULL }
};
RVALS_INT(rs_value, rs_value_int)
proto_tree_add_item(tree, hf_proto_value, tvb, offset, 1, FALSE);
static hf_register_info hf[] = {
{ &hf_proto_value,
{ "Value", "proto.value",
FT_UINT8, BASE_DEC,
RVALS(rs_value_int), 0x0,
"How much is it worth", HFILL }}
};
+ Frame
+ Ethernet II
+ IP
+ TCP
+ Proto
Value: High (220)
ChangeLog :
- RVALS_INT(rs_value, rs_value_int) is added to encapsulate the
range_string structure
- and the macro RVALS take another input, to know rs_value_int
Regards,
Sebastien Tandel
Jaap Keuter wrote:
> 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
>> 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 PROTECTED] För Jaap Keuter
>> Skickat: den 12 januari 2007 15:48
>> Till: Developer support list for Wireshark
>> Ämne: Re: [Wireshark-dev] proto_tree_add_item() with range_string
>>
>> 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);
>>
>> static hf_register_info hf[] = {
>> { &hf_proto_value,
>> { "Value", "proto.value",
>> FT_UINT8, BASE_DEC,
>> RS(rs_value), 0x0,
>> "How much is it worth", HFILL }}
>> };
>>
>> + Frame
>> + Ethernet II
>> + IP
>> + TCP
>> + Proto
>> Value: High (220)
>>
>> That would require weaving in the range string handling along the types
>> where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
>> epan/proto.c comes to mind.
>>
>> Thanx,
>> Jaap
>>
>> On Fri, 12 Jan 2007, Anders Broman wrote:
>>
>>
>>> 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-dev mailing list
>> Wireshark-dev@wireshark.org
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>
>>
>>
>
>
>
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
Index: gtk/isis_analysis.c
===
Index: gtk/isis_analysis.h
===
Index: epan/value_string.h
===
--- epan/value_string.h (révision 20409)
+++ epan/value_string.h (copie de travail)
@@ -41,6 +41,15 @@
const gchar *strptr;
} range_string;
+/* Structure used to encapsulate a range_string (maybe other in the future?)
+ * and able to be used inside a hf_register_info with RVALS macro. */
+typedef struct _int_rval_val {
+ guint32 value;
+ gchar * strptr;
+ const range_string * rstr;
+}int_rval_val;
+
+
/* #define VS_DEF(x) { x, #x } */
/* #define VS_END{ 0, NULL } */
Index: epan/proto.c
===
--- epan/proto.c(révision 20409)
+++ epan/proto.c(copie de travail)
@@ -4009,6 +4009,9 @@
}
+#define INT_RVAL_GET_STR(x) ((const int_rval_val*)(x))->strptr
+#define RVAL_GET(x) ((const int_rval_val*)(x))->rstr
+
static void
fill_label_enumerated_uint(field_info *fi, gchar *label_str)
{
@@ -4023,9 +4026,15 @@
value = fvalue_get_integer(&fi->value);
/* Fill in the textual info */
- ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
+ if (INT_RVAL_GET_STR(hfinfo->strings) == NULL) {
+ ret = g_snprintf(label_str, ITEM_LABEL_LENGTH,
format, hfinfo->name,
+ rval_to_str(value, RVAL_GET(hfinfo->strings),
"Unknown"), value);
+ } else {
+
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
- 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 (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. > > That's certainly my intent for libpcap in the future. > > I want to provide two interfaces: > > 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 multiple capture interfaces within a section and multiple sections. > > 2) a newer API, which exposes the full capabilities of pcap-ng, and > also transparently supports reading old-style libpcap files. 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. Have a nice day GV > > That would give applications using libpcap to read captures (such as > tcpdump) transparent pcap-ng support (I'd convert tcpdump to use the > newer API if available, with the configure script checking for it). > Libpcap-based applications would be able to handle "typical" pcap-ng > files without change; if they changed to support the new API's, they'd > be able to handle all pcap-ng files (assuming they support all the > possible link-layer types) and still support old-style libpcap files. > > Wireshark has its own code to read libpcap files; its Wiretap library's > API, etc. is a bit different, as it's oriented towards random access and > support for non-libpcap-style file formats. The API would be changed to > handle pcap-ng's capabilities (which might also allow support to be > added for other capture file formats' capabilities). > > (If the Wiretap API were ever stable enough that we'd have good reason > to think we wouldn't have to change it to support new capture file > formats or new capabilities or link-layer types in existing file > formats, we could perhaps consider merging it with libpcap - but the > different licenses, BSD vs. GPL, would be a problem with that. Given > that Wireshark's release cycles are faster than libpcap's, we wouldn't > be ready to consider that until we have something we don't think we'd > need to change faster than libpcap. I.e., I think we'll probably > continue to have Wiretap around for a while.) > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
- 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 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 elegent fashion. > With a custom dissector, that should give us a lot of the features we're > looking for. > > Is the seeking problem a mechanics issue, or an API issue? I'd be It's an API problem, in the sense that I haven't found a set of APIs that satisfies me 100%. I don't know if you ever looked at the NTAR APIs, however there are basically three handle types: file handles, section handles and block handles. When you have an open block handle, you also have a corresponding section and file handle. When you perform a seek between blocks, if the block is within the same section, everything works ok. What happens to the section handle block when you jump to a block in a different section? Also, should it be possible to have a section seek pointer as well (so jump from a section to another, instead of block-to-block). Regarding the implementation, it's not 100% trivial, and actually depends on how the new APIs are designed. At the moment i'm trying to create some samples with different API designs and see if they make sense or not... > interest in talking about it more with you, or perhaps contributing a > bit if that makes sense. It would be definitely useful. > > 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. Modifying libpcap to write pcap-ng files is quite easy, as pcap-ng is a superset of the pcap format. Reading is much more tricky. The problem is that the current libpcap API to read pcap files doesn't support all the features of pcap-ng (the most important one is probably the fact that a capture file can contain packets coming from multiple interfaces and link layers at the same time). In this case an idea is to modify the internals of libpcap to support a minimal set of the pcap-ng features without changing the current API (e.g. files with only one section and packets from one interface). IMHO the best thing to do would be better decouple packet capture from packet logging to file. libpcap is the capture library, NTAR (or any other library) is the library used to read/write capture files. Just my two cents. GV > > Cheers! > --Benn > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:wireshark-dev- >> [EMAIL PROTECTED] On Behalf Of Gianluca Varenni >> Sent: Thursday, January 11, 2007 4:39 PM >> To: Developer support list for Wireshark >> Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap? >> >> Benn, >> >> regarding the NTAR project (i.e. the only implementation of the > pcap-ng >> "wannabe" spec so far) that I "maintain", I've been pretty busy in the >> last >> year or so, thus not being able to work on it. The project is not dead > at >> all, I'm simply giving priority to other tasks... >> >> As far as the integration with wireshark is concerned, technically >> speaking >> there is one big feature missing from NTAR that is needed by > wireshark, >> that >> is seeking within a file. >> I started working on it during the xmas holidays, but I haven't come > out >> with a definitive API for it. The main problem I'm having is the > hierarchy >> of the file (packets are embedded in blocks which are grouped into >> sections) >> that make everything much more complicated. I plan to work on it in > the >> upcoming weeks and post something on the NTAR website as soon as > possible. >> >> I think that the wireshark devs have a great interest in moving to > pcap-ng >> as the standard trace format (being it through NTAR or reimplementing > the >> spec), I have no idea where this task sits within the Wireshark > roadmap, >> and >> if this task would fit before or after the 1.0 milestone. >> >> Have a nice day >> GV >> >> >> >> - Original Message - >> From: "Benn Bollay" <[EMAIL PROTECTED]> >> To: "Developer support list for Wireshark" > >> Sent: Wednesday, January 10, 2007 2:27 PM >> Subject: [Wireshark-dev] Is pcap-ng/ntar still in roadmap? >> >> >> > Hello all - >> > >> > Is the next-gen pcap format still in the roadmap at all? I've heard >> > nothing about it for ages; there doesn't seem to be any discussions, > nor >> > any implemention details for well over a year now. >> > >> > I'm trying to decide whether I should hack-up the libpcap format or >> > spend more development effort and move entirely to
Re: [Wireshark-dev] SSL dissector conflicting with dissector plugin
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 0e 00 00 8... > 0060 00 In this case, your dissector should call the SSL dissector once its done processing its own data. See epan/dissector/packet-eap.c for an example of calling SSL as a sub-dissector (look for each instance of "ssl_handle" and how it builds next_tvb before calling it). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL dissector conflicting with dissector plugin
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 80 18 20 00 81 e4 00 00 01 01 08 0a 09 53 d3 f3 .. ..S.. 0040 09 53 d3 f3 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 8... 0060 00 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 0e 00 00 8... 0060 00 Regards .. Martin Stephen Fisher wrote the following on 12/01/2007 19:10: > 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 dissect SSL/TLS within SSL/TLS. The > dissector is called "ssl" instead of "tls" used above. > > >> My follow-up question would be; Is it possible to follow the SSL >> stream when the SSL data is embedded in another protocol? This would >> be a very useful feature for what I'm working on. >> > > What other protocol would SSL be embedded in? > > > Steve > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > jy�u�U2�צ�m > �rV�j��z�b��,� ڶ�V���]jם�Z�%���_����m4 > -- Scanned by ClamAV antivirus system - http://www.clamav.net Virus signatures last updated: Fri Jan 12 18:33:21 2007 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL dissector conflicting with dissector plugin
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 dissect SSL/TLS within SSL/TLS. The dissector is called "ssl" instead of "tls" used above. > My follow-up question would be; Is it possible to follow the SSL > stream when the SSL data is embedded in another protocol? This would > be a very useful feature for what I'm working on. What other protocol would SSL be embedded in? Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL dissector conflicting with dissector plugin
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 which specified this port so it was correctly attempting to dissect this packet as SSL after all. My follow-up question would be; Is it possible to follow the SSL stream when the SSL data is embedded in another protocol? This would be a very useful feature for what I'm working on. Regards .. Martin Martin Warnes wrote the following on 12/01/2007 16:27: > 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 off to the SSL dissector for subdissection. > > I updated the source today and now all the Connect:Direct protocol > packets are being identified as SSL continuation data, this occurs with > or without my dissector plugin loaded. > > Example for the packet below: > > > 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 80 18 20 00 81 e4 00 00 01 01 08 0a 09 53 d3 f3 .. ..S.. > 0040 09 53 d3 f3 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2 > 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 8... > 0060 00 > > The Connect:Direct protocol contains a header that starts with "TCP2" > the length of the header is offset +6 (x10), there are 4 bytes of flag > data and then the payload data starts. > >54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2 > 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 8... > 0060 00 . > > In this case the payload is SSL data starting x'16 x'03 x'01 > > Has something changed in the SSL dissector that may caue this behaviour? > I looked at the SVN history and can't see anything obvious, but a quick > look through the SSL dissector code and I saw some routines called > "ssl_looks_like_". This seems to suggest that the SSL code does a > heuristic attempt to determine whether the packet contains SSL data, > which this does although it is not the only protocol in the packet. > > Is there a way to prevent this? > > I can work around the problem by using "decode as..", but that's not a > desirable solution. > > Regards .. Martin > > > > -- > Scanned by ClamAV antivirus system - http://www.clamav.net > Virus signatures last updated: Fri Jan 12 15:33:21 2007 > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > jy�u�U2�צ�m > �rV�j��z�b��,� ڶ�V���]jם�Z�%���^����m4 > -- Scanned by ClamAV antivirus system - http://www.clamav.net Virus signatures last updated: Fri Jan 12 15:33:21 2007 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
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. That's certainly my intent for libpcap in the future. I want to provide two interfaces: 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); 2) a newer API, which exposes the full capabilities of pcap-ng, and also transparently supports reading old-style libpcap files. That would give applications using libpcap to read captures (such as tcpdump) transparent pcap-ng support (I'd convert tcpdump to use the newer API if available, with the configure script checking for it). Libpcap-based applications would be able to handle "typical" pcap-ng files without change; if they changed to support the new API's, they'd be able to handle all pcap-ng files (assuming they support all the possible link-layer types) and still support old-style libpcap files. Wireshark has its own code to read libpcap files; its Wiretap library's API, etc. is a bit different, as it's oriented towards random access and support for non-libpcap-style file formats. The API would be changed to handle pcap-ng's capabilities (which might also allow support to be added for other capture file formats' capabilities). (If the Wiretap API were ever stable enough that we'd have good reason to think we wouldn't have to change it to support new capture file formats or new capabilities or link-layer types in existing file formats, we could perhaps consider merging it with libpcap - but the different licenses, BSD vs. GPL, would be a problem with that. Given that Wireshark's release cycles are faster than libpcap's, we wouldn't be ready to consider that until we have something we don't think we'd need to change faster than libpcap. I.e., I think we'll probably continue to have Wiretap around for a while.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
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 elegent fashion. With a custom dissector, that should give us a lot of the features we're looking for. Is the seeking problem a mechanics issue, or an API issue? I'd be interest in talking about it more with you, or perhaps contributing a bit if that makes sense. 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. Cheers! --Benn > -Original Message- > From: [EMAIL PROTECTED] [mailto:wireshark-dev- > [EMAIL PROTECTED] On Behalf Of Gianluca Varenni > Sent: Thursday, January 11, 2007 4:39 PM > To: Developer support list for Wireshark > Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap? > > Benn, > > regarding the NTAR project (i.e. the only implementation of the pcap-ng > "wannabe" spec so far) that I "maintain", I've been pretty busy in the > last > year or so, thus not being able to work on it. The project is not dead at > all, I'm simply giving priority to other tasks... > > As far as the integration with wireshark is concerned, technically > speaking > there is one big feature missing from NTAR that is needed by wireshark, > that > is seeking within a file. > I started working on it during the xmas holidays, but I haven't come out > with a definitive API for it. The main problem I'm having is the hierarchy > of the file (packets are embedded in blocks which are grouped into > sections) > that make everything much more complicated. I plan to work on it in the > upcoming weeks and post something on the NTAR website as soon as possible. > > I think that the wireshark devs have a great interest in moving to pcap-ng > as the standard trace format (being it through NTAR or reimplementing the > spec), I have no idea where this task sits within the Wireshark roadmap, > and > if this task would fit before or after the 1.0 milestone. > > Have a nice day > GV > > > > - Original Message - > From: "Benn Bollay" <[EMAIL PROTECTED]> > To: "Developer support list for Wireshark" > Sent: Wednesday, January 10, 2007 2:27 PM > Subject: [Wireshark-dev] Is pcap-ng/ntar still in roadmap? > > > > Hello all - > > > > Is the next-gen pcap format still in the roadmap at all? I've heard > > nothing about it for ages; there doesn't seem to be any discussions, nor > > any implemention details for well over a year now. > > > > I'm trying to decide whether I should hack-up the libpcap format or > > spend more development effort and move entirely to something else. > > > > Cheers, > > --Benn > > ___ > > Wireshark-dev mailing list > > Wireshark-dev@wireshark.org > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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 of the structure you have. In the current code of proto.c you can't
decide if it's a range_string or value_string structure at this point.
You then have to implement a mechanism which can decide which type it is
before thinking about a specific treatment in proto.c
You may operate like the following by creating an intermediate structure
which will be used to determine which is the structure we're using :
(little bit tricky but it's working (I already have a patch for))
*** in value_string.h
typedef struct _rval_val_int {
guint32 value;
gchar * strptr;
const range_string * rstr;
}rval_val_int;
*** in proto.h
#define RVALS(x) (const _value_string*)(x)
*** in your dissector
const range_string rstr[] = {
{ 0, 10, "test" },
{ 0, 0, NULL }
};
const rval_val_int rval_interm[] = {
{ 0, NULL, rstr }
};
After having done this work, you can now change the code of
fill_label_enumerate_(u)int by doing a test on the first string element
of the structure you have if it's NULL => you have a range_string
structure. (you may imagine having more different types of structures,
and then doing a test on string names?)
refinement :
you may define a macro to hide a little bit more the intermediate structure
#define RVAL_INT(rvalstring, int_rvalstring) const rval_val_int
(int_rvalstring_name)[]= { { 0, NULL, rvalstring } };
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
Regards,
Sebastien Tandel
Jaap Keuter wrote:
> 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
>> 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 PROTECTED] För Jaap Keuter
>> Skickat: den 12 januari 2007 15:48
>> Till: Developer support list for Wireshark
>> Ämne: Re: [Wireshark-dev] proto_tree_add_item() with range_string
>>
>> 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);
>>
>> static hf_register_info hf[] = {
>> { &hf_proto_value,
>> { "Value", "proto.value",
>> FT_UINT8, BASE_DEC,
>> RS(rs_value), 0x0,
>> "How much is it worth", HFILL }}
>> };
>>
>> + Frame
>> + Ethernet II
>> + IP
>> + TCP
>> + Proto
>> Value: High (220)
>>
>> That would require weaving in the range string handling along the types
>> where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
>> epan/proto.c comes to mind.
>>
>> Thanx,
>> Jaap
>>
>> On Fri, 12 Jan 2007, Anders Broman wrote:
>>
>>
>>> 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-dev mailing list
>> Wireshark-dev@wireshark.org
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>
>>
>>
>
>
>
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] SSL dissector conflicting with dissector plugin
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 off to the SSL dissector for subdissection. I updated the source today and now all the Connect:Direct protocol packets are being identified as SSL continuation data, this occurs with or without my dissector plugin loaded. Example for the packet below: 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 80 18 20 00 81 e4 00 00 01 01 08 0a 09 53 d3 f3 .. ..S.. 0040 09 53 d3 f3 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 8... 0060 00 The Connect:Direct protocol contains a header that starts with "TCP2" the length of the header is offset +6 (x10), there are 4 bytes of flag data and then the payload data starts. 54 43 50 32 00 02 00 10 00 00 00 09 .S..TCP2 0050 80 00 00 00 38 00 00 00 16 03 01 00 04 0e 00 00 8... 0060 00 . In this case the payload is SSL data starting x'16 x'03 x'01 Has something changed in the SSL dissector that may caue this behaviour? I looked at the SVN history and can't see anything obvious, but a quick look through the SSL dissector code and I saw some routines called "ssl_looks_like_". This seems to suggest that the SSL code does a heuristic attempt to determine whether the packet contains SSL data, which this does although it is not the only protocol in the packet. Is there a way to prevent this? I can work around the problem by using "decode as..", but that's not a desirable solution. Regards .. Martin -- Scanned by ClamAV antivirus system - http://www.clamav.net Virus signatures last updated: Fri Jan 12 15:33:21 2007 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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
> 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 PROTECTED] F??r Jaap Keuter
> Skickat: den 12 januari 2007 15:48
> Till: Developer support list for Wireshark
> ??mne: Re: [Wireshark-dev] proto_tree_add_item() with range_string
>
> 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);
>
> static hf_register_info hf[] = {
> { &hf_proto_value,
> { "Value", "proto.value",
> FT_UINT8, BASE_DEC,
> RS(rs_value), 0x0,
> "How much is it worth", HFILL }}
> };
>
> + Frame
> + Ethernet II
> + IP
> + TCP
> + Proto
> Value: High (220)
>
> That would require weaving in the range string handling along the types
> where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
> epan/proto.c comes to mind.
>
> Thanx,
> Jaap
>
> On Fri, 12 Jan 2007, Anders Broman wrote:
>
> > 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-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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 PROTECTED] För Jaap Keuter
Skickat: den 12 januari 2007 15:48
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] proto_tree_add_item() with range_string
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);
static hf_register_info hf[] = {
{ &hf_proto_value,
{ "Value", "proto.value",
FT_UINT8, BASE_DEC,
RS(rs_value), 0x0,
"How much is it worth", HFILL }}
};
+ Frame
+ Ethernet II
+ IP
+ TCP
+ Proto
Value: High (220)
That would require weaving in the range string handling along the types
where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
epan/proto.c comes to mind.
Thanx,
Jaap
On Fri, 12 Jan 2007, Anders Broman wrote:
> 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-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] write plugin following README.plugins
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 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 guide up to date and what could I have possibly missed? > > Cheers > Armin > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
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);
static hf_register_info hf[] = {
{ &hf_proto_value,
{ "Value", "proto.value",
FT_UINT8, BASE_DEC,
RS(rs_value), 0x0,
"How much is it worth", HFILL }}
};
+ Frame
+ Ethernet II
+ IP
+ TCP
+ Proto
Value: High (220)
That would require weaving in the range string handling along the types
where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
epan/proto.c comes to mind.
Thanx,
Jaap
On Fri, 12 Jan 2007, Anders Broman wrote:
> 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
Re: [Wireshark-dev] Win32 build broken?
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. > 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: Developer support list for Wireshark > Subject: [Wireshark-dev] Win32 build broken? > > 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 a member of > 'SslPacketInfo' >..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of > 'SslPacketInfo' > ssl-dlg.c(176) : error C2039: 'app_data' : is not a member of > 'SslPacketInfo' >..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of > 'SslPacketInfo' > > Any idea? > > Thanks, > Giorgio > > > - Original Message - > From: "Ulf Lamping" <[EMAIL PROTECTED]> > To: > Sent: Friday, January 12, 2007 12:43 PM > Subject: Re: [Wireshark-dev] [The Wireshark Wiki] Update of "FrontPage" > bynickvlas > > >> 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 >>> >>> > > -- >>>* ["Preferences"]: Preference settings controlling the behaviour > of >>> Wireshark and TShark >>>* ["Statistics"]: Statistics range from general capture file >>> information to protocol specific statistics >>>* ["Security"]: how to use Wireshark as securely as possible >>> + * [http://freeclips.adrenalinbet.com free porn clips] Preference >>> settings controlling the behaviour of Wireshark >>>* ["Performance"]: how to "fine tune" Wireshark's performance >>>* ["Timestamps"]: Accuracy, precision, and resolution >>>* ["Tools"]: tools and scripts that relate to the use of Wireshark > and >>> TShark >>> >>> >> Hi Gerald! >> >> Someones spamming the frontpage repeatedly :-( >> >> Maybe it's time to lock write access to a few known developers? >> >> Regards, ULFL >> ___ >> Wireshark-dev mailing list >> Wireshark-dev@wireshark.org >> http://www.wireshark.org/mailman/listinfo/wireshark-dev > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] write plugin following README.plugins
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 guide up to date and what could I have possibly missed? Cheers Armin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build Error in 0.99.4 LNK1181/U1073
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 without the option to fix the ones that didn't compile the first time. > I found out, that the problem started with the libui.lib (in GTK) which > couldn´t be build. > There seems to be another declaration of somehting in VS 2005 (V.8) that > tries to overwrite one of the definitions in the wireshark sources. > > After commenting out the IFNDEF line in the source of VS, it worked further > on to the next problem with the openssl.h which was called in the GTK Package > and a new error. > > It just looked like my environment isn´t suitable for that task.(VS 2005 V8, > cygwin and nmake.exe) > Switching to linux (ubuntu) should help me at least compiling wireshark and > starting with my 802.15.4 plugin project. > > If you want to have more Information about my problem, I could switch back to > Windows, but for now I will use Linux instead. > Thank you anyway. Upgrade to the latest SVN. It compiles with MSCV2005 with almost no fiddling. There has been an ongoing discussion in wireshark-dev between Ulf, Anders, Laurent and me (with a few others thrown in for good measure) over the last couple of weeks to get it working. -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Win32 build broken?
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: Developer support list for Wireshark Subject: [Wireshark-dev] Win32 build broken? 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 a member of 'SslPacketInfo' ..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of 'SslPacketInfo' ssl-dlg.c(176) : error C2039: 'app_data' : is not a member of 'SslPacketInfo' ..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of 'SslPacketInfo' Any idea? Thanks, Giorgio - Original Message - From: "Ulf Lamping" <[EMAIL PROTECTED]> To: Sent: Friday, January 12, 2007 12:43 PM Subject: Re: [Wireshark-dev] [The Wireshark Wiki] Update of "FrontPage" bynickvlas > 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 >> >> -- >>* ["Preferences"]: Preference settings controlling the behaviour of >> Wireshark and TShark >>* ["Statistics"]: Statistics range from general capture file >> information to protocol specific statistics >>* ["Security"]: how to use Wireshark as securely as possible >> + * [http://freeclips.adrenalinbet.com free porn clips] Preference >> settings controlling the behaviour of Wireshark >>* ["Performance"]: how to "fine tune" Wireshark's performance >>* ["Timestamps"]: Accuracy, precision, and resolution >>* ["Tools"]: tools and scripts that relate to the use of Wireshark and >> TShark >> >> > Hi Gerald! > > Someones spamming the frontpage repeatedly :-( > > Maybe it's time to lock write access to a few known developers? > > Regards, ULFL > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build Error in 0.99.4 LNK1181/U1073
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 declaration of somehting in VS 2005 (V.8) that tries to overwrite one of the definitions in the wireshark sources. After commenting out the IFNDEF line in the source of VS, it worked further on to the next problem with the openssl.h which was called in the GTK Package and a new error. It just looked like my environment isn´t suitable for that task.(VS 2005 V8, cygwin and nmake.exe) Switching to linux (ubuntu) should help me at least compiling wireshark and starting with my 802.15.4 plugin project. If you want to have more Information about my problem, I could switch back to Windows, but for now I will use Linux instead. Thank you anyway. With kind Regards Jan Original-Nachricht Datum: Fri, 12 Jan 2007 10:40:48 +0100 (CET) Von: Jaap Keuter <[EMAIL PROTECTED]> An: Developer support list for Wireshark Betreff: Re: [Wireshark-dev] Build Error in 0.99.4 LNK1181/U1073 > 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 nmake now doesn't know how to build. > > Debugger rule of thumb: Always start with the first problem, then work > your way down. Ignoring them won't make them go away. > > Thanx, > Jaap > > On Fri, 12 Jan 2007, Jan Kokott wrote: > > > 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 > 'capture_if_details_dlg.obj' > > NMAKE : fatal error U1073: don't know how to make 'gtk\libui.lib' > > Stop. > > > > The second fatal error was found some time ago : > > http://www.ethereal.com/lists/ethereal-dev/200606/msg00228.html > > but no one answered to the problem. > > > > I tried to do it again with a distclean and another cmd Window with > clean Path as suggested here > http://www.wireshark.org/lists/wireshark-dev/200611/msg00590.html > > but that didn´t work. > > > > Anyone got a solution to this problem ? > > > > So longJan > > > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Win32 build broken?
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 a member of 'SslPacketInfo' ..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of 'SslPacketInfo' ssl-dlg.c(176) : error C2039: 'app_data' : is not a member of 'SslPacketInfo' ..\epan/dissectors/packet-ssl-utils.h(640) : see declaration of 'SslPacketInfo' Any idea? Thanks, Giorgio - Original Message - From: "Ulf Lamping" <[EMAIL PROTECTED]> To: Sent: Friday, January 12, 2007 12:43 PM Subject: Re: [Wireshark-dev] [The Wireshark Wiki] Update of "FrontPage" bynickvlas > 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 >> >> -- >>* ["Preferences"]: Preference settings controlling the behaviour of >> Wireshark and TShark >>* ["Statistics"]: Statistics range from general capture file >> information to protocol specific statistics >>* ["Security"]: how to use Wireshark as securely as possible >> + * [http://freeclips.adrenalinbet.com free porn clips] Preference >> settings controlling the behaviour of Wireshark >>* ["Performance"]: how to "fine tune" Wireshark's performance >>* ["Timestamps"]: Accuracy, precision, and resolution >>* ["Tools"]: tools and scripts that relate to the use of Wireshark and >> TShark >> >> > Hi Gerald! > > Someones spamming the frontpage repeatedly :-( > > Maybe it's time to lock write access to a few known developers? > > Regards, ULFL > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [The Wireshark Wiki] Update of "FrontPage" by nickvlas
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 > > -- >* ["Preferences"]: Preference settings controlling the behaviour of > Wireshark and TShark >* ["Statistics"]: Statistics range from general capture file information > to protocol specific statistics >* ["Security"]: how to use Wireshark as securely as possible > + * [http://freeclips.adrenalinbet.com free porn clips] Preference settings > controlling the behaviour of Wireshark >* ["Performance"]: how to "fine tune" Wireshark's performance >* ["Timestamps"]: Accuracy, precision, and resolution >* ["Tools"]: tools and scripts that relate to the use of Wireshark and > TShark > > Hi Gerald! Someones spamming the frontpage repeatedly :-( Maybe it's time to lock write access to a few known developers? Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] proto_tree_add_item() with range_string
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
Re: [Wireshark-dev] Build Error in 0.99.4 LNK1181/U1073
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 nmake now doesn't know how to build. Debugger rule of thumb: Always start with the first problem, then work your way down. Ignoring them won't make them go away. Thanx, Jaap On Fri, 12 Jan 2007, Jan Kokott wrote: > 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 > 'capture_if_details_dlg.obj' > NMAKE : fatal error U1073: don't know how to make 'gtk\libui.lib' > Stop. > > The second fatal error was found some time ago : > http://www.ethereal.com/lists/ethereal-dev/200606/msg00228.html > but no one answered to the problem. > > I tried to do it again with a distclean and another cmd Window with clean > Path as suggested here > http://www.wireshark.org/lists/wireshark-dev/200611/msg00590.html > but that didn??t work. > > Anyone got a solution to this problem ? > > So longJan > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Build Error in 0.99.4 LNK1181/U1073
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 'capture_if_details_dlg.obj' NMAKE : fatal error U1073: don't know how to make 'gtk\libui.lib' Stop. The second fatal error was found some time ago : http://www.ethereal.com/lists/ethereal-dev/200606/msg00228.html but no one answered to the problem. I tried to do it again with a distclean and another cmd Window with clean Path as suggested here http://www.wireshark.org/lists/wireshark-dev/200611/msg00590.html but that didn´t work. Anyone got a solution to this problem ? So longJan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
