Date: Wed, 13 Oct 93 04:30:05 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 #266
To: tcp-group-digest
TCP-Group Digest Wed, 13 Oct 93 Volume 93 : Issue 266
Today's Topics:
Log file not written after crash in KA9Q NOS
NetRom Protocol info wanted
NOS telnet echo option problem?
Packet FTP Site
SMTP transparency
TCP-Group Digest V93 #265
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, 12 Oct 93 23:59 PDT
From: bob@nyssa.wa7ipx.ampr.org (Bob Finch)
Subject: Log file not written after crash in KA9Q NOS
To: tcp-group@ucsd.edu
In recent versions of KA9Q NOS, the log file is not written out when
NOS crashes. The following patch fixes this.
73 -- Bob
===================================================================
RCS file: /usr3/bob/radio/cvs/ka9q/dos.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 dos.c
*** /tmp/T0a29743 Tue Oct 12 22:27:59 1993
--- dos.c Sun Oct 10 11:30:14 1993
***************
*** 208,215 ****
errno = EINVAL;
return -1;
}
! if(--Refcnt[fd] != 0)
! return 0; /* Somebody else is still using it */
regs.x.bx = fd;
regs.h.ah = 0x3e;
intdos(®s,®s);
--- 208,228 ----
errno = EINVAL;
return -1;
}
! if(--Refcnt[fd] != 0) {
! /*
! * Somebody else is still using it. Dup and close it
! * to make sure the file is written out.
! */
! regs.x.bx = fd;
! regs.h.ah = 0x45;
! intdos (®s, ®s);
! if (regs.x.cflag) {
! if (regs.x.ax < NERROR)
! errno = _ioerr[regs.x.ax];
! return (-1);
! }
! fd = regs.x.ax; /* close the duped file */
! }
regs.x.bx = fd;
regs.h.ah = 0x3e;
intdos(®s,®s);
------------------------------
Date: Tue, 12 Oct 1993 21:38:13 -0600 (MDT)
From: William Ti Baggett <wbaggett@nmsu.edu>
Subject: NetRom Protocol info wanted
To: TCP-Group@ucsd.edu
Hello,
I am an engineering student and I am writing a paper on the routing
methods of AX.25, NetRom and TCPIP. In intend to describe how each
protocol routes packets and compare the differences between them.
I am particularly looking for a Net/Rom spec document, but would also be
interested in finding further information on AX.25, TheNet, and TCP/IP.
FTP sources, addressed, and or phone numbers would be greatly appreciated.
Thanks,
Tim, AA5DF
(Reply to me direct if possible)
********************************************************************
Tim Baggett, AA5DF Electrical Engineering Student
New Mexico State University
Internet: WBAGGETT@DANTE.NMSU.EDU
AMPR: AA5DF@NMSUGW.AMPR.ORG US Snail: 1970 Buchanan Avenue
Twisted Pair: (505) 523-6829 Las Cruces, NM 88001
********************************************************************
------------------------------
Date: Tue, 12 Oct 93 1:44:42 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: NOS telnet echo option problem?
To: tcpgroup@ucsd.edu
I've noticed a problem in the way the NOS telnet server handles echo option
negotiation when talking with a LINUX telnet client. Here's a typical option
trace:
--------
Will show option processing.
telnet> open 44.14.10.43
Trying 44.14.10.43...
Connected to 44.14.10.43.
Escape character is '^]'.
SENT DO SUPPRESS GO AHEAD
SENT WILL TERMINAL TYPE
SENT WILL NAWS
SENT WILL TSPEED
SENT WILL LFLOW
SENT WILL LINEMODE
SENT WILL ENVIRON
SENT DO STATUS
KA9Q NOS (wh6aq.ampr.org)
login: ah6bw
RCVD WILL ECHO
SENT DO ECHO
Password: RCVD WONT ECHO
SENT DONT ECHO
[JNOS-1.10x9-HM$]
-----------------
In the above, NOS is setup with 'echo accept' (the default). LINUX
receives from NOS a WILL ECHO which it acknowledges, but AFTER I enter the
password, NOS then sends a WONT ECHO and LINUX goes into a local echo mode.
Ordinarily this wouldn't be too bad but anytime a carriage return is
entered a '^M' is displayed.
On the one hand if 'echo accept' is in effect, why should NOS be
sending a WONT ECHO in the first place?
On the other hand, it it says it WONT ECHO, why does it make an
exception for the carriage return?
I'm sooo confused. Is there a way to work around this problem without
having to resort to line mode in telnet?
Antonio Querubin
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet
------------------------------
Date: Tue, 12 Oct 93 17:23:25 EDT
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: Packet FTP Site
To: nos-bbs@hydra.carleton.CA
I now have a fulltime FTP server online that will carry the latest
code, as I get it, from UCSD, WG7J and others. It is a Windows NT
FTP server. It's domain name is 'crompton.nadc.navy.mil' with an
IP address of 138.60.14.19.
Feel free to use it for updates. There is also an incoming R/W directory
for file transfer. Structure is /pub/incoming, /pub/packet/...
Since this site is on the MILNET, via a net 26 cisco router, access
times may at times be slow to sites outside of MILNET. Let me know
if you experience problems.
Doug
------------------------------
Date: Tue, 12 Oct 93 11:38:13 MET
From: pa0gri@tophat.cdh.cdc.com
Subject: SMTP transparency
To: tcp-group@ucsd.edu
Hello All,
I do read a conflict in the RFC:
1) on send: insert a dot if the first char is a dot.
2) on rec: delete a leading dot (no matter what follows).
Case 1 inserts a dot only is a dot is on the line, so for the wanted
transparency the case ends up to only have a .. on reception.
THERE WIL NEVER be a case of .ANYTHING else as a ..ANYTHING on reception.
The old smtp server is correct in looking at a ".." case for reading
but just finding the first thing on a line is "." is sufficient.
. (test case , 1 dot on this line)
.. (now there are two.)
Regards, Gerard.
PS, will check what I have left on sources.
------------------------------
Date: Tue, 12 Oct 93 20:04:06 -0700
From: Johan. K. Reinalda <johan@ECE.ORST.EDU>
Subject: TCP-Group Digest V93 #265
To: TCP-Group@UCSD.EDU
this with regard to lzw compression:
-as far as i am aware the step you outline should to it jack, other then
adding some handshaking between the 2 sides to agree on using it and, the
number of bits to use...
I am not sure adding it to pop3 is a good idea, since that would lead
to non-conforming code. But for a single instance i guess, whatever :-)
The short packets probably have to do with the sockets being flushed all
over the place to send responses when they are needed. Then what ever
data outstanding (short packet from the comporession) will be send...
It should be rather trivial to add compression to all sockets on a system.
Simply hardcode the bits size etc, and add a call to lzwinit() at the
enbd of the socket() call ...
73
Johan
------------------------------
End of TCP-Group Digest V93 #266
******************************
******************************