Date: Fri, 21 May 93 04:30:07 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 #131
To: tcp-group-digest
TCP-Group Digest Fri, 21 May 93 Volume 93 : Issue 131
Today's Topics:
ENCAP packets not recognized properly?
KA9Q Flavor Supporting CD-ROMs??
MORE on "ENCAP Packets not recognized properly?"
TCP-Group Digest V93 #130 (2 msgs)
Thenet X-1H
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: Thu, 20 May 93 17:41:41 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: ENCAP packets not recognized properly?
To: tcp-group@ucsd.edu
As some of you may know, the Salt Lake Gateway has been up (in one form or
another) since January, 93. Almost from the beginning, though, we were unable
to RECEIVE encap frames: We could send them back, but they got tossed in
the bit-bucket before they got to our doorstep.
FINALLY (a bit more than a month ago) it was figured out what was wrong.
The University of Utah has CISCO servers and SOME filtering (necessary
security) the HAD to remain in place. This is the preliminary analysis
of the problem by the system admin. that located (and fixed) the problem:
---------------- plagiarize mode: ON ----------------
From: zeleznik@cs.utah.edu (Mike Zeleznik)
Date: Thu, 20 May 93 17:24:40 MDT
Subject: UDP issue
Clint had asked about the reason packets were not getting through earlier.
The reason is that I thought they were supposed to be user datagram
protocol (UDP) packets, but for some reason neither the cisco nor Suns
etherfind recognizes them as such. I have not had time to really look at
them with the Sniffer, but my guess is that they are not following one or
more of the rules for UDP packet formation. Perhaps the way they calculate
the checksum? (UDPs require a strange way of doing this, by prepending a
pseudo header that includes the src/dst IP addrs and such).
Of course, they do not HAVE to be UDPs. I am just saying that if you
expect that they are, they aren't.
Mike
-------
---------------- plagiarize mode: NON-ON -------------
I believe that the solution was to allow any ip and udp packets to get to
us.
It should be noted that the ***ONLY*** modes affected were those that
encapsulated packets for AXIP and ENCAP use. We have ALWAYS been able to
use SMTP, FTP, CONVERS, FINGER, etc. etc.
Comments?
(Hey, PLEASE don't flood Mike with comments! :-)
<Clint>
------------------------------
Date: Fri, 21 May 93 11:44:52 +0200
From: jt@fuw.edu.pl
Subject: KA9Q Flavor Supporting CD-ROMs??
To: tcp-group@ucsd.edu
> From: moore@email.ncsc.navy.mil (Moore)
> Message-Id: <9305171236.AA17368@email.ncsc.navy.mil>
> Subject: KA9Q Flavor Supporting CD-ROMs??
> To: tcp-ip@nic.ddn.mil
> Date: Thu, 13 May 1993 14:33:16 -0700 (PDT)
>
> Someone pointed me to this list as the folk to ask for a flavor of
> KA9Q-NOS that supports a change drive command under FTP, so that (for
> instance), I can hook up a CD-ROM to the KA9Q server and let people
> pull files off the CD-ROM disc. Is this a FAQ? Can someone point me
> to a compiled version that'll handle this? I'm interested in Ethernet
> interface, don't really care about mail or pop.
I'm just the man who made it, on begin of 1992. Unfortunately, I still
use GRINOS 1.8b on zfja-gate and newest version I tried is GRINOS 2.0m -
hope I can find some executable if need...
> Date: Tue, 18 May 1993 21:34:43 +1000
> From: Terry Dawson <terryd@extro.ucc.su.OZ.AU>
> Message-Id: <199305181134.AA25764@extra.ucc.su.OZ.AU>
> To: tcp-group@ucsd.edu
> Subject: NOS support for other drives
> Status: RO
>
> Actually, I'd quite like to see an implementation of the approach that
> has been taken by some companies that produce pc based NFS servers,
> that being for the drive to be prepended to the filepath as top level
> directory.
>
> for example: c:\pub\filename.txt becomes /c/pub/filename.txt
>
> much more elegant in my opinion, and it doesn't break any existing
> software at all.
Thanks, Terry, it is nice idea to simplify path parsing, in permcheck()
for example. However, one of DOS advantages (not implemented in NOS, but
possible in future) is ability to "cd" separately on every drive - it is
great advantage when using pathes 50 characters long, to type just "d:"
instead something like "cd /d/pub/hamradio/packet/tcpip/incoming".
Some ideas I have now: use "cd /d/" or "cd /d/$" to change actual
directory to first allowed on drive "d:", or use "cd /d/$1", "cd /d/$2"
to select directories specified in "/ftpusers" for drive "d:", or even
allow "cd /pth/$3" to select 3-rd of pathes matching "/pth/*"; and keep
few lastly used pathes to allow "cd /pth/*" to select one of them.
> Date: Tue, 18 May 93 10:03:59 -0700
> From: karn@qualcomm.com (Phil Karn)
> Message-Id: <9305181703.AA06614@servo>
> To: tcp-group@ucsd.edu, terryd@extro.ucc.su.OZ.AU
> Subject: Re: NOS support for other drives
> Status: RO
>
Phil suggests use of "join" and asks if networks drives still cannot be
joined under DOS 6.0; under 5.0 they cannot as well as under previous.
> Date: Thu, 20 May 1993 08:42:39 +1000
> From: Terry Dawson <terryd@extro.ucc.su.OZ.AU>
> Message-Id: <199305192242.AA28334@extra.ucc.su.OZ.AU>
> To: tcpgroup@ucsd.edu
> Subject: Re: Re: NOS support for other
> Status: RO
>
> Absolutely, I've used 'join' quite successfully on a couple of occasions,
> but my thought was that if such a scheme were employed within NOS such that
> it performed the necessary translations, then the limitations of 'join'
> and its genre, with respect to networked and other special or virtual
> drives would be overcome without exception.
>
> To take this one step further, and while it seems a little kludgy, perhaps
> a 'mount' command could be built into NOS such that you could 'mount' a
> device:filesystem onto anywhere else. All I guess this would really entail is
> for NOS to keep a translation record somewhere, and for it to parse each
> filname it is given, and performing the necessary translations to real
> drives:subdirectory.
>
> If noone else wants to do it, and there is enough demand for it, I'll look
> at coming up with an implementation. It seems to me that it should be
> fairly trivial to do.
I would think about something like DOS SUBST: "SUBST J: C:\USER\JT"
causes directory "C:\USER\JT" with all subdirectories to be seen as
a DOS drive; the SUBST is an utility program which changes tables in
memory, not a system call in MS-DOS or PC-DOS, in DR DOS it is same
system call as "CD" - "SUBST J: C:\USER\JT" is "CD J:=C:\USER\JT".
Since, some idea - "/ftpusers" can specify pathes in form like:
/in=C:/USER/NOS/FTP/INCOMING 3 /pub=C:/USER/NOS/FTP/PUB 1 /cdrom=E:/ 1
and remote user should see disk with directories /in, /pub, /cdrom
It should be quite easy to implement if restricted to FTP server only.
A more advanced idea: every fopen() in NOS should pass through function
which checks path and makes substitutions and alse verifies if a task
trying to open file has a privilege to access it; every task should
either use its own data structure specifying substitutions/permissions
or use some global structure by fopen(name,"gr"); no more need to use
permcheck() explicitely - the check should be internal to fopen().
Perhaps can use name like nfopen() anywhere in NOS, and write sth like:
FILE *nfopen(name,access)
char *name,*access;
{ char *realname;
struct taskperm *perm;
FILE *fd=NULLFILE;
if (*access=='g'){
access++;
perm=&global_permissions;
}else perm=current_task->permissions;
if((realname=substitute_filename(name,access,perm))==NULLCHAR)
sprintf(error_message,"... No permission to access file %s\n",name);
else if((fd=fopen(realname,access))==NULLFILE)
sprintf(error_message,"... File %s open error: %s\n",
name,strerror(errno));
return(fd);
}
Some important note about permission check: when several patterns given,
e.g. /pub 1 /pub/incoming 3, use longest matching pattern, not first
matching (I take 1st matching in my code, result is I cannot define
"incoming" directory under guest login directory to make the guest
read-only and the "incoming" writeable; don't repeat my error!).
73's, JT
------------------------------
Date: Thu, 20 May 93 21:30:03 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: MORE on "ENCAP Packets not recognized properly?"
To: tcp-group@ucsd.edu
Here is more info:
From: zeleznik@cs.utah.edu (Mike Zeleznik)
Subject: Unknown protocol
I see the root of my confusion.
I just captured some stuff with Etherfind. The IP protocol type I believe
you are using for the pings is 94 (IP within IP), not 7 (UDP).
To eliminate confusion you would be correct to say you are communicating
via "IP Datagrams" (which is anything carried in an IP packet), but not to
say "User Datagrams" since that implies the User Datagram Protocol (UDP)
which is a specific protocol type indicated in the IP packet. The latter
is what I thought you were using.
Things make MUCH more sense now.
This *might* explain a few things...
73
<Clint>
------------------------------
Date: Thu, 20 May 93 12:21:23 GMT
From: jbloom@arrl.org (Jon Bloom KE3Z)
Subject: TCP-Group Digest V93 #130
To: TCP-Group@UCSD.Edu
>This leaves your proposal to actually write a protocol specification for
>netrom. I considered this, but I am not sure how well received it would
>be in the mainstream community of netrom protocol implementors, especially
>if were issued unilaterally by the TCP/IP community. I am also not too
>sure how far we could get away with standardizing. For example, I doubt
>that any attempt to define and specify the function of the acknowledgment
>timers would fly, since no matter what we did, all but one of the existing
>implementations would be declared non-compliant.
I'll go on record here that if you (or someone else) puts together a
suitable protocol spec, I'll print it in QEX. That's sufficiently
public (you can get a photocopy of any article by calling ARRL HQ)
that it should serve the purpose.
I would think the major NET/ROM implementors should be asked to
participate in drafting the document, or at least in reviewing it
pre-publication. In the process, perhaps they would come to agree
on fixes for some of the existing incompatibilities.
>At a minimum, a specification document would allow us to standardize on
>terminology. There are a lot of subtle issues that we could at least
>document across implementations. For example, G8BPQ decrements the
>obsolescence counter on a route when the NODES broadcast is sent, locking
>the timing intervals together, while NOS runs a separate "netrom obsotimer"
>timer for this purpose. Nevertheless, this threatens to be a horrendous
>task if the document is to be accurate enough to attain credibility.
Agreed. If NET/ROM continues to burgeon, though, this is worth doing.
(It also would make clear to the non-TCPers that the TCP/IP folks are
not their enemies.)
------
Jon Bloom, KE3Z | jbloom@arrl.org
American Radio Relay League |
225 Main St., Newington CT 06111 |
------------------------------
Date: Thu, 20 May 1993 20:53:19 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: TCP-Group Digest V93 #130
To: jbloom@arrl.org, tcp-group@ucsd.edu
All right... assuming that we were to take on the job of writing a
netrom standards document, who should be explicitly consulted? I
suppose WA8DED and G8BPQ are obvious choices, but who after that?
And are they mailable on the Internet?
By the way, what would we call the protocol? "NET/ROM" is supposed
to be a trademark, regardless of its history, and I don't like the
idea of writing a public standard for a proprietary protocol. (Note
that Software 2000, as far as I know, never attempted to claim that
the protocol itself was proprietary, as distinct from their EPROM
code implementation.)
Another big problem is the level at which the standard would apply.
It seesm pretty obvious that any meaningful standard would have to
specify frame structures and the like, but what about implementation
details which have network wide significance? Netrom is notorious
for these things. G8BPQ, for example, defines lots of dangerous
extensions to the protocol, such as QUALADJUST, which operate wholly
within the software but which affect the whole neighborhood. Would
the standard address issues such as this?
Would we take on the user interface in the standards document? Why
does "I" get you a paragraph of [I]nformation from G8BPQ, yet mean
[I]dentify to a real NET/ROM node? Why does "S" mean [S]ystem to
G8BPQ and [S]ysop to TheNet? And, of course, my personal favorite,
"C <port> <callsign>" for G8BPQ and nothing else.
Another winner is the serial async ("back end") port on NET/ROM and
TheNet TNCs. The latest fashion up here, using a scheme adopted by
the Notheast Digital Association (NEDA), is to define the relative
quality across the diode matrix as 203. In other words, one port of
a wireline connected system would know about each other port of the
same wireline connected system at less than perfect quality. This
obviously has no basis in reality, and is used as a kludge method to
limit the propagation of nodes. However, G8BPQ has no way to do this,
since G8BPQ has a weird notion that you never lose packets when moving
them from one port to another on the same machine. Is the lack of
this rather odd (if not foolish) capability to be counted against
G8BPQ when determining its compliance?
I've had a cold for the last week, and I have, as a result, had far
too much time to spend on my e-mail.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Fri, 21 May 1993 16:46:27 +1000
From: makinc@hhcs.gov.au
Subject: Thenet X-1H
To: tcp-group@ucsd.edu
Is anyone using this software?
We're trying to get it running and are having some problems.
Mainly, it seems to be trying to use some sort of bogus digipeater address
when repeating IP frames. We've added ARP entries but they don't seem to
be recognised! Is there some magic incantation or dance ritual to perform?
We'd like to contact someone who has installed and is running one of these
to find out more on how to do it. :-(
Carl,
Canberra Amateur Packet Radio Group.
--
Carl Makin (VK1KCM) Systems Programmer
Internet: makinc@hhcs.gov.au
Amprnet: vk1kcm@vk1kcm.act.aus.oc
Work Phone: +61 6 289-8443
------------------------------
End of TCP-Group Digest V93 #131
******************************
******************************