Hi Ronnie,
the "The same type names for different ..." warning is recommendation for TYPE_RENAME
derective usage. See attached x509af.cnf file.
The "#Unhandled ..." message is internal compiler message which means that something is
not supported and I have to implement it :-). But it is the better case of unsupported
feature. Worse case is that it crashes with Python error :-(.
The "#Unhandled GetTTag() in SetOfType" was fixed with my patch which I sent few minutes ago.
If you would like to understand a little bit an internal structure of the compiler you can
use "-d t" option and redirect standard output. It will contain internal tables of
compiler. (see attached file x509af)
Regards,
Tomas
Ronnie Sahlberg wrote:
Hi Tomas,
I tried again to get X509AF working with the compiler but get errors i dont
understand.
I have attached the files I used.
I try to generate the dissector using :
../../tools/asn2eth.py -X -b -p x509af -s packet-x509af-template
AuthenticationFramework.asn
Which generates warnings and errors i dont understand.
1, ===
../../tools/asn2eth.py:815: UserWarning: The same type names for different
types. Explicit renaming is recommended.
T_subject
T_subject AttributeCertificateInfo/subject
T_subject1 AttributeCertificateAssertion/subject
I tried to fix this by adding :
#.FIELD_RENAME
AttributeCertificateInfo/subject info_subject
AttributeCertificateAssertion/subject assertion_subject
to x509af.cnf but that did not help. What did i do wrong?
I also get a whole bunch of:
#Unhandled GetTTag() in SetOfType
SetOfType
name: CrossCertificates
val:
Type_Ref
name: None
val: Certificate
constr: None
constr: None
What do these ones mean and what should I do to resolve them?
----- Original Message -----
From: "Tomas Kukosa"
Sent: Friday, May 28, 2004 7:23 PM
Subject: Re: [Ethereal-dev] H235 & ASN1 compiler
On Tue, May 25, 2004 at 11:23:54AM -0700, Guy Harris wrote:
../packet-h235.c: In function `dissect_h235_NULL':
../packet-h235.c:556: warning: unused parameter `pinfo'
For that one, the translator could perhaps figure out whether an
argument is used and emit _U_ after it if so - but, as the dissectors
are all machine-generated, and as the argument can't be omitted as a
pointer to that function is used, the translator can probably just emit
_U_ for *all* "pinfo" arguments, and perhaps for *all* arguments.
The argument can be used with user defined code in the dissector function.
What happens if the _U_ is emitted and the parameter is used in the
function?
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
------------------------------------------------------------------------
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
--
_________________________________________________
ANF DATA ANF DATA spol. s r. o.
a SIEMENS Company M-palác, Heršpická 5
639 00 Brno
Czech Republic
Tomáš Kukosa Tel.: +420 - 5 4310 6822
PSE ECT AES 6 Fax: +420 - 5 4324 8780
Room: 8.24 mailto:tomas.kukosa@xxxxxxxxxxx
_________________________________________________
Attachment:
x509af_1.tgz
Description: Binary data
