Re: [netsniff-ng] trafgen seems broken on kernel 3.19
On Mon, Mar 23, 2015 at 02:03:54PM +0200, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 01:07:24PM +0200, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 12:12:54PM +0100, Daniel Borkmann wrote: On 03/23/2015 11:37 AM, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 11:25:26AM +0100, Lorenzo Pistone wrote: ... Thats what I got on 3.18 with the same cfg file: $ trafgen/trafgen -c ~/trafgen.cfg -o wlp3s0 -n 1 4 packets to schedule 168 bytes in total Running! Hang up with ^C! 0 packets outgoing 0 bytes outgoing 0 sec, 0 usec on CPU0 (0 packets) 0 sec, 0 usec on CPU1 (0 packets) 0 sec, 0 usec on CPU2 (0 packets) 0 sec, 0 usec on CPU3 (0 packets) Seems packet was not sent from trafgen ? If you increase -n e.g. to 64 or omit -n entirely, does that work? Looks like a trafgen bug. Yeah, w/o -n my sniffer on the other side was totally stucked:-) so it helped. Meanwhile I see (by printf) that ctx-num is zeroed in xmit_packet_precheck where it is rounded. Regards, My understanding is that it works in slow path because in slow path we use 1 cpu, but in fast path the numbers of packets is multiplied by number of cpus in xmit_packet_precheck(...): plen_total = __wait_and_sum_others(ctx, cpu); which in my case plen_total is 4 when I specified -n 1 and then it is rounded to 0 - plen=1 plen_total=4 orig=1: ctx-num = (unsigned long) round((1.0 * plen / plen_total) * orig); -- 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] trafgen seems broken on kernel 3.19
On Mon, Mar 23, 2015 at 12:12:54PM +0100, Daniel Borkmann wrote: On 03/23/2015 11:37 AM, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 11:25:26AM +0100, Lorenzo Pistone wrote: ... Thats what I got on 3.18 with the same cfg file: $ trafgen/trafgen -c ~/trafgen.cfg -o wlp3s0 -n 1 4 packets to schedule 168 bytes in total Running! Hang up with ^C! 0 packets outgoing 0 bytes outgoing 0 sec, 0 usec on CPU0 (0 packets) 0 sec, 0 usec on CPU1 (0 packets) 0 sec, 0 usec on CPU2 (0 packets) 0 sec, 0 usec on CPU3 (0 packets) Seems packet was not sent from trafgen ? If you increase -n e.g. to 64 or omit -n entirely, does that work? Looks like a trafgen bug. Yeah, w/o -n my sniffer on the other side was totally stucked:-) so it helped. -- 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] trafgen seems broken on kernel 3.19
On 03/23/2015 11:37 AM, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 11:25:26AM +0100, Lorenzo Pistone wrote: ... Thats what I got on 3.18 with the same cfg file: $ trafgen/trafgen -c ~/trafgen.cfg -o wlp3s0 -n 1 4 packets to schedule 168 bytes in total Running! Hang up with ^C! 0 packets outgoing 0 bytes outgoing 0 sec, 0 usec on CPU0 (0 packets) 0 sec, 0 usec on CPU1 (0 packets) 0 sec, 0 usec on CPU2 (0 packets) 0 sec, 0 usec on CPU3 (0 packets) Seems packet was not sent from trafgen ? If you increase -n e.g. to 64 or omit -n entirely, does that work? Looks like a trafgen bug. -- 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] trafgen seems broken on kernel 3.19
On Mon, Mar 23, 2015 at 01:07:24PM +0200, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 12:12:54PM +0100, Daniel Borkmann wrote: On 03/23/2015 11:37 AM, Vadim Kochan wrote: On Mon, Mar 23, 2015 at 11:25:26AM +0100, Lorenzo Pistone wrote: ... Thats what I got on 3.18 with the same cfg file: $ trafgen/trafgen -c ~/trafgen.cfg -o wlp3s0 -n 1 4 packets to schedule 168 bytes in total Running! Hang up with ^C! 0 packets outgoing 0 bytes outgoing 0 sec, 0 usec on CPU0 (0 packets) 0 sec, 0 usec on CPU1 (0 packets) 0 sec, 0 usec on CPU2 (0 packets) 0 sec, 0 usec on CPU3 (0 packets) Seems packet was not sent from trafgen ? If you increase -n e.g. to 64 or omit -n entirely, does that work? Looks like a trafgen bug. Yeah, w/o -n my sniffer on the other side was totally stucked:-) so it helped. Meanwhile I see (by printf) that ctx-num is zeroed in xmit_packet_precheck where it is rounded. 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] trafgen seems broken on kernel 3.19
Hi Lorenzo,
On 03/22/2015 03:13 PM, Lorenzo Pistone wrote:
Hi,
I'm trying to send UDP packets with zero length withthis simple configuration
on trafgen:
{
# --- ethernet header ---
0xbe, 0x15, 0x1d, 0x12, 0x1c, 0x57, # mac destination
0xfa, 0x16, 0x3e, 0xa0, 0x5d, 0x18, # mac source
const16(0x0800), # protocol
# --- ip header ---
# ipv4 version (4-bit) + ihl (4-bit), tos
0b01000101, 0,
# ipv4 total len
const16(28),
# id (note: runtime dynamic random)
drnd(2),
# ipv4 3-bit flags + 13-bit fragment offset
# 001 = more fragments
0b0100, 0,
64, # ttl
17, # proto udp
# dynamic ip checksum (note: offsets are zero indexed)
csumip(14, 33),
92, 222, 69, 15, # source ip
85, 214, 106, 103, # dest ip
# --- udp header ---
# as this is a fragment the below stuff does not matter too much
const16(48054), # src port
const16(28785), # dst port
const16(8),# udp length
# udp checksum can be dyn calc via csumudp(offset ip, offset tcp)
# which is csumudp(14, 34), but for udp its allowed to be zero
csumudp(14, 34),
}
I can send these packets on lo, but trafgen fails to send anything on real
devices. I used both the TX_RING and sendto method.
I've tried with iwlwifi and virtio. mausezahn on the contrary works. I
checked with strace and there does not seem to be any
call that returns an error.
Thanks for the bug report.
Can you provide some more debug information?
How do you invoke trafgen? strace -f? Something suspicious in dmesg? ip link?
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] trafgen seems broken on kernel 3.19
On 03/23/2015 03:39 PM, Lorenzo Pistone wrote: I'm checking with netsniff-ng, I use the same interface with which I'm sending this email Ok, well that doesn't work. If you emit packets with trafgen, it uses by default a path that bypasses the traffic control layer. If you really want to see with netsniff-ng or tcpdump what has been emitted, you need to run trafgen with --qdisc-path . For stress testing you could use ifpps to display current stats, but those are rather global ones. -- 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] trafgen seems broken on kernel 3.19
So I tried now without -n, still absolutely no packet out on real
devices (contrary to lo), but when interrupting I get Cannot destroy
the TX_RING: Device or resource busy! for each CPU (so 4 times in my
case). Looks like a start.
Il 23/03/2015 10:27, Daniel Borkmann ha scritto:
Hi Lorenzo,
On 03/22/2015 03:13 PM, Lorenzo Pistone wrote:
Hi,
I'm trying to send UDP packets with zero length withthis simple
configuration on trafgen:
{
# --- ethernet header ---
0xbe, 0x15, 0x1d, 0x12, 0x1c, 0x57, # mac destination
0xfa, 0x16, 0x3e, 0xa0, 0x5d, 0x18, # mac source
const16(0x0800), # protocol
# --- ip header ---
# ipv4 version (4-bit) + ihl (4-bit), tos
0b01000101, 0,
# ipv4 total len
const16(28),
# id (note: runtime dynamic random)
drnd(2),
# ipv4 3-bit flags + 13-bit fragment offset
# 001 = more fragments
0b0100, 0,
64, # ttl
17, # proto udp
# dynamic ip checksum (note: offsets are zero indexed)
csumip(14, 33),
92, 222, 69, 15, # source ip
85, 214, 106, 103, # dest ip
# --- udp header ---
# as this is a fragment the below stuff does not matter too much
const16(48054), # src port
const16(28785), # dst port
const16(8),# udp length
# udp checksum can be dyn calc via csumudp(offset ip, offset tcp)
# which is csumudp(14, 34), but for udp its allowed to be zero
csumudp(14, 34),
}
I can send these packets on lo, but trafgen fails to send anything on
real devices. I used both the TX_RING and sendto method.
I've tried with iwlwifi and virtio. mausezahn on the contrary works.
I checked with strace and there does not seem to be any
call that returns an error.
Thanks for the bug report.
Can you provide some more debug information?
How do you invoke trafgen? strace -f? Something suspicious in dmesg?
ip link?
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] trafgen seems broken on kernel 3.19
On 03/23/2015 03:24 PM, Lorenzo Pistone wrote:
I don't get the same message (obviously) with not -n but -t, however still no
packet gets out.
Well, with -t you'll be using sendto(), so that's expected.
So let me ask a stupid question, assuming you don't use -n and therefore
not hit this rounding bug, and you still cannot send a packet out ... is
your link from the device actually up (ip link)?
Are you perhaps checking with tcpdump if a packet has been sent out?
Il 23/03/2015 15:23, Lorenzo Pistone ha scritto:
So I tried now without -n, still absolutely no packet out on real devices (contrary to
lo), but when interrupting I get Cannot destroy the TX_RING: Device or resource
busy! for each CPU (so 4 times in my case). Looks like a start.
Il 23/03/2015 10:27, Daniel Borkmann ha scritto:
Hi Lorenzo,
On 03/22/2015 03:13 PM, Lorenzo Pistone wrote:
Hi,
I'm trying to send UDP packets with zero length withthis simple configuration
on trafgen:
{
# --- ethernet header ---
0xbe, 0x15, 0x1d, 0x12, 0x1c, 0x57, # mac destination
0xfa, 0x16, 0x3e, 0xa0, 0x5d, 0x18, # mac source
const16(0x0800), # protocol
# --- ip header ---
# ipv4 version (4-bit) + ihl (4-bit), tos
0b01000101, 0,
# ipv4 total len
const16(28),
# id (note: runtime dynamic random)
drnd(2),
# ipv4 3-bit flags + 13-bit fragment offset
# 001 = more fragments
0b0100, 0,
64, # ttl
17, # proto udp
# dynamic ip checksum (note: offsets are zero indexed)
csumip(14, 33),
92, 222, 69, 15, # source ip
85, 214, 106, 103, # dest ip
# --- udp header ---
# as this is a fragment the below stuff does not matter too much
const16(48054), # src port
const16(28785), # dst port
const16(8),# udp length
# udp checksum can be dyn calc via csumudp(offset ip, offset tcp)
# which is csumudp(14, 34), but for udp its allowed to be zero
csumudp(14, 34),
}
I can send these packets on lo, but trafgen fails to send anything on real
devices. I used both the TX_RING and sendto method.
I've tried with iwlwifi and virtio. mausezahn on the contrary works. I
checked with strace and there does not seem to be any
call that returns an error.
Thanks for the bug report.
Can you provide some more debug information?
How do you invoke trafgen? strace -f? Something suspicious in dmesg? ip link?
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] trafgen seems broken on kernel 3.19
I'm checking with netsniff-ng, I use the same interface with which I'm
sending this email
Il 23/03/2015 15:33, Daniel Borkmann ha scritto:
On 03/23/2015 03:24 PM, Lorenzo Pistone wrote:
I don't get the same message (obviously) with not -n but -t, however
still no packet gets out.
Well, with -t you'll be using sendto(), so that's expected.
So let me ask a stupid question, assuming you don't use -n and therefore
not hit this rounding bug, and you still cannot send a packet out ... is
your link from the device actually up (ip link)?
Are you perhaps checking with tcpdump if a packet has been sent out?
Il 23/03/2015 15:23, Lorenzo Pistone ha scritto:
So I tried now without -n, still absolutely no packet out on real
devices (contrary to lo), but when interrupting I get Cannot
destroy the TX_RING: Device or resource busy! for each CPU (so 4
times in my case). Looks like a start.
Il 23/03/2015 10:27, Daniel Borkmann ha scritto:
Hi Lorenzo,
On 03/22/2015 03:13 PM, Lorenzo Pistone wrote:
Hi,
I'm trying to send UDP packets with zero length withthis simple
configuration on trafgen:
{
# --- ethernet header ---
0xbe, 0x15, 0x1d, 0x12, 0x1c, 0x57, # mac destination
0xfa, 0x16, 0x3e, 0xa0, 0x5d, 0x18, # mac source
const16(0x0800), # protocol
# --- ip header ---
# ipv4 version (4-bit) + ihl (4-bit), tos
0b01000101, 0,
# ipv4 total len
const16(28),
# id (note: runtime dynamic random)
drnd(2),
# ipv4 3-bit flags + 13-bit fragment offset
# 001 = more fragments
0b0100, 0,
64, # ttl
17, # proto udp
# dynamic ip checksum (note: offsets are zero indexed)
csumip(14, 33),
92, 222, 69, 15, # source ip
85, 214, 106, 103, # dest ip
# --- udp header ---
# as this is a fragment the below stuff does not matter too
much
const16(48054), # src port
const16(28785), # dst port
const16(8),# udp length
# udp checksum can be dyn calc via csumudp(offset ip,
offset tcp)
# which is csumudp(14, 34), but for udp its allowed to be zero
csumudp(14, 34),
}
I can send these packets on lo, but trafgen fails to send anything
on real devices. I used both the TX_RING and sendto method.
I've tried with iwlwifi and virtio. mausezahn on the contrary
works. I checked with strace and there does not seem to be any
call that returns an error.
Thanks for the bug report.
Can you provide some more debug information?
How do you invoke trafgen? strace -f? Something suspicious in
dmesg? ip link?
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] [PATCH] flowtop: Print error cause if errno is set when panic
On 2015-03-21 at 22:58:17 +0100, Vadim Kochan vadi...@gmail.com wrote: From: Vadim Kochan vadi...@gmail.com Signed-off-by: Vadim Kochan vadi...@gmail.com Applied, thank you Vadim! -- 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] trafgen seems broken on kernel 3.19
I was hoping you could give me debugging tips. I checked all I could
(dmesg, echo 1 rp_filter, strace -f), and I couldn't see anything
suspicious. I have nothing in my iptables or tc, and tso is off.The
exact command line is strace -f trafgen -c theconfig.cfg -o wlp3s0 -n 10.
Il 23/03/2015 10:27, Daniel Borkmann ha scritto:
Hi Lorenzo,
On 03/22/2015 03:13 PM, Lorenzo Pistone wrote:
Hi,
I'm trying to send UDP packets with zero length withthis simple
configuration on trafgen:
{
# --- ethernet header ---
0xbe, 0x15, 0x1d, 0x12, 0x1c, 0x57, # mac destination
0xfa, 0x16, 0x3e, 0xa0, 0x5d, 0x18, # mac source
const16(0x0800), # protocol
# --- ip header ---
# ipv4 version (4-bit) + ihl (4-bit), tos
0b01000101, 0,
# ipv4 total len
const16(28),
# id (note: runtime dynamic random)
drnd(2),
# ipv4 3-bit flags + 13-bit fragment offset
# 001 = more fragments
0b0100, 0,
64, # ttl
17, # proto udp
# dynamic ip checksum (note: offsets are zero indexed)
csumip(14, 33),
92, 222, 69, 15, # source ip
85, 214, 106, 103, # dest ip
# --- udp header ---
# as this is a fragment the below stuff does not matter too much
const16(48054), # src port
const16(28785), # dst port
const16(8),# udp length
# udp checksum can be dyn calc via csumudp(offset ip, offset tcp)
# which is csumudp(14, 34), but for udp its allowed to be zero
csumudp(14, 34),
}
I can send these packets on lo, but trafgen fails to send anything on
real devices. I used both the TX_RING and sendto method.
I've tried with iwlwifi and virtio. mausezahn on the contrary works.
I checked with strace and there does not seem to be any
call that returns an error.
Thanks for the bug report.
Can you provide some more debug information?
How do you invoke trafgen? strace -f? Something suspicious in dmesg?
ip link?
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.
