LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 07-11-2017, 06:53 AM   #1
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Rep: Reputation: Disabled
TCP ACK question


Click image for larger version

Name:	236.PNG
Views:	44
Size:	101.9 KB
ID:	25447
please check the attachment, it is receiver , all the tcp seq and ack number are real.

please look at the high line ack = 2305863558 , is it correct ? or should it be the the last tcp datagram 's SEQ + len it received , which is ack = 2305863644 + 86 .

and tcp restrasmission happen more the 10 times on this packet

and from the sender , Click image for larger version

Name:	237.PNG
Views:	40
Size:	66.3 KB
ID:	25448
it receive this packet more then one time , but , it still consider it as a no ack status .

it is possible dropped by the system because of the incorrect ACK number?

our current kernel version is Linux kickseed 4.9.20-040920-generic
 
Old 07-11-2017, 09:35 AM   #2
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
Click image for larger version

Name:	238.PNG
Views:	31
Size:	24.3 KB
ID:	25450

i just check the 6th packet as the picture shows . the wireshark tells it next SEQ sould be 2305863730, it just equal 2305863644 + 86
 
Old 07-11-2017, 12:11 PM   #3
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
any reply ?
 
Old 07-11-2017, 09:54 PM   #4
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
any body interested in this question ?
 
Old 07-12-2017, 05:12 AM   #5
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 2,138

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
I think there's no problem, make sure you understand how packet framing works.

TCP is a reliable protocol, which basically means that if the packet is dropped, lost in transit or corrupted.

The frame will be reassembled in sequence until the whole packet is in order, after a number of times of trying and not able to get the packet in order that will be the time that the application will throw an error.

What issue are you experiencing? Downloading from the internet and every time the data is corrupted?
 
Old 07-12-2017, 05:17 AM   #6
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 2,138

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
Lightbulb

Quote:
Originally Posted by gbcbooks View Post
Attachment 25450

i just check the 6th packet as the picture shows . the wireshark tells it next SEQ sould be 2305863730, it just equal 2305863644 + 86
The sequence number is decided by the Layer 3 in the OSI model (network layer) and is decided by both parties (two end devices).

You don't add the sequence number like that it's incremented by one only.

Don't dive too deep, learn the basics of OSI. Mileage will always vary, don't be in a hurry unless you don't have other priorities.
 
Old 07-12-2017, 05:44 AM   #7
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JJJCR View Post
The sequence number is decided by the Layer 3 in the OSI model (network layer) and is decided by both parties (two end devices).

You don't add the sequence number like that it's incremented by one only.

Don't dive too deep, learn the basics of OSI. Mileage will always vary, don't be in a hurry unless you don't have other priorities.
thks for reply , yes , of course TCP SEQ is completed by the Network layer , and we dont need to bother it. but knowing well how TCP works it is good for our job, isn't it .

and it is a really case in my business of my machine . it might be the root cause of our issue .

in normal time , we should believe that Layer 3 always working find , few situation that TCP will send a incorrect ack number . if it is so, the receiver will absolutely drop the incorrect ACK packet . so i was asking you guys think this issue is really happening on this machine .
 
Old 07-12-2017, 05:54 AM   #8
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 2,138

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
It's quite hard to get into depth, but if there's an issue in your network; I would check on your network card interface, network cables, network switches, routers and even your bandwidth whether it's stable or not.


If everything doesn't work well, then I guess it could be some malware changing the packets in transit but someone should be very determine to hack your network because changing or modifying network packets requires a high level of network knowledge and programming.

Search duckduckgo.com, Google or any of your favorite search engine this keywords: "Packets replay"

Quote:
and it is a really case in my business of my machine . it might be the root cause of our issue .
What is that issue, you're talking about? Like what? (layman terms please)

Analyzing network packets it's not easy as eating a pie, and it will take a definite amount of time to analyse it.

Sorry, I can't help you to get into details of it.

Last edited by JJJCR; 07-12-2017 at 05:59 AM. Reason: edit
 
Old 07-12-2017, 06:00 AM   #9
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JJJCR View Post
I think there's no problem, make sure you understand how packet framing works.

TCP is a reliable protocol, which basically means that if the packet is dropped, lost in transit or corrupted.

The frame will be reassembled in sequence until the whole packet is in order, after a number of times of trying and not able to get the packet in order that will be the time that the application will throw an error.

