Brian,
I found the following in a Linux manual for the 'ip tunnel' command:
nopmtudisc -- disable Path MTU Discovery on this tunnel. It is enabled by default. Note that fixed ttl is incompatible with this option: tunnels with fixed ttl always make pmtu discovery.
If you create a tunnel that does not care about MTU state, it's also unconcerend about the 'distance' the packet has traveled, your eth interface would handle both tasks in that instance (being a 'dumb tunnel,' if you will). With nopmtudisc on, your 44Router would properly fragment the packet when transmitting on eth and sets the ttl on the ARPA Internet, as opposed to AMPRnet. If this command worked before you updated your IP utilities, it was probally due to the previous version not being written true to RFC.
73,
Lynwood KB3VWG
On Mon, 2013-12-30 at 18:59 -0500, lleachii@aol.com spake:
nopmtudisc -- disable Path MTU Discovery on this tunnel. It is enabled by default. Note that fixed ttl is incompatible with this option: tunnels with fixed ttl always make pmtu discovery.
The opposite is what occurs now... by default and it refuses to allow a change.
If you create a tunnel that does not care about MTU state, it's also unconcerend about the 'distance' the packet has traveled, your eth interface would handle both tasks in that instance (being a 'dumb tunnel,' if you will). With nopmtudisc on, your 44Router would properly fragment the packet when transmitting on eth and sets the ttl on the ARPA Internet, as opposed to AMPRnet. If this command worked before you updated your IP utilities, it was probally due to the previous version not being written true to RFC.
This is NOT what was occurring however with the updated libs, it's setting an MTU of 0 (discover) even though my ifconfig statement has an MTU of 1480, AND it's locking out the ability to set TTL. Another issue at hand is that ifconfig and iproute2 tools do not see each other. What's occurring now is not true to RFC.
Perhaps I stated the issue backwards... sorry if I did, lost a family member today.