Wireshark · Wireshark-dev: Re: [Wireshark-dev] happy birthday, bug 5531!

[Joerg Mayer <jmayer@xxxxxxxxx>]

On Thu, Dec 29, 2011 at 02:25:43PM -0500, Ed Beroset wrote:
> Chris Maynard wrote:
>> Ed Beroset<beroset@...>  writes:
>>
>>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531
>>>
>>> It's been a year since it was originally submitted.  As always, if there's
>> anything I can do to help get this
>>> into the main code, please let me know.  I know a number of people that are
>> waiting for it.  And thanks again for
>>> a mighty handy tool!
>>>
>>> Ed
>>
>> I know it can be frustrating when waiting for something so thanks for your
>> continued patience.  If it makes you feel any better, some bugs are over 6 years
>> old.  :)
>
> Yes, it's a bit frustrating, but I also certainly understand.  I wish I  
> had more time to spend on this, too.  I have a half-finished  
> documentation section on how to write ASN.1 based dissectors that I'm  
> hoping to finish within the next few weeks and I've been looking over  
> Bill's rewritten tvb_ stuff to see if I can help explain that, too.  
> First I'd have to understand it...

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/?
- why do we have files named crypt/crypt-aes.c instead of crypt/aes.c?
- is eax.c added to CMakeLists.txt as well?
- is this in any way related to RFC 6142?
- 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?

Thanks
   Jörg
-- 
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.