What issue are you experiencing? Downloading from the internet and every time the data is corrupted?
sorry , i did not see your first post .
two of our server will establish TCP connection and send data flow period . most of time they are working fine . but in a low rate , TCP data can not be sent and data are stock.

from the capture file , we see that the last ACK number of last TCP ack packet it wrong , by restramsit 15 times , TCP connection will be rest and open a new TCP session between this two machine . for our business , wait 15 time to restramsit is too long , and unacceptable .

so we want to fine out what cause the ack number incorrect, kernel ?
from this issue , we can reduce the times of tcp restramsit. but who can guarantee that the appearance rate of this issue
 
Old 07-12-2017, 06:08 AM   #10
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 2,138

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
Lightbulb

Quote:
Originally Posted by gbcbooks View Post
sorry , i did not see your first post .
two of our server will establish TCP connection and send data flow period . most of time they are working fine . but in a low rate , TCP data can not be sent and data are stock.

from the capture file , we see that the last ACK number of last TCP ack packet it wrong , by restramsit 15 times , TCP connection will be rest and open a new TCP session between this two machine . for our business , wait 15 time to restramsit is too long , and unacceptable .

so we want to fine out what cause the ack number incorrect, kernel ?
from this issue , we can reduce the times of tcp restramsit. but who can guarantee that the appearance rate of this issue
Are you using a custom application to transfer data or create a TCP connection?

The two machine is in the same network? or it's on a remote host?
 
Old 07-12-2017, 06:08 AM   #11
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
i m a network engineer , the rule of generating TCP SEQ is not so complicated as you think at less i think so .

the thing i can not believe that is TCP protocol stack i used to believe so hard would have a suck a stupid problem . i want somebody to tell me that i was wrong .
 
Old 07-12-2017, 06:09 AM   #12
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 2,138

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
Quote:
but in a low rate , TCP data can not be sent and data are stock.
Ahh okay, in low rate there's an error. Maybe the frame is too large for the bandwidth. Or there's a packet collision in between transit.

If the two machine is on a remote host, is it using a BGP network, frame relay or what?

If you think it's a kernel issue then search the web whether it's a common issue.

But I suppose you're experimenting sending packets in low bandwidth, there are a lot of things to consider. My pay grade is unable to adapt such things. LOL.

Last edited by JJJCR; 07-12-2017 at 06:14 AM. Reason: edit
 
Old 07-12-2017, 06:11 AM   #13
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JJJCR View Post
Are you using a custom application to transfer data or create a TCP connection?

The two machine is in the same network? or it's on a remote host?
yes , application layer is custom , we developer they only care application layer , layer 4 will be completed by kernel or protocol stack .

this two machine exist in two IDC
 
Old 07-12-2017, 06:13 AM   #14
gbcbooks
Member
 
Registered: Aug 2014
Posts: 199

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JJJCR View Post
Ahh okay, in low rare there's an error. Maybe the frame is too large for the bandwidth.
no , because of the sender received receiver's ack , even most of 15 retramsission packet were lost .
 
Old 07-12-2017, 06:16 AM   #15
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 2,138

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
Wink

Quote:
Originally Posted by gbcbooks View Post
i m a network engineer , the rule of generating TCP SEQ is not so complicated as you think at less i think so .

the thing i can not believe that is TCP protocol stack i used to believe so hard would have a suck a stupid problem . i want somebody to tell me that i was wrong .
Ohh, here comes the truth you're a network engineer then I guess you should be able to solve it. Just take it slowly, maybe tomorrow you will be able to figure it out. Maybe it just need a can of beer relaxing under the moon light. hahaha.

I'm a Sys Admin, so your network skills will be 1 billion percent better than me.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
TCP - ACK frequency meir129 Linux - Networking 2 04-08-2014 02:01 PM
How long before TCP ack's timeout and36y Linux - Networking 1 10-13-2010 12:53 PM
Linux change TCP kernel Parameter for TCP DELAY ACK TICKS linux_mando Linux - Networking 5 08-22-2006 09:20 AM
Disntiguishing between ACK packets in a TCP connection!! vishamr2000 Linux - Networking 3 05-23-2006 02:08 AM
TCP retransmission and duplicated ack enjoyzj Linux - Networking 0 06-05-2004 07:19 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 06:53 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration