Open CameronNemo opened 1 year ago
Thanks for your interest in the project. Could you share a single Scapy packet that reproduces this behavior, along with the expected correct packet?
Looking at https://github.com/influxdata/telegraf/pull/14373/commits/8b97b42cb680bd72f4bfb04e3339a92d8d024a78 it seems the length got lost somewhere. The packet produced by the script contains
Field (12/15): flowStartSeconds
0... .... .... .... = Pen provided: No
.000 0000 1001 0110 = Type: flowStartSeconds (150)
Length: 0
Field (13/15): flowEndSeconds
0... .... .... .... = Pen provided: No
.000 0000 1001 0111 = Type: flowEndSeconds (151)
Length: 0
According to https://datatracker.ietf.org/doc/html/rfc5102#section-5.9.1
Abstract Data Type: dateTimeSeconds
and according to https://www.rfc-editor.org/rfc/rfc7011.html#section-6.1.7 it should be
an unsigned 32-bit integer in network byte order containing the number of seconds since the UNIX epoch
My guess would be that something like
netflow.NetflowTemplateFieldV9(fieldType="flowStartSeconds", fieldLength=4),
netflow.NetflowTemplateFieldV9(fieldType="flowEndSeconds", fieldLength=4),
should probably make it work without crashing telegraf
.
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