SYN-ACK

Hi,

Could someone here tell me All Possible reasons for SYN ACK loss ?

Thx in advans, Karthik Balaguru

Reply to
karthikbg
Loading thread data ...

The cat ate your router, probably.

--
:wq
^X^Cy^K^X^C^C^C^C
Reply to
Ico

Nah, I've found that dogs are much more likey than cats to eat things like routers.

--
Grant Edwards                   grante             Yow!  I'm in ATLANTIC CITY
                                  at               riding in a comfortable
 Click to see the full signature
Reply to
Grant Edwards

I suspect it would be the same set of all possible reasons for any other packet being lost.

A bit more context to the question might help.

rick jones

--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." 
 Click to see the full signature
Reply to
Rick Jones

Yes, but you should really do your homework or midterm exam.

Thanks for playing, though !

Reply to
Justa Lurker

I doubt anyone can enumerate ALL of them.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
 Click to see the full signature
Reply to
Barry Margolin

You're going to fail your course on TCP/IP, so please give up now.

pete

--
pete@fenelon.com "it made about as much sense as a polythene sandwich"
Reply to
Pete Fenelon

Once i was sober. When that was, i did sometings that were dumb with fragmented packets. Then i realised and re fragmented. All is now good. All i can say is 'Refragment'/

Syn is cool/

Reply to
The Real Andy

Hi,

The strange thing is 'SYN-ACK' gets lost only during certain times and sometimes consistently. So, i suspected RED algorithm and traced the drop packets using counters. But, i do not find any RED drops during the SYN-ACK losses scenario. Really strange . Any ideas ??

Thx in advans, Karthik Balaguru

Reply to
karthikbg

I suspect that the SYN-ACK packet is just a red herring. It's more likely that the SYN-ACK fails because it happens to be the first packet from the server. Does the server have the client's hardware address when it wants to send the SYN-ACK ?

There may be a problem with your server's ARP packet. Since it's a broadcast, and you have a wireless link in there, it may have gotten lost. Try looking at your ARP traffic, and/or set up a static ARP entry, and see if that helps.

Reply to
Arlet

Yes, the server has the Client's hardware address.

I too suspected that initally, so the changes have been made such that communication takes place via a particular modem only. It is not a broadcast being done now. I am trying with Unicast only.

I am tracking the SYN-ACK flags in the TCP header and tracing through the whole its flow(life-cycle). Maybe, that would give some info.

But this is really strange to see SYN-ACK getting dropped. There is no Collision drops also. If it drops for a particular condition, then it should drop everytime . But that does not happen here. Any ideas ?

Thx in advans, Karthik Balaguru

Reply to
karthikbg

