Re: Problem testing sflow

Thank you for the detailed description. It looks like I introduced
a bug in version 6.0. You should add the line:

sa4->sin_port = htons((u_int16_t)receiver->sFlowRcvrPort);

To the IPv4 section of the initSocket() function in sflow_receiver.C
(line 83).

To see samples being generated I suggest you add "-P" to the command
line to kick the interface into promiscuous mode, or change "-s 75"
to something like "-s 10".

A gdb breakpoint on sfl_receiver_writeFlowSample() will trigger on a
datagram being sent.

In another window, the command: "/usr/sbin/tcpdump udp port 6343"
should log the packets. I just checked it on a Red Hat ES3 system
and on a Fedora 7 64-bit system.

regards,
Neil

P.S. That error message opening the IPv6 socket will appear on
systems that do not support IPv6, but apart from the nuisance-factor
it should have no effect on the generation of sFlow-over-IPv4.

On Apr 28, 2008, at 3:57 AM, Rune V. Sjxen wrote:

> ./sflsp -d eth0 -v -C 137.138.130.66 -c 6343 -s 64
>
> creating sfl agent
> sflow agent error: sfl_agent_sysError: agent: IPv6 socket open failed
> (errno = 97 - Address family not supported by protocol)
>
> calling pcap_open_live(dev=eth0, snaplen=128, promisc=0, to_ms=100,
> errbuf)
> sending tick
> sending tick
> sending tick
> sending tick
> sflow agent error: sfl_agent_sysError: receiver: socket sendto error
> (errno = 22 - Invalid argument)
> agentCB_getCounters
> .....
>
> So, as you can see the error is from the sendto function and the error
> code implies an invalid argument.
> When I examine the function call with gdb I get the following
> information (which are the arguments of sendto.
>
> (gdb) print receiver->agent->receiverSocket4
> $1 = 6
>
> (gdb) print receiver->sampleCollector.data
> $2 = {83886080, 16777216, 16842879, 0, 16777216, 3490119680, 16777216,
> 16777216, 2617245696, 16777216, 16777216, 1073741824, 50331648, 0,
> 4294967103, 16777216, 16777216,
> 16777216, 1946157056, 16777216, 1711276032, 67108864, 1644167168, 0,
> 0, 0, 4521992, 21504, 20971584, 8365884, 8323328, 524544, 675017151,
> 2984968704, 3875883027, 151519245,
> 218893066, 286265102, 353637138, 421009174, 488381210, 555753246,
> 623125282, 690497318, 757869354, 825241390, 892613426, 14134, 0
> <repeats 427 times>}
>
> (gdb) print receiver->sampleCollector.pktlen
> $3 = 192
>
> (the flags argument is 0)
>
> (gdb) print receiver->receiver4
> $4 = {sin_family = 2, sin_port = 0, sin_addr = {s_addr = 16777343},
> sin_zero = "\000\000\000\000\000\000\000"}
>
> (gdb) print soclen
> $5 = 16
>
> As you can see the port is 0, which is a problem. So after some
> mucking about I set the port in the sockaddr struct right before the
> call to sendto. And now the application seems to run clean. With
> sendto returning the correct number of bytes sent.
> I'm going to investigate this matter further as I dont see any reason
> the port should not be set.
>
> However, when I try to capture these packages using wireshark I have
> nothing. I tried using sFlowTrend which also gives me squat.
> The output from the application with -vv is the following:
>
> creating sfl agent
> sflow agent error: sfl_agent_sysError: agent: IPv6 socket open failed
> (errno = 97 - Address family not supported by protocol)
>
> calling pcap_open_live(dev=eth0, snaplen=128, promisc=0, to_ms=100,
> errbuf)
> calling pcap_dispatch()
> readPacket: 0007e9ef705e -> ffffffffffff (len = 60, captured = 60)
> check clock
> calling pcap_dispatch()
> readPacket: 0007e9ef705e -> ffffffffffff (len = 60, captured = 60)
> check clock
> calling pcap_dispatch()
> readPacket: 009027dc17dc -> ffffffffffff (len = 60, captured = 60)
> check clock
> sending tick
> sending tick
> calling pcap_dispatch()
> readPacket: 000ffe6090c5 -> ffffffffffff (len = 60, captured = 60)
> check clock
> calling pcap_dispatch()
> readPacket: 0007e9c781fa -> ffffffffffff (len = 60, captured = 60)
> check clock
> calling pcap_dispatch()
> readPacket: 0011111a5f72 -> ffffffffffff (len = 60, captured = 60)
> check clock
> calling pcap_dispatch()
>
> Does this indicate that samples are being sent ? I have no evidence
> that suggests otherwise except the fact that the packages never seem
> to appear anywhere. Even tracing traffic on the same host that the
> agent is running on I am unable to capture any sflow datagrams.
>
> I am just trying to generate some sflow datagrams from the eth0
> interface and send them to a collector. I tried running the collector
> both locally using the sflow5Test.awk script, and remote using ntop
> and sFlowTrend.
>
> Am I missing something here ?
> --
>
> Rune V. SjC8en
> You always pass failure on the way to success
Received on Mon Apr 28 12:01:58 2008