On 14. nov.. 2007, at 22.24, Graeme Lunt wrote:
I think your patch is correct - but should adopt Tomas suggestions:
a) use the *_ref_present members; and
b) try to do a presentation context lookup if an indirect reference is
found.
I find three ways to implement handling of the
Anders, Tomas, Stig,
RTSE should be changed to use EXTERNAL and put the callback
in the asnctx.
I have now checked in a change so that RTSE uses the packet-ber EXTERNAL
decoding.
(http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=23450)
Tomas: I had to make some minor changes
Anders: Is someone looking at doing something similar for ACSE (which still
uses an EXTERNALt)?
Not in the near future...and I don't know that protocol that well.
Regards
Anders
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
-dev] Use of EXTERNALt
On 6. nov.. 2007, at 22.57, Anders Broman wrote:
I have gotten rid of the use of EXTERNALt in a lot of dissectors
(check your traces)
The EXTERNAL handling in packet-ber.c does not decode octet-aligned
encoding according to the direct-reference, like acse did (from
Anders,
I have gotten rid of the use of EXTERNALt in a lot of dissectors (check your
traces)
But I'm not sure if it's needed for FTAM
--- snip –
Node-Name ::= EXTERNALt
n The type to be used for Node-Name is defined in IS08571-FADU.
--- snip –
Does any one have a trace with
Hi,
I have gotten rid of the use of EXTERNALt in a lot of dissectors (check your
traces)
But I'm not sure if it's needed for FTAM
--- snip -
Node-Name ::= EXTERNALt
* The type to be used for Node-Name is defined in IS08571-FADU.
--- snip -
Does any one have a trace with
On 6. nov.. 2007, at 22.57, Anders Broman wrote:
I have gotten rid of the use of EXTERNALt in a lot of dissectors
(check your traces)
The EXTERNAL handling in packet-ber.c does not decode octet-aligned
encoding according to the direct-reference, like acse did (from r22308).
The attached
On 7. nov.. 2007, at 00.27, Stig Bjørlykke wrote:
The attached patch will dump a correct TNEF in a X.420
FileTransferData (like before), but I don't have time to dig deeper
into this to determine if this is an appropriate solution. Maybe
the X.420 dissector should decode the
