Date: Thu, 11 Nov 93 04:30:02 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 #293
To: tcp-group-digest


TCP-Group Digest            Thu, 11 Nov 93       Volume 93 : Issue  293

Today's Topics:
                 FP_OFF/SEG on Borland vs. Microsoft
                      KA9Q NET problem once more
                         NOS Boogers (3 msgs)
                     NOS FTP breaks 3B2 (2 msgs)
                             NOS FTP Bug
                       Re- TCP broadcast storm
                   Recording of the telnet sessions
                    WinQVT/Net ( was Campus Net )

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, 10 Nov 93 21:06:46 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: FP_OFF/SEG on Borland vs. Microsoft
To: myers@pongo.West.Sun.COM

>Though it may be against the rules, I'm currently building NOS
>(the base KA9Q code) using Microsoft C/C++ 8.0.  I'm starting to
>wonder if the behaviour of FP_OFF and FP_SEG differ in the two
>compilers.  In particular, I'm wondering about the parameter that
>is passed to the macros.

>Can anyone explain to me exactly how Borland defines these macros?

Last friday, while waiting in the Phoenix airport, I had typed up a
reply to this note on my laptop when I promptly lost it in a DOS
crash. Argh! Maybe SunOS will be more cooperative.

Rules? We are hams, we don't need no stinkin' rules! :-)

Here are the appropriate definitions from /borlandc/include/dos.h. They
appear to work for both near and far pointers:

#define FP_SEG( fp )( (unsigned )( void _seg * )( void far * )( fp ))
#define FP_OFF( fp )( (unsigned )( fp ))

Note that the FP_SEG macro uses a built-in Borland keyword, _seg, that
extracts the segment portion of a far pointer.  Dunno if Microsoft has
an equivalent feature.

Phil

------------------------------

Date: Wed, 10 Nov 1993 19:28:25 -0100 (GMT-1:00)
From: andy@mimuw.edu.pl (Andrzej K. Brandt)
Subject: KA9Q NET problem once more
To: tcp-group@ucsd.edu

Hello,

I still can't figure out why when async device is attached at any speed KA9Q
stops displaying what is being typed or what is comming in the sessions, but
it works, accepts that input and even shows it - after using F8 to get
screen change.

Any hints?

-- 


                               73 de Andy SP5WCA


/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I 
\-------------------+--------+-------------------+-------------------------/

------------------------------

Date: Wed, 10 Nov 93 13:09:50 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: NOS Boogers
To: jmd@cube.handheld.com

>I extracted it to plain, old. .c and .h files, from my unix paltform, but then  
>ran into the same problems of strange, missing, stuff.  Kdebug, and the FAX  
>stuff, for starters.  I think Phil has crossed over to the dark side (unix :-)  
>), and left DOS to rot.

What do you mean? I was using UNIX long before I used DOS, and I'll be
using UNIX (or whatever the lawyers let us call it) long after DOS is
buried in its unmarked grave. DOS is just a glorified bootstrap loader
I was forced to use while waiting for personally-affordable computers
to get powerful enough to run UNIX.

I still use NOS almost continuously, but almost solely as an IP dialup
router to support my 386BSD box (soon to be BSDI). That's why I'm not
terribly interested in the application and user interface issues (not
that I ever was!)

NOS is still good for routing over special low-speed networks, like
phone modems and amateur packet radio. And it's still a convenient
platform for experimentation with new transmission media, like CDMA
digital cellular at work, and experimental new "middle of the stack"
protocols like the IP security protocol I'm currently working on.  But
I never intended it to be a UNIX substitute, and I'm just a little
distressed by all the effort that seems to be going into reinventing
the UNIX wheel!

Phil

------------------------------

Date: Wed, 10 Nov 93 16:17:17 -0500
From: Jim De Arras <jmd@cube.handheld.com>
Subject: NOS Boogers
To: karn@qualcomm.com (Phil Karn)

> >I extracted it to plain, old. .c and .h files, from my unix paltform, but  
then  

> >ran into the same problems of strange, missing, stuff.  Kdebug, and the FAX  

> >stuff, for starters.  I think Phil has crossed over to the dark side (unix  
:-)  

> >), and left DOS to rot.
> 

