Date: Fri, 21 Jan 94 04:30:08 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 V94 #17
To: tcp-group-digest
TCP-Group Digest Fri, 21 Jan 94 Volume 94 : Issue 17
Today's Topics:
TCP-Group Digest V94 #16
TCP MSS and TCP WIN settings (3 msgs)
TNOS Missing Function - NOT (2 msgs)
Wampes loopback (3 msgs)
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: Fri, 21 Jan 94 09:50:38 GMT
From: A.D.S.Benham@bnr.co.uk
Subject: TCP-Group Digest V94 #16
To: TCP-Group@UCSD.EDU
> ------------------------------
>
> Date: Wed, 19 Jan 94 16:46:28 CST
> From: Jack Snodgrass <kf5mg@kf5mg.ampr.org>
> Subject: TCP MSS and TCP WIN settings
> To: tcp-group mailling list <tcp-group@ucsd.edu>
>
> Is there any way to assign a TCP WIN and TCP MSS setting per port? 9600b ports
> can use larger Window's and Packets than 1200b ports. I'm sure that it's been
> asked before but now that I've got a 9600b port going, I need to know what to
> do to get the most out of the system. Thanks.
>
> 73's de Jack - kf5mg
> Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
> AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
> Dialup - kf5mg@tcet.unt.edu - work (looking for)
I put the window mod into my JNOS sources last year. I'll post the deltas next
week.
The settings are set with the "ifconfig <port>" subcommands. Setting the window
is slightly more complicated than it might at first appear, because when one
initiates a session on port <n> the reverse path traffic might arrive on port <m>.
I therefore use the "tcp window" for the SYN frame, and then set the window on
all other outgoing frames for that session according to the value set for the
window on the port on which the replies are received.
Don't worry if it sounds too complicated, I'll mail the deltas.
73,
Andrew Benham, G8FSL
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
adsb@bnr.ca +44 279 402372 Fax: +44 279 402029
Home: g8fsl@g8fsl.ampr.org [44.131.19.165]
--------------------------------------------------------------------
------------------------------
Date: Wed, 19 Jan 1994 19:19:08 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: TCP MSS and TCP WIN settings
To: kf5mg@kf5mg.ampr.org
If the physical port is on the same machine as the TCP, then TCP
already limits its MSS to avoid fragmentation out through that port.
For example, if the other end advertises that it will accept a MSS of
1460 bytes but the MTU of the local interface you'll take to reach it
is only 576 bytes, then the local TCP will use a MSS of only 536 bytes
(576-40).
If the interface with the small MTU is on another router, however, the
originating TCP won't know this and fragmentation will occur.
Note also that the effective window size used by TCP, the "congestion
window" is always less than the window advertised by the other
end. The congestion window size is controlled by the slow start and
congestion control algorithms in TCP. These are not perfect, but they
do help.
Phil
------------------------------
Date: Thu, 20 Jan 94 05:53:01 CST
From: Jack Snodgrass <kf5mg@kf5mg.ampr.org>
Subject: TCP MSS and TCP WIN settings
To: tcp-group@ucsd.edu
Phil Karn writes:
> If the physical port is on the same machine as the TCP, then TCP
> already limits its MSS to avoid fragmentation out through that port.
> For example, if the other end advertises that it will accept a MSS of
> 1460 bytes but the MTU of the local interface you'll take to reach it
> is only 576 bytes, then the local TCP will use a MSS of only 536 bytes
> (576-40).
Well... that's what I thought should happen, but I tried it with JNOS
1.10x15. There's a IFCONFIG MTU command that I used to set the MTU to a
value of 256. The MSS was 1024 and the WINDOW was 4K. When I made a FTP
connect, I figured that NOS would use 256 byte packets, but it used 512
byte packets. The IFCONFIG MTU value didn't seem to have an effect.
I took a look at the TCP*.C files. There are only a couple of places
where the Tcp_mss and Tcp_window settings are assigned to a connection. It
appears that it would be easy to change this to a Tcp_mss.Interface and
Tcp_window.Interface so that you could use different Window and MSS sizes
per interface. The only problem is I don't see where in the TCP*.C code
that it references what Interface it's using. Any idea how to tell what
Interface a TCP socket is going to be using?
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Dialup - kf5mg@tcet.unt.edu - work (looking for)
------------------------------
Date: Thu, 20 Jan 1994 14:10:25 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: TCP MSS and TCP WIN settings
To: kf5mg@kf5mg.ampr.org
mss is automatically lowered to mtu-40 based on the mtu of the first
hop in the routing table. For window, you would have to rely on
the congestion window I guess.
Some tcp stacks have started keeping mtu in the routing table (probably
only those that use the "new" mtu probing. Who is adding that to nos? :-)
milton
--
Milton Miller KB5TKF miltonm@austin.ibm.com
I never speak for IBM
------------------------------
Date: Thu, 20 Jan 94 09:02:13 EST
From: brian@lantz.cftnet.com (Brian A. Lantz)
Subject: TNOS Missing Function - NOT
To: tcp-group@ucsd.edu
Come on, guys! It's a little unfair to blame TNOS for not including standard
BorlandC 3.x DOS library functions in case you are running a version of the
compiler that is 2-3 years old! The before mentioned function is a part of
Borland's library for versions 3.0, 3.1, and 4.0.
Lack of memory.... Borland C 3.x and up uses EMS/XMS to permit virtually
unlimited source size. Is this file big, yep!
As for the commment about it being perfect out of the box, NOT! If you
expected that it would compile under every possible combination, your
expectations are based in the clouds! Your mileage will vary!
As for TNOS support, I suggest subscribing to TNOS-TOPICS and sending the
messages there. I don't know that Brian wants a lot of "how do you compile
this TNOS feature" stuff in this group. We don't want to abuse his
understanding.
/----------------------------------------------/
/ Brian A. Lantz/KO4KS /
/ /
/ Packet: KO4KS@KO4KS.#TPAFL.FL.USA.NA /
/ Internet: brian@lantz.cftnet.com /
/ { printf ("Hey Jude"); /
/ bad = !make; /
/ better = sad_song; } /
/----------------------------------------------/
------------------------------
Date: Fri, 21 Jan 94 04:26:00 -0000
From: mikebw@bilow.uu.ids.net (Mike Bilow)
Subject: TNOS Missing Function - NOT
To: tcp-group@ucsd.edu
Cc: brian@lantz.cftnet.com
In a msg on <Jan 20 14:02>, Brian A. Lantz writes:
BAL> Come on, guys! It's a little unfair to blame TNOS for not
BAL> including standard BorlandC 3.x DOS library functions in
BAL> case you are running a version of the compiler that is 2-3
BAL> years old! The before mentioned function is a part of
BAL> Borland's library for versions 3.0, 3.1, and 4.0.
The _dos_xxxx() form (like "_dos_getfileattr()") of the Borland library calls
was added for increased source level compatibility with Microsoft library calls
as of BC++ 3.0. These are made equivalent in system header macro definitions
to the old form Borland calls (like "getfileattr()"). Another motivation for
the change was to more clearly indicate which functions are not part of the
ANSI C specification because they are specific to the operating system or
platform. ANSI suggests that such symbols be started with the extra prepended
underscore character. Similar changes were made in designating "near" and
"far" keywords as "_near" and "_far" in newer compilers.
It would be fairly easy to generate a special header file for older Borland
compilers that would implement some extremely simple text translations, such as
defining the newer prefaces (like "_dos_") so that they were stripped by
translating them to empty text strings. This special header file would have to
be included ahead of any system header files. Somebody has probably already
done this somewhere, but I don't know of it.
Changes to the Borland assembler are a more irritating situation. Borland
doesn't really seem to care very much about the quality of TASM, essentially
regarding it as a throwaway product. Source code that assembles perfectly with
TASM 2.5 (from BC++ 2.0) breaks substantially under the newer TASM 3.1 (from
BC++ 3.1), a known fact for a long time. You almost never see this with the C
compilers, where source code only breaks in the opposite direction, going from
newer to older compilers. The most irritating part of it for me is that TASM
actually has a switch which is supposed to allow it to emulate any prior
version of TASM or MASM, but it doesn't work right. Probably the best solution
would be to provide a prebuilt ASMOBJ.LIB of the assembly modules as Phil does
for the base KA9Q source kit; he originally started doing this when TC 2.0 was
all that some people had and Borland didn't even make an assembler.
BAL> Lack of memory.... Borland C 3.x and up uses EMS/XMS to permit
BAL> virtually unlimited source size. Is this file big, yep!
BC++ 2.0 comes with two different command-line versions, BCC.EXE and BCCX.EXE.
BCC runs in real mode, while BCCX runs in protected mode with an included DOS
extender. You can also use compiler switches on BCC to enable it to use
XMS/EMS while compiling.
There are some bugs in the old Borland tools that can cause serious XMS/EMS
corruption, and this can be devastating if you are running SMARTDRV or a
similar disk cache which maintains disk buffers in XMS/EMS. BCCX spawns the
real mode linker, TLINK, instead of the protected mode linker, TLINKX. If you
use the "-l" switch on BCCX to pass an argument to the linker which enables the
use of XMS/EMS, then this will conflict with the loaded DOS extender and very
bad things will occur. When using BCCX, you must either live with the real
mode linker and no XMS/EMS, or use the protected mode linker manually by
starting TLINKX from the command line. By default, NOS MAKEFILEs invoke the
compiler as a final step just to run the linker, and this might have to be
changed. The real mode linker should work fine for NOS in most cases, since
you will probably run out of DGROUP space long before you run out of symbol
space.
As was noted by someone else, the MAKE utility can be invoked with the "-S"
switch to enable swapping itself out of memory, but there is a fairly serious
speed penalty for that. When I was compiling NOS on a 386SX-16 in the old
days, it took about an hour from scratch. On my current system, running the
compiler in an OS/2 DOS emulation with DPMI seeing a lot of virtual memory, it
takes about three or four minutes.
BAL> As for TNOS support, I suggest subscribing to TNOS-TOPICS and
BAL> sending the messages there. I don't know that Brian wants a
BAL> lot of "how do you compile this TNOS feature" stuff in this
BAL> group. We don't want to abuse his understanding.
Why are you referring to yourself in the third person? Have you been reading
"The Education of Henry Adams" or something?
-- Mike
------------------------------
Date: Thu, 20 Jan 94 15:55:30 EDT
From: "Jan Jaeger" <JANJ@ACCIVM.acci.COM.AU>
Subject: Wampes loopback
To: tcp-group@ucsd.edu
I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3).
I seem to have run into a problem where packets send over the loopback
interface cause wampes to crash. The problem is that loopback->send
is defined as NULLFP in iface.c and ip_route() tries to call (loopback->send).
I have also compiled wampes in an RS6K (3.2.4) and the same problem exist.
Am I safe to assume that this is not a porting problem? (It still needs to
be fixed of course).
Jan PA3EFU/VK3CEX
------------------------------
Date: Thu, 20 Jan 94 21:40:00 MST
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: Wampes loopback
To: JANJ@ACCIVM.acci.COM.AU, tcp-group@ucsd.edu
> I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3).
Could you send me your changes, so I can merge them into the
distribution?
> I seem to have run into a problem where packets send over the loopback
> interface cause wampes to crash. The problem is that loopback->send
> is defined as NULLFP in iface.c and ip_route() tries to call (loopback->send).
> I have also compiled wampes in an RS6K (3.2.4) and the same problem exist.
> Am I safe to assume that this is not a porting problem? (It still needs to
> be fixed of course).
This can only happen if you set up a route to some address different
from 127.0.0.1 thru the loopback interface. Just don't do this. In the
next version of WAMPES I will put in a safeguard, which will ignore
packets routed this way, instead of crashing the system.
> Jan PA3EFU/VK3CEX
--
Dieter Deyke - deyke@fc.hp.com - dk5sg@db0sao.ampr.org
------------------------------
Date: Fri, 21 Jan 94 05:01:00 -0000
From: mikebw@bilow.uu.ids.net (Mike Bilow)
Subject: Wampes loopback
To: tcp-group@ucsd.edu
Cc: JANJ@ACCIVM.acci.COM.AU
In a msg on <Jan 20 19:55>, Jan Jaeger of writes:
JJ> I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3).
Great! We have one of those dinosaurs here. Unfortunately, it is running AIX.
Still worse, it is running AIX v2, since AIX v3 needs the RS machines and will
not run on the RT machines. I think we have the native TCP/IP support, but no
one knows where the manual is, and no one at IBM seemed to care much about
locating another one even when we dangled small bills in front of them.
Is your port available at any FTP site, ideally UCSD.EDU?
-- Mike
------------------------------
End of TCP-Group Digest V94 #17
******************************
******************************