home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / next / misc / 19541 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  5.2 KB
  1. Xref: sparky comp.sys.next.misc:19541 comp.sys.next.advocacy:2195
  2. Newsgroups: comp.sys.next.misc,comp.sys.next.advocacy
  3. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
  4. From: louie@sayshell.umd.edu (Louis A. Mamakos)
  5. Subject: New release of SLIP software
  6. Message-ID: <1992Sep13.021511.22878@ni.umd.edu>
  7. Followup-To: comp.sys.next.advocacy
  8. Sender: usenet@ni.umd.edu (USENET News System)
  9. Nntp-Posting-Host: sayshell.umd.edu
  10. Organization: University of Maryland, College Park
  11. Date: Sun, 13 Sep 1992 02:15:11 GMT
  12. Lines: 109
  13.  
  14.  
  15. I've left a new version of my SLIP software on SONATA.CC.PURDUE.EDU and
  16. CS.ORST.EDU.  Look for the files:
  17.  
  18. -rw-r--r--  1 louie       4462 Sep  4 22:27 SLIP_920904.README
  19. -rw-r--r--  1 louie        291 Sep  4 22:27 SLIP_920904.md5
  20. -rw-r--r--  1 louie     532480 Sep  4 22:27 SLIP_920904.tar
  21.  
  22. This version has been updated to work with NextStep Release 3.0.
  23. There were two prior releases, not widely announced which corresponded
  24. to NextStep 3.0 PR1 and 3.0 PR2.  
  25.  
  26. There are some minor bug fixes here and there.  The only real new
  27. "feature" is a traceback whenever a TCL error occurs.  This should make
  28. it much easier to debug TCL dialer scripts.
  29.  
  30. The 920904 version should work with Release 2.1, 2.2, 3.0 PR1, 3.0 PR2
  31. and 3.0.  Note that due to bugs in the serial driver in release 2.0,
  32. you probably shouldn't bother trying to run SLIP (or anything else
  33. that requires the power to the system to be turned on, for that
  34. matter).
  35.  
  36. The version sensitivity is almost exclusively due to a single bug in
  37. the NeXT Mach kernel that was reported in 2.1, 2.2, 3.0 PR1, and 3.0
  38. PR2.  For some reason unknown to me, the 3 line fix to
  39. netinet/tcp_output.c that I supplied has not been installed.  Because
  40. of this, the SLIP kernel driver has to reach into the code and patch
  41. it.  The location of the patch, of course, varies with every version
  42. of the kernel.  So you see, I have this (ever lengthing) table of
  43. patch locations which is becomine most tiresome to keep updating.
  44.  
  45. The only time this bugs comes home to roost is if you use an MTU on
  46. the SLIP interface less than 576 bytes, so most folks won't be
  47. affected.  Thus, if you see the warning message:
  48.  
  49. dialupip: Can't patch tcp_output() MSS option bug: unknown kernel version
  50. dialupip: Note that this is NOT a fatal error.  Don't panic.  See manual
  51. dialupip: for further details about this issue.
  52.  
  53. Don't worry about it.  If you like, you can call NeXT and ask them why
  54. bug reports: 15949, 16323, 16625, 25449    (3.0 PR1), 29905 (3.0 PR2)
  55. can't seem to be fixed or even given some disposition (like "go away,
  56. we can't be bothered", "fixed in next release" or "we don't understand
  57. your suggested fix").  
  58.  
  59. For those interested, the body of the actual bug report from 14 Aug
  60. 1991 is as follows.  The code noted is from the Berkeley networking
  61. code which had the bug in an earlier version (which NeXT apparently
  62. still uses).  I've been getting real good at reading disassembled
  63. code, a skill I had hope I would not have to develop.
  64.  
  65. ==============================================================================
  66.  
  67. When a TCP connection is opened, the TCP Maximum Segment Size option is
  68. not always sent.  The existing code in tcp_output.c only sends a MSS option
  69. if the MTU of the interface is larger than the default 536 byte MSS.  If 
  70. the MTU of the interface is smaller (such as 256 bytes for a SLIP interface
  71. using VJ TCP header compression), no MSS option is sent.  This causes the
  72. remote TCP to send "large" packets which are fragmented by the SLIP gatway,
  73. negating the usefulness of the TCP header compression.
  74.  
  75. You need to change this code in tcp_output.c
  76.  
  77.         opt = NULL;
  78.         if (flags & TH_SYN && (tp->t_flags & TF_NOOPT) == 0) {
  79.                 u_short mss;
  80.  
  81.                 mss = MIN(so->so_rcv.sb_hiwat / 2, tcp_mss(tp));
  82.                 if (mss > IP_MSS - sizeof(struct tcpiphdr)) {
  83.                         opt = tcp_initopt;
  84.                         optlen = sizeof (tcp_initopt);
  85.                         *(u_short *)(opt + 2) = htons(mss);
  86.                 }
  87.         }
  88.  
  89. to something like this:
  90.  
  91.         opt = NULL;
  92.         if (flags & TH_SYN && (tp->t_flags & TF_NOOPT) == 0) {
  93.                 u_short mss;
  94.  
  95.                 mss = MIN(so->so_rcv.sb_hiwat / 2, tcp_mss(tp));
  96.                 opt = tcp_initopt;
  97.                 optlen = sizeof (tcp_initopt);
  98.                 *(u_short *)(opt + 2) = htons(mss);
  99.         }
  100.  
  101. The added "overhead" of always sending an MSS option is minimal since
  102. its only sent in one segment and is only 4 bytes long.
  103.  
  104. ==============================================================================
  105.  
  106. Note the extent of the fix is to remove two lines (the `if' and the
  107. the closing brace) and to re-indent the body of the if statement
  108. removed.  I'm not sure what futher assistance I can be to NeXT in
  109. getting the problem resolved beyond giving them the actual source code
  110. changes.  Presumably good networking code is not required for "Mission
  111. Critical" applications, though I would have thought it would have been
  112. during the "Interpersonal Computing" marketing era.
  113.  
  114. At this point, I have given up relying on NeXT to fix the problem and
  115. just hope that it will go away if they decide to use a relatively
  116. modern version of the Berkeley networking code in some future release.
  117.  
  118. Sigh.  Please note Followup-To: line.
  119.  
  120. louie
  121.  
  122.  
  123.