Age | Commit message (Collapse) | Author | Files | Lines |
|
Use same function to calculate csum for packet_update and for
packet_finish events.
Allow update csum if one of the ICMPv6 fields was changed.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Update csum if any of the ICMPv4 field was changed.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Currently struct proto_hdr is used twofold:
1) Statically define protocol behavior, i.e. all the *_hdr definitions in
trafgen_l{2,3,4}.c which map a protocol id/layer to a set of callback
functions.
2) For each packet created at parse time the struct is memcpy()'ed
(including all the static information from 1) and then used to store
dynamic information at parse/run time.
Thus, struct proto_hdr members such as the proto id, layer and the
pointers callback functions get copied for each created packet (in
addition to the other fields which get changed during parsing). Also,
static/dynamic information get mixed and we e.g. can't make the protocol
definitions const to ensure they'll not get changed by mistake.
Rather than copying the struct proto_hdr for every packet, clearly
separate the two purposes defined above by splitting struct proto_hdr
into two structs:
1) struct proto_ops for the static (const) protocol behavior definition
2) struct proto_hdr (reduced) for dynamic information
struct proto_hdr keeps a pointer to the corresponding proto_ops instance
and uses it to execute the corresponding callbacks.
Reference: https://groups.google.com/forum/#!msg/netsniff-ng/20RvwJdh50Y/eMkbmKSaBgAJ
Acked-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Do not use user-provided 'len' field for csum calculation which
is potentially dangerous due to possible read buffer overflows.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
[tk: reword commit message]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Support for generating ICMPv4 headers using the 'icmp4()/icmpv4()'
trafgen generation functions.
Fields supported:
type Set type field (default 0: Echo reply)
Supported keywords: echorequest, echoreply
code Set code field (default 0)
csum Set checksum field (calculated by default)
mtu Set mtu field for destination unreachable (default 0)
seq Set sequence field (default 0)
id Set identifier field (default 0)
addr Set redirect address (default 0.0.0.0)
Example (send ping request):
{ icmpv4(echorequest, seq=1, id=1326) }
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
[tk: squash commits, consistency between functionality and docu]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Support for generating simple ICMPv6 headers using the 'icmp6()/icmpv6()'
trafgen generation function.
Fields supported:
mtype Message type (default: 0)
Supported keywords: echorequest, echoreply
code Code (default: 0)
csum Message checksum (calculated by default)
Examples:
{ eth(), ipv6(daddr=::1), icmpv6(echorequest), 42, 42, 0, 0 }'
If not explicitely specified, the lower header is initialized as Ethernet.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Support for generating simple IPv6 headers using the 'ip6()/ipv6()'
trafgen generation function.
Fields supported:
ver|version Version (default: 6)
tc|tclass Traffic class (default: 0)
fl|flow Flow Label (default: 0)
len|length Payload length (calculated by default)
nh|nexthdr Type of next header (default: 0)
hl|hoplimit|ttl Hop Limit, TTL (default: 0)
sa|saddr Source IPv6 address (default: device address)
da|daddr Destination IPv6 address (default: 0:0:0:0:0:0:0:0)
Examples:
{ eth(), ipv6(daddr=1:2:3:4:5:6:7:8) }
{ ipv6(tc=2, hl=3, daddr=::1) }
{ eth(), ipv6(nh=58, sa=2001:db8::, da=::1), 128, 0, 0x52, 0x03, 0, 0, 0, 0 }
If not explicitely specified, the lower header is initialized as Ethernet.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Move setting lower protocol id field value from UDP & TCP
protocols to IPv4 only, so lower layer will know exactly value
to set in protocol id field.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Add set_next_proto callback to proto_hdr struct to allow lower
protocol set next protocol id by enum proto_id.
Extended proto_lower_default_add(...) function to take upper protocol
to delegate it's id to lower protocol to set next protocol field.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Change proto_header_init(...) and proto_lower_default_add(...)
functions to return struct proto_hdr * to do not call
proto_current_header(...) after, so it makes more sense to get struct
proto_hdr * right after initializing protocol by id.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Add a function 'tcp()' to generate TCP headers from the trafgen
configuration language.
Fields supported:
sp|sport TCP source port (default 0)
dp|dport TCP destination port (default 0)
seq Sequence number (default: 0)
aseq|ackseq Acknowledgement number (default 0)
doff|hlen Header length/data offset (default: 5)
cwr Congestion Window Reduced flag (default: 0)
ece|ecn ECN-Echo flag (default: 0)
urg Urgent flag (default: 0)
ack Acknowledgement flag (default: 0)
psh Push flag (default: 0)
rst Reset flag (default: 0)
syn Synchronize flag (default: 0)
fin Finish flag (default: 0)
win|window Receive window size (default: 0)
csum Checksum field (calculated automatically)
urgptr Urgent pointer (default: 0)
Example (SYN on port 80/http):
{ tcp(dport=80, syn, window=5840) }
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Add trafgen_l4.c module with generation UDP header fields.
UDP protocol generation logic automaticaly sets the protocol field of
the lower level protocol to IPPROTO_UDP by default (if it is IPv4).
Also checksum & length are calculated and set if it is not given by the
user.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|