On Mon, Sep 16, 2013 at 11:48:54PM +0200, Joerg Mayer wrote:
> Thanks. I just copied over the change to cmake. Out of curiosity:
> How did you find out which file was missing, so I may be able to
> fix this myself in the future?
And another question: I noticed that the IMPORT statements in .cnf fi
On Mon, Sep 16, 2013 at 10:13:41PM +, Christopher Maynard wrote:
> Joerg Mayer writes:
>
> > Thanks. I just copied over the change to cmake. Out of curiosity:
> > How did you find out which file was missing, so I may be able to
> > fix this myself in the future?
[Explanation deleted]
> so I
I did a bit of work on this, and there are now 31 files remaining.
Some of them (see my recent email on unlicensed tools) appear to be
just oversights that will involve tracking down and emailing the
original author. Others just have a header that is
non-standard/malformed and can be easily fixed.
Should we, instead, look the port number up in the "tcp.port" or "udp.port" (or
"sctp.port") dissector table and, if it finds a dissector handle, look up the short name of the
protocol for that dissector handle and use that?
I think this is more useful, since the dissector short name is typica
Joerg Mayer writes:
> When I try to generate the idmp dissctor in asn1/idmp/, I get an error:
>
> If I build all asn1 dissectors in order (make in asn1/), then it builds fine,
> so it looks like there is some sort of dependency problem.
It looks like the dependency in this case was on x509af.
Joerg Mayer writes:
> Thanks. I just copied over the change to cmake. Out of curiosity:
> How did you find out which file was missing, so I may be able to
> fix this myself in the future?
Thanks for applying to cmake.
I noticed your output:
> /home/jmayer/work/wireshark/svn/trunk/asn1/x509ce/x
No, the issue is a dissector wants to use "reserved" or "Unknown ",
etc instead of the strict "Unknown". Providing the numeric value that
accompanies that enumeration is almost secondary.
I think Jakub's idea is a good one, just didn't know if we wanted to convert
all (most) value_strings
On Mon, Sep 16, 2013 at 09:36:07PM +, Christopher Maynard wrote:
> Joerg Mayer writes:
>
> > When I try to generate the idmp dissctor in asn1/idmp/, I get an error:
> >
> > If I build all asn1 dissectors in order (make in asn1/), then it builds
> > fine,
> > so it looks like there is some s
When I try to generate the idmp dissctor in asn1/idmp/, I get an error:
jmayer@egg:~/work/wireshark/svn/build/test/asn1/idmp> make
Scanning dependencies of target x509ce-exp.cnf
ASN.1 to Wireshark dissector compiler
/home/jmayer/work/wireshark/svn/trunk/asn1/x509ce/x509ce.cnf:18: UserWarning:
Non
On Sep 16, 2013, at 1:15 PM, Dirk Jagdmann wrote:
>> Should we, instead, look the port number up in the "tcp.port" or "udp.port"
>> (or "sctp.port") dissector table and, if it finds a dissector handle, look
>> up the short name of the protocol for that dissector handle and use that?
>
> I thi
On 09/16/13 16:04, Guy Harris wrote:
On Sep 16, 2013, at 12:44 PM, Anders Broman wrote:
I got rid of getservbyport() and added reading of the local services file
perhaps the read should be removed again?
"Local services file" as in "/etc/services" on UN*X and its equivalent on Windows
(C:
On 9/16/2013 4:15 PM, Dirk Jagdmann wrote:
Should we, instead, look the port number up in the "tcp.port" or
"udp.port" (or "sctp.port") dissector table and, if it finds a
dissector handle, look up the short name of the protocol for that
dissector handle and use that?
I think this is more useful
On Sep 16, 2013, at 1:39 PM, Jeff Morriss wrote:
> On 09/16/13 16:04, Guy Harris wrote:
>>
>> On Sep 16, 2013, at 12:44 PM, Anders Broman wrote:
>>
>>> If we decide to have it default off perhaps we shouldn't default to write
>>> User Datagram Protocol, Src Port: 6 (6), Dst Port: 1386
Should we, instead, look the port number up in the "tcp.port" or "udp.port" (or
"sctp.port") dissector table and, if it finds a dissector handle, look up the short name of the
protocol for that dissector handle and use that?
I think this is more useful, since the dissector short name is typica
Jeff Morriss skrev 2013-09-16 21:17:
On 09/16/13 14:57, Guy Harris wrote:
On Sep 16, 2013, at 7:20 AM, Anders Broman
wrote:
In serv_name_lookup() we call getservbyport() for ports not resolved
in the IANA port list the function
Seems quite expensive so my question is does it add any value
On Sep 16, 2013, at 12:44 PM, Anders Broman wrote:
> I got rid of getservbyport() and added reading of the local services file
> perhaps the read should be removed again?
"Local services file" as in "/etc/services" on UN*X and its equivalent on
Windows (C:\winnt\system32\drivers\etc\services?
On Mon, Sep 16, 2013 at 03:17:54PM -0400, Jeff Morriss wrote:
> On 09/16/13 14:57, Guy Harris wrote:
> >
> > On Sep 16, 2013, at 7:20 AM, Anders Broman
> > wrote:
> >
> >> In serv_name_lookup() we call getservbyport() for ports not resolved in
> >> the IANA port list the function
> >> Seems quit
On 09/16/13 14:57, Guy Harris wrote:
On Sep 16, 2013, at 7:20 AM, Anders Broman wrote:
In serv_name_lookup() we call getservbyport() for ports not resolved in the
IANA port list the function
Seems quite expensive so my question is does it add any value or can I remove
it?
At least on UN*X
On 09/16/13 06:49, mman...@netscape.net wrote:
Is there a way to provide the "unknown string" for the val_to_str call
made in hf_ registration (ie some derivation of the VALS() macro)?
There are many proto_tree_add_[u]int_format[_value] calls that are done
strictly to provided an "unknown string"
On Sep 16, 2013, at 7:20 AM, Anders Broman wrote:
> In serv_name_lookup() we call getservbyport() for ports not resolved in the
> IANA port list the function
> Seems quite expensive so my question is does it add any value or can I remove
> it?
At least on UN*Xes, getservbyport() does one or m
On Mon, Sep 16, 2013 at 06:47:50AM -0400, mman...@netscape.net wrote:
> Is there a way to provide the "unknown string" for the val_to_str call made
> in hf_ registration (ie some derivation of the VALS() macro)?
> There are many proto_tree_add_[u]int_format[_value] calls that are done
> strictly
On Sep 16, 2013, at 1:18 PM, Francisco Sanchez wrote:
> Dear dev,
>
> My name is Francisco Sanchez. I'm a PhD who's trying to install Wireshark
> latest version in order to obtain the new releases. For that purposes,
> following your instructions at:
>
> http://www.wireshark.org/docs/wsdg_htm
Hi,
In serv_name_lookup() we call getservbyport() for ports not resolved in the
IANA port list the function
Seems quite expensive so my question is does it add any value or can I remove
it?
Regards
Anders
___
Sent via:Wi
Hi, List,
While update 1.8.8 to 1.8.9 on SUSE, we found some CVE(s) specified 'fixed' in
release note, still has problems in new version.
Now update to 1.8.10, those problems still exist. Could anyone familiar with
this bugs check it?
wireshark is crashing for HTTP dissector when 'Decode As...'
Is there a way to provide the "unknown string" for the val_to_str call made in
hf_ registration (ie some derivation of the VALS() macro)? There are many
proto_tree_add_[u]int_format[_value] calls that are done strictly to provided
an "unknown string" for the val_to_str that is different than
Is there a way to provide the "unknown string" for the val_to_str call made in
hf_ registration (ie some derivation of the VALS() macro)? There are many
proto_tree_add_[u]int_format[_value] calls that are done strictly to provided
an "unknown string" for the val_to_str that is different than
26 matches
Mail list logo
