Peter Golding wrote: > > sounds like the tcp mss parameter could be the cause. mss (max > segment > size) should negotiate end to end but some devices dont fall > down to a > lower mss requirement from the other end and therefore nothing > is sent > even when the tcp connection establishes.
Sending nothing because the receiver has a small Maximum Segment Size (MSS) would indicate a very broken TCP implementation. I think that's unlikely considering TCP has been around for a long time and MSS is such a fundamental part of TCP. Perhaps you didn't mean that the sender sends nothing, but rather, that it appears that way because packets get dropped en route and the receiver doesn't receive anything. But that wouldn't be a TCP issue. It could be an IP MTU issue, but that's another story. The TCP maximum segment size (MSS) isn't a negotiated parameter, by the way. Each host can specify its own MSS. The hosts don't have to agree. A host specifies its own MSS during the 3-way handshake, using a TCP option. One host can say that it can receive x number of bytes per segment and the other host can say something different. A host keeps track of how much data it can send to the other side, based on the other side's MSS value as reported in the TCP option in the other side's SYN packet. A host has a S_MSS (from a sending point of view) for each connection and a R_MSS from a receive point of view. I don't think he got this to work simply because he made the MTUs agree. I think he got it to work because he started to use an MTU that worked for the one side that was misconfigured. Although it's possible something squirrely happened at the TCP layer, it's more likely something weird happened at the IP layer. Probably what happened is HTTP packets from the server arrived that were 1500 bytes and the PIX couldn't send them to the other network because the other network was configured for an MTU of less than 1500 bytes. Although you can tell the PIX to forward IP fragments, note that this isn't the same thing as asking the PIX to do IP fragmentation itself, which isn't supported, as far as I can tell. Priscilla > > regards, peter > > Albert Lu wrote: > > > > Hello Group, > > > > I've had this interesting thing happen with a PIX where tcp > connection for > > HTTP was established through it however data does not pass > through > > correctly, since there was no HTTP data being sent through. I > noticed that > > the MTU for the outside and inside interfaces were different > and changed > > them to the default 1500 and things began to work normally. > > > > Does anyone have any idea why the MTU size would effect HTTP > data eventhough > > tcp was established? > > > > Thanks > > > > Albert > > -- > Peter Golding Content / Network Services > Technical Assistance Centre Cisco Systems > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62720&t=62704 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
