mjhammel@Kepler.dell.com (Michael J. Hammel) (03/12/91)
I seem to be having a problem with V4 systems and UDP. It appears that
an NFS-based test between two V3.2 systems that I run shows up under
Netwatch as follows:
IP: src addr -> dest addr <value> UDP <value2> -> <value3> <value4>
where
value: is some number apparently less than 1000 (but I can't prove that)
value2: is either 2049, 1043, or 1045 (there may be others, Netwatched
was stopped for some reason when I wrote this up)
value3: appears to be of the same group of numbers as value2 but never
value4: was either 104, 1152, or 124. Those were the only values I saw.
With V4 to V4 systems its more like:
IP: src addr -> dest addr 1500 UDP Fragment
And its *always like that.
I don't have data on what happens between V4 and V3.2 systems.
Question: what do these numbers mean, what does Netwatch mean by
Fragment (and how does he know its a fragment?), and why does either
Netwatch see things differently between the two scenarios or why is
there a difference? Can it be related to the rsize/wsize default
values? Where are these values specified? I'm not specifying these
values in the mount command.
Comments? Suggestions?
Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std> | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Recycle. Just do it."romkey@ASYLUM.SF.CA.US (John Romkey) (03/17/91)
Date: 12 Mar 91 00:57:55 GMT
From: decwrl!ames.arc.nasa.gov!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!chinacat!uudell!Kepler.dell.com!mjhammel (Michael J. Hammel)
Organization: Dell Computer Corp.
I seem to be having a problem with V4 systems and UDP. It appears that
an NFS-based test between two V3.2 systems that I run shows up under
Netwatch as follows:
Are you actually having an NFS problem, or is the Netwatch output just not
being clear?
IP: src addr -> dest addr <value> UDP <value2> -> <value3> <value4>
value is the length of the IP packet. value2 is the UDP source port.
value 3 is the UDP destination port. value4 is the length of the UDP
packet (as I recall).
With V4 to V4 systems its more like:
IP: src addr -> dest addr 1500 UDP Fragment
And its *always like that.
Question: what do these numbers mean, what does Netwatch mean by
Fragment (and how does he know its a fragment?), and why does either
Netwatch see things differently between the two scenarios or why is
there a difference? Can it be related to the rsize/wsize default
values? Where are these values specified? I'm not specifying these
values in the mount command.
Fragment means the packet is fragmented at the IP layer. There's
information in the IP header that says "this packet has been
fragmented" as well as where it fits in the reassembled packet.
Netwatch won't tell you more because it's not sure what the UDP port
numbers are since the packet is fragmented. It could've picked them up
out of the first packet, but I didn't check on that when I wrote it.
I don't know enough details about NFS to relate this to particular
versions, but it does like to send large (8Kbyte) packets and fragment
them into pieces you can actually transmit over the ethernet (roughly
1500 bytes or less). That's what you're seeing in the second
situation. Someone else will have to answer the NFS-specific
questions.
- john romkey Epilogue Technology
USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141jclark@sdcc6.ucsd.edu (John Clark) (03/23/91)
In article <9103160909.AA01947@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
+Fragment means the packet is fragmented at the IP layer. There's
+information in the IP header that says "this packet has been
+fragmented" as well as where it fits in the reassembled packet.
With UDP and NFS based on it, is there a check sum on the
reassembled packet. It seems that there is an assumption that the
ethernet hardware CRC etc. is enough, but is that true.
--
John Clark
jclark@ucsd.eduromkey@ASYLUM.SF.CA.US (John Romkey) (03/24/91)
Date: 23 Mar 91 01:46:58 GMT From: decwrl!ucsd.edu!sdcc6!jclark (John Clark) Organization: University of California, San Diego References: <16241@uudell.dell.com>, <9103160909.AA01947@asylum.sf.ca.us> Sender: tcp-ip-relay@nic.ddn.mil With UDP and NFS based on it, is there a check sum on the reassembled packet. It seems that there is an assumption that the ethernet hardware CRC etc. is enough, but is that true. IP carries a mandatory checksum over its headers. UDP carries an optional checksum over its headers and data. The UDP checksum is verified after the packet is reassembled by IP and passed on to UDP. It can be set to 0 to indicate no sum was done. Certain NFS implementations, like Sun's, do not generate UDP checksums. Ethernet's CRC check is enough to validate the data *while it's on the ethernet wire*. It doesn't protect the packets while they're switched through routers, or copied into the network interface, or transmitted over a different type of network link, for instance a serial line. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (03/24/91)
In article <17725@sdcc6.ucsd.edu>, jclark@sdcc6.ucsd.edu (John Clark) writes: > > With UDP and NFS based on it, is there a check sum on the > reassembled packet. It seems that there is an assumption that the > ethernet hardware CRC etc. is enough, but is that true. Many workstation vendors ship with UDP checksums turned on by default. This provides an end-to-end checksum of the entire NFS/UDP/IP datagram after reassembly at the destination of any IP fragmentation. Some customers have strongly held opinions that the CPU cost of computing the checksum is worthwhile. On modern hardware, it's hard to disagree. A major vendor (not my employer, of course!) is said to still be shipping with UDP checksums off by default. It is said that a simple adb command can turn UDP checksums on in recent releases of their software. Vernon Schryver, vjs@sgi.com