Testing Protocol with Packets out of order


(Duarte Ferreira) #1

Hi, Sorry if this is a very noobish question but I'm only starting with packetbeat and Go.

I've been playing around with packetbeat and the ELK stack and decided to implement a new protocol to test how packet beat works, nad learn myself some Go on the way.

I'm using a TCP based protocol that sends huge messages that are split through several packets.
using localhost ( in a debian VM) I am able to receive and rebuild the whole message correctly on packetbeat.
Then I decided to see what would hapen if some packets were delayed.

From StackOverflow I'm using this command "tc qdisc add dev lo root netem delay 100ms 20ms distribution normal " to simulate packet delay. When running packetbeat I was hopping that the message would be rebuild correctly but instead it triggers the GapInStream function.

if this is the expected result how can I rebuild the message when I get packets out of order?


(Steffen Siering) #2

Packet delay should not trigger any packet loss. If delay is bigger then transaction timeout, the stream might be dropped.

You can get tcp debug output by running packetbeat with -d 'tcp' enabled.

Have you checked your pcap in wireshark? Are packets re-ordered in your tcp-stream? E.g. check log output 'Gap in tcp stream' for last seen tcp sequence numbers.


(Duarte Ferreira) #3

Hi Steffen,
Thanks for the fast reply.
I found that using two machines instead of the localhost works fine.
The packets arrive out of orders and the messages are correctly rebuilt.
Maybe the lo interface timeout is too short and was a bad example to start with.


(Steffen Siering) #4

replaying on localhost should be no problem in general. But sniffing can always drop messages (depending on how pcap is replayed).

Did you use the packetbeat '-N' option for testing?


(system) #5