🚀 go-pugleaf

From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Thu, 6 Jun 91 10:04:02 EDT
Subject: PA0GRI PARAM CODE


Yes the param code is broken in 0531 PA0GRI and Gerard will fix it in the
next version.

In most cases (Kantronics is an example) the param code is not even required.
The txd,slot and persist can be perm'ed into the tnc along with kiss mode
on, and no requirement exists to resend it again from NOS. 


Doug


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Thu, 6 Jun 91 10:06:05 EDT
Subject: Re: param command broaken

Thanks for the update on the problems Gerard. You did fail to mention
one thing though - does the fkey code eliminate the F3 last command recall
or has this been changed to something else. It would be nice to retain
that feature, or even nicer to allow it to recall multiple last commands.

Doug


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Thu, 6 Jun 91 11:42:14 EDT
Subject: Re: nos 0531 from pa0gri

Tony,

   Yes Gerard pointed out that '^m' in the text gives a return. I checked
and as you pointed out - fk 59 "ping ka9q^m" and fk 59 "ping ka9q\r"
are equivalent. The second '\r' version displays a '^m' when displaying
what is assigned to the key - 'fk 59'

 I noticed that there is new rspf code at thumper - also a late nos
release. Maybe the new code corrects the problem you mentioned.

Doug


----
From: ben@val.uucp
Date: Thu, 06 Jun 91 00:34:00 -0500
Subject: Re: 0531 PA0GRI

I found the problem with the param command in the latest from Gerard.
Somehow a line was deleted that should not have been. Kiss_ioctl was
never getting the correct value of the parameter.

Use patch to apply this diff to MAIN.C[doparam()]:
-----------CUT HERE------------

*** omain.c
--- main.c
**************
*** 409,414
  		val = 0L;
  	} else {
  		set = TRUE;
  	}
  	val = (*ifp->ioctl)(ifp,param,set,val);
  	if(val == -1){
--- 409,415 -----
  		val = 0L;
  	} else {
  		set = TRUE;
+ 		val = atol(argv[3]);
  	}
  	val = (*ifp->ioctl)(ifp,param,set,val);
  	if(val == -1){

-------
Ben Thornton             packet:  wd5hls@wd5hls.ampr.org
Video Associates       Internet:  ben@val.com
Austin, TX                 uucp:  ...!cs.utexas.edu!val!ben


----
From: gvdg@tophat.cdh.cdc.com
Date: Thu, 6 Jun 91 16:33:55 MDT
Subject: Re: param command broaken

> 
> Thanks for the update on the problems Gerard. You did fail to mention
> one thing though - does the fkey code eliminate the F3 last command recall
> or has this been changed to something else. It would be nice to retain
> that feature, or even nicer to allow it to recall multiple last commands.
> 
> Doug
> 
Hello Doug,
You guessed it, it is gone. It should be possible to retain the last command
line and reuse it (multiple even) I dont like the f3 key for this as it
is "in the middle of nowhere" and f1 and f2 dossismsh are not there eighter.
Perhaps i think of something later and try it.
Note : the netrom save and reload are not functional!!! just the start of
something.......
Regards, Gerard.

-- 
Internet: gvdg@gvdgpc.cdh.cdc.com       |     Gerard J van der Grinten
UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
Telephone: 0(+31)-70-3119703            |     Van Markenlaan 5
                                        |     2805 VL RIJSWIJK    Netherlands


----
From: mwester@sunbird.Central.Sun.COM (Mike Westerhof SE Chicago Metro)
Date: Thu, 6 Jun 91 12:06:26 CDT
Subject: Re: mfj-2400 baud modem

Dave,
  A group of us in Chicago have been using the 2400-baud modems for some
time now.  Some observations:

  The packet size must be increased.  We run 512 bytes for the MTU on the
2400 baud TNCs, and the window size is also increased (if I recall correctly,
tcp mss 472 and tcp window 944 along with the 512 MTU on the attach command
was required).

  The baud rate between the host and the TNC is a larger factor -- 9600 baud
is exclusivly used here.  16550A chips make the difference.

  The tapr DCD mod is perhaps the worst possible thing to do to the 2400
baud modem!  Take it out!  The modulation scheme used by the 2400 units
will not reliably trip the tapr DCD.  I used to run the tapr DCD with the
squelch open on 1200 baud, but on 2400 baud I have found using the radio's
RF squelch to trip the DCD to be the most reliable way.  If you must use
the normal DCD, align the tones using the 1.1.7 techniques using the 2400
modem.

I suspect this is why you have to double your TXD and tail delays.

We did not double throughput here, but it was satisfying to see an FTP
transfer of >100Kbytes report a rate of 121bytes/second.

Final comment:  We share the channel with 1200 baud users.  Although all the
2400 users can reliably detect both 1200 and 2400 signals, many of the 1200
users cannot detect 2400 baud (misadjusted tones, the tapr DCD mod, or
software DCD detection, I suspect) and tromp all over 2400 baud traffic!

73,

Mike, KA9WSB
Mike.Westerhof@Central.Sun.COM


----
From: Marcus (M.D.) Leech <MLEECH@BNR.CA>
Date:  6 Jun 91 15:14:00 EDT
Subject:  Any other packeteers going to Usenix Nashville?

Doug Yuill (VE3OCU) will be at the Usenix conference at Nashville, staying
  at the Sheraton Music City.

Any other TCP/IP Packeteers going to be there?
--
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs


----
From: Anders.Klemets@cs.cmu.edu
Date: Thu, 6 Jun 91 18:19:46 -0400 (EDT)
Subject: Re: Any other packeteers going to Usenix Nashville?

> Doug Yuill (VE3OCU) will be at the Usenix conference at Nashville,
> staying  at the Sheraton Music City.
> Any other TCP/IP Packeteers going to be there?

I'll be at the Shoney's Music Inn, apparently across the street from the
Opryland conference hotel.

Anders


----
From: Anders.Klemets@cs.cmu.edu
Date: Thu, 6 Jun 91 17:27:38 -0400 (EDT)
Subject: Re: nos 0531 from pa0gri

> Our stations here will try to ping the
> broadcast IP address (in this case 44.14.1.255) over and over again. 

Hmm, are you having a 32 bit wide route for 44.14.1.255 in the routing
table? RSPF probably thinks it is a host route. But you should be able
to accomplish the same functionality by using a less specific routing
entry, such as [44.14.1.0]/24. That will solve the problem, because RSPF
only tries to ping host routes. (Kinda hard to ping an entire network.)

> Eventually it gives up and marks the entry as 'bad' in the rspf tables,
> but it doesn't drop the arp entry thank goodness!

What is this about having an arp entry for a broadcast address?
Broadcast packets will not be received by other NOS'es unless they are
sent to "QST-0" or "NODES-0." Since the former is the default AX.25
broadcast address you do not need to add it to the arp table.

Anders


----