Hi Harald,<br /><br />> instead of building more hacks on existing hacks, we should probably<br />> consider to use our TLV parser instead<br /><br />[... patch snipped ...]<br /><br />> all that we need is a second 'struct tlv_parsed' on the stack, as well as<br />> a 'static const struct tlv_definition' for the nested attributes such as<br />> SW_DESCR and FILE_ID, FILE_VERSION (or any others, if they exist).<br /><br />Mmmm,  I don't really see how to do that without another hack ...<br /><br />* You can view it either as flat (liek the wireshard dissector does) like this :<br /><br />SW_CONFIG<br />FILE_ID    len_16    data<br />FILE_VERSION    len_16    data<br />SW_CONFIG<br />FILE_ID    len_16    data<br />FILE_VERSION    len_16    data<br /><br />But then the problem is that the tag will override each other in the tlv_parser, you can't really 'choose' which config you get.<br /><br /><br />* Or you can view the FILE_ID & FILE_VERSION as 'nested into' SW_CONFIG:<br /><br />SW_CONFIG<br />   FILE_ID    len_16    data<br />   FILE_VERSION    len_16    data<br />SW_CONFIG<br />   FILE_ID    len_16    data<br />   FILE_VERSION    len_16    data<br /><br />But that's not better, because even if I start tlv_parsing a sw_config+1, SW_CONFIG tag doesn't have a 'length' it's just defined as having two child, so I can't really tell the tlv_parser to stop and it will continue past the first FILE_VERSION and into the second SW_CONFIG tag.<br /><br /><br />Or am I missing something obvious here ?<br /><br />    Sylvain