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.


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.

Reply via email to