> What do you mean? I was using UNIX long before I used DOS, and I'll be
> using UNIX (or whatever the lawyers let us call it) long after DOS is
> buried in its unmarked grave. DOS is just a glorified bootstrap loader
> I was forced to use while waiting for personally-affordable computers
> to get powerful enough to run UNIX.


Phil, there was a smiley there!  I'm entering this on a unix box!  I HATE DOS!
My reference was due to the Kdebug stuff, which sounded like Kernal Debug.  Dos  
has no Kernal, IMHO.

> 

> I still use NOS almost continuously, but almost solely as an IP dialup
> router to support my 386BSD box (soon to be BSDI). That's why I'm not
> terribly interested in the application and user interface issues (not
> that I ever was!)
> 

> NOS is still good for routing over special low-speed networks, like
> phone modems and amateur packet radio. And it's still a convenient
> platform for experimentation with new transmission media, like CDMA
> digital cellular at work, and experimental new "middle of the stack"
> protocols like the IP security protocol I'm currently working on.  But
> I never intended it to be a UNIX substitute, and I'm just a little
> distressed by all the effort that seems to be going into reinventing
> the UNIX wheel!

All I want to do is compile it for a 56kbs HAM link, and I cannot get past the  
kdebug stuff.  I was not trying to put you down, sorry if it came off that way!
> 

> Phil
> 

> 

> 

Jim

------------------------------

Date: Wed, 10 Nov 93 16:20:14 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: NOS Boogers
To: jmd@cube.handheld.com

>Phil, there was a smiley there!  I'm entering this on a unix box!  I HATE DOS!
>My reference was due to the Kdebug stuff, which sounded like Kernal Debug.  Dos  
>has no Kernal, IMHO.

Oops, I should have put a smiley on my message too. But I always enjoy
an opportunity to flame DOS, any excuse will do... :-)

The "Kdebug" reference you mention is a debugging feature I put in a
while back that causes the NOS (not DOS) kernel to display the name of
the currently running task on the lower right corner of the screen. I
found it very useful in finding bugs that cause NOS to hang, as it
helps to know which task was running at the time. Dunno why it came up
undefined in a recompile, I guess I need to update the stuff on
ucsd.edu to make sure it's all current.

The references to qfax (and possibly cdma) are to files we've been
writing here at Qualcomm for a work project, and as such are not
released. I've tried to keep them all in a separate library called
cdma.lib, so if you just comment out that line in the makefile NOS
should compile and link without any errors.

Phil

------------------------------

Date: Wed, 10 Nov 93 11:08:55 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: NOS FTP breaks 3B2
To: steve@zero.com, unbc.edu!lyndon@vu-vlsi.ee.vill.edu

The following are changes that I made to the JNOS ftp client and server to
better emulate the multiline display correctly. Becasue of the way it was
done it is compatible with the older style (220- on every line) as well.
The basic changes are:

   1. remove 220- from all but first banner message.
   2. change last banner message to 220<sp>text
   3. Change ftpmotd to send only text - no code

Since banner[] is always sent first - 220- is in that line.
Since banner2[] is always sent last (after ftpmotd) send final 220 in that line

In ftp client changed getresp() function to better accomodate this.
Some of the checks are not included though - I.E. the ftpmotd cannot have
numbers 220 or 230 numbers in the first columns. This is a first cut and
may need some more massaging. In particuliar it is unclear waht code to
use. The RFC says 220, which I  believe is correct. Windows NT uses 230 but
it is AFTER login. It does look cleaner this way and is more in line with the
way the RFC states. I must add thought that WB3FTP who origianlly brought this
up with his 3B2 system, is still having problems with this change.  

*****************
* FTP server    *
*****************

/* Response messages */
static char banner[] = "220- Welcome to %s, running KA9Q NOS\n";
static char banner1[] = "     FTP version %s\n";
static char banner2[] = "220  FTP server ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: Type is ASCII and %s appears to be binary\n";


log(s,"open FTP");
 usprintf(s,banner,Hostname);
 usprintf(s,banner1,Version);
 if((fp = fopen(Ftpmotd,"r")) != NULL) {
  while(fgets(buf,128,fp)) {
   rip(buf);
   usprintf(s,"%s\n",buf);
  }
  fclose(fp);
 }

**************************************************
*  FTP client code - getresp() function          *
**************************************************

/* Wait for, read and display response from FTP server.
 * Return the result code. */
