Date: Sun, 28 Mar 93 04:30:11 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 #80
To: tcp-group-digest


TCP-Group Digest            Sun, 28 Mar 93       Volume 93 : Issue   80

Today's Topics:
                    Ftpmotd in jnos v108d (2 msgs)
                         G8BPQ with IP Router
                    KA9Q NOS questions... (2 msgs)
                  TCP-Group Digest V93 #79 (2 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: Sat, 27 Mar 93 17:43:49 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd in jnos v108d
To: TCP-Group@ucsd.edu

 Hello, for those of you who are interested I have changed the
 ftpmotd in jnos ftpserv to conform to internet standards. I
 have put the motd in my version of net and also in a version
 of pa0gri. It works with most of the original ka9q ftpcli 
 including net and most nos except the jnos client with has
 a verbose default problem that somebody changed. I sent my
 changes to Johan and explained the problem. Its due to the
 client remaining quiet till a remote command is ordered
 giving it a V_NORMAL verbose. Then the ftpmotd gets shown
 when a data port is able to be read verbose. It works normal
 with net and other versions of nos clients showing the motd
 at 230 AFTER the login as it should be. I mainly changed the
 motd routine and added it also to my server because of the
 way it was sent out at 220 breaking my ka9q net client. Since
 I don't have a dos box to compile jnos I can't fix the jnos
 client myself without some debugging since the initial test
 with wa3dsp Doug has proven to be ok with my client by a
 slight difference in the jnos client because of its verbose.
 Since I can't debug and compile jnos because I don't have
 a dos box I had wa3dsp compile it for me. It worked ok for
 me but the jnos client was coded differently then the vanilla
 client code. It looks easy enough to debug if I had a dos
 machine an compiler. Here are the diffs to the change from
 220 to 230 for the motd.

 73 - Steve

