Date: Fri, 9 Apr 93 04:30:16 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #93
To: tcp-group-digest
TCP-Group Digest Fri, 9 Apr 93 Volume 93 : Issue 93
Today's Topics:
advanced-packet list shut down
DOS 6.0 and stat cmd (2 msgs)
IBUFS in JNOS
Internetworking with TCP/IP - Volume II (2 msgs)
KA9Q bug - fragments
Thoughts on 108e
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 8 Apr 93 10:14 PDT
From: bruce@pixar.com (Bruce Perens)
Subject: advanced-packet list shut down
To: tcp-group@ucsd.edu
I have shut down the advanced-packet list due to a lack of interest on
the part of the subscribers. I wrote about half the postings, just trying
to get the subscribers stirred up. It didn't work. My apologies to Brian
and anyone else I pissed off by creating the list.
I'm going to direct my energy into writing a new protocol stack to
address some of the issues like making RSPF 2.2 work under TCP/IP.
I'll tell you more about that when I have something to show.
Bruce Perens KD6OTD
------------------------------
Date: Thu, 8 Apr 93 11:59:11 EDT
From: Mike Gallaher <mg@bds.bds.com>
Subject: DOS 6.0 and stat cmd
To: to.wa9yyf@ke9yq.ampr.org
I've seen the stat command produce garbage instead of the file list,
but in DOS 5.0 with JNOS 1.08 (all flavors). It only happens on
my 386DX40, not on my 286 running the same version of DOS.
I never tracked down why it happens, but it's not just DOS 6.0.
mg
------------------------------
Date: Fri, 9 Apr 93 00:52:44 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: DOS 6.0 and stat cmd
To: mg@bds.bds.com
Works fine here on DOS 6 on two different machines - Yes think this goes
back to the Borland stat problem. I have had reports that on some systems
(compatibles) the stat command flat out crashes the system. I have never
seen any problems on any clones that I use here.
------------------------------
Date: Fri, 9 Apr 93 00:48:08 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: IBUFS in JNOS
To: karn@qualcomm.com
Phil,
Regarding the code in YOUR iface.c file in the network function - you
call the dequeue function. It seems that interrupts are turned off and
on in this area more than they need be? Dequeue turns them off and on
and so does the calling function. In the WG7J code as of now the dequeue
function is not called. Instead the same action as deqeue is done right
in network - although it seems the interrupts are handled differently.
Kinda hard to follow. The network function is in config.c in WG7J.
Doug
------------------------------
Date: 08 Apr 1993 18:24:05 -0400 (EDT)
From: John Stewart <JSTEWART@umiami.IR.Miami.EDU>
Subject: Internetworking with TCP/IP - Volume II
To: tcp-group@ucsd.edu
Does anyone know if the jnos software shares any common heritage
with the tcp/ip code presented in Comer's Volume II (actually Comer and
Stevens)? This book seems well written and may offer a good entry point
for someone who wishes to develop an understanding of tcp/ip code in
general, jnos code in particular.
John, n4qi
jstewart@umiami.ir.miami.edu
------------------------------
Date: Thu, 08 Apr 93 19:31:14 -0400
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Internetworking with TCP/IP - Volume II
To: John Stewart <JSTEWART@ren.IR.Miami.EDU>
Assuming that that TCP protocol implementation in jnos is based on
Phil Karn's NOS code, then the only relationship might be that the
Comer book is based on Phil's code. I've not seen the Comer book, but
the NOS code was based on Phil's NET code which was based on Phil's
NET code for Z80 platforms some number of years ago. I belive this
predates the second volumes of Comer's book.
I recall doing some hacking on some of Phil's *really* early code,
getting it running on a small 68K single-board sort of platform.
That's been at least 5 years, I think.
louie
wa3ymh
------------------------------
Date: Wed, 7 Apr 93 15:47:04 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: KA9Q bug - fragments
To: tcp-group@ucsd.edu
This is a bug in all versions of KA9Q for about 2 years.
In iproute.c, there are two calls to q_pkt. The second one is missing
a free when sending the fragment fails. This results in the loss of
the mbuf. Since this usually only fails when memory is low, things go
from bad to worse.
if(q_pkt(iface,gateway,&ip,f_data,IP_CS_NEW) == -1){
--> free_p(bp);
ipFragFails++;
return -1;
}
Thanks to Tree Tech in Buffalo NY for the report.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Fri, 9 Apr 93 00:40:07 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Thoughts on 108e
To: nos-bbs@hydra.carleton.CA
First let me remind you all that 108e is not anything official just
my version numbering for 108df with Phil's mbuf/alloc stuff thrown it.
Well it crashed twice today. I was not at the helm either time so I
cannot say exactly what happenned. The log did not show anything
conclusive. It was strange though that the screen had crazy characters
on it - no meaningful text - cntrl/alt/del reset worked. Up until the
crash the system seemed to work normally.
Some quick observations on the code - Phil's malloc eliminated the 'mem eff'
code (or it never had it) that I believe G1EMM implemented. Instead Phils
uses a 'circular' define. I did not have this defined so I was using neither.
Remembering that I never had a stable system when NOT using 'mem eff' I
hard coded that one line addition into malloc. I will try it over night
with that change - and also the iproute fix that came down today.
It seemed that I did have more fragmented memory with the new code, which
is what I experienced with the wg7j and 'mem eff' off. I assume most people
are running that ON??
QUESTION - I have heard few comments on Phil's January and later releases.
Is anybody using this code? Is it running cleanly in hard enviroments?
I believe we have a little (hopefully not long) battle on our hands if
we really want to get the code to current KA9Q compliance. I would advise
those who need a stable enviroment to maintain data flow hold onto a current
version that works for them, until this is all ironed out.
As per Johan's request I will bundle my changes and put them at UCSD
in the morning. They can be copied on top of 108df. Use at your own
risk - or better yet do like I do here and maintain seperate complete
copies of the source code in different directories.
Doug
------------------------------
End of TCP-Group Digest V93 #93
******************************
******************************