# Testing Protocol with Packets out of order

**URL:** <https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321>\
**Category:** Beats\
**Tags:** packetbeat\
**Created:** [November 11, 2015, 11:43am UTC](https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321 "2015-11-11T11:43:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![lonangel](https://avatars.discourse-cdn.com/v4/letter/l/59ef9b/32.png) [@lonangel](https://discuss.elastic.co/u/lonangel)\
**Post date:** [November 11, 2015, 11:43am UTC](https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321/1 "2015-11-11T11:43:45Z")

</div>

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](http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux "Stack Overflow") 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?

---

<div class="post-metadata">

**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\
**Post date:** [November 12, 2015, 2:36am UTC](https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321/2 "2015-11-12T02:36:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lonangel](https://avatars.discourse-cdn.com/v4/letter/l/59ef9b/32.png) [@lonangel](https://discuss.elastic.co/u/lonangel)\
**Post date:** [November 16, 2015, 6:02pm UTC](https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321/3 "2015-11-16T18:02:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\
**Post date:** [November 17, 2015, 5:35pm UTC](https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321/4 "2015-11-17T17:35:16Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 9:58pm UTC](https://discuss.elastic.co/t/testing-protocol-with-packets-out-of-order/34321/5 "2017-07-05T21:58:09Z")

</div>