Path: utzoo!utgpu!watserv1!watmath!att!news.cs.indiana.edu!samsung!cs.utexas.edu!sun-barr!newstop!eastapps!suncan!brian From: brian@ganglion.Canada.Sun.Com (Brian Onn) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <4234@eastapps.East.Sun.COM> Date: 10 Feb 91 00:13:51 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> Sender: news@East.Sun.COM Reply-To: Brian.Onn@Canada.Sun.Com Organization: Sun Microsystems of Canada Inc. Lines: 40 Tim Peiffer (the net guy) writes: |> In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: |> Well, I might not go *that* far. Ethernet has a checksum, and SLIP |> doesn't, so if you're, say, using UDP without checksums, Ethernet may be |> more reliable than SLIP.... |> |> This sounds like you are willing to compare apples to oranges. IP |> differs not at all whether it originates on a coaxial Ethernet, or a |> slow speed serial line. UDP without checksums is only mentioning that |> you are willing to disallow checksums at the transport level. This |> option exists under both Ethernet and SLIP connections. The network |> level (IP) still has a checksum that resides at byte 12. I believe |> that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum |> will be accomplished at byte 5. RFC1055 refers one back to the |> IP document for the content of the IP header. *sigh* . The net guy should read the RFC he mentions. The IP checksum is only for the IP header, and does not include the *data*. IP relies on the upper layer protocols (UDP, TCP) to provide checksumming of the data. What Guy is saying is that running UDP without checksums is more reliable on an Ethernet due to the fact that the Ethernet frame includes a checksum (CRC, actually) for all of the frame. A SLIP frame does not include a frame checksum, and this will allow bad data to be passed up the protocol stack. If the SLIP layer doesn't catch bad data (ie, a bad SLIP frame), and the IP layer also doesn't checksum the data, and higher up the UDP layer doesn't checksum the data, you've just received bad data. Brian. -- _____________________________________________________________________ Brian Onn. Inet : Brian.Onn@Canada.Sun.Com Sun Microsystems of Canada. Uucp : uunet!sun!suncan!brian Product Support Specialist. Voice : (416) 477-6745. ---------------------------------------------------------------------