Strange Problem with 16 byte packets
Hi, I am using a proprietary protocol and sending a bunch of bytes to a Draytek router at an enterprise site. When i send the data in TCP batches of 1 MB i see no problem. However, when i first send 16 bytes followed by 1 MB of data, and then repeat this till the entire data has beeen sent out. During this process I see that my TCP session times out. Unable to understand why this could be happening? How can sending 16 bytes of data followed by 1MB of data affect the transfer. Thanks !
Follow the TCP stream - which side times out the link, and for what sequences of data do you get ACKs for? /Ruairi On 16 June 2016 at 10:43, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
I am using a proprietary protocol and sending a bunch of bytes to a Draytek router at an enterprise site. When i send the data in TCP batches of 1 MB i see no problem. However, when i first send 16 bytes followed by 1 MB of data, and then repeat this till the entire data has beeen sent out. During this process I see that my TCP session times out. Unable to understand why this could be happening? How can sending 16 bytes of data followed by 1MB of data affect the transfer.
Thanks !
Thanks i will. However, the doubt is that what does introducing a 16 byte data into the steam does that causes the session to time out. I added instrumentation to push some dummy data so that instead of 16 bytes, we push 1 MB of data. In that case i saw no issues. Any idea if there is a firewall setting that could be coming into play here? On Thu, Jun 16, 2016 at 2:17 PM, Ruairi Carroll <ruairi.carroll@gmail.com> wrote:
Follow the TCP stream - which side times out the link, and for what sequences of data do you get ACKs for?
/Ruairi
On 16 June 2016 at 10:43, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
I am using a proprietary protocol and sending a bunch of bytes to a Draytek router at an enterprise site. When i send the data in TCP batches of 1 MB i see no problem. However, when i first send 16 bytes followed by 1 MB of data, and then repeat this till the entire data has beeen sent out. During this process I see that my TCP session times out. Unable to understand why this could be happening? How can sending 16 bytes of data followed by 1MB of data affect the transfer.
Thanks !
It's hard to tell based on no data. Anything from here would be an assumption and hear-say, since you're debugging a black box and trying to infer inner workings based on external observations. You _need_ to collect more data and observe the data at the source and destination devices, and probably in transit if you're tunnelling/fragmenting. Basica, On 16 June 2016 at 11:36, Glen Kent <glen.kent@gmail.com> wrote:
Thanks i will. However, the doubt is that what does introducing a 16 byte data into the steam does that causes the session to time out. I added instrumentation to push some dummy data so that instead of 16 bytes, we push 1 MB of data. In that case i saw no issues. Any idea if there is a firewall setting that could be coming into play here?
On Thu, Jun 16, 2016 at 2:17 PM, Ruairi Carroll <ruairi.carroll@gmail.com> wrote:
Follow the TCP stream - which side times out the link, and for what sequences of data do you get ACKs for?
/Ruairi
On 16 June 2016 at 10:43, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
I am using a proprietary protocol and sending a bunch of bytes to a Draytek router at an enterprise site. When i send the data in TCP batches of 1 MB i see no problem. However, when i first send 16 bytes followed by 1 MB of data, and then repeat this till the entire data has beeen sent out. During this process I see that my TCP session times out. Unable to understand why this could be happening? How can sending 16 bytes of data followed by 1MB of data affect the transfer.
Thanks !
Thu, Jun 16, 2016 at 03:06:24PM +0530, Glen Kent wrote:
Thanks i will. However, the doubt is that what does introducing a 16 byte data into the steam does that causes the session to time out. I added instrumentation to push some dummy data so that instead of 16 bytes, we push 1 MB of data. In that case i saw no issues. Any idea if there is a firewall setting that could be coming into play here?
Collect TCP dumps from both sides, come back and show that (or analyze yourself ;) -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
participants (4)
-
Eygene Ryabinkin
-
Glen Kent
-
Randy Bush
-
Ruairi Carroll