sflow packets with padding after sample is not parsed correctly

[dbardbar]

See the attached pcap.
After flow sample #3, sequence 452104583, and before sample #4, sequence 947406136, there is a 4 byte gap.
The code today does not handle this gap, and tries to parse those 4 bytes as part of sample #4, which causes failures, and the whole packet is dropped.

I couldn't find in the sFlow RFC any statement that either requires or prohibits such padding. The sFlow RFC says it uses the XDR standard (RFC 4506), which states that fields need to aligned on 4 bytes, which would mean no padding is required in this packet. Perhaps I'm misreading the XDR RFC, and there's a 8 byte alignment requirement.

At any rate, we've seen such packets in the wild, so some implementations add such padding, and vflow should handle such cases.
Wireshark handles this scenario well.

The solution is to change SFDecode so that it'll know the d.reader offset at the beginning of each sample, let the decoders decode, and then check the offset after the decoders moved it. If it is smaller than the declared sample size, then move the d.reader forward, by the remaining bytes, to reach the next sample.

sflow_padding_between_samples.zip