static int
getresp(ftp,mincode)
struct ftpcli *ftp;
int mincode;            /* keep reading until at least this code comes back */
{
 register char *line;
 int rval,more_text=0;

 usflush(ftp->control);
 line = mallocw(LINELEN);
 for(;;) {
  /* Get line */
  if(recvline(ftp->control,line,LINELEN) == -1) {
   rval = -1;
   break;
  }
  rip(line);                      /* remove cr/lf */
  rval = atoi(line);
  if(rval >= 400 || ftp->verbose >= V_NORMAL) {
   tprintf("%s\n",line);   /* display to user */
   }
      
  if (line[3]=='-' && (rval==220 || rval==230)) {
    more_text=1;
    continue;
  }
       
  if (more_text)  {
   if (rval==220 || rval==230)   {
        break;
       }
  }
  else {
   if (rval>=mincode){
        break;
        }
  }
    
  
 }
 if(rval == 399) {               /* return encrypted password */
  ftp->line = mallocw(LINELEN);
  strcpy(ftp->line,line);
 }
 free(line);
 return rval;
}


And this is what a login now looks like.....

Trying 44.80.8.120:ftp..
      
Resolving wa3dsp..
Local Directory - F:/
FTP session 1 connected to wa3dsp
220- Welcome to wa3dsp.ampr.org, running KA9Q NOS
     FTP version 911229 WG7J v1.09 (K2MF v1.06 - 80386)
         
     **************************************************************************
     * Welcome to the WA3DSP File Repository - Type 'DIR' to View Directories *
     * Please upload to the /pub/incoming directory                           *
     **************************************************************************
         
220 FTP server ready on Wed Nov 10 13:06:52 1993
331 Please enter PASS command
230 Logged in
ftp>



Comments please....


Doug
         

------------------------------

Date: Wed, 10 Nov 93 20:12:43 EST
From: Steve Urich <steve@zero.com>
Subject: NOS FTP breaks 3B2
To: tcp-group@ucsd.edu

 
> use. The RFC says 220, which I  believe is correct. Windows NT uses 230 but
> it is AFTER login. It does look cleaner this way and is more in line with the
 I still like the 230- ftp messages ;).

> way the RFC states. I must add thought that WB3FTP who origianlly brought this
> up with his 3B2 system, is still having problems with this change.  
 I have a maxed out 3b1 not 3b2 but it doesn't matter because I don't use
 the win/3b tcpip stuff only ka9q net and ka9q net doesn't like the 
 multible 220- banner lines either so I have to type in USER anonymous
 PASS call anyway.

 Here is what my ftp message looks like.

220 wb3ftp.ampr.org FTP server v2.9a(UNIX) (Ready at Wed Nov 10 20:06:12 1993)
USER anonymous
331 Enter PASS command
PASS steve
230- 
230-      Welcome to the WB3FTP.AMPR.ORG Archive
230- 
230-      This system is open 24 hours of the day and all the  transactions
230-      are  being  logged. The INDEX file in ~pub is a total list of all
230-      the files and where they are located in  the  ~/pub  directories.
230-      This  INDEX  is a TYPE A file and is automatically updated once a
230-      day. Please feel free to upload so others can share  your  latest
230-      files.  The ~pub/incoming dir is where all uploads are to be made
230-      and if possible with a readme file.
230- 
230-          Share and Enjoy!! 73 - Steve
230- 
230 Guest login restrictions apply, Type set to A


-- 
|Stephen Urich|        Internet:steve@zero.com         |He hitotsu wa kusuri|
|NIC: SU2     |        UUCP:uunet!beyonet!steve        |  sempuku ni makau. |
|ARS: WB3FTP  | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM  |ax25<->PBBS<->IPGATE|
|Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]|TCP/IP-FTP-SMTP-UNIX|

------------------------------

Date: Wed, 10 Nov 1993 16:21:13 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: NOS FTP Bug
To: TCP-Group@UCSD.Edu

brian@nothing.ucsd.edu says:
>In one sense, it's a good idea to be conservative what you send in order
>to avoid breaking existing software.  Yet progress must be made; at some
>point you have to make changes - and these changes might expose
>previously-unknown-to-be-broken software.
> - Brian

While I agree that new NOS routines can't be responsible for working with
AT&T machines, maybe we can at least make NOS work per the RFC, and then any
problems with AT&T users can be answered with "tough tits, get yourself
something that works".  :-)

