>Number:         7375
>Category:       misc
>Synopsis:       IPNAT would not always send or retrieve with MTU/MRU = 552
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people (Misc Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 13 19:05:00 1999
>Last-Modified:
>Originator:     Roger Fischer
>Organization:
	
>Release:        NetBSD 1.3.2/Mac68k<NetBSD-current source date>
>Environment:
NetBSD 1.3.2/Mac68k on Centris 610 with full 040 processor
	
System: NetBSD max 1.3.2 NetBSD 1.3.2 (max_kernel) #0: Wed Oct 14 08:27:13 PDT 1998 roger@max:/usr/src/sys/arch/mac68k/compile/max_kernel mac68k


>Description:
	While using IPNAT on my NetBSD Machine as a gateway for my MacOS 8.5.1
	machine, Eudora (email) would occasionally hang for no reason, while
	trying to send mail.  Eudora would try to send, but it would never
	Get to the mail server.  If I cut and pasted the message into pine
	on the NetBSD box itself, it would go through fine.

	Someone suggested I use tcpdump to look at what was not passing.
	I received several errors mentioning the MTU.  When I upped the MTU
	from 552 to 1500, the mail passed through OK.  Upping the MRU from
	552 to 1500 solved a problem I had loading some web pages such as
	www.excite.com.

	Here is Dave Huangs explanation of what he thinks is happening.

	> 22:59:48.611914 max > max.badger1.net: icmp: mail.badger1.net unreachable - need to frag (mtu 552) (DF)
	> 22:59:48.611915 max > max.badger1.net: icmp: mail.badger1.net unreachable - need to frag (mtu 552) (DF)
	> 22:59:48.611916 max > max.badger1.net: icmp: mail.badger1.net unreachable - need to frag (mtu 552) (DF)

	Okay, I think these need to frag messages are the problem (I wonder why
	it says "max" one place and "max.badger1.net" the other). I think the
	problem is that NAT gets a packet from the machine sending the mail,
	then changes the source address to be your NetBSD machine's address.
	It's about to send it out, but notices that it's bigger than your PPP
	link's MTU (552 bytes) and the Don't Fragment (DF) bit is set. So, it
	tries to send back a "need to fragment" message back, but it's already
	changed the address on the packet and ends up sending the message to
	itself instead of the machine actually sending the packet.


	
>How-To-Repeat:
	
>Fix:
Set MTU and MRU higher.  I had them low for better modem
	performance when I had noisy lines.  Currently 1500 is working OK.
	
>Audit-Trail:
>Unformatted: