Re: [Wireshark-dev] [Wireshark-commits] rev 21716: /trunk/ /trunk/epan/: epan.c epan.h libwireshark.def proto.c proto.h /trunk/gtk/: about_dlg.c about_dlg.h main.c /trunk/tools/: make-dissector-reg ma
Is it just me or does this change slow down the launching of Wireshark noticably? On Mon, May 07, 2007 at 05:55:47PM +, [EMAIL PROTECTED] wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21716 > > User: gal > Date: 2007/05/07 05:55 PM > > Log: > Updated splash screen for Wireshark that shows the initialisation progress. > The splash screen shows a progress bar and a percentage complete - like the > progress dialog. > As dissectors are initialised and handed off the name is shown. However, the > names of plugin dissectors are not shown. > The update to the make-dissector-reg shell script has been tested, though I > think generally the python version is used. > > Directory: /trunk/epan/ > ChangesPathAction > +5 -3 epan.c Modified > +5 -2 epan.h Modified > +1 -0 libwireshark.defModified > +10 -4 proto.c Modified > +5 -2 proto.h Modified > > Directory: /trunk/gtk/ > ChangesPath Action > +123 -4about_dlg.cModified > +5 -4 about_dlg.hModified > +7 -6 main.c Modified > > Directory: /trunk/tools/ > ChangesPath Action > +62 -9 make-dissector-reg Modified > +23 -4 make-dissector-reg.pyModified > > > (3 files not shown) > ___ > Wireshark-commits mailing list > [EMAIL PROTECTED] > http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] OpcUa update
Gerhard Gappmeier wrote:
> it loads the file imediately on my computer without any delay.
> I tried the fuzzy file also with tshark.
> I called "tshark -r sample.cap", is this right?
> Because it didn't crash for me. I tried it several times.
>
> Any ideas why it behaves different for you?
> I'm currently working on revision 21246.
> Compiled with VC6 on windows.
>
Gerald already gave you some notes. BTW: accessing "unknown" memory can
result in virtually *every* possible response ...
>> Some points that I've seen immediately:
>> - you *must* end *every* value_string you use by a an ending sequence
>> { 0, NULL }, otherwise unexpected values coming from the network will
>> result in an access
>>
> Ok, I'll fix that.
>
That's the main point that *needs* to be fixed and I guess it's the
cause of the regression test problems. Unless there are other problems
as well ;-)
>> violation, as the corresponding access functions will run into the
>> wrong memory areas
>> - e.g. opcua.c / g_szMessageTypes unnecessarily re-implements a
>> value_string - this bloats code size and complexity
>>
>>
> I don't know how to do this with value_string.
> I'm parsing textual protocol message signatures and not numbers:
> e,g, "UATH" -> "Hello Message"
> "UAMA" -> "Abort Message"
> ...
> static char* g_szMessageTypes[] =
> {
> "Hello message",
> "Acknowledge message",
> "Disconnect message",
> "Data message, last chunk in message.",
> "Data message, further chunks must follow.",
> "Abort message",
> "Error message",
> "Invalid message",
> "Unknown message"
> };
> How does this small string table bloat the code size?
> It wouldn't be smaller with value_string.
> And the parsing code always defaults to "Unkown message", so there is no
> way for an out of bounds szenerio
> like with the value_string arrays and so I don't need NULL at the end here.
>
Sorry for the noise, I didn't saw the pfctParse, so you'll actually need
the if/switch construct anyway, regardless of the strings - just forget
this one ...
Regards, ULFL
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] OpcUa update
Gerhard Gappmeier wrote:
> Hi,
>
>> A fuzzed Sample.cap file (attached) crashed TShark and took a *very*
>> long time (2 mins) to load in WS.
>>
> it loads the file imediately on my computer without any delay.
> I tried the fuzzy file also with tshark.
> I called "tshark -r sample.cap", is this right?
> Because it didn't crash for me. I tried it several times.
You might try "tshark -rVx", which forces a packet detail hex dump
display for each packet. If a bug is inside an "if (tree) { ... }"
block, then a simple "tshark -r" won't find it.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits]rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.cpacket-ber.c
Hi,
Thanks, I'll check if I have any traces and send them privatly.
Regards
Anders
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
Sent: den 7 maj 2007 13:19
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev]
[Wireshark-commits]rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.cpacket-ber.cpacket-ber.hpacket-camel.c
...
Hi,
the T.38 is PER dissector, i.e. it is not involved in changes in BER.
BTW T.38 has been automatically generated since last week.
I will make changes into asn2wrs activable with commandline option -X.
@Anders, dou you have available any RNSAP traces?
Regards,
Tomas
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Monday, May 07, 2007 10:21 AM
To: Developer support list for Wireshark
Subject: SV: [Wireshark-dev] [Wireshark-commits]
rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
packet-ber.cpacket-ber.hpacket-camel.c ...
Hi,
Could you do the asn2wrs changes and send me the file then I could do some
experiments and
see how much work is involved? At least you have taken care of T38 then there
is Kerberos
and some gsm stuff so it might not be to difficult.
Regards
Anders
Från: [EMAIL PROTECTED] genom Kukosa, Tomas
Skickat: må 2007-05-07 09:42
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] [Wireshark-commits]
rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
packet-ber.cpacket-ber.hpacket-camel.c ...
Hi,
BTW when you are making such large changes do not you think about
changing of packet-ber from "field oriented" to "type oriented"?
I.e. replacing
field_function() {
type_function(hf_field);
}
sequence_structure[] = {
{..., field_function},
}
with code
sequence_structure[] = {
{&hf_field, ..., type_function},
}
I did the same for PER last year and generated code is much shorter.
Unfortunately it will be probaly very hard for BER as there are much BER
code written by hands which can not be regenerated but has to be
changed.
regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Monday, May 07, 2007 8:57 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
21705:/trunk//trunk/plugins/asn1/:
asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
packet-camel.c ...
Hi,
I thought as much but there is still a lot of work to get the actx into
all the BER dissecors. I'm taking it a step
At the time.
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
Sent: den 7 maj 2007 07:58
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
/trunk//trunk/plugins/asn1/: asn1.h
packet-asn1.c/trunk/epan/dissectors/:
packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
packet-ber.cpacket-ber.h packet-camel.c ...
Hello Anders,
I had not checked X.690 (BER) specification before I defined PER
external structures in asn1_ctx_t.
I expected BER uses encoding based on X.680 definition.
I think we could merge most of PER and BER items in external structure.
I will move PER items one layer upper and you can reuse them later in
BER too.
Regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 07, 2007 12:34 AM
To: [EMAIL PROTECTED]
Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
packet-ber.h packet-camel.c ...
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21705
User: etxrab
Date: 2007/05/06 10:34 PM
Log:
Start introducing actx to ber functions.
Directory: /trunk/plugins/asn1/
ChangesPath Action
+45 -0 asn1.h Modified
+0 -1 packet-asn1.cModified
Directory: /trunk/epan/dissectors/
ChangesPath Action
+20 -20packet-MAP_DialoguePDU.c Modified
+56 -56packet-acp133.c Modified
+103 -103 packet-acse.cModified
+501 -501 packet-ansi_map.cModified
+13 -10packet-ber.c Modified
+2 -1 packet-ber.h Modified
+434 -434 packet-camel.c Modified
+8 -8
Re: [Wireshark-dev] OpcUa update
Hi,
> A fuzzed Sample.cap file (attached) crashed TShark and took a *very*
> long time (2 mins) to load in WS.
>
it loads the file imediately on my computer without any delay.
I tried the fuzzy file also with tshark.
I called "tshark -r sample.cap", is this right?
Because it didn't crash for me. I tried it several times.
Any ideas why it behaves different for you?
I'm currently working on revision 21246.
Compiled with VC6 on windows.
>
> Some points that I've seen immediately:
> - you *must* end *every* value_string you use by a an ending sequence
> { 0, NULL }, otherwise unexpected values coming from the network will
> result in an access
Ok, I'll fix that.
> violation, as the corresponding access functions will run into the
> wrong memory areas
> - e.g. opcua.c / g_szMessageTypes unnecessarily re-implements a
> value_string - this bloats code size and complexity
>
I don't know how to do this with value_string.
I'm parsing textual protocol message signatures and not numbers:
e,g, "UATH" -> "Hello Message"
"UAMA" -> "Abort Message"
...
static char* g_szMessageTypes[] =
{
"Hello message",
"Acknowledge message",
"Disconnect message",
"Data message, last chunk in message.",
"Data message, further chunks must follow.",
"Abort message",
"Error message",
"Invalid message",
"Unknown message"
};
How does this small string table bloat the code size?
It wouldn't be smaller with value_string.
And the parsing code always defaults to "Unkown message", so there is no
way for an out of bounds szenerio
like with the value_string arrays and so I don't need NULL at the end here.
regards,
Gerhard.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c packet-ber
Hi,
the T.38 is PER dissector, i.e. it is not involved in changes in BER.
BTW T.38 has been automatically generated since last week.
I will make changes into asn2wrs activable with commandline option -X.
@Anders, dou you have available any RNSAP traces?
Regards,
Tomas
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Monday, May 07, 2007 10:21 AM
To: Developer support list for Wireshark
Subject: SV: [Wireshark-dev] [Wireshark-commits]
rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
packet-ber.cpacket-ber.hpacket-camel.c ...
Hi,
Could you do the asn2wrs changes and send me the file then I could do some
experiments and
see how much work is involved? At least you have taken care of T38 then there
is Kerberos
and some gsm stuff so it might not be to difficult.
Regards
Anders
Från: [EMAIL PROTECTED] genom Kukosa, Tomas
Skickat: må 2007-05-07 09:42
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] [Wireshark-commits]
rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
packet-ber.cpacket-ber.hpacket-camel.c ...
Hi,
BTW when you are making such large changes do not you think about
changing of packet-ber from "field oriented" to "type oriented"?
I.e. replacing
field_function() {
type_function(hf_field);
}
sequence_structure[] = {
{..., field_function},
}
with code
sequence_structure[] = {
{&hf_field, ..., type_function},
}
I did the same for PER last year and generated code is much shorter.
Unfortunately it will be probaly very hard for BER as there are much BER
code written by hands which can not be regenerated but has to be
changed.
regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Monday, May 07, 2007 8:57 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
21705:/trunk//trunk/plugins/asn1/:
asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
packet-camel.c ...
Hi,
I thought as much but there is still a lot of work to get the actx into
all the BER dissecors. I'm taking it a step
At the time.
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
Sent: den 7 maj 2007 07:58
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
/trunk//trunk/plugins/asn1/: asn1.h
packet-asn1.c/trunk/epan/dissectors/:
packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
packet-ber.cpacket-ber.h packet-camel.c ...
Hello Anders,
I had not checked X.690 (BER) specification before I defined PER
external structures in asn1_ctx_t.
I expected BER uses encoding based on X.680 definition.
I think we could merge most of PER and BER items in external structure.
I will move PER items one layer upper and you can reuse them later in
BER too.
Regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 07, 2007 12:34 AM
To: [EMAIL PROTECTED]
Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
packet-ber.h packet-camel.c ...
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21705
User: etxrab
Date: 2007/05/06 10:34 PM
Log:
Start introducing actx to ber functions.
Directory: /trunk/plugins/asn1/
ChangesPath Action
+45 -0 asn1.h Modified
+0 -1 packet-asn1.cModified
Directory: /trunk/epan/dissectors/
ChangesPath Action
+20 -20packet-MAP_DialoguePDU.c Modified
+56 -56packet-acp133.c Modified
+103 -103 packet-acse.cModified
+501 -501 packet-ansi_map.cModified
+13 -10packet-ber.c Modified
+2 -1 packet-ber.h Modified
+434 -434 packet-camel.c Modified
+8 -8 packet-cdt.c Modified
+133 -133 packet-cmip.cModified
(68 files not shown)
___
Wireshark-commits mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-commits
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wir
Re: [Wireshark-dev] [Wireshark-commits]rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.cpacket-ber.c
Hi,
You are probably right. As with other stuff where "hand" made BER/PER code is
used
I have made dummy files to let asn2wrs create the code to cut-and-paste to
where needed
Should we check that type of code in some where and if so where?
/asn1/helpers/
/ros
/kerberos
/...
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ronnie sahlberg
Sent: den 7 maj 2007 11:20
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev]
[Wireshark-commits]rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.cpacket-ber.cpacket-ber.hpacket-camel.c
...
Is it really worth it to asn2wsr'ify the kerberos dissector?
First, the dissector currently handles two different versions of kerberos, both
the "standard" 1510 ASN but also the slightly different ASN used by packetcable.
Second, the dissector as it is today is almost complete and dissects virtually
the entire asn for both dialects of kerberos we support, so asn2wrs'ifying it
will not really increase the coverage of it.
Third, the dissector contains a lot of special stuff that vendors
(==ms) added to kerberos that is not ans1 defined,things such as
storing nt_status codes inside salt fields and also calling off to NDR stuff
like the PAC in w2k domains
Fourth, there is a lot of code to handle the decryption feature which also
ties into the various places where krb is used un conjunction with gss-api for
decryption of packets (== dcerpc and secure ldap)
maybe it is easier and less work to just handmassage the existing dissector to
use the new signatures instead of asn2wrs'ifying it ?
On 5/7/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote:
> Hi,
> Could you do the asn2wrs changes and send me the file then I could do
> some experiments and see how much work is involved? At least you have
> taken care of T38 then there is Kerberos and some gsm stuff so it might not
> be to difficult.
> Regards
> Anders
>
>
>
> Från: [EMAIL PROTECTED] genom Kukosa, Tomas
> Skickat: må 2007-05-07 09:42
> Till: Developer support list for Wireshark
> Ämne: Re: [Wireshark-dev] [Wireshark-commits]
> rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
> packet-ber.cpacket-ber.hpacket-camel.c ...
>
>
>
> Hi,
>
> BTW when you are making such large changes do not you think about
> changing of packet-ber from "field oriented" to "type oriented"?
>
> I.e. replacing
>
> field_function() {
>type_function(hf_field);
> }
> sequence_structure[] = {
> {..., field_function},
> }
>
> with code
>
> sequence_structure[] = {
> {&hf_field, ..., type_function},
> }
>
> I did the same for PER last year and generated code is much shorter.
>
> Unfortunately it will be probaly very hard for BER as there are much
> BER code written by hands which can not be regenerated but has to be
> changed.
>
> regards,
> Tomas
>
>
> Mailcode: NdD2sKHg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anders
> Broman
> (AL/EAB)
> Sent: Monday, May 07, 2007 8:57 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
> 21705:/trunk//trunk/plugins/asn1/:
> asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpac
> ke t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
> packet-camel.c ...
>
> Hi,
> I thought as much but there is still a lot of work to get the actx
> into all the BER dissecors. I'm taking it a step At the time.
> Regards
> Anders
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa,
> Tomas
> Sent: den 7 maj 2007 07:58
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
> /trunk//trunk/plugins/asn1/: asn1.h
> packet-asn1.c/trunk/epan/dissectors/:
> packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c
> packet-ansi_map.c packet-ber.cpacket-ber.h packet-camel.c ...
>
> Hello Anders,
>
> I had not checked X.690 (BER) specification before I defined PER
> external structures in asn1_ctx_t.
> I expected BER uses encoding based on X.680 definition.
>
> I think we could merge most of PER and BER items in external structure.
>
> I will move PER items one layer upper and you can reuse them later in
> BER too.
>
> Regards,
> Tomas
>
>
> Mailcode: NdD2sKHg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Monday, May 07, 2007 12:34 AM
> To: [EMAIL PROTECTED]
> Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
> asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
> packet-acp133.c packet-acse.c packet-ansi_map.c
Re: [Wireshark-dev] [Wireshark-commits] rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c packet-ber
Is it really worth it to asn2wsr'ify the kerberos dissector?
First, the dissector currently handles two different versions of
kerberos, both the "standard" 1510 ASN but also the slightly different
ASN used by packetcable.
Second, the dissector as it is today is almost complete and dissects
virtually the entire asn for both dialects of kerberos we support,
so asn2wrs'ifying it will not really increase the coverage of it.
Third, the dissector contains a lot of special stuff that vendors
(==ms) added to kerberos that is not ans1 defined,things such as
storing nt_status codes inside salt fields and also calling off to NDR
stuff like the PAC in w2k domains
Fourth, there is a lot of code to handle the decryption feature which
also ties into the various places where krb is used un conjunction
with gss-api for decryption of packets (== dcerpc and secure ldap)
maybe it is easier and less work to just handmassage the existing
dissector to use the new signatures instead of asn2wrs'ifying it ?
On 5/7/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote:
> Hi,
> Could you do the asn2wrs changes and send me the file then I could do some
> experiments and
> see how much work is involved? At least you have taken care of T38 then there
> is Kerberos
> and some gsm stuff so it might not be to difficult.
> Regards
> Anders
>
>
>
> Från: [EMAIL PROTECTED] genom Kukosa, Tomas
> Skickat: må 2007-05-07 09:42
> Till: Developer support list for Wireshark
> Ämne: Re: [Wireshark-dev] [Wireshark-commits]
> rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
> packet-ber.cpacket-ber.hpacket-camel.c ...
>
>
>
> Hi,
>
> BTW when you are making such large changes do not you think about
> changing of packet-ber from "field oriented" to "type oriented"?
>
> I.e. replacing
>
> field_function() {
>type_function(hf_field);
> }
> sequence_structure[] = {
> {..., field_function},
> }
>
> with code
>
> sequence_structure[] = {
> {&hf_field, ..., type_function},
> }
>
> I did the same for PER last year and generated code is much shorter.
>
> Unfortunately it will be probaly very hard for BER as there are much BER
> code written by hands which can not be regenerated but has to be
> changed.
>
> regards,
> Tomas
>
>
> Mailcode: NdD2sKHg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
> (AL/EAB)
> Sent: Monday, May 07, 2007 8:57 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
> 21705:/trunk//trunk/plugins/asn1/:
> asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
> t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
> packet-camel.c ...
>
> Hi,
> I thought as much but there is still a lot of work to get the actx into
> all the BER dissecors. I'm taking it a step
> At the time.
> Regards
> Anders
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
> Sent: den 7 maj 2007 07:58
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
> /trunk//trunk/plugins/asn1/: asn1.h
> packet-asn1.c/trunk/epan/dissectors/:
> packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
> packet-ber.cpacket-ber.h packet-camel.c ...
>
> Hello Anders,
>
> I had not checked X.690 (BER) specification before I defined PER
> external structures in asn1_ctx_t.
> I expected BER uses encoding based on X.680 definition.
>
> I think we could merge most of PER and BER items in external structure.
>
> I will move PER items one layer upper and you can reuse them later in
> BER too.
>
> Regards,
> Tomas
>
>
> Mailcode: NdD2sKHg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Monday, May 07, 2007 12:34 AM
> To: [EMAIL PROTECTED]
> Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
> asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
> packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
> packet-ber.h packet-camel.c ...
>
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21705
>
> User: etxrab
> Date: 2007/05/06 10:34 PM
>
> Log:
> Start introducing actx to ber functions.
>
> Directory: /trunk/plugins/asn1/
> ChangesPath Action
> +45 -0 asn1.h Modified
> +0 -1 packet-asn1.cModified
>
> Directory: /trunk/epan/dissectors/
> ChangesPath Action
> +20 -20packet-MAP_DialoguePDU.c Modified
> +56 -56packet-acp133.c Modified
> +103 -103 packet-acse.cModified
> +501 -501 packet-ansi_map.cModified
> +13 -10packet-ber.c Modified
> +2 -1 packet-ber.h Modif
Re: [Wireshark-dev] [Wireshark-commits] rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c packet-ber
Hi,
Could you do the asn2wrs changes and send me the file then I could do some
experiments and
see how much work is involved? At least you have taken care of T38 then there
is Kerberos
and some gsm stuff so it might not be to difficult.
Regards
Anders
Från: [EMAIL PROTECTED] genom Kukosa, Tomas
Skickat: må 2007-05-07 09:42
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] [Wireshark-commits]
rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
packet-ber.cpacket-ber.hpacket-camel.c ...
Hi,
BTW when you are making such large changes do not you think about
changing of packet-ber from "field oriented" to "type oriented"?
I.e. replacing
field_function() {
type_function(hf_field);
}
sequence_structure[] = {
{..., field_function},
}
with code
sequence_structure[] = {
{&hf_field, ..., type_function},
}
I did the same for PER last year and generated code is much shorter.
Unfortunately it will be probaly very hard for BER as there are much BER
code written by hands which can not be regenerated but has to be
changed.
regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Monday, May 07, 2007 8:57 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
21705:/trunk//trunk/plugins/asn1/:
asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
packet-camel.c ...
Hi,
I thought as much but there is still a lot of work to get the actx into
all the BER dissecors. I'm taking it a step
At the time.
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
Sent: den 7 maj 2007 07:58
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
/trunk//trunk/plugins/asn1/: asn1.h
packet-asn1.c/trunk/epan/dissectors/:
packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
packet-ber.cpacket-ber.h packet-camel.c ...
Hello Anders,
I had not checked X.690 (BER) specification before I defined PER
external structures in asn1_ctx_t.
I expected BER uses encoding based on X.680 definition.
I think we could merge most of PER and BER items in external structure.
I will move PER items one layer upper and you can reuse them later in
BER too.
Regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 07, 2007 12:34 AM
To: [EMAIL PROTECTED]
Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
packet-ber.h packet-camel.c ...
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21705
User: etxrab
Date: 2007/05/06 10:34 PM
Log:
Start introducing actx to ber functions.
Directory: /trunk/plugins/asn1/
ChangesPath Action
+45 -0 asn1.h Modified
+0 -1 packet-asn1.cModified
Directory: /trunk/epan/dissectors/
ChangesPath Action
+20 -20packet-MAP_DialoguePDU.c Modified
+56 -56packet-acp133.c Modified
+103 -103 packet-acse.cModified
+501 -501 packet-ansi_map.cModified
+13 -10packet-ber.c Modified
+2 -1 packet-ber.h Modified
+434 -434 packet-camel.c Modified
+8 -8 packet-cdt.c Modified
+133 -133 packet-cmip.cModified
(68 files not shown)
___
Wireshark-commits mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-commits
___
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
Re: [Wireshark-dev] [Wireshark-commits] rev 21705:/trunk//trunk/plugins/asn1/: asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.cpacket-ansi_map.c packet-
Hi,
BTW when you are making such large changes do not you think about
changing of packet-ber from "field oriented" to "type oriented"?
I.e. replacing
field_function() {
type_function(hf_field);
}
sequence_structure[] = {
{..., field_function},
}
with code
sequence_structure[] = {
{&hf_field, ..., type_function},
}
I did the same for PER last year and generated code is much shorter.
Unfortunately it will be probaly very hard for BER as there are much BER
code written by hands which can not be regenerated but has to be
changed.
regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: Monday, May 07, 2007 8:57 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
21705:/trunk//trunk/plugins/asn1/:
asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
packet-camel.c ...
Hi,
I thought as much but there is still a lot of work to get the actx into
all the BER dissecors. I'm taking it a step
At the time.
Regards
Anders
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
Sent: den 7 maj 2007 07:58
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
/trunk//trunk/plugins/asn1/: asn1.h
packet-asn1.c/trunk/epan/dissectors/:
packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
packet-ber.cpacket-ber.h packet-camel.c ...
Hello Anders,
I had not checked X.690 (BER) specification before I defined PER
external structures in asn1_ctx_t.
I expected BER uses encoding based on X.680 definition.
I think we could merge most of PER and BER items in external structure.
I will move PER items one layer upper and you can reuse them later in
BER too.
Regards,
Tomas
Mailcode: NdD2sKHg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 07, 2007 12:34 AM
To: [EMAIL PROTECTED]
Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
packet-ber.h packet-camel.c ...
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21705
User: etxrab
Date: 2007/05/06 10:34 PM
Log:
Start introducing actx to ber functions.
Directory: /trunk/plugins/asn1/
ChangesPath Action
+45 -0 asn1.h Modified
+0 -1 packet-asn1.cModified
Directory: /trunk/epan/dissectors/
ChangesPath Action
+20 -20packet-MAP_DialoguePDU.c Modified
+56 -56packet-acp133.c Modified
+103 -103 packet-acse.cModified
+501 -501 packet-ansi_map.cModified
+13 -10packet-ber.c Modified
+2 -1 packet-ber.h Modified
+434 -434 packet-camel.c Modified
+8 -8 packet-cdt.c Modified
+133 -133 packet-cmip.cModified
(68 files not shown)
___
Wireshark-commits mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-commits
___
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
