Date: Wed, 13 Jan 93 04:30:12 PST
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 #13
To: tcp-group-digest
TCP-Group Digest Wed, 13 Jan 93 Volume 93 : Issue 13
Today's Topics:
Ack swatting
CPU ID test code
Cross Band Digi with JNOS 107b
Ethernet card selection advice needed
Jihad, Jihad (was Jehad, Jehad)
KISS and concatenated TCP ACK packets (4 msgs)
PMNOS - unzip
Routing for Australia.
Unwanted mail
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: Wed, 13 Jan 93 09:49:30 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Ack swatting
To: tcp-group@ucsd.edu
I've been trying to ack swatting with ka9q net, but it is hard and my
attempts have so far ended up either deadlocking core dumping going
berserk or all 3 simultaneously.
A timer sounds the proper technique.
Alan
------------------------------
Date: Tue, 12 Jan 93 14:33:58 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CPU ID test code
To: "Mike Bilow" <MIKEBW@ids.net>, "Phil Karn"@zfja-gate.fuw.edu.pl
reference: my msg <1207.JT@zfja-gate.fuw.edu.pl> of Mon, 11 Jan 93 15:16:26 PST
Hello,
I implemented the idea to modify .EXE, program was put as CPUCHK2.ZIP
(5kB) on zfja-gate (148.81.6.100) in guest login directory, can get it
using FTP or sending mail to listserv@zfja-gate (GET CPUCHK2.* in text)
It increases .EXE size about 120 bytes, but doesn't add anything
to code of executing program - the 120 bytes are used at startup
time only and can be used for memory allocation later.
Important for NOS which is already so big and needs more memory...
Of course 120 bytes for my CPU check code, can use the program to
add any other code, but it must be position-independent.
73's, JT
------------------------------
Date: 12 Jan 93 21:27:25 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: Cross Band Digi with JNOS 107b
To: <TCP-Group@UCSD.Edu>
The ax.25 cross band digi function doesn't seem to be working with
JNOS 107b. Can anyone else confirm or deny this? It was working
under JNOS 104. I've made sure that ax25 digi is on for each interface.
Thanks.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
------------------------------
Date: Tue, 12 Jan 1993 09:05:00 EST
From: "Mark Lucia (203)285-2915" <MLUCI@fuel.abb.com>
Subject: Ethernet card selection advice needed
To: "crompton@NADC.NAVY.MIL@SMTP@WA" <tcp-group-relay@ucsd.edu>
I've been playing with one for about a month now, and done some
<not so scientific> tests comparing it to 3c503, depca turbo, and
wd8003 cards. I've tried it with FTP software, DEC Pathworks,
KEALink TCP, and Smarterm TCP, Windose for Workgroups' NetBEUI.
It seems to work well, with one small exception. The first packet
true it takes forever, ie ping something and invariably the first
resonse is in the 600ms range, with all of the following in the
more normal range. I've not investigated this yet 'cause it
hasn't bothered me enough. The other thing that I don't like is
the config routine. In order to config it, or check it's config
(all extrenal software driven) you cannot have any network stuff
loaded, ie boot from a 'clean' config.sys. Just an anoiance.
It seems to perform well, in the same ballpark as a depca
(without the L O N G boot time).
Mark wb1fcg.ampr.org
mluci@fuel.abb.com
------------------------------
Date: Tue, 12 Jan 93 22:55:13 CST
From: jrc@brainiac.mn.org (Jeffrey Comstock)
Subject: Jihad, Jihad (was Jehad, Jehad)
To: tcp-group@ucsd.edu
>Windows is somewhat popular as well. "Cant we all just get along" (Rodney King)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nope.
LET THE QUARTERLY TCP-GROUP OS FLAME/RELIGION WAR BEGIN !!!!!!!
--
Jeffrey R. Comstock
HOME jrc@brainiac.mn.org
CW -. .-. ----- -..
------------------------------
Date: Tue, 12 Jan 1993 13:50:46 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: KISS and concatenated TCP ACK packets
To: tcp-group@ucsd.edu
I am operating a PK-88 and WAMPES on a congested 1200-baud channel. I
have noticed a problem concerning the way my system transmits TCP ACK
packets.
The TNC often queues up several several TCP ACK packets before it can
send any, and when it finally gets the channel, it sends them all. Often
it sends three TCP ACK packets together. My reading of the RFCs
indicates that of those three ACK packets, only the last one is
necessary, since a TCP ACK packet acknowledges all packets that have
sequence numbers lower than its own.
Now, I don't see how I can tell the TNC, via KISS, to "obsolete" the
previous ACK packets if they haven't been transmitted. Thus, my
transmission is three times as long as necessary, and I contribute to
channel congestion.
I also don't see any way for me to implement the "Prioritized ACK" scheme
for TCP ACK packets, since KISS provides me no way to flag that a packet
is an ACK and has priority.
I've only been running TCP/IP for a few weeks, and thus my perceptions
could easily be wrong. Would you more experienced folks please comment
on this?
Many Thanks
Bruce Perens
------------------------------
Date: Tue, 12 Jan 1993 21:01:51 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: KISS and concatenated TCP ACK packets
To: tcp-group@ucsd.edu
Bruce,
I noticed this problem some time ago and brought it up in this
group. Basically, there's not much you can do if you have an
external TNC. There's lack of communications between the "layers",
since they're on different, loosely-coupled hardware.
If you had a PC card TNC and a driver, I suppose NOS could send
some kind of flush message to the AX.25 queue to "recall"
no-longer-necessary TCP messages. Or more likely, it would
never send a message to the L2 send queue unless it had, say,
already keyed the transmitter (which leaves enough time for
NOS to interrupt and forward the packet to the card). I suppose
this is another reason to not use TNCs.
fred k1io
------------------------------
Date: Tue, 12 Jan 1993 18:16:28 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: KISS and concatenated TCP ACK packets
To: goldstein@carafe.enet.dec.com
A first step would then be for us to start adding the capacity to our
software to communicate some more information to the AX.25 driver.
The information necessary is:
1. A flag that indicates that a packet is to be handled as
a "prioritized ACK".
2. A sequence number.
3. A command to the driver to abort transmission of a packet,
given the sequence number of the packet. This would be ignored
once transmission of the packet was started.
I'm not talking about adding this to KISS, but it would be nice if the
information were communicated to device drivers, so that it could be
implemented for devices like the DRSI.
Bruce Perens
------------------------------
Date: Wed, 13 Jan 1993 2:24:33 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: KISS and concatenated TCP ACK packets
To: bruce@pixar.com, tcp-group@ucsd.edu
I would STRONGLY discourage anyone from implementing the ACKPRIOR scheme.
While it looks logical on paper, listening to a channel where it is being
run will immediately indicate a problem: there is no space for other users
to get in when two stations are sending data to each other using ACKPRIOR.
MFJ TNCs default to ACKPRIOR enabled, and they are the bane of packet.
The proper solution to sending three TCP ACKs when only the last is
necessary is to run a NOS timer of about 5 seconds before sending an ACK.
This is how the netrom code implements ACKs. (At least, this is the way
it does now since I fixed a bug in the routine that does it.) In other
words, have an incoming TCP frame start a timer (if none is already in
progress) that will cause an ACK to be sent. If more TCP frames arrive
between the starting and expiring of the timer, the ACK will be sent for
them also, so that the ACK is current as of the expiration of the timer.
This may have undesirable side effects, but it swould be a lot better than
trying to quash an enqueued frame in the TNC.
-- Mike
------------------------------
Date: Tue, 12 Jan 1993 17:23:42 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: PMNOS - unzip
To: kz1f@legent.com, tcp-group@ucsd.edu
I got Walt's PM NOS v1.0d posted at ChowdaNet the other day after the
mishap with out virus scanner not liking Walt's OS/2 ZIP program.
Files are:
PMNOS1DX.ZIP -- executable
PMNOS1DS.ZIP -- source
UNZ50X32.EXE -- GNU unzip utility
ZIP19X32.ZIP -- GNU zip utility
ChowdaNet is now itself runing PKZIP/PKUNZIP v2.04c for DOS, which will
support deflation.
ChowdaNet files may be download by calling (401)331-0334 (9600 bps V.32)
or (401)331-5587 (14400 bps V.32bis). Files are also available by
Fidonet FReq to 1:323/120.
-- Mike Bilow, <mikebw@ids.net> (Internet)
1:323/120.1 ChowdaNet BBS (Fido)
------------------------------
Date: Wed, 13 Jan 93 10:41:22 +1100
From: "Carl Makin" <makinc@hhcs.gov.au>
Subject: Routing for Australia.
To: tcp-group@ucsd.edu
Hi,
Is it possible to have a router defined to handle a subnet of network
44?
The problem for people outside of the US is that all frames from the Internet
to Amprnet go via mirrorshades at ucsd. This means that the 512Kb link
between Australia and the US is unneccessarily carying frames over and then
back (via encap).
I was wondering if it was possible for us to have all 44.136 frames routed
to a machine like minnie. (This is ignoring the problem of how
do we get the router information setup in the first place. :-( )
Carl.
------------------------------
Date: Tue, 12 Jan 93 8:24:22 EST
From: John Ackermann AG9V <John.Ackermann@DaytonOH.NCR.COM>
Subject: Unwanted mail
To: "Andrzej K. Brandt" <andy@mimuw.edu.pl>
You (Andrzej K. Brandt) write:
>
> Milton Miller wrote:
>
> >PS: In the AMPR community, not everyone will know your name but will know
> >your call by seeing you on the air, so I like to see call@call.ampr.org
> >be received by someone.
>
> Probably you are right, but mail to unknown users should be rejected, so the
> sender would know that address he has is wrong. Currently such mail may simply
> wanish without any trace.
That poses a problem for NOS systems (like mine) that are acting as full
service BBS's. I don't want to have to set up an authorization for each
of the 80+ users who login to the system, and the users don't want to
have to register.
I think the best answer is to have aliases as necessary, and spend a few
minutes every now and then with a dir /spool/mail/*.txt to see what's
lurking out there.
> And I really don't like mail adressed as call@call.ampr.org... (But that's my
> personal opinion only)
Some folks object to that format as "impersonal", but remember that it's
the only address format that will work reliably if you're going into/out
of the PBBS network. Particularly for folks whose first names are
longer than six characters! :-}
John AG9V
------------------------------
End of TCP-Group Digest V93 #13
******************************
******************************