Other transport layers

[cn-tu]

Other transport layers

[notti]

At the moment, transport layers that aren't TCP/UDP simply aren't exported.

1. Do you mean exposed as TransportLayer in packet?
2. Or are you not seeing the flows?

at 1.:
What you described above would do exactly that. Right now the transport layers that target the most IEs in the IANA ipfix spec are implemented (TCP, UDP, ICMPv4/6). All the other layers below, that are implemented, are the ones that are needed to being able to decode those.
The original Idea was that if features needed more, they should decode the rest themselves. Right now there is no generic way of doing that, but it shouldn't be hard to implement. Maybe add something to decode() that holds a pointer to the top most decoded layer (which would be IP for OSPF) which can be retrieved with some function. From there on one could continue with NextLayerType() and LayerPayload().
The reason this is done by hand was to get this part really fast (every packet has to go through this!). This works faster because no layers are ever allocated (they are part of the packet buffer) - instead the layers are reused everytime.

Maybe it we could also provide an additional slice in the packet buffer where one could add additionally decoded Layers so if multiple features use the same layer it only needs to be decoded once. This can then be done in a generic way (gopacket hast functions where you can daisy chain the NextLayer and decoding stuff) - or with some kind of filter.

at 2.:
Well this can be caused by the flow key. If for instance the port is part of the flow key this can never work since OSPF has no notion of ports. The same is true for every other protocol that has no ports.

[dcferreira]

Sorry, I wasn't clear. I have a file with empty flowkey, and only feature is packetTotalCount. When I run it on an OSPF packet, the csv exporter doesn't export anything.
I also tried with some other flowkeys (e.g., only source ip).

[notti]

Ah sorry thats then option 3.

try flipping the lines

go-flows/packet/buffer.go

Line 624 in a066f89

return false

go-flows/packet/buffer.go

Line 576 in a066f89

return false

to return true

These should actually return true (basically false would mean "I couldn't decode the packet" - But these two actually say "I couldn't find TCP,UDP,ICMP"). In the beginning this was needed, since the flow key didn't check if layers existed... Should be fixed by now. So hopefully nothing breaks if this is true...