On Wed, 9 Jan 2002, Ira Abramov wrote:
> personally, my MTU is set at 1452, and also forced to re-fragment in the > iptables: > > $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu > > no idea if it helps, but it doesn't hurt :) lets try to guestimate why this is indeed the solution, and yet why eli's change also works: 1. if you set the MTU of ppp0 to 1452, while that on the ethernet card on the masquareded computer is higher, then that machine, under some protocol, might send packets which are larger then the MTU of 1452, and thus cause fragmentation. as was said in the past, _some_ of the adsl modems have a bug with handling of fragmented packets(?), or some router(s) on the way blocked the DONT-FRAGMENT ICMP message, causing such fragmented packets to be lost. in any vent - this problem wasn't identical for every person and towards every server even in the past. i would suggest that the ttps packets eli's winME tried to send ineed got fragmented - this could be verified with a sniffer, to see that one (or more) of them was larger then the 1452 MTU allowed. eli - do you wish to run such a sniffer, or otherwise, anyone else that has set their MTU to 1500, and know eactly which service to which host failed to work before this change? 2. ira (like others did) has set a rule in ipchains to set the MSS (maximum segment size, for TCP connectins) to the PMTU (path MTU - i think its the MTU found during 'MTU discovery', and surely not greater then the MTU of the linux machine's outgoing interface for the connection, which is ppp0). hence, this will make sure masqueraded hosts, even if they have an MTU of 1500, don't send packets whose IP data exceeds 1452 bytes (this including the IP header). 3. it _could_ be that even without it, the mere fact that ira uses 're-fragmentation' (which, as i remember, was a requirement for any masquerading linux machine, back in 2.2 kernels - have that changed) would have caused any fragmented packets to be de-fragmented before sent again. however, if the next hop is still too small - they will also be re-fragmented (as far as i can see), so this only helps for incoming pakcets, not for outgoing ones. btw, the reason for this de-fragmentation is to allow rules handling upper-level protocols (i.e. protocols above the IP layer) to be handled properly for the full packet, since the IP fragments do not contain the TCP data of the packet). eli (or someone else with a similar problem) - could y'all check if you have the MSS-handling rule, and if not - add it, and try reducing the MTU back to 1452 on the ppp0 interface, to check if practice falls withing these theories? i know that you don't personally care since your own problem(s) were solved, but to get the howto fixed, we need input. i don't have any masqueraded host at home, so i cannot make such test. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
