Ronald A. McCormick
Updated to latest version of sample md5.c to correct the annoying warnings when compiling on linux and freebsd.
Can you please explain the difference between decode_tlvbuf and pretty_decode_buffer in docsis_docode.c? They take identical parameters and are extrememly similiar. I have added several TLVs to decode_tlvbuf but not yet to pretty_decode_buffer... I will send diffs once I get more of the TLVs implemented.
Also, I have noticed the the decode portion will not re-encode any configuration files which were previously decoded due to the = and no type identifier for integer values.
decode_tlvbuf decodes a buffer printing out more information (for example it says "type 2 len 4 ident DownstreamFrequency value somevalue" instead of just saying "DownstreamFrequency somevalue".
pretty_decode_buffer outputs a format that is almost compatible with the format used to encode the file - but not identical. It's not identical because of the "=" and the fact that there are keywords like IpAddress, Hex, etc before the value;these are automatically output by the snmp library (unless you set "quick printing", in which case the output is not too correct anymore - for example HexStrings appear as normal strings "C0" instead of Hex: C0, so you can't distinguish between a String that has 1 character equal to 0xC0 and a Strings that has 2 characters="C0".
To overcome this I would have to write my own BER decoder, which doesn't seem trivial. I could also distribute a modified version of ucd-snmp that prints out variables in the format I want. Or, I could modify the syntax to accept the default ucd-snmp syntax. What do you think the best way would be ?
I think the best way to do the decoding is to do it just like the encoding - adding a function to the symtable (docsis_symtable.h) so that each type has and encoder function and a decoder function. Then when we decode, we just call the function associated with that type, offering it the pointer to the buffer and the length as an argument, and the function formats and prints the value.
I'll try to implement this "generic" decoding this week-end; this should make life much easier at least for standard variables like integers, shorts, chars, ip addresses, MAC addresses and such. The SNMP stuff won't use this because the encoder functions take more arguments.
I was wondering if you new anything about TTCN or ASN.1, It would be nice to be able to leverage off these models to help me understand the complex of technologies at work in the protocols described in CableLabs RFI documents. I feel that I burned myself out trying to get the docsis code to compile in Cygwin/Windows ME. If you are interested in this port(I did get 3 or 4 of the snmp ucd 4.2.2 tests to pass!) I will pursue it further. No problems on Linux 7.0
I have a collection of tcl scripts that I have to work through. Any advice on how to work through this vertical learning curve would be helpful.
Don't know what TTCN stands for :). ASN.1 is Abstract Syntax Notation, it's an ITU-T standard I think (which means you have to pay for the spec). It is the syntax used by the SNMP MIBs for example to describe how certain variables should be encoded, tables etc.
It works with BER (Basic Encoding Rules I think) which specifies how the ASN.1 types are actually represented on a bit level.
What are the tcl scripts ?
The most important thing is to read Appendix C of the Cablelabs RFI. That's where all these encodings are specified. And remember, we only have to create a file, most of the rest of the RFI spec is not very helpful. If you want to learn it though, it would be nice to have access to a CMTS and a couple of CMs.