Netflow packets built by Scapy fail to decode when they contain timestamps
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 12.6k
- Forks
- 2.2k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 56
Description
Brief description
I've tried generating some netflow packets and sending them to various collectors (goflow2, telegraf)
It was going alright until I tried to add flow start and end timestamps... I tried with both seconds and milliseconds. On goflow2, it just ignored the encoded timestamp and telegraf crashed.
I included the full scapy program / output / reproduction in the telegraf ticket:
influxdata/telegraf#14370
Seems like more of a scapy issue, though, considering that neither goflow2 nor telegraf could successfully decode the field.
Scapy version
2.5.0
Python version
3.9
Operating system
Rocky8
Additional environment information
No response
How to reproduce
Create packet with flowStartSeconds and send it to popular open source netflow collectors
Actual result
start seconds not decoded by collector correctly
Expected result
start seconds decoded successfully
Related resources
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the full Scapy program, packet output, and reproduction linked in influxdata/telegraf#14370, focusing on packets containing the flowStartSeconds field. Compare the encoded seconds and milliseconds timestamps with how goflow2 and telegraf decode them; done means the generated NetFlow timestamps decode correctly in both collectors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100