nraoaoc@nmt.edu (NRAO Array Operations Center) (02/07/91)
Where can I get some good documentation on SLIP? I have RFC1055, but it does
not state which of the actual protocols it uses (presumably because it can use
more than one). Now, I thought it used UDP in most implementations, and I'm
trying to convince someone that he's not getting much, if any, error correction
on his SLIP connections, but he wants actual written proof. He thinks it's
using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links.
I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is
there such a beast?
Our particular implementation is Rayan Zachariassen's streams SLIP for Suns.
The closest thing I can find in the source code is that it includes the TCP
header definition from /usr/include/netinet/tcp.h if SLIP_FASTECHO is defined
(to give rlogin/telnet better response). But what about ftp? Does that use udp
instead, or does SLIP just use raw IP in this case? And what implications does
that have for error correction?
While enough personal testimonials would help, more formal-looking documents
would be better :-).
Thank you all.
--
Ruth Milner
Systems Manager NRAO/VLA Socorro NM
rmilner@zia.aoc.nrao.edujnford@handlebar.weeg.uiowa.edu (Jay Ford) (02/08/91)
In article <1991Feb6.172144.12605@nmt.edu>, nraoaoc@nmt.edu writes: |> Where can I get some good documentation on SLIP? I have RFC1055, but it does |> not state which of the actual protocols it uses (presumably because it can use |> more than one). Now, I thought it used UDP in most implementations, and I'm |> trying to convince someone that he's not getting much, if any, error correction |> on his SLIP connections, but he wants actual written proof. He thinks it's |> using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links. |> I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is |> there such a beast? SLIP does not "use" any transport or application protocols. SLIP simply provides a way to transmit IP traffic over a serial line. In effect, it gives you a link layer over a serial line functionally similar to that provided by Ethernet for use on coax (or fiber, or twisted pair, or microwave...). Once you have a working link layer to run IP over, you can run any transport (UDP, TCP, etc) over IP on that link. The upper layers don't care what the medium is. That's the point of a layered approach to networking! Applications use whatever transport protocol is appropriate, independent of the link layer. TELNET, FTP, SMTP and others use TCP; NFS, DNS, and others use UDP. Basically, the only difference you should see between an Ethernet Internet connection and a SLIP Internet connection is the speed and throughput. ------------------------------------------------------------------------ Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242 jnford@handlebar.weeg.uiowa.edu, 319-335-5555
guy@auspex.auspex.com (Guy Harris) (02/09/91)
>Basically, the only difference you should see between an Ethernet Internet >connection and a SLIP Internet connection is the speed and throughput. 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....
henry@zoo.toronto.edu (Henry Spencer) (02/09/91)
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.... Surely nobody would be so stupid as to use UDP without checksums. :-) :-) (For those who don't get the point of the ":-) :-)", NFS uses UDP without checksums. And people wonder why NFS is so unreliable...) -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
amanda@visix.com (Amanda Walker) (02/09/91)
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.... On the other hand, if you're running NFS (the only common use I know of for UDP without checksums) over SLIP, you may have worse problems :). Of course, I'm firmly in the end-to-end-reliability-check camp, and thus I think that running UDP without checksums is just a way of asking for trouble. I still fail to understand why it was done in NFS. Sigh. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- If you know what you're doing, how long it will take, or how much it will cost, it isn't research.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/09/91)
In article <1991Feb8.203703.25654@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: > > (For those who don't get the point of the ":-) :-)", NFS uses UDP without > checksums. And people wonder why NFS is so unreliable...) Everyone! Please stop repeating this complaint. It doesn't take much perception or knowledge to find many real and inconvenient differences between NFS and other UNIX file systems. If complaining about NFS brings you joy, then complain about open-unlink, caching, security, ownership & UID's, dates, and idempotency holes. If you don't like using NFS, then use something else like AFS or "the emerging standard, RFS" (AT&T press release, 1986). Anyone with an NFS implementation that does not use UDP checksums should either fix or enjoy it. The NFS on common and current workstations does use UDP checksums by default. Ours do. I'm told that Sun's does as of the NFS 3.2 source release. I personally think the choice made in 1984 (85?) was correct for 1982 thru 1988. The fact that for years (!) NFS has used UDP with checksums turned on makes our disagreement about the correctness of the original decision almost as interesting today as the old arguments whether "HLL's will replace assembly language". Vernon Schryver, vjs@sgi.com
peiffer@umn-cs.cs.umn.edu (Tim Peiffer (the net guy)) (02/09/91)
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. Tim Peiffer ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota MPLS MN 55455 ** Internet Protocol A summary of the contents of the internet header follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | | Identification |Flags| Fragment Offset | | Time to Live | Protocol | Header Checksum | | Source Address | | Destination Address | | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
barmar@think.com (Barry Margolin) (02/09/91)
In article <84702@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >> (For those who don't get the point of the ":-) :-)", NFS uses UDP without >> checksums. And people wonder why NFS is so unreliable...) >Everyone! Please stop repeating this complaint. I agree that the complaint is wrong, but not for the same reason you do. It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in general (in its default configuration). In fact, SunOS doesn't provide a way for a UDP-based application protocol to control whether it uses checksums -- it's a single, system-wide parameter. Even worse, this one parameter controls both whether checksums are generated during sending and whether they are checked when receiving. >Anyone with an NFS implementation that does not use UDP checksums should >either fix or enjoy it. The NFS on common and current workstations does >use UDP checksums by default. I think Suns would count as "common and current workstations", and by default SunOS doesn't enable UDP checksums. In fact, until SunOS 4.1.1, enabling UDP checksums required patching the kernel; in the latest release they've finally moved it into a configuration file used during the kernel build process. > Ours do. I'm told that Sun's does as >of the NFS 3.2 source release. Since the socket library doesn't provide a way to enable or disable UDP checksums (I could be wrong -- I simply searched for "checksum" in the setsockopt man page), I don't see how the NFS source release can do this. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
brian@ganglion.Canada.Sun.Com (Brian Onn) (02/10/91)
Tim Peiffer (the net guy) <peiffer@umn-cs.cs.umn.edu> 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. ---------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (02/11/91)
>It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in >general (in its default configuration). In fact, SunOS doesn't provide a >way for a UDP-based application protocol to control whether it uses >checksums -- it's a single, system-wide parameter. Even worse, this one >parameter controls both whether checksums are generated during sending and >whether they are checked when receiving. The latter two statements are true of BSD, as it comes from Berkeley, from 4.3BSD to 4.3-reno. Whether UDP checksumming is enabled or not in BSD as it comes from Berkeley is, by default, under the control of the COMPAT_42 #define; that doesn't seem to be on in most of the configuration files, so I don't think the first statement is true of BSD, although it is true of SunOS (SunOS != BSD). >> Ours do. I'm told that Sun's does as >>of the NFS 3.2 source release. > >Since the socket library doesn't provide a way to enable or disable UDP >checksums (I could be wrong -- I simply searched for "checksum" in the >setsockopt man page), I don't see how the NFS source release can do this. It can if the default configuration of the NFS source release turns the system-wide parameter on; he didn't say the NFS 3.2 source release lets you arbitrary control whether UDP checksumming is done, he just said that he was told that it *DID* UDP checksumming as of the NFS 3.2 source release. The NFS 4.0 source release is derived from 4.3BSD, and behaves like 4.3BSD in this regard - "udpcksum" is turned on only if COMPAT_42 is defined, and it's not defined in the GENERIC configuration file.
guy@auspex.auspex.com (Guy Harris) (02/11/91)
>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. Yes, I know IP doesn't differ, but how reliably the link level checks the link-level packets in which IP packets are wrapped *DOES* differ - Ethernet has a checksum, and SLIP doesn't, as I said. >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. If you disable UDP checksumming, the transmission of your UDP datagrams will be checked by checksum when the transmission goes over Ethernet, but not when it goes over SLIP, so if the transmission includes a SLIP connection, that connection won't have any checksumming other than the IP checksum you mention, which does *NOT* checksum the entire packet, just the IP header. If the transmission includes only Ethernet connections, it will be checksummed on each one of those hops. (It won't necessarily be checksummed as it's moved internally to any of the intermediate machines, of course....) >The network level (IP) still has a checksum that resides at byte 12. Which only checksums IP headers; it doesn't check the entire datagram. >I believe that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum >will be accomplished at byte 5. He also states that: This compression is specific to TCP/IP datagrams./2/ The author investigated compressing UDP/IP datagrams but found that they were too infrequent to be worth the bother and either there was insufficient datagram-to-datagram coherence for good compression (e.g., name server queries) or the higher level protocol headers overwhelmed the cost of the UDP/IP header (e.g., Sun's RPC/NFS). so it's irrelevant to the discussion of UDP anyway.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/12/91)
In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes: > In article <84702@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > >> (For those who don't get the point of the ":-) :-)", NFS uses UDP without > >> checksums. And people wonder why NFS is so unreliable...) > >Everyone! Please stop repeating this complaint. > > I agree that the complaint is wrong, but not for the same reason you do. > It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in > general (in its default configuration). In fact, SunOS doesn't provide a > way for a UDP-based application protocol to control whether it uses > checksums -- it's a single, system-wide parameter. Even worse, this one > parameter controls both whether checksums are generated during sending and > whether they are checked when receiving. Isn't this the right way to do it? With a "single, system-wide parameter" controlling whether UDP is checksummed or not? We argued among ourselves years ago whether the NFS switch should be the same as the global UDP switch. Ultimately, we decided that those who want no UDP checksums on NFS would not want them on anything else, including RPC, and conversely. Some might like a per-link switch, turning it on for SLIP lines and off for Ethernet and FDDI. (Having seen many checksums errors in FDDI frames with good CRC and E-bit, I'm not one.) Unfortunately, that idea does not work with routers; you'd need a UDP-cksum-is-a-good-idea-discovery protocol. The source from BSD has UDP checksums turned on by default. I haven't looked at the Reno NFS, but would be surprised if it's off there. > >Anyone with an NFS implementation that does not use UDP checksums should > >either fix or enjoy it. The NFS on common and current workstations does > >use UDP checksums by default. > > I think Suns would count as "common and current workstations", and by > default SunOS doesn't enable UDP checksums. In fact, until SunOS 4.1.1, > enabling UDP checksums required patching the kernel; in the latest release > they've finally moved it into a configuration file used during the kernel > build process. I finally used the source, and found I'm wrong about NFS3.2, which still set the checksum=0. In the NFS4.0 reference code, they follow the 4.3BSD convention of obeying "udpcksum". Poking around with `adb /vmunix` on a vanilla Sun that says "SunOS Release 4.1-GFX-Rev.1 (GFXRev1)" finds the horrifying fact that udp_cksum=0. Thus, Sun appears to be disabling all UDP checksums, not just NFS. I hope someone from Sun will dispute this, since I'd hate to have to tell everyone to sell their solar hardware and buy flowers.*** > > Ours do. I'm told that Sun's does as > >of the NFS 3.2 source release. > > Since the socket library doesn't provide a way to enable or disable UDP > checksums (I could be wrong -- I simply searched for "checksum" in the > setsockopt man page), I don't see how the NFS source release can do this. The NFS 3.2 source I meant was the kernel code received by NFS vendors who pay maintenance or royalties to Sun. It is in lib/libc/rpc/kdup_fastsend.c Vernon Schryver, vjs@sgi.com *** Silicon Graphics has called our products "IRIS" for about as long as other machines have had solar labels. That I feel compelled to append this says a lot about the validity of my claim about "common and current workstations." Oh, well.
barmar@think.com (Barry Margolin) (02/12/91)
In article <84878@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes: >> Even worse, this one >> parameter controls both whether checksums are generated during sending and >> whether they are checked when receiving. >Isn't this the right way to do it? With a "single, system-wide parameter" >controlling whether UDP is checksummed or not? From p.78 of RFC1122: An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on. If a UDP datagram is received with a checksum that is non-zero and invalid, UDP MUST silently discard the datagram. 4.2BSD-based UDP implementations violate both these requirements. First, it is supposed to be the application that decides whether it wants checksumming; in BSD, either all applications get it or none do. Second, it is not permitted to disable checking of received packets. > We argued among ourselves >years ago whether the NFS switch should be the same as the global UDP >switch. I wasn't only complaining about the fact that it affects all applications. I was complaining about the fact that you can't disable generation of checksums but still enable checking of checksums. Thus, even though my client does checksumming correctly, errors will still get through if the server has them disabled. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/13/91)
In article <1991Feb11.233102.24222@Think.COM>, barmar@think.com (Barry Margolin) writes: > > From p.78 of RFC1122: > > An application MAY optionally be able to control whether a UDP checksum > will be generated, but it MUST default to checksumming on. > > If a UDP datagram is received with a checksum that is non-zero and > invalid, UDP MUST silently discard the datagram. > > 4.2BSD-based UDP implementations violate both these requirements. First, > it is supposed to be the application that decides whether it wants > checksumming; in BSD, either all applications get it or none do. Second, > it is not permitted to disable checking of received packets. The important word in the first paragraph is "MAY". 1122 does not require that an application be able to disable UDP checksumming. 4.3BSD does not have such a switch, and does not violate 1122 by not having it. As long as you don't break it by changing udpcksum, 4.3BSD does not violate the second paragraph. The fact that 4.3BSD has additional characteristics cannot rationally be considered a violation of the standard. If the characteristic of being able to change to non-conforming behavior is sufficient to be non-standard, then only ROM based systems can be standard, since there are always bozos--err--valued customers who can, will, and do change things in ways you and I consider obviously stupid and non-conforming. Does the fact that many people installed their own implementations of TCP/IP (often BSD derived) on popular workstations by itself make those systems non-1122 compliant even when running the vendor supplied system? If the answer to that question were yes, then 1122 and 1123 would be uninteresting to workstation vendors and our customers. Please keep standards carping rational. It appears that some common workstations (not my employer's) violate the above quoted part of 1122. Their "feet should be held to the fire". You are putting out the flame when you lump 4.3BSD checksumming behavior with theirs. (I'm assuming you mean 4.3BSD base UDP implementations, which follow the rules you criticize, not 4.2 BSD.) Vernon Schryver, vjs@sgi.com
barmar@think.com (Barry Margolin) (02/13/91)
In article <85079@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >> 4.2BSD-based UDP implementations violate both these requirements. >(I'm assuming you mean 4.3BSD base UDP implementations, which follow the >rules you criticize, not 4.2 BSD.) No, I meant 4.2BSD, since that is the release whose default value of udpcksum is wrong. Since the latest release of SunOS has this default wrong, I assumed it is 4.2-based (but perhaps they changed the default in the process of porting 4.3 TCP/IP, due to another of their misguided ideas about backward-compatibility (the same misguidedness that causes them to continue to default the broadcast address wrong)). I'm not sure what the latest Ultrix does, but I think 3.5 had the wrong default. These are the only BSD-based systems I have access to (we've got an SGI box, but it won't let me login because it doesn't mount my home directory (I've never before used a Unix system that didn't say something like "can't access home directory, using /"). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
guy@auspex.auspex.com (Guy Harris) (02/14/91)
>Since the latest release of SunOS has this default wrong, I assumed it >is 4.2-based (but perhaps they changed the default in the process of >porting 4.3 TCP/IP, They did change the default; SunOS 4.0's networking is somewhere between 4.3BSD and 4.3-tahoe based, and 4.1's networking is closer to tahoe.
lars@spectrum.CMC.COM (Lars Poulsen) (02/14/91)
In article <1991Feb6.172144.12605@nmt.edu> Ruth Milner <nraoaoc@nmt.edu> (NRAO Array Operations Center) writes: >Where can I get some good documentation on SLIP? I have RFC1055, but it does >not state which of the actual protocols it uses (presumably because it can use >more than one). Now, I thought it used UDP in most implementations, and I'm >trying to convince someone that he's not getting much, if any, error correction >on his SLIP connections, but he wants actual written proof. He thinks it's >using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links. >I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is >there such a beast? SLIP sits *UNDER* IP, and will carry any and all IP traffic that the router sends to the SLIP interface. The user executes the FTP client program. The FTP specification (RFC-959) will tell you that FTP uses two simultaneous TCP connections to do the work. It is possible to use a UDP based protocol to transfer files. Two examples of UDP based file transfer protocols are TFTP (RFC-783) and NFS. Be aware, however, that the error detection capabilites of SLIP are somewhat weaker than those of Ethernet (or HDLC). -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM