sfcapd inserts wrong srcAS number when there is no Extended gateway data

[crami]

I suspect that sfcapd inserts the previous srcAS into the dump file if there is no Extended gateway data in the corresponding flow sample. If I make a nfdump with a filter allowing only one interface and one IP-Address I get several source AS numbers back, which is not feasible.
I then captured raw sflow data with tcpdump and had a look at them in wireshark and it looks like that those samples which have no Extended gateway data show up with the wrong (from a previous sample) srcAS.

[crami]

Looks like the variable that stores the SFlow Data (sample) is initialized once end then the values in the struct are just overwritten for each sample. The variable gets created in sflow_nfdump.c line 203. In my Opinion the Data should be cleared somewhere in sflow_process.c, probably in the function readFlowSample(). But not sure if this is the right or only place.

[crami]

Forget what I wrote above. Just found that in sflow_nfdump.ch line 206 in Process_sflow the variable is nulled...
So why are there wrong source as numbers in the dump?

[phaag]

Would it be possible for you to tcpdump a few minutes of sflow traffic to the collector and send it to me offlist? If I can reproduce this somehow, it would help.

[crami]

@phaag just sent you a pcap file.

[phaag]

My analysis did not reveal a bug in sfcapd. Extended/nonExtended data is decoded correctly. If you have more details on possible wrong data handling, please reopen the ticket.

[phaag]

Reopened for fix. See #273

[phaag]

Fix in master branch applied. Fixed bug in sflow code extended field parsing.