On Fri, Jun 19, 2015 at 12:08:57AM +0200, Daniel Borkmann wrote:
> On 06/18/2015 03:24 PM, Vadim Kochan wrote:
> >On Thu, Jun 18, 2015 at 11:07:12AM +0200, Daniel Borkmann wrote:
> >>On 06/18/2015 10:57 AM, Vadim Kochan wrote:
> >>...
> >>>Not yet, but I will try keep thinking about this, and will let know if I
> >>>will have some real ideas regarding implementation.
> >>
> >>Sounds good!
> >
> >Some 1st though which I came up is may be to start extend current
> >trafgen generation api set:
> >
> >{
> > eth
> > {
> > src(),
> > dst(),
> > proto(),
> > }
> > ,
> > ip
> > {
> > ver(),
> > src(),
> > dst(),
> > opt(0x1, 20),
> > opt(0x2, 30),
> > },
> > tcp
> > {
> > dport(),
> > sport(),
> > flags(),
> > },
> >}
>
> Can you elaborate on your idea, what would this config do? I.e. if src()
> etc is empty.
>
> Thanks,
> Daniel
Hi,
OK here is another (may be better) design.
Here is an example of the cfg script:
{
eth
{
dst: eth_addr(AA:BB:CC:DD:EE:FF)
proto: ipv4,
}
ip
{
src: ip_addr(192.168.1.1)
dst: ip_addr(192.168.1.2)
}
tcp
{
flags: syn | ack
}
}
Needs some refactoring of trafgen code & existing cfg funcs which allows to use
& manipulate of
current packet offset variable.
Each proto should be registered via struct proto_gen:
struct proto_field {
int id;
uint32_t offset;
uint32_t len;
};
struct proto_value {
void *value;
uint32_t len;
};
struct proto_gen {
struct cfg_ctx *ctx;
/* get field name info - id, len, offset */
struct proto_field *field_parse(struct proto_gen *prot, char *name);
/* indicates that this field was filled */
void field_set(struct proto_gen *proto, struct proto_field *field);
/* get info about some proto defined const value */
struct proto_value *value_get(struct proto_gen *proto, struct proto_field
*field, char *name);
/* fill the rest unfilled fields */
void fill(struct proto_gen *prot, uint8_t *hdr);
/* finish after whole packet was built */
void finish(struct proto_gen *prot, uint8_t *data, int len);
}
Each proto hdr field can be filled by specifying field name separated by ':' and
macro/func which will fill the bytes.The field may be filled with any
existing trafgen macro (const(), rnd() - the field len should be
considered). Also some additional macro/funcs should be added - ipv4_addr,
eth_addr, etc.
The parser will lookup & keep struct proto_gen proto_ptr when the proto section
was entered (when '#proto {' was parsed), and parser can call the
proto_ptr->field_parse to obtain the field information by name (id,
offset, len) then change the current packet offset & call the macro/func
which will fill the field. Then parser should call proto_ptr->field_set
to let know to the proto_gen which field was filled. At the end parser
will call proto_ptr->fill to fill the rest unfilled fields with some
default values & fill the csum fields if needed.
While filling the default fields values the proto_gen should know some
trafgen's context info - interface id, and may be some other info which may
help to construct such unfilled fields like dst/src Ethernet addresses or
src/dst IP addresses.
Also it is possible that each proto_gen may have some own defined values like
flag names which can be evaluated via proto_gen->value_get where field pointer
may be specified. It might be useful if these values will be a part of
expressions
like: syn | ack.
At the end the parser will walk over each proto from higher layer to do a last
call
proto_gen->finish where each proto may do some calculations and fill some
unfilled fields.
Meanwhile I am not sure if it will be needed.
Well this is very conceptually and I will try to prepare better version which
would consider the existing trafgen code & cfg syntax parser.
Regards,
--
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.
