I'm not sure if you're aware, but this implementation doesn't really need to conform to IPFIX standards. PSKreporter uses IPFIX as the base, but doesn't really implement all aspects of it. As such, I don't really see the issue in Wireshark complaining about not being able to parse the packet. What really matters is whether or not PSKreporter can parse the packet, and from what I can tell, that works perfectly fine.

Please check the development documentation: https://pskreporter.info/pskdev.html

As you can see, the "error" is present in the examples on that site, too.

I'm not sure if you're aware, but this implementation doesn't really need to conform to IPFIX standards. PSKreporter uses IPFIX as the base, but doesn't really implement all aspects of it. As such, I don't really see the issue in Wireshark complaining about not being able to parse the packet. What really matters is whether or not PSKreporter can parse the packet, and from what I can tell, that works perfectly fine.

Please check the development documentation: https://pskreporter.info/pskdev.html

As you can see, the "error" is present in the examples on that site, too.

Yes, it's true it doesn't need to comply with the RFC for PSKReporter to accept it. But the non-compliance does make analysis with utilities like Wireshark or some IPFIX libraries more difficult, since they may treat the template as malformed. I submitted an update to the website & it's now reflected there. Another change it now recommends is to advance the sequence number by the number of flows (instead of 1); I think your code already does that, which is excellent. 😄

For context, I've been using packet captures/Wireshark to analyze why some OpenWebrx payloads are getting fragmented. Since the template is malformed, I couldn't see the deserialized values at a glance & had to check them using the raw bytes manually.

I believe I found the fragmentation issue - I submitted a PR: #391

I submitted an update to the website & it's now reflected there. Another change it now recommends is to advance the sequence number by the number of flows (instead of 1); I think your code already does that, which is excellent. 😄

I will check the website. The main question for me is whether it works with pskreporter.

I actually had a bit of a back and forth about the sequence numbers with Philip... See #341 😉

The main question for me is whether it works with pskreporter.

It should work without issue. There's no code on the PSKReporter backend that checks it & spot uploaders using scope field count = 1 are successfully uploading spots. Code-wise, the Net::Flow library (link) is used & the flow_decode() treats all fields identically w/o considering the template's scope field count.