home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / ibmpc / 7183 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  1.4 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!usenet.ins.cwru.edu!slc6!trier
  2. From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
  3. Newsgroups: comp.protocols.tcp-ip.ibmpc
  4. Subject: Re: fragmented packets with slip driver
  5. Date: 29 Dec 1992 21:54:21 GMT
  6. Organization: Case Western Reserve University, Cleveland OH (USA)
  7. Lines: 22
  8. Message-ID: <1hqhedINN986@usenet.INS.CWRU.Edu>
  9. References: <BzInEn.H40@csn.org>
  10. NNTP-Posting-Host: slc6.ins.cwru.edu
  11. Keywords: slip packets fragment
  12.  
  13. In article <BzInEn.H40@csn.org> ben@teal.csn.org (Ben Domenico) writes:
  14. >There seems to be something in the slip setup I use which chokes
  15. >the packets down to a maximum around 254 bytes.
  16.  
  17. The MTU setting to worry about is not on your end -- it's on your SLIP
  18. server.  Get that MTU bumped up to something larger like 576 bytes, and
  19. you won't have problems.
  20.  
  21. A better solution would be to pester the authors of your TCP products
  22. to at least support the TCP MSS option, since it would eliminate your
  23. headaches.  The "right" thing to do, of course, is to implement fragment
  24. reassembly, but until then, the TCP MSS option can help.
  25.  
  26. >Perhaps ka9q is able to deal with fragmented packets?!?!
  27.  
  28. Bingo.
  29.  
  30. -- 
  31. Stephen Trier                      "We want to offer you a price that you
  32. Network software type               just can't afford to take advantage of."
  33. Case Western Reserve University         - Sales blurb from HSC Software
  34. trier@ins.cwru.edu
  35.