On 02/ 3/10 04:54 PM, Darren Reed wrote:
Antoon Huiskens wrote:
On 02/ 3/10 04:05 PM, Darren Reed wrote:
In the mean time, if ethernet headers are unimportant, you should be
able to do this:
pfexec tcpdump -y IPNET -i iwk0
Darren
That works indeed.
Any thoughts on how we can diagnose the ethernet headers issue (I
like to work my way up the stack..)
I think the first thing to do is confirm what is being passed into bpf
is correct with the dtrace script below.
Run the script and then do "tcpdump -y EN10MB -i iwk0 -c 1".
Darren
#!/usr/sbin/dtrace -Fs
mblk_t *m;
size_t len;
fbt:bpf:bpf_mtap:entry {
m = (mblk_t *)arg2;
len = m->b_wptr - m->b_rptr;
printf("%d:msg %p sz %d len %d", arg3, m, msgdsize(m), len);
tracemem(m->b_rptr, 20);
}
fbt:bpf:bpf_mtap:return {}
named the script bpftrace.d:
$ pfexec dtrace -s bpftrace.d
dtrace: script 'bpftrace.d' matched 2 probes
CPU ID FUNCTION:NAME
1 63200 bpf_mtap:entry 0:msg ffffff01d0bca5c0 sz
96 len 40
0 1 2 3 4 5 6 7 8 9 a b c d e f
0123456789abcdef
0: 08 41 00 00 00 23 69 ae 0b 1c 00 1d e0 19 e9 25
.A...#i........%
10: 00 23 69 ae .#i.
1 63201 bpf_mtap:return
$ pfexec tcpdump -y EN10MB -i iwk0 -c 1
tcpdump: data link type EN10MB
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on iwk0, link-type EN10MB (Ethernet), capture size 96 bytes
17:17:59.824483 69:ae:0b:1c:00:1d (oui Unknown) > 08:41:00:00:00:23 (oui
Unknown), ethertype Unknown (0xe019), length 96:
0x0000: e925 0023 69ae 0b1a 0000 0000 0000 0000 .%.#i...........
0x0010: 0000 aaaa 0300 0000 0800 4500 0038 1ba6 ..........E..8..
0x0020: 0000 ff11 e6b1 c0a8 0165 d436 2319 96c5 .........e.6#...
0x0030: 0035 0024 249b 685b 0100 0001 0000 0000 .5.$$.h[........
0x0040: 0000 0269 6d03 7375 6e03 636f 6d00 0001 ...im.sun.com...
0x0050: 0001 ..
1 packets captured
1 packets received by filter
0 packets dropped by kernel
Antoon
_______________________________________________
networking-discuss mailing list
[email protected]