[My prior post seems to have gone missing, so here's a resend...]

Hi, Karthik.

If this is truly only happening to SYN-ACK packets, then it sounds like a stateful device in the path (e.g., a NAT device, or perhaps firewall) which is taking issue with the incoming SYN-ACK packet. This could happen if it didn't promptly build the table entry to allow return traffic when it observed the outgoing SYN packet. (With asymmetric routing, this can happen consistently.)

However... Occam's Razor says that this is probably simple packet loss, and with a wireless device it's probably interference.

If you were experiencing inbound packet loss, it might not normally be obvious from your vantage point except during steps like the 3-way handshake - you might only observe very slight pauses, much less than 3 seconds apiece.

You would not see your device re-transmitting much due to lost incoming ACKs, since they are dupicated in many other incoming packets. However, the remote device could be detecting and re-transmitting without a large timeout because it's receiving regular ACKs embedded in packets from your device, and those ACKs indicate lack of receipt for the missing packet.

You would have to explain more about this "BTS" setup and where your sniffers are placed to investigate further. (Is this a satellite downlink with a terrestrial / dial-up uplink, or are you describing some setup with WiFi? Are you routing asymmetrically here [different inbound vs. outbound data paths]?)

Reply to
Richard H.

There are no Firewall or Static devices issue . This setting has been confirmed.

Maybe, this will get ruled out if there is no firewalls or Static devices on the way. So, i think, this gets ruled out in the scenario here.

I experience more than 3 seconds delay issues.

Yes, i too accept this.

I have a BTS connected to Internet(backhaul) on one side and Wireless Modem(in PC) on the other side which accesses websites via that BTS.

When trying to access websites via the modem from PC, i find it to be slow. I analysed the data flow using the Protocol analyser 'Ethereal' (Sniffer). So, I ran Ethereal in my PC(modem side) and Ethereal(Sniffer) at the place where my BTS is connected to the internet(backhaul).

I find that SYN request is getting fired from the wireless modem to BTS and later to the corresponding website. I am able to find this in the Ethereal running on the modem side .

I find that SYN-ACK is being fired back from the website to BTS via the Ethreal running at that place. But, that SYN-ACK does not reach the modem from BTS. Here is the SYN- ACK loss problem :( :( :( Because of this, after 3 seconds, SYN is being sent once again by the Modem to the corresponding website via BTS and the whole cycle of above process gets repeated until the SYN-ACK is received and the connection gets established.

If that SYN-ACK loss is avoided, that 3 seconds delay can be avoided and this will quicken whole process. The situation is very bad when there is Multiple SYN-ACK losses at frequent intervals.

It is a CDMA setup.

No .

Any ideas ??

Thx in advans, Karthik Balaguru

Reply to
karthik_balaguru79

OK. I'm not clear on what you mean by "static devices", but I suppose this your interpretation of "NAT" (Network Address Transalation).

My point here is that you might simply have issues with poor wireless transmission for traffic toward your device.

In many situations this may not be obvious from the receiver's perspective. An exception would be during SYN-ACK when the problem would be very visible, and would be much slower to recover.

OK, so this "BTS" thing is some sort of CDMA-based wireless link between your PC and a fixed location? Is the path between the BTS and your PC over the public CDMA network, where traffic between the endpoints is being carrier-switched? Or is it a direct point-to-point from the PC to the base station?

To boil this down:

  • General transport instability can cause the behavior you see, and it may only be obvious during 3-way handshaking.
  • Most devices will unaware that a packet is SYN-ACK, so it's unlikely that this behavior is really only affecting SYN-ACK. Exceptions being: * Stateful devices like firewalls and NAT that care about SYNs * For the first packet in each direction, extra steps are sometimes required (ARP, route lookup & caching). If your BTS setup is a simple wireless extension of a subnet, none of these extra steps would be involved at that point.

If you have access to both ends of the wireless link (as it seems you do, since you can place Sniffers there), it would be prudent to find a tool to run an end-to-end BERT for an extended period (whether at a bit or packet level) to understand if you have basic transmission issues. Start with an assumption that this is not a devilishly complex problem, and first establish that the wireless transport really is reliable.

Reply to
Richard H.

Hi, I find something interesting. I put some debug-prints in the BTS and Modem side. I was able to see that the SYN-ACK in ethereal of BTS side and the debug-prints of the BTS side. But, on the Modem side, i found that the "Source IP address" got changed to some different value and so my modem is discarding the packet. But the strange thing is that, the "Source IP address" gets changed whenever there is some SYN-ACK loss. Further, the "Source IP address" is perfectly intact when i view it via the Ethreal on the BTS side w.r.t that SYN-ACK. On the Way to Modem from BTS, How does the "Source IP address" and "Destination IP address" gets changed whenever there is SYN-ACK loss on the way to the Modem from BTS . That too, it is getting changed to the same value whenever there is SYN-ACK loss. Can this be the reason behind the SYN ACK getting lost here ?

Thx in advans, Karthik Balaguru

Reply to
karthik_balaguru79

packet.

Hi, I find that there is an ARP coming during that time & SYN-ACK losses happen during that time. I think, this problem is related with ARP. Any how, need to confirm if the ARP comes into picture everytime there is a SYN-ACK loss.

I have put some logs in the code to make it even more efficient than Ethereal to analyse the data at various levels. While analysing the data that is present before segmentation in the BTS side, the data remaiins intact. But, in the modem side , if we examine the data after reassembly of the segments obtained , we find a strange thing.There is a different Source IP address (Instead of the intended website's address) that reaches modem at the time of arrival of SYN-ACKs. This we were able to find in the

2 or 3 small checks that had SYN-ACK loss scenarios.

Any ideas ? Can ARP cause such problems ?

Thx in advans, Karthik Balaguru

Reply to
karthik_balaguru79

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.