----Start `diff -c' ftpserv.c v1.08d----
*** ftpserv.old Wed Mar 24 18:20:45 1993
--- ftpserv.new Fri Mar 26 01:26:59 1993
***************
*** 55,62
  };
  
  /* Response messages */
! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "220  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";
  static char unsupp[] = "500 Unsupported command or option\n";

--- 55,62 -----
  };
  
  /* Response messages */
! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "230  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";
  static char unsupp[] = "500 Unsupported command or option\n";
***************
*** 173,179
   long t;
   int cnt,i;
   struct sockaddr_in socket;
-     FILE *fp;
  
   sockmode(s,SOCK_ASCII);
   memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */

--- 173,178 -----
   long t;
   int cnt,i;
   struct sockaddr_in socket;
  
   sockmode(s,SOCK_ASCII);
   memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */
***************
*** 197,209
  
   log(s,"open FTP");
   usprintf(s,banner,Hostname,Version);
-     if((fp = fopen(Ftpmotd,"r")) != NULL) {
-         while(fgets(buf,128,fp)) {
-             rip(buf);
-             usprintf(s,"220- %s\n",buf);
-         }
-         fclose(fp);
-     }
   time(&t);
   cp = ctime(&t);
   

--- 196,201 -----
  
   log(s,"open FTP");
   usprintf(s,banner,Hostname,Version);
   time(&t);
   cp = ctime(&t);
   
***************
*** 211,218
      if((cp1 = strchr(cp,'\n')) != NULLCHAR)
   *cp1 = '\0';
  #endif
-  
-  usprintf(s,banner1,cp);
  
  loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
    /* He closed on us */

--- 203,208 -----
      if((cp1 = strchr(cp,'\n')) != NULLCHAR)
   *cp1 = '\0';
  #endif
  
  loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
    /* He closed on us */
***************
*** 568,574
  struct ftpserv *ftp;
  char *pass;
  {
!  char *path;
   char *p;
   int anony = 0;
  

--- 558,564 -----
  struct ftpserv *ftp;
  char *pass;
  {
!  char *path,buf[128],*cp;
   char *p;
   long t;
   FILE *fp;
***************
*** 570,575
  {
   char *path;
   char *p;
   int anony = 0;
  
   path = mallocw(200);

--- 560,567 -----
  {
   char *path,buf[128],*cp;
   char *p;
+  long t;
+  FILE *fp;
   int anony = 0;
  
   path = mallocw(200);
***************
*** 590,595
   if((p = strchr(path,';')) != '\0')
    *p = '\0';              /* delimit initial cd */
  #endif
  
   if(!anony){
    usprintf(ftp->control,logged);

--- 582,598 -----
   if((p = strchr(path,';')) != '\0')
    *p = '\0';              /* delimit initial cd */
  #endif
+  time(&t);
+  cp = ctime(&t);
+  usprintf(ftp->control,banner1,cp);
+ 
+     if((fp = fopen(Ftpmotd,"r")) != NULL) {
+         while(fgets(buf,sizeof(buf),fp)) {
+             rip(buf);
+             usprintf(ftp->control,"230- %s\n",buf);
+         }
+         fclose(fp);
+     }
  
   if(!anony){
    usprintf(ftp->control,logged);
---End of diff cut here---


-- 
|Stephen Urich|        Internet:steve@zero.com         | "Cattle mutilations |
|NIC: SU2     |        UUCP:uunet!beyonet!steve        | are up!" --Sneakers |
|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: Sat, 27 Mar 93 17:43:49 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd in jnos v108d
To: TCP-Group@ucsd.edu

 Hello, for those of you who are interested I have changed the
 ftpmotd in jnos ftpserv to conform to internet standards. I
 have put the motd in my version of net and also in a version
 of pa0gri. It works with most of the original ka9q ftpcli 
 including net and most nos except the jnos client with has
 a verbose default problem that somebody changed. I sent my
 changes to Johan and explained the problem. Its due to the
 client remaining quiet till a remote command is ordered
 giving it a V_NORMAL verbose. Then the ftpmotd gets shown
 when a data port is able to be read verbose. It works normal
 with net and other versions of nos clients showing the motd
 at 230 AFTER the login as it should be. I mainly changed the
 motd routine and added it also to my server because of the
 way it was sent out at 220 breaking my ka9q net client. Since
 I don't have a dos box to compile jnos I can't fix the jnos
 client myself without some debugging since the initial test
 with wa3dsp Doug has proven to be ok with my client by a
 slight difference in the jnos client because of its verbose.
 Since I can't debug and compile jnos because I don't have
 a dos box I had wa3dsp compile it for me. It worked ok for
 me but the jnos client was coded differently then the vanilla
 client code. It looks easy enough to debug if I had a dos
 machine an compiler. Here are the diffs to the change from
 220 to 230 for the motd.

 73 - Steve

----Start `diff -c' ftpserv.c v1.08d----
*** ftpserv.old Wed Mar 24 18:20:45 1993
--- ftpserv.new Fri Mar 26 01:26:59 1993
***************
*** 55,62
  };
  
  /* Response messages */
! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "220  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";
  static char unsupp[] = "500 Unsupported command or option\n";

--- 55,62 -----
  };
  
  /* Response messages */
! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "230  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";
  static char unsupp[] = "500 Unsupported command or option\n";
***************
*** 173,179
   long t;
   int cnt,i;
   struct sockaddr_in socket;
-     FILE *fp;
  
   sockmode(s,SOCK_ASCII);
   memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */

--- 173,178 -----
   long t;
   int cnt,i;
   struct sockaddr_in socket;
  
   sockmode(s,SOCK_ASCII);
   memset((char *)&ftp,0,sizeof(ftp));     /* Start with clear slate */
***************
*** 197,209
  
   log(s,"open FTP");
   usprintf(s,banner,Hostname,Version);
