Re: [netsniff-ng] mausezahn
Hello, On Thu, Feb 14, 2019 at 09:09:21AM +0530, trupti nanaware wrote: > Hi , > > > > I have a question about mausezahn. > > 1)When I see help for mausezahn , I can see that codec is 1 of the option. > > I want to know if codecs other than G711 are now being supported or not. > Not sure, but may be I will see how to add it to the trafgen. > > > 2) > > Can I configure mausezahn to match the speed to codec ? > > For eg :: > > G729 will send data with 8kbps , I am not able to see any option to specify > bitrate directly. > > Also count which we specify as a option in mausezahn , does it sends that > many packets per second ? Looks like you can use the following option: -c . use this packet count value instead of infinity -d . use this delay value instead of the defaul I just looked in the code, did not try the tool itself. Regards, Vadim Kochan -- 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.
Re: [netsniff-ng] Mausezahn - virtual nic "unknown physical layer type"
BTW I did grep over the kernel and looks like it might the 'tun' device. On Tue, Jan 31, 2017 at 12:38 PM, Vadim Kochan wrote: > On Tue, Jan 31, 2017 at 12:36 PM, Vadim Kochan wrote: >> On Tue, Jan 31, 2017 at 12:47 AM, Jojonix1-Web wrote: >>> Hello dear netsniff team >>> >>> >>> >>> My name is Jonathan, I am an IT specialist from Germany and I have some >>> difficulties with Mausezahn. >>> >>> >>> >>> I am running a virtual server with Ubuntu 14.04 LTS. I wanted to test my >>> DDoS protection, but Mausezahn is unable to send those frames through the >>> virtual NIC. There is no problem with the Local Loopback. Is this a known >>> incident? Is there anything I can do to get it running? >>> >>> >>> >>> I had updated the pcap files before I tried and tshark is able to scan the >>> virtual NIC without any troubles. >>> >>> >>> >>> The error message is: >>> >>> libnet_init() failed (unknown physical layer type 0x) Invalid command >>> line parameters! >>> >>> >>> >>> I am looking forward to your reply. >>> >>> >>> >>> Greetings from Germany >>> >>> Jonathan >>> >>> -- >>> 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. >> >> Hi Jonathan, >> >> 1st thing which comes to mind is that the link type of this interface >> is "none" or "void", and >> libnet can't handle it. >> >> Could you please give some details about this interface with 'ip link' >> and ifconfig output ? >> Also you can try to use trafgen for DDoS testing. >> >> Regards, >> Vadim Kochan > > CC Jonathan -- 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.
Re: [netsniff-ng] Mausezahn - virtual nic "unknown physical layer type"
On Tue, Jan 31, 2017 at 12:36 PM, Vadim Kochan wrote: > On Tue, Jan 31, 2017 at 12:47 AM, Jojonix1-Web wrote: >> Hello dear netsniff team >> >> >> >> My name is Jonathan, I am an IT specialist from Germany and I have some >> difficulties with Mausezahn. >> >> >> >> I am running a virtual server with Ubuntu 14.04 LTS. I wanted to test my >> DDoS protection, but Mausezahn is unable to send those frames through the >> virtual NIC. There is no problem with the Local Loopback. Is this a known >> incident? Is there anything I can do to get it running? >> >> >> >> I had updated the pcap files before I tried and tshark is able to scan the >> virtual NIC without any troubles. >> >> >> >> The error message is: >> >> libnet_init() failed (unknown physical layer type 0x) Invalid command >> line parameters! >> >> >> >> I am looking forward to your reply. >> >> >> >> Greetings from Germany >> >> Jonathan >> >> -- >> 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. > > Hi Jonathan, > > 1st thing which comes to mind is that the link type of this interface > is "none" or "void", and > libnet can't handle it. > > Could you please give some details about this interface with 'ip link' > and ifconfig output ? > Also you can try to use trafgen for DDoS testing. > > Regards, > Vadim Kochan CC Jonathan -- 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.
Re: [netsniff-ng] Mausezahn - virtual nic "unknown physical layer type"
On Tue, Jan 31, 2017 at 12:47 AM, Jojonix1-Web wrote: > Hello dear netsniff team > > > > My name is Jonathan, I am an IT specialist from Germany and I have some > difficulties with Mausezahn. > > > > I am running a virtual server with Ubuntu 14.04 LTS. I wanted to test my > DDoS protection, but Mausezahn is unable to send those frames through the > virtual NIC. There is no problem with the Local Loopback. Is this a known > incident? Is there anything I can do to get it running? > > > > I had updated the pcap files before I tried and tshark is able to scan the > virtual NIC without any troubles. > > > > The error message is: > > libnet_init() failed (unknown physical layer type 0x) Invalid command > line parameters! > > > > I am looking forward to your reply. > > > > Greetings from Germany > > Jonathan > > -- > 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. Hi Jonathan, 1st thing which comes to mind is that the link type of this interface is "none" or "void", and libnet can't handle it. Could you please give some details about this interface with 'ip link' and ifconfig output ? Also you can try to use trafgen for DDoS testing. Regards, Vadim Kochan -- 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On Mon, Jun 22, 2015 at 03:55:01PM +0200, Daniel Borkmann wrote: > On 06/21/2015 07:02 PM, Vadim Kochan wrote: > ... > >Not sure if it is necessary to use libnet by trafgen as it is used by mz > >to generate packets ? It will add the new dependency, but seems it can > >simplify generation of the proto packets. > > Yes sure, we shouldn't depend on it, I think some small helper functions > inside the netsniff-ng tree could do the job, too. Hm, I missed this email ... anyway I almost developed generic mechanism for proto fields generation which uses the low level trafgen's xxx_byte functions from trafgen_parser.c which I had to export, I have also implemented ethernet & arp protocol generation based on the common field generation code, but I can't decide which command line syntax would be good, so I think that something like this might be ok (we should not follow mz style right?): $ trafgen --dev lo -n 1 eth sa=11:22:33:44:55:66 da=11:22:33:44:55:66, arp op=req tip=192.168.1.1 this syntax will allow to easy parse parameters per protocol name just by split whole cmdline by ",". Sure I tried to use mz's style but seems it more complicated: $ trafgen/trafgen --dev lo eth da = AA:BB:CC:DD:EE:FF,sa=11:22:33:44:55:66 arp tip=192.168.1.1 -n 1 by more complicated I mean that it will not allow to use strtok parsing but for each character, but sure it possible. mz seems parses params from the whole command line, but I'd like to separate params per protocol. Regards, Vadim Kochan -- 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On 06/22/2015 03:37 PM, Vadim Kochan wrote: ... Well, anyway I am trying to implement basic cmdline mz-like proto generation API with few layered protocols: eth, ip, udp for trafgen utility. If I success with this I will share the patch series (I will try to better split it for easier review). Looking forward to review! -- 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On 06/21/2015 07:02 PM, Vadim Kochan wrote: ... Not sure if it is necessary to use libnet by trafgen as it is used by mz to generate packets ? It will add the new dependency, but seems it can simplify generation of the proto packets. Yes sure, we shouldn't depend on it, I think some small helper functions inside the netsniff-ng tree could do the job, too. -- 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On Sun, Jun 21, 2015 at 08:02:40PM +0300, Vadim Kochan wrote: > On Sat, Jun 20, 2015 at 01:10:45AM +0200, Daniel Borkmann wrote: > > On 06/20/2015 12:25 AM, Vadim Kochan wrote: > > ... > > >>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? > > . > > >You mean that this is out of scope of this thread which was related to > > >mz ? If so, then yes ... may be extend the trafgen's cfg script to > > >describe the protocols and then add the cmd line interface based on this > > >extension ? Or do you think that extending cfg script syntax is not good > > >or may be problematic ? > > > > > >Well, I think may be I can do some "just for fun" implementation, just > > >for demonstration ... > > > > As a start, if you're interested, I think it would be great if you have > > some cycles to look into: > > http://thread.gmane.org/gmane.linux.network.netsniff-ng/799 > > I.e. the idea would be to have a _textual_ replacement initially and then > > push the config through the lexer/parser. > > > > Anyway, back to the topic, as it started out with mz. ;) > > > > I do quite like the interactive mode of mz and it's cmdline syntax is > > fine with me too. mz's implementation rather hacky and uneasy to maintain. > > trafgen so far has a very low level language on how to define packets. > > > > I'm happy to entertain the idea to add an mz-like _interactive_ mode > > that is libreadline-based with more or less similar feature set. I'm > > also good if we add a similar direct _cmdline_ usage possibility. Think > > of it as kind a /clean/ merge of mz which is in staging, into trafgen, > > together with the (f.e. performance) benefits of having direct packet > > socket access. > > > > Thus, we'd end up having the ability of cmdline, config, and interactive > > mode in one traffic generator with different levels of granularity. > > > > Thanks, > > Daniel > > Not sure if it is necessary to use libnet by trafgen as it is used by mz > to generate packets ? It will add the new dependency, but seems it can > simplify generation of the proto packets. > > Regards, Well, anyway I am trying to implement basic cmdline mz-like proto generation API with few layered protocols: eth, ip, udp for trafgen utility. If I success with this I will share the patch series (I will try to better split it for easier review). 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On Sat, Jun 20, 2015 at 01:10:45AM +0200, Daniel Borkmann wrote: > On 06/20/2015 12:25 AM, Vadim Kochan wrote: > ... > >>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? > . > >You mean that this is out of scope of this thread which was related to > >mz ? If so, then yes ... may be extend the trafgen's cfg script to > >describe the protocols and then add the cmd line interface based on this > >extension ? Or do you think that extending cfg script syntax is not good > >or may be problematic ? > > > >Well, I think may be I can do some "just for fun" implementation, just > >for demonstration ... > > As a start, if you're interested, I think it would be great if you have > some cycles to look into: > http://thread.gmane.org/gmane.linux.network.netsniff-ng/799 > I.e. the idea would be to have a _textual_ replacement initially and then > push the config through the lexer/parser. > > Anyway, back to the topic, as it started out with mz. ;) > > I do quite like the interactive mode of mz and it's cmdline syntax is > fine with me too. mz's implementation rather hacky and uneasy to maintain. > trafgen so far has a very low level language on how to define packets. > > I'm happy to entertain the idea to add an mz-like _interactive_ mode > that is libreadline-based with more or less similar feature set. I'm > also good if we add a similar direct _cmdline_ usage possibility. Think > of it as kind a /clean/ merge of mz which is in staging, into trafgen, > together with the (f.e. performance) benefits of having direct packet > socket access. > > Thus, we'd end up having the ability of cmdline, config, and interactive > mode in one traffic generator with different levels of granularity. > > Thanks, > Daniel Not sure if it is necessary to use libnet by trafgen as it is used by mz to generate packets ? It will add the new dependency, but seems it can simplify generation of the proto packets. 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On 06/20/2015 12:25 AM, Vadim Kochan wrote: ... 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? . You mean that this is out of scope of this thread which was related to mz ? If so, then yes ... may be extend the trafgen's cfg script to describe the protocols and then add the cmd line interface based on this extension ? Or do you think that extending cfg script syntax is not good or may be problematic ? Well, I think may be I can do some "just for fun" implementation, just for demonstration ... As a start, if you're interested, I think it would be great if you have some cycles to look into: http://thread.gmane.org/gmane.linux.network.netsniff-ng/799 I.e. the idea would be to have a _textual_ replacement initially and then push the config through the lexer/parser. Anyway, back to the topic, as it started out with mz. ;) I do quite like the interactive mode of mz and it's cmdline syntax is fine with me too. mz's implementation rather hacky and uneasy to maintain. trafgen so far has a very low level language on how to define packets. I'm happy to entertain the idea to add an mz-like _interactive_ mode that is libreadline-based with more or less similar feature set. I'm also good if we add a similar direct _cmdline_ usage possibility. Think of it as kind a /clean/ merge of mz which is in staging, into trafgen, together with the (f.e. performance) benefits of having direct packet socket access. Thus, we'd end up having the ability of cmdline, config, and interactive mode in one traffic generator with different levels of granularity. Thanks, 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On Fri, Jun 19, 2015 at 11:16:54PM +0200, Daniel Borkmann wrote:
> 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?
You mean that this is out of scope of this thread which was related to
mz ? If so, then yes ... may be extend the trafgen's cfg script to
describe the protocols and then add the cmd line interface based on this
extension ? Or do you think that extending cfg script syntax is not good
or may be problematic ?
Well, I think may be I can do some "just for fun" implementation, just
for demonstration ...
Regards,
>
> 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
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
--
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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
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(),
},
}
and after use them when add cmd line options interface.
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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
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! -- 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On Thu, Jun 18, 2015 at 10:51:44AM +0200, Daniel Borkmann wrote: > On 06/18/2015 01:30 AM, Vadim Kochan wrote: > >Hi, > > > >I tried to look over mz tool and try to start adding TX fast path as it > >is done in trafgen but I am not sure it will be easy, for me it seems the > >code is not easy to change. > > > >I have no some objective arguments but I feel that may be it would be > >good to start something like pktgen-ng or start writing mz from empty > >page ? > > > >What do you think ? > > I think in general, it would be useful to 'merge' mz into trafgen. > No doubt it's quite some work, but that would allow us to have a > clean, fresh implementation at some point. By 'merge', I mean to > have mostly compatible syntax/features, but the underlying > implementation would be from scratch. I.e. to let trafgen have an > interactive mode, so you can have it as a shell on an appliance, > and for quick tests, the direct cmdline mode from mz. Do you have > any plans? Not yet, but I will try keep thinking about this, and will let know if I will have some real ideas regarding implementation. > > Thanks, > 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.
Re: [netsniff-ng] mausezahn: TX fast path ... or may be rewrite everything ?
On 06/18/2015 01:30 AM, Vadim Kochan wrote: Hi, I tried to look over mz tool and try to start adding TX fast path as it is done in trafgen but I am not sure it will be easy, for me it seems the code is not easy to change. I have no some objective arguments but I feel that may be it would be good to start something like pktgen-ng or start writing mz from empty page ? What do you think ? I think in general, it would be useful to 'merge' mz into trafgen. No doubt it's quite some work, but that would allow us to have a clean, fresh implementation at some point. By 'merge', I mean to have mostly compatible syntax/features, but the underlying implementation would be from scratch. I.e. to let trafgen have an interactive mode, so you can have it as a shell on an appliance, and for quick tests, the direct cmdline mode from mz. Do you have any plans? Thanks, 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.
Re: [netsniff-ng] Mausezahn compiling under Yocto/ppc
On 05/10/2013 11:36 PM, Daniel Borkmann wrote: On 05/10/2013 11:25 PM, Clayton Davis wrote: I am glad to report that Mausezahn cross-compiles successfully to ppc under the Yocto project. There are some endianness issues (IP addresses/Ethertypes in reverse order), but the bulk of MOPS functions seem to work correctly. I have not gotten around to building the rest of netsniff-ng, but we plan on using trafgen and possibly others for an internal test appliance at my company. The libcli interface to mz is Great to hear! The man-pages should tell you everything you need, but in case of questions, don't hesitate to ask. exactly what we need. Is there any chance that mz will be moved into the main github repo soon? What is the best way right now to submit patches for mz? I've just created a staging area and moved the code there into the main repo, also integrated mausezahn into the main build process. Thus, if you have patches against that code, feel free to send them to us as mentioned in the previous mail. I will write a man page for mausezahn very soon as well. After the code has reached a good enough quality, will will be moved from staging into the root folder. -- 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/groups/opt_out.
Re: [netsniff-ng] Mausezahn compiling under Yocto/ppc
On 05/10/2013 11:25 PM, Clayton Davis wrote: I am glad to report that Mausezahn cross-compiles successfully to ppc under the Yocto project. There are some endianness issues (IP addresses/Ethertypes in reverse order), but the bulk of MOPS functions seem to work correctly. I have not gotten around to building the rest of netsniff-ng, but we plan on using trafgen and possibly others for an internal test appliance at my company. The libcli interface to mz is Great to hear! The man-pages should tell you everything you need, but in case of questions, don't hesitate to ask. exactly what we need. Is there any chance that mz will be moved into the main github repo soon? What is the best way right now to submit patches for mz? In general for submitting patches, there's a document here: https://github.com/borkmann/netsniff-ng/blob/master/SubmittingPatches To cut it short: it's the same process as submitting patches to the kernel if you have already done that. We also accept git pull requests. Probably I'll open an extra single stable branch for mausezahn or a sort-of staging area in the toolkit so that we can take patches from you. As we have taken this project over, you might have seen that the code quality of mz is quite bad, so we probably plan to rewrite it from scratch and thus fully integrate it into the main repository since it's a very useful tool. So you can send patches either to Tobias or me via email, for instance. You can export them via git-format-patch(1). -- 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/groups/opt_out.
