I am struggling with a devious problem.  The scenario:

sprint dsl user in illinois with a cisco router connected to a linksys
BEFW 11S4 wireless hub which connects to computers in the house.

Website 1: new jersey, cobalt linux.
Website 2: new jersey, sun sparc with solaris 8.  (same subnet)

This user (who happens to be the Big Boss on our project) uses a
website on website 1 fine, but on website 2, if he tries to post
content from a form greater than 1387 bytes in length, his web browser
hangs (netscape: host contacted, waiting for reply), until (error:
connection reset by server).  This happens on an XP machine, ME
machine, and a 98 laptop, with IE and netscape.

We've narrowed it down to a Path MTU problem.  However, I'm not a
network engineer and this is the first time I've heard of it.

We've tried setting the MTU on the solaris machine down to 536, as per
one recommendation we read.  However, this still did not work.

I should mention that nobody else (colorado, california, etc) can
duplicate the problem... the linksys hub has firmware from oct 2001,
and there is a more recent version.  The sun sysadmin is convinced
that if we upgrade the firmware, the problem will go away (so he
refuses to investigate making more changes on the sun).  However,
my boss is concerned that even if we fix the boss's computer, the
problem will still exist on the sun such that other site users could
experience this "hanging".

question:  Given this scenario, is there a way to change something on
the solaris box to fix this problem?  Remember, there is NO problem
with the linux box that is on the same subnet as the solaris.

Thanks for any help you can be.

---

Clarification of Question by climbingboulder-ga on 18 Oct 2002 11:51 PDT

thanks for the reply.  We had seen this page, and already tried
those.... here's the comments/specs:

</u/howie> x1a.howie{12} sudo ndd /dev/tcp \? | grep mss
tcp_mss_def_ipv4              (read and write)
tcp_mss_max_ipv4              (read and write)
tcp_mss_min                   (read and write)
tcp_recv_hiwat_minmss         (read and write)
tcp_mss_def_ipv6              (read and write)
tcp_mss_max_ipv6              (read and write)

and here are their values: 
</u/howie> x1a.howie{13} sudo ndd /dev/tcp  tcp_mss_def_ipv4 536
</u/howie> x1a.howie{14} sudo ndd /dev/tcp tcp_mss_max_ipv4 65495
</u/howie> x1a.howie{15} sudo ndd /dev/tcp tcp_mss_min 108
</u/howie> x1a.howie{16} sudo ndd /dev/tcp tcp_recv_hiwat_minmss 4
</u/howie> x1a.howie{17} sudo ndd /dev/tcp tcp_mss_def_ipv6 1220
</u/howie> x1a.howie{18} sudo ndd /dev/tcp tcp_mss_max_ipv6 65475


and here are all the ip values relating to mtu at all:
</u/howie> x1a.howie{21} sudo ndd /dev/ip \? | grep mtu
ip_ire_pathmtu_interval       (read and write)
ip_path_mtu_discovery         (read and write)

and here are their values: 

</u/howie> x1a.howie{20} sudo ndd /dev/ip ip_path_mtu_discovery 1
</u/howie> x1a.howie{22} sudo ndd /dev/ip ip_ire_pathmtu_interval
600000


before reboot, I set the following and had george test: 
ip_path_mtu_discovery 	1
tcp_mss_max_ipv4 	1200
tcp_mss_max_ipv6 	1200


he still saw whirling. 

Basically I think this means that we did try both of their workarounds
in that page, but neither worked.

This page: http://www.cisco.com/warp/public/105/38.shtml describes:

Sometimes, over some IP paths, a TCP/IP node may send small amounts of
data (typically less than 1500 bytes) with no difficulty, but
transmission attempts with larger amounts of data hang, then time out.
Often this is observed as a unidirectional problem: large data
transfers succeed in one direction but fail in the other direction.
This problem is likely caused by the TCP MSS value, PMTUD failure,
different LAN media types, or defective links.

The page then goes to describe how to adjust the above values, etc.


Searched on: "Path MTU" problem "solaris 8"

this does indeed sound like a problem with the MTU (maximum
transmission unit), and having recently read about ethernet
specifications, leads me to believe it may be a problem with the
boss's network. it is interesting that you can only transfer amounts
less than 1387 bytes, since this is close to the maximum size of an
ethernet frame (1500 bytes is the MTU for ethernet).

this would lead me to suspect it is a problem with the bridging
function of the wireless hub, which probably uses a higer MTU than the
ethernet frame, and is having a problem sizing it down properly when
converting the packet from the wireless network onto the wired one.

even though this problem does not crop up on the other server on the
same subnet, i would suspect that this is more a factor of the nature
of the data you are sending to the server, rather than any server
misconfiguration. the nature of sending data via a webform may not
lend itself to packet segmentation whereas other types of data would
work fine.

please please please upgrade your firmware as this is very likely to
solve your problem. linksys routers in general and wireless gateways
in particular are notorious for general "lousy" performance and
specifically weird errors when using the firmware that comes with the
shipping versions of the units.

if upgrading the firmware works, your boss can be reasonably assured
that no similar problem will result for other users. the exception to
this being those using an indentical setup to his, which would not be
blamed on your website anyhow, as other strange networking problems
are likely to crop up elsewhere without the updated firmware.

i am drawing the information for these comments from personal
experience rather than research due to the fact that i am only
supplying a comment rather than a full answer. i trust the comment i
am giving is better than nothing at all, which is what i would be
giving if i were required to provide a full answer instead of a
comment.

It sounds like you have control over the networks at both sides
(Illinois and New Jersey). If so, look very carefully at any firewall
or packet filtering rules and be sure you are *not* filtering ICMP
destination unreachable messages. Specifically the "fragmentation
needed and DF set" message.

These packets are ICMP type 3, code 4, and should be allowed through
your firewalls so that hosts can automatically detect the path MTU and
adjust the size of the packets they send accordingly.

This URL gives some more background information on my previous comment:
http://alive.znep.com/~marcs/mtu/