Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Has anyone seen or know of a problem with the handling of mangled incoming TCP packets in Linux 2.4.21 or 2.6.16 during "bulk delivery" -- like FTP? Essentially, one of incoming packets has a bad TCP checksum, mangled by some intervening switch no doubt. This apparently causes the TCP stack to NOT respond with duplicate ACKs for all subsequent packets, but it knows the mangled packet is bad and drops it. The sender waits 0.4 seconds and resends the missing packet. The receiver responds immedeiately with an ACK for all remaining packets. Below is an trace of such an incident from the sender side:
Pkt#521 is mangled (bad TCP checksum). The rcver ACKs in Pkt#529 up to and including Pkt#520. At Pkt#538, the sender has waited 0.4 seconds and resends Pkt#521 as Pkt#538. The rcver immediately responds with Pkt#539, which ACKs up to and including Pkt#537. NOTICE that Linux is NOT sending any duplicate ACKs for Pkts 522 thru 537!!!!