[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gif tunnel mtu problem - changing mss not an option
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: gif tunnel mtu problem - changing mss not an option
- From: Chuck Yerkes <chuck+obsd_(_at_)_2003_(_dot_)_snew_(_dot_)_com>
- Date: Thu, 3 Jul 2003 15:19:57 -0400
- Mail-followup-to: Chuck Yerkes <chuck+obsd_(_at_)_2003_(_dot_)_snew_(_dot_)_com>, misc_(_at_)_openbsd_(_dot_)_org
Um, if a machine is ignoring icmp messages, then they
are not running TCP/IP. They are running their own
proprietary network stack that looks like IP.
What a friend calls "TCP/IP aware" (vs. "compliant").
Feel free to peruse the IP RFCs and look for the word
MUST. It's popular. Richard Stevens and Doug Comer
also cover IP in pretty good detail.
Anything else (like using pf) is a work around.
But pf can do it for you.
Quoting c0g (c0g_(_at_)_wp_(_dot_)_pl):
> I've made gif tunnel (protected by IPSec) between two OpenBSD boxes.
> ~ tunnel
> client ---- rl0-OBSD-gif0 ======= gif0-OBSD-rl0 --- internet -- server
> MTU of the tunnel is smaller than 1500. When server transmits big
> packets to client, they don't fit in the tunnel, so OBSD box sends icmp
> need to frag. Some servers are broken and drops this kind of icmp
> packets. This is well knows mss-mtu issue - can be repaired by changing
> mss to fit mtu hack on router box.
> But i think, that in my setup, it is not optimal. I want to maximalize
> usage of my internet connection, so I want to transmit and receive
> packets as big as possible = 1500 bytes. Changing mss will increase
> number of small packets. Larger number of packets mean that there is
> more "signalization" data bounded to each packet, so there is fewer room
> for data that these packets carry. So fragmentation (only between tunnel
> endpoints which are under my control) sounds better in my opinion.
> Is there any way to tell OpenBSD kernel to fragment too big packets
> going thru tunnel instead sending icmp need to frag? To make tunnel
Visit your host, monkey.org