On 06/19/2015 10:46 AM, Vadim Kochan wrote:
...
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.
Ok, how would all of this tie together with flex and bison that we
use for trafgen as parser generator? It looks on a first glance that
this design would be outside of that scope?
Cheers,
Daniel
--
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.