-     if((fp = fopen(Ftpmotd,"r")) != NULL) {
-         while(fgets(buf,128,fp)) {
-             rip(buf);
-             usprintf(s,"220- %s\n",buf);
-         }
-         fclose(fp);
-     }
   time(&t);
   cp = ctime(&t);
   

--- 196,201 -----
  
   log(s,"open FTP");
   usprintf(s,banner,Hostname,Version);
   time(&t);
   cp = ctime(&t);
   
***************
*** 211,218
      if((cp1 = strchr(cp,'\n')) != NULLCHAR)
   *cp1 = '\0';
  #endif
-  
-  usprintf(s,banner1,cp);
  
  loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
    /* He closed on us */

--- 203,208 -----
      if((cp1 = strchr(cp,'\n')) != NULLCHAR)
   *cp1 = '\0';
  #endif
  
  loop:   if((cnt = recvline(s,buf,sizeof(buf))) == -1){
    /* He closed on us */
***************
*** 568,574
  struct ftpserv *ftp;
  char *pass;
  {
!  char *path;
   char *p;
   int anony = 0;
  

--- 558,564 -----
  struct ftpserv *ftp;
  char *pass;
  {
!  char *path,buf[128],*cp;
   char *p;
   long t;
   FILE *fp;
***************
*** 570,575
  {
   char *path;
   char *p;
   int anony = 0;
  
   path = mallocw(200);

--- 560,567 -----
  {
   char *path,buf[128],*cp;
   char *p;
+  long t;
+  FILE *fp;
   int anony = 0;
  
   path = mallocw(200);
***************
*** 590,595
   if((p = strchr(path,';')) != '\0')
    *p = '\0';              /* delimit initial cd */
  #endif
  
   if(!anony){
    usprintf(ftp->control,logged);

--- 582,598 -----
   if((p = strchr(path,';')) != '\0')
    *p = '\0';              /* delimit initial cd */
  #endif
+  time(&t);
+  cp = ctime(&t);
+  usprintf(ftp->control,banner1,cp);
+ 
+     if((fp = fopen(Ftpmotd,"r")) != NULL) {
+         while(fgets(buf,sizeof(buf),fp)) {
+             rip(buf);
+             usprintf(ftp->control,"230- %s\n",buf);
+         }
+         fclose(fp);
+     }
  
   if(!anony){
    usprintf(ftp->control,logged);
---End of diff cut here---


-- 
|Stephen Urich|        Internet:steve@zero.com         | "Cattle mutilations |
|NIC: SU2     |        UUCP:uunet!beyonet!steve        | are up!" --Sneakers |
|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: Sun, 28 Mar 93 09:00:50 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: G8BPQ with IP Router
To: TCP-Group@ucsd.edu

Hi All

I put BPQ406E.ZIP into the wrong incoming directory. It is now in
/hamradio/packet/tcpip/incoming.

Sorry

Jonathan

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

Date: Sat, 27 Mar 1993 11:41:17 -0600 (CST)
From: gerry@cs.tamu.edu (Gerald J Creager)
Subject: KA9Q NOS questions...
To: tcp-group@ucsd.edu

 I recently shipped this to the group, but I've seen neither the question, nor
 any responses, so I guess it went to a bit bucket in the sky... Let's try
 again.

I recently downloaded Phil's latest from ucsd.edu.  I tried to bring it up
initially with an autoexec.nos configured for jnos 107b.  With the exception of
the attach asy statement, I have changed nothing, but I'm seeing some
interesting anomolies and NEED some help.

1.  Hardware config:
'386DX/'387, 4 Mb memory, 130 Mb hard disk, 3 Mb free on NOS logical drive, 6
Mb free on a separate logical drive for /temp.

2.  Software Config:
QEMM/386, ansi.sys, the world loaded high, 633k available.

3.  TNC config:
PacComm Tiny-2 with "node" (higher speed) parts, port speed 9600 baud, radio
speed 1200 baud, ROM rev. 1.1.6b (PacComm)

4.  Recent history:
Works "fine" with jnos, older karncode (tm) and g1emmCode (tm).  Worked fine at
higher radio rates with DataEngine testing last year.

5.  Symptoms:

A.  When I issue *ANY* sort of transmission, with trace turned on, I see an
ax.25 "bad header" message in trace.

B.  Occassionally, say, <10% of the time, I see what looks to the code
(appparently) like a good ax.25 packet but is gibberish.

C.  Other systems see the packets I'm pumping out, and they look normal to
them.  A connect request using either native ax.25 or tcp/ip results in the
other system thinking it can really talk to me, but I cannot make sense of the
replys.

I have used both the ax25ui and ax25i constructs in the attaach asy command
line, with similar results.  Since I haven't pulled down the source yet, I have
no "documentation" to work with...  I need more disk space, and I'm working oin
that issue.

Anyone got thoughts?  I was wondering if KISS wasn't compiled into the code,
possibly...  If that's the case, I guess I need to learn something about RCS
and grab a copy of Borland C++ 3.x...

Thanks,
Gerry  n5jxs
gerry@cs.tamu.edu

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

Date: Sat, 27 Mar 93 17:01:07 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: KA9Q NOS questions...
To: gerry@cs.tamu.edu (Gerald J Creager)

Try using "kissui" or "kissi" instead of "ax25ui"/"ax25i".
If you use ax25 encapsulation, it just sends raw ax25 packets to the
serial port, assuming that whatever hears them will transmit them
literally (like an 8530 card).  If you use kiss encapsulation, it
prepends a kiss "data follows" byte to the ax25 packet; this is
what the TNC expects, to distinguish data from parameter-setting commands,
for instance.  At least, that's what I've been able to glean from
looking at the source, and playing with it for a few minutes.
I haven't seen any documentation either.

mg

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

Date: Sat, 27 Mar 93 15:05:15 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #79
To: tcp-group@ucsd.edu

Returned Mail: Could not find any To: or Cc: recipients.

*** Returned Mail Message Follows: ***

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

Date: Sat, 27 Mar 93 04:30:06 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #79
To: tcp-group-digest@ucsd.edu

TCP-Group Digest            Sat, 27 Mar 93       Volume 93 : Issue   79

Today's Topics:
                             3COM Sniffer
              Anyone seen this problem before ? (2 msgs)
         any System V release 3 ports of NOS/NET (KA9q)/slip
                       AX25 and Linux (2 msgs)
                              LAPB bugs
                      Latest BPQ with IP Router
                  TCP-Group Digest V93 #78 (2 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, 26 Mar 93 11:28:05 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: 3COM Sniffer
To: tcp-group@ucsd.edu

I put the file eprobe.zip in the ucsd.edu incoming. It is a PUBLIC
DOMAIN ethernet monitor program from 3COM for any of there ethernet
board products. It is a nifty way to monitor ethernet traffic on a
PC. It has filtering modes and detailed viewing.

I thought this might be of interest to the ampr group. If it is not
appropriate to have it on here then take it off.

Doug

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

Date: Fri, 26 Mar 93 10:10:09 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Anyone seen this problem before ?
To: tcp-group@ucsd.edu (TCP Group)

Has anyone seen NOS behave in the following way ?

An interface is set up to work in datagram mode, but sometimes
NOS decides to start talking in VC mode (to just one or two
stations, not everyone on that interface). If the remote
station in question has jumpstart on, there's a timewasting
round of "Huh?", "Huh?", "Huh?".... until one or other gets bored
and drops the ax25 connection.

Things I know as facts :-

1. I'm running a very recent version of KA9Q (not JNOS, PA0GRI etc),
   with some local mods, they might be the culprit, but I thought
   I'd ask.

2. This has been going on for a while now, so the problem existed
   with earlier NOS versions I used (PA0GRI based, I believe).

3. It is definately my station that initiates the VC mode, (I send
   the SABM).

Observations that may or may not be true :-

1. I run a name server on my ethernet, and accesses by other stations
   to the nameserver seem to cause the problem to occur most readily.
   From the traces I have noticed that sometimes I will get an "ICMP
   code port unreachable" when I issue a DNS reply, could this be that
   NOS got bored waiting for my answer, and closed the port ?

2. I've never seen this happen to a TCP connection, only to UDP traffic.

If this sounds familiar to anyone, or if you've got any ideas, send
mail & I'll summarise. I hope to dive into the code this weekend...
-- 
andyw. N0REN/G1XRL

andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835

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

Date: Fri, 26 Mar 1993 12:31:34 -0600 (CST)
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Subject: Anyone seen this problem before ?
To: tcp-group@ucsd.edu (tcp/ip networking group)

>
>Has anyone seen NOS behave in the following way ?
>
>An interface is set up to work in datagram mode, but sometimes
>NOS decides to start talking in VC mode (to just one or two

Andy,

One thing that would cause this is for someone to send a datagram
with the "reliability" flag set (0x04) in the IP TOS field.  JNOS will
send such datagrams in VC mode, regardless of the default "ax25 mode"
setting.

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

Date: Fri, 26 Mar 93 16:34:58 CST
From: "Erach A. Irani" <irani@cs.umn.edu>
Subject: any System V release 3 ports of NOS/NET (KA9q)/slip
To: tcp-group@ucsd.edu

--- If this is a repeat, please excuse me.  I still cannot locate a
working implementation, and that seems highly unlikely to me ---

Hi,
 I read that you have agreed to help out by being the
coordinator for the UNIX ports.  have you heard of a sys 5 release 3
port of nos/net ka9q slip WHICH can allow me to login to the
originating machine and do UNIX'ish work (rather than talk alone).

 A limited number of logins is all I need.
 Thanks,
 erach

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

Date: Fri, 26 Mar 93 08:22:10 CST
From: Brian K. Teravskis <brian@smedley.telex.mn.org>
Subject: AX25 and Linux
To: tcp-group@ucsd.edu

Is anyone working on getting AX25 incorporated
into the Linux kernel or is KA9Q the only way
to go for now??

Thanks..

Brian

------------------------------------------------------------------------------
Brian K. Teravskis          |   Internet: brian@smedley.telex.mn.org
Telex Communications, Inc   |             brian@hercules.vware.mn.org
Bloomington, MN  55420      |   AMPRNET:  brian@hercules.wd0efl.tcman.ampr.org
------------------------------------------------------------------------------

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

Date: Fri, 26 Mar 1993 09:50:10 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: AX25 and Linux
To: "Brian K. Teravskis" <brian@smedley.telex.mn.org>

Right now, you must run a KA9Q variant such as WAMPES under Linux,
because the various people who have been hacking in AX.25 drivers
aren't ready to release them. We're waiting for the SLIP modifications
to the kernel (mostly STREAMS support) to stabilize, as we want to use
some of that to support AX.25. Also, the Linux TCP/IP implementation is
still being debugged - the original developer has left the effort in a
huff due to too much criticism, and others are now posting about one
bug-fix a day. 

I find that running KA9Q under Linux is much more comfortable than
running KA9Q on DOS, simply because of the multi-tasking - I can do
something else with the computer while KA9Q is running, and if KA9Q
dies it doesn't crash the system.

It is going to be nice when we can abandon the monolithic structure of
NOS, and break the system into separate processes. I find it much easier
to modify and debug that way.
     Bruce Perens KD6OTD

On Fri, 26 Mar 1993, Brian K. Teravskis wrote:

> Is anyone working on getting AX25 incorporated
> into the Linux kernel or is KA9Q the only way
> to go for now??
> 
> Thanks..
> 
> Brian
> 
> ------------------------------------------------------------------------------
> Brian K. Teravskis          |   Internet: brian@smedley.telex.mn.org
> Telex Communications, Inc   |             brian@hercules.vware.mn.org
> Bloomington, MN  55420      |   AMPRNET:  brian@hercules.wd0efl.tcman.ampr.org
> ------------------------------------------------------------------------------
> 
> 

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

Date: Fri, 26 Mar 93 14:29:55 PST
From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
Subject: LAPB bugs
To: tcp-group@ucsd.edu

Following are some bugs and deficiencies that I've found in the LAPB
code, which a couple of group members have requested that I post.
Excuse the extra-wide format. Hope it doesn't make this unreadable
for some.

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

Date: Fri, 26 Mar 93 19:04:03 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: Latest BPQ with IP Router
To: TCP-Group@ucsd.edu

On incoming as ucsd.edu is the latest version of G8BPQs switch software,
BPQ406E.ZIP. In it is included the first release of his IP router software
that operates as an application above the switch. It has been in beta testing
for quite a while in our local packet area with good results. John has added
a protocol for auto routing between his switches.

Could somebody move it from incoming to the g8bpq directory please.

John G8BPQ can now be reached at g8bpq@g4klx.demon.co.uk

73's

Jonathan

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

Date: Fri, 26 Mar 93 11:02:08 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #78
To: tcp-group@ucsd.edu

Returned Mail: Could not find any To: or Cc: recipients.

*** Returned Mail Message Follows: ***

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

Date: Fri, 26 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #78
To: tcp-group-digest@ucsd.edu

TCP-Group Digest            Fri, 26 Mar 93       Volume 93 : Issue   78

Today's Topics:
                        New nos version PA0GRI

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, 26 Mar 93 10:08:02 MET
From: gvdg@tophat.cdh.cdc.com
Subject: New nos version PA0GRI
To: tcp-group@ucsd.edu

Hello All,
Just before going i loaded my latest work on NOS onto ucsd.edu
Main work lately was on tcp and ip access code. 
The c command help display now correctly displays the possible commands
for the various compile options of mailbox.c
Now i am all set to get "lost" in the big lands and have a good time.
>>For all who wrote me a message: I took all notes with me and use them
as time and place comes by. Freq for simplex is 145.520 (i forgot the
30kc channel space.) Thanks all those responded , to nummerous to get back
to individualy (sorry).
Please have funn, i will.
Regards, Gerard.
-- 
Internet: gvdg@cdc.com                  |     Gerard J van der Grinten
UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
Telephone: 0(+31)-15-153123             |     Olaf Palmestraat 20
                                        |     2616 LS DELFT    Netherlands

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

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

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

Date: (null)
From: (null)
        Start
File    Line       Function                        Description

lapb.c   168       lapb_input           The following code fragment is part of
the processing for
                                        the LAPB_CONNECTED state. 'control'
contains
                                        the complete control field from an
incoming frame, which,
                                        in the case of an RNR, has an N(R)
field. Therefore, the 
                                        control == RNR test fails when the N(R)
field of the RNR
                                        contains nonzero. Change 'control' to
'type' to fix this.

                                 case RR:
                                 case RNR:
                                  axp->flags.remotebusy = (control == RNR) ?
YES : NO;
                                  if(poll)
                                   enq_resp(axp);
                                  ackours(axp,nr);
                                  break;

lapb.c  371        ackours              The ackours() function returns a -1
value to cause a
                                        FRMR if an acknowledgement is received
for an unsent frame.
                                        None of the routines calling ackours
pays any attention to
                                        the return value. Suggest modifying
ackours to send the FRMR
                                        itself:

                                        static int
                                        ackours(axp,n)
                                        struct ax25_cb *axp;
                                        int16 n;
                                        { 
                                           struct mbuf *bp;
                                           int acked = 0; /* Count of frames
acked by this ACK */
                                           int16 oldest; /* Seq number of
oldest unacked I-frame */
                                           int32 rtt,abserr;

                                           /* Free up acknowledged frames by
purging frames from the I-frame
                                            * transmit queue. Start at the
remote end's last reported V(r)
                                            * and keep going until we reach the
new sequence number.
                                            * If we try to free a null pointer,
                                            * then we have a frame reject
condition.
                                            */
                                            oldest = (axp->vs - axp->unack) &
MMASK;
                                            while(axp->unack != 0 && oldest !=
n){
                        >>                     if((bp = dequeue(&axp->txq)) ==
NULLBUF){
                        >>                 /* Acking unsent frame */
                        >>                        sendfrmr(axp, axp->control,
LAPB_RESPONSE, axp->pf, Z);
                        >>                 return -1;
                                             }

                                             Remainder of routine is same. The
arguments to sendfrmr are
                                             the offending packet's control and
pf fields, an indication
                                             that this is a response, and the
reason for the FRMR.
                                             Note: have to add 'control' and
                                             'pf' fields to struct ax25_cb and
fill them with the control
                                             and pf fields of the offending
incoming frame. Also, the X.25 
                                             standard specifies that after
sending an FRMR, the DCE enters into
                                             a frame rejection condition and
waits for a SABM, DISC, or DM
                                             from the DTE (this is an
abbreviated description of what the
                                             standard really says). Suggest
adding the LAPB_REJECT state 
                                             and the processing for it in the
lapb_input function, and have
                                             the sendfrmr function invoke the
LAPB_REJECT state. Also
                                             suggest adding 

                                                  sendfrmr(axp, axp->control,
LAPB_RESPONSE, axp->pf, W);

                                             for the cases where an incoming
frame has a control field
                                             containing an unknown type.


lapb.c   various   lapb_input                The code decides whether the local
station is busy by the
                   enq_resp                  following means:

                                             if(len_p(axp->rxq) >= axp->window){
                                                     /* Too bad he didn't
listen to us; he'll
                                                      * have to resend the
frame later. This
                                                      * drastic action is
necessary to avoid
                                                      * memory deadlock.
                                                      */
                                                     
sendctl(axp,LAPB_RESPONSE,RNR | pf);

                                             _or_

                                             tmp = len_p(axp->rxq) >=
axp->window ? RNR : RR;

                                             The len_p routine only determines
the length of the 
                                             packet at the front of the receive
queue. If multiple
                                             receive packets are queued, they
aren't taken into
                                             account in calculating whether the
window has been
                                             exceeded.

lapbtime.c 95      tx_enq                    The following code fragment is
from the tx_enq routine:

                                              if(axp->txq != NULLBUF
                                               && (len_p(axp->txq) <
axp->pthresh || axp->proto == V1)){
                                               /* Retransmit oldest unacked
I-frame */
                                              
dup_p(&bp,axp->txq,0,len_p(axp->txq));
                                               ctl = PF | I | (((axp->vs -
axp->unack) & MMASK) << 1)
                                                | (axp->vr << 5);
                                              
sendframe(axp,LAPB_COMMAND,ctl,bp);
                                              } else {
                                               ctl = len_p(axp->rxq) >=
axp->window ? RNR|PF : RR|PF; 
                                               sendctl(axp,LAPB_COMMAND,ctl);
                                              }

                                              A condition can arise wherein a
transmit packet has been put on
                                              axp->txq, but transmission not
initiated because lapb_output()
                                              found that axp->flags.remotebusy
indicated that the remote station
                                              is busy. In this case, if
tx_enq() is called by recover() or
                                              pollthem(), txq will be non-null,
and the I frame could be transmitted.
                                              This is incorrect behavior when
the remote is busy. If by chance
                                              the remote has become unbusy
between the time of the lapb_output()
                                              failure and the call to tx_enq(),
the tx_enq() transmission of the
                                              I frame doesn't increment
axp->vs, and axp->unack is zero, so an
                                              acknowledgement by the remote
will not be processed properly by
                                              ackours();

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

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

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

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