Date: Wed, 7 Apr 93 04:30:13 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 #91
To: tcp-group-digest
TCP-Group Digest Wed, 7 Apr 93 Volume 93 : Issue 91
Today's Topics:
Problems with packet on a SUN (2 msgs)
Say it ain't so...
Utah Backbone/Network Services
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: Tue, 6 Apr 1993 18:18:16 -0400 (EDT)
From: jbj@USDesign.COM (Jeff Johnson)
Subject: Problems with packet on a SUN
To: tcp-group@ucsd.edu
Greetings --
I've been watching a TCP/IP problem and I'm not quite sure
what is wrong. I have a sun ELC running SUNOS 4.1.3 with the
ax25ip driver from ucsd.edu using a PK232. I have been trying to
ftp a file from another node without success. After watching the
packets using tcpdump-2.2.1, I think I understand what *IS* happening.
I thought that some of you might be able to explain what *SHOULD*
be happening.
The configuration is a little complicated.
A(sun ELC)
^
| 145.55, 1200b
v
B(NOS) <-145.55, 1200b-> D(NOS)
^
| 145.55, 1200b
v
C(NOS)
My machine A can hear (ie has arp entries) all the other machines.
Machines B and D are near by, C is about 30 miles away.
Since I can hear C directly, machine A routes directly to C.
Machine C has a route to my subnet that goes to machine B.
Consequently, I *believe* I have an asymmetric path for packets:
A -> C -> B -> A
I am able to initiate ftp transfers and do telnet connections, even
though the routes are non-optimal.
I am seeing a lot of fragmentation, however, when I initiate an ftp
transfer from C to A. Here are the maximum segment and window sizes
as best as I can tell:
MSS WINDOW
----------------------
A 960 24768
B 196 754
C 216 1560
I see 2 fragments, one of 196 bytes, the second of 20 bytes, confirming
that the return path is C->B->A and that the MSS is as described. I am
able to transfer 1 to 8 K succesfully from machine C to machine A before
the transfer hangs.
The transfers hangs soon after machine B starts ARP'ing for machine A.
Machine A does not ARP reply. Other simultaneous connections from A
to B or C are also hung.
Clearly, there is a *LOT* of room for tuning here :-). I am addressing
these issues, but any suggestions are gratefully received. I also
have the following questions:
1) Should machine B ARP for machine A in the middle of an ftp transfer?
I would have expected that the ARP cache would not timeout for an
active connection; this may be naive.
2) If machine A *CAN* ARP for machine B in the middle of an active
connection, why doesn't the AX25ip driver respond? I suspect there
may be a software problem there. BTW there is a problem using ax25ip
in promiscuous mode. It is possible to panic due to a NULL pointer
in ax_btom. The "quick" but possibly incorrect fix is to check for
a NULL pointer near the end of ax_btom:
cp += count;
len -= count;
mp = &m->m_next;
}
! if(ax->ah_pid== AX25PID_ARP && top != NULL) {
top->m_off += sizeof(ifp); /* XXX ax_ax2etherarp() weak */
ax_ax2etherarp(top);
top->m_off -= sizeof(ifp);
}
return top;
I will post a more complete fix as soon as I can figger out what is happening.
3) Many of the parameters, including timeouts during connection and MSS,
on a virgin SUN TCP implementation are not appropriate for 1200b packet.
Any suggestions about what to change and what to watch out for are appreciated.
73 de Jeff N3NPQ
jbj@USDesign.COM
------------------------------
Date: Wed, 7 Apr 93 0:04:20 PDT
From: Bill Healy <healy@moriah.ee.unr.edu>
Subject: Problems with packet on a SUN
To: tcp-group@ucsd.edu (tcp-group)
>
> Greetings --
>
> I've been watching a TCP/IP problem and I'm not quite sure
> what is wrong. I have a sun ELC running SUNOS 4.1.3 with the
> ax25ip driver from ucsd.edu using a PK232. I have been trying to
> ftp a file from another node without success. After watching the
> packets using tcpdump-2.2.1, I think I understand what *IS* happening.
> I thought that some of you might be able to explain what *SHOULD*
> be happening.
>
> The configuration is a little complicated.
>
> A(sun ELC)
> ^
> | 145.55, 1200b
> v
> B(NOS) <-145.55, 1200b-> D(NOS)
> ^
> | 145.55, 1200b
> v
> C(NOS)
Well there's your problem, you are operating on a frequency reserved for
space operations, shuttle and MIR! :-)
Bill
------------------------------
Date: Tue, 6 Apr 93 17:11:43 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Say it ain't so...
To: mg@bds.bds.com, tcp-group@ucsd.edu
I added the ibuf stuff some years ago in an attempt to reduce NOS's
interrupt latencies. Since malloc and free can get called either in a
task or at interrupt time, I had to disable interrupts in order to
protect the heap from corruption, and when these functions execute for
an appreciable time they can delay interrupts.
But it all just got too clumsy. Interrupt buffers were of a single,
fixed size, and there were only so many available. If you wanted more,
you had to take them away from the regular heap. If you wanted a
bigger one in an interrupt handler, you had to make them all bigger
and waste the extra space when you only wanted a small one.
Also, developments like faster CPUs and the 16550A FIFO buffered UART
lessened the overall limits on interrupt latency in NOS. And there
were other contributors to interrupt latency that I couldn't do anything
about (like certain DOS calls).
I also discovered, through some "stopwatch" testing, that the typical
execution times for free() (the slower of the two) were much less than
I had expected. And there were probably some other things I have since
forgotten that finally made me decide to rip them all out.
So I got rid of the ibuf stuff from my own code. It has apparently
lingered in other versions, however.
Phil
------------------------------
Date: Wed, 7 Apr 1993 10:10:35 +1000
From: makinc@hhcs.gov.au
Subject: Utah Backbone/Network Services
To: tcp-group@ucsd.edu
Marvin wrote;
> Lyndon Nerenburg wrote:
>> software. Gigabit networks are about as useful as 1200 bps networks
>> if there are no applications to layer on top of them."
> Agreed, but no applications are going to be written until a high-speed
> network is in place.
You have to have a reason to build the high speed network in the first
place. It's fine for the techies to want to build a whizz bang network
just for the fun of it but unless you're blessed with having a couple of
millionaire techies around it takes user capital to buy the bits.
>Carl Makin wrote:
>> "eh? Without applications, at *any* speed, packet radio is
>> only a toy. Asignificant part of what has made packet radio popular is
..
..
>> Applications have to be developed *at the same time* as the network they
>> will run on!"
> Carl, this is a good point. Now, I'm trying to push some high-speed
> hardware, guys are looking into the protocols, who's writing applications?
> I see nobody. (If I'm incorrect, flame away) Why? Nothing to run them on.
Nope. I don't agree with that. There are better reasons for the limited
number of applications available for packet. The vast majority of users
are, if not computer illiterate, then "unsophisticated" in the full
capabilities of the equipment they are running. The equipment is capable
of considerably more than the vast majority put it to but they have either
been conditioned to believe that what they have is all packet is, or that
the rest is for the techies.
> Sure not going to happen as long as we're stuck with the 1200 baud AX.25
> boondoggle.
I ran TCP/IP over 1 digipeater at 1200 baud and transferred megabytes of
information. I had interactive sessions and mail running and we had a
small IP routing network running. 1200 baud isn't too slow for serious
work. It's just a little tedious. :-)
> Case in point. Why do all the BBS's have to forward everything to every
> other BBS? Why not just propogate pointers the way Gopher does? It's
> because the current network (sic) can't do it, that's why.
Because forwarding to every BBS is more efficient and practical than a
worldwide distributed message database. The network load would be
frightening if there were a million users trying to access messages across
a distributed network. Even the internet couldn't cope. At the moment the
BBS network is handling a million users worldwide and doing it via
300/1200/4800/9600 and some higher speed links, but mainly 1200 baud links.
Now I don't think the current BBS system is perfect, but it does provide a
service that is in high demand worldwide.
Along with building our higher speed networks we should be looking at
providing services to replace the outdated services currently operational
such as the BBS network, DXCluster(ugh) ROSE and netrom nodes and such.
Carl.
(Soapbox off)
--
Carl Makin (VK1KCM) Systems Programmer
Internet: makinc@hhcs.gov.au
Amprnet: vk1kcm@vk1kcm.act.aus.oc
Work Phone: +61 6 289-9443
------------------------------
End of TCP-Group Digest V93 #91
******************************
******************************