Joerg Mayer wrote:
I looked at this patch a bit but as I don't know anything about BER I can't
comment on much.
I have a few small questions that came up during looking at the patch
(not all of them relevant to this patch!):
- why is eax.[ch] in epan instead of epan/crypt/?
It could be moved to epan/crypt, and that may well be appropriate.
- why do we have files named crypt/crypt-aes.c instead of crypt/aes.c?
Historic. Back in 2007, there was no epan/crypt and crypt-aes.c was in
in epan. In 2007, epan/crypt was created and code moved but not renamed.
- is eax.c added to CMakeLists.txt as well?
No, it isn't. A quick check shows a number of files in epan are not.
$for foo in *.c ; do grep -q $foo CMakeLists.txt ; if [ "$?" -eq 1 ];
then echo $foo; fi ; done
diam_dict.c
dtd_grammar.c
dtd_parse.c
dtd_preparse.c
eax.c
exntest.c
inet_aton.c
radius_dict.c
reassemble_test.c
tpg.c
tvbtest.c
uat_load.c
Keeping three different build systems (CMake, make, nmake) synchronized
is perhaps in need of some additional automation. Should we use
Makefile.common in CMake to reduce this problem? A little more checking:
$ for foo in *.c ; do grep -q $foo Makefile.common ; if [ "$?" -eq 1 ];
then echo $foo; fi ; done
asm_utils.c
exntest.c
inet_aton.c
reassemble_test.c
tpg.c
tvbtest.c
I can see that the various test programs shouldn't be there, and it
appears that the configure script handles inet_aton.c, but it appears
that tpg.c isn't in either. Is it used at all?
- is this in any way related to RFC 6142?
Not directly, no. That RFC describes one rather idiosyncratic way to
implement the same C12.22 standard over TCP/IP and UDP/IP. I know of no
real implementation that follows it, but if one ever did, there would be
no problem with this dissector on such a stream. (If anybody reading
this has implemented such a thing, please send me a sample capture or
add it to the sample captures so I can verify this.)
- I don't know anything about BER encoding, but is the existence of the
function get_ber_len_size owed to missing infrastructure in Wireshark?
Good question, but I think it's more attributable to the particular
usage of BER and cryptography to secure this particular protocol. I
created three functions (get_ber_len_size, get_ber_len_raw and
encode_ber_len) which might have been put into packet-ber.c but I
decided that these functions are unlikely to be generally useful. This
is because these functions are to assist in constructing BER encodings
in memory (for processing with cryptography) rather than the more usual
direction of disassembling BER encodings, which is what packet-ber.c
does. Where the latter kinds of functions are needed, the existing
functions in packet-ber.c were used without problems, so I don't think
there's missing infrastructure in Wireshark.
Ed