By the way, the Sun machine at ds.internic.net also sends out 220- on every
line just like NOS, so maybe this is the way everyone is interpreting the RFC??

P.S.  Anyone who has the BSD ftp and ftpd ported to the 3B2 and SysV 3.2,
I wouldn't mind a copy.  Just the thought of all the changes to the
include files makes me tired :-)

Untested hack to FTPSERV.C for discussion purposes:

 log(s,"open FTP");
 usprintf(s,banner,Hostname,Version);
 usprintf(s,banner1,cp);

 if ((fp = fopen(Ftpmotd,"r")) != NULL) {
  usprintf(s,"230-\n");
  
  while (fgets(buf, 128, fp)) {
   rip(buf);
   usprintf(s,"  %s\n",buf);  /* easy way out - n5owk */
  }

  usprintf(s,"230 We hope you enjoyed the show\n");
  fclose(fp);
 }
---
Steve, N5OWK

------------------------------

Date: Wed, 10 Nov 93 21:17:02 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Re- TCP broadcast storm
To: postel@ISI.EDU

This confusion between the Internet itself and the hosts attached to
it continues. Last week, during the Houston IETF, the New York Times
carried an article titled "Traffic Jams on the Information Highway"
(or words to that effect, this is from memory). The article was
clearly about the extreme loads that certain popular *server machines*
on the net have been experiencing, but the title metaphor obviously
gives the (mis)impression that the NSF backbone communication links are
overloaded. As far as I have been able to observe, they are not.

Phil

------------------------------

Date: Wed, 10 Nov 93 18:45:09 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Recording of the telnet sessions
To: ve3mrm@bbs.ve3rpi.ampr.org

>I use KA9Q NOS 2.0p and the only problem I have is in recording of
>telnet sessions (using the command "record <filename>"). The problem
>appears any time the text is paginated by the system with "--More--".
>Simply, the "--More--" terminates the recording without announcing it,
>making the record files not longer than about 1052 bytes (one page). The
>"session # flow on|off" command does not work (will not disable
>pagination) despite what the "session # flow" says.

I take it this bug was introduced in one of the other versions of NOS?
I just tried to invoke it on my own version, without success.  I
logged into a UNIX box, started recording the session, then ran "more"
on a file.  Everything worked fine.

Phil

------------------------------

Date: Wed, 10 Nov 93 20:35:43 -0800
From: jhays@hays.org (John D. Hays)
Subject: WinQVT/Net ( was Campus Net )
To: kf5mg@kf5mg.ampr.org

I've been thinking for some time that a new ROM for TNCs which does SLIP  
instead of KISS might be in order.  There would probably need to be a loader  
program of some type that downloaded Callsign, PARAMs, etc.  to the TNC, but on  
the serial port it would look like a SLIP Point-to-Point connection ... Then  
various implementations of TCP/IP which speak SLIP could access the AX.25  
encapsulated IP network....

John D. Hays
KD7UW

Begin forwarded message:

Errors-To: tcp-group-relay@UCSD.EDU
Sender: tcp-group-relay@UCSD.EDU
Precedence: List
From: kf5mg@kf5mg.ampr.org
Date: Tue, 09 Nov 93 06:45:15 GMT
To: tcp-group@ucsd.edu
Subject: re: WinQVT/Net ( was Campus Net )

I downloaded WinQVT/Net and it looks promising. I'm looking for something 

'slick' to use to intoroduce a ax.25 user to the world of TCP/IP. Is there
any way... short of using 2 ethernet cards to have WinQVT/Net running under
Windows to talk to a NOS, IP-Router running in a Window's DOS Box on the
same machine. Is there a 'Vitrual' Packet driver that will emulate a card 

and allow 2 apps to communicate using the packet driver Interface. Doesn't
BPQ have something like that that lets NOS talk to a BPQ switch via a 

Packet Driver interface? Any info would be appreciated. 


73's  de  Jack  -  kf5mg   ( running JNOS in a 735K - OS/2 2.1 Dos Box! )
Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
Worknet         -  kf5mg@vnet.ibm.com              -  work (817) 962-4409
-------------------------------------------------------------------------
|    "I am Homer of Borg.... Prepare to be assim.... oooo Donuts."      |
-------------------------------------------------------------------------

------------------------------

End of TCP-Group Digest V93 #293
******************************
******************************