On 2017-03-14 at 20:15:45 +0100, Vadim Kochan <vadi...@gmail.com> wrote: > On Tue, Mar 14, 2017 at 12:21 PM, Tobias Klauser <tklau...@distanz.ch> wrote: > > On 2017-01-30 at 09:33:29 +0100, Vadim Kochan <vadi...@gmail.com> wrote: > >> Add trafgen_l7.c module with DNS proto header generation with > >> support of filling DNS query/answer/authority/additional sections > >> as sub headers. > >> > >> Introcuded new concept as 'sub header' which is needed to easy handle > >> DNS sections which might be added on-demand, and to simplify using > >> sub-header as regular header with a fields, offset, etc. There is a > >> parent header which contains array of pointers of sub-headers, and the > >> array is ordered as they are located in the parent header. The > >> sub-headers mostly encapsulated by the parent header which 'knows' > >> the semantic of them. The new proto_hdr->push_sub_header(...) callback > >> was added to tell the parent header to push the sub-header's fields, > >> sub-header also may have proto_ops which must be filled by the parent. > >> This sub-header concept might be used in the future if it will be needed > >> to support DHCP, WLAN headers. > >> > >> There are 4 kinds of DNS sub-headers - query, answer, authority, > >> additional. 'id' of each sub-header is used to only differentiate these > >> types of sections. These sections have strict order inside DNS header, > >> and there was added the proto_hdr_move_sub_header(...) to sort them in > >> required order. > > > > Might be a bit of a naive question: But wouldn't it be possible to > > enforce the sub-header order through the parser (i.e. only allow > > trafgen scripts which specify the respective sections in the right > > order? This would safe us from doing the whole header sorting/moving > > dance which looks a bit sacry to me (memmove of payload especially). > > > > Well, I was thinking about this and decided to do so because: > > 1) I really think that there might be in the future libtrafgen > which will handle sub-headers > automatically (if it is needed by protocol header) both for > the application and trafgen tool (this > reason might be not so strict).
Well, that's a bit hypothetical ;) And a don't quite see how this prevents us from going with the easier, less scary solution for now ;) > 2) sub-headers might be a generic way for other protocol headers > like DHCP, WLAN. We could enforce sub-header order there too, no? > Yes, the logic which does sub-headers moving is a bit scary as you > said, not sure if I can re-write it > to simplify it, will try. Ok, let's try that. I'm not strictly against the current solution and I see that there might be cases in the future where this would be benefitial. I'd just like to prevent us from introducing a lot of code with growing complexity which could be prevented if we were a bit more restrictive in terms of what the user can do. Thanks Tobias -- You received this message because you are subscribed to the Google Groups "netsniff-ng" group. To unsubscribe from this group and stop receiving emails from it, send an email to netsniff-ng+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
