Programmer 7500/MAX_PROGRAMMERS.iso/PROGRAMS/UTILS/HAMRADIO/TCP90135.ZIP/TCP90135.TXT

Internet Message Format | 1990-09-14 | 14.7 KB

Path: tosspot!indep1!pete
From: [e-mail] (Peter Franks)
Newsgroups: to.tosspot
Subject: TCP Digest #135
Message-ID: <[e-mail]>
Date: 14 Sep 90 01:25:59 GMT
Reply-To: [e-mail] (Peter Franks)
Followup-To: to.tosspot
Distribution: to
Organization: as little as possible
Lines: 377

TCP-Group Digest            Tue, 11 Sep 90       Volume 90 : Issue 135

Today's Topics:
                            Administrivia
                           Choosing an SSID
                              Mailbox ID
                        RSPF problems (3 msgs)
                           SSID's (2 msgs)
                    SSIDs and NETROM IDs  (5 msgs)
                            SSIDs in Italy
                        TAPR 1.1.7 KISS broken

Send Replies or notes for publication to: <[e-mail]>
Send requests of an administrative nature (addition to, deletion from the
distribution list, et al) to: <[e-mail]>

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
----------------------------------------------------------------------

Date: Mon, 10 Sep 90 08:44:38 -0700
From: brian (Brian Kantor)
Subject: Administrivia
To: tcp-group

Will whoever is redistributing or forwarding this mailing list to a uucp
site 'nipper' please stop.  The mail is bouncing.

Note that if you are forwarding or redistributing this mailing list, you
MUST arrange that errors caused by your actions go to YOU and not to me.
If you don't know how to do that, you've got no business redistributing
the damn list!
    - Brian

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

Date: Mon, 10 Sep 90 10:28:47 EDT
From: [e-mail] (Marshall Jose)
Subject: Choosing an SSID
To: [e-mail]

Jeff writes:

> ....
> -15 The first hop from a netrom.
>
> The -9 for TCP/IP and Netrom is because initially most connects
> to the TCP/IP stations were via Netrom connections.
>
> It seems that -7 is the international designation for KA-Nodes.

As I understand Net/Rom transport, an AX.25 station's SSID will be
complemented and used as the call for transport on the first hop.
I noticed this when I connected to a Net/Rom node as WA3VPZ-1, and
saw my call "repeated" as WA3VPZ-14.  Presumably no further complements
occur as additional hops are initiated.

So:  Using -8 as the TCP/IP designator gives a complement of -7,
possibly conflicting with KA-Nodes.  And so on.



Marshall Jose  WA3VPZ
[e-mail]  ||  ...mimsy!aplcen!aplvax!mjj

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

Date: Mon, 10 Sep 90 15:10:57 EDT
From: rutgers!wb3ffv.ampr.org!howardl (Howard Leadmon - WB3FFV)
Subject: Mailbox ID
To: [e-mail] (D. Crompton)

   Hello Doug,

> A local BBS operator has requested that the NOS BBS ID be changed
> from [NET-$] to [NET-H$] - this was done in net towards the end but
> somehow got lost in NOS.

So tell us, what is the difference between [NET-$] and [NET-H$] ??
I have seen the first, but the inclusion of the H is new to me...

-------------------------------------------------------------------------------
Internet  : [e-mail]    |    Howard D. Leadmon
UUCP      : wb3ffv!howardl        |    Advanced Business Solutions
TELEX     : 152252474             |    210 E. Lombard St - Suite 410
Telephone : [phone]        |    Baltimore, MD  21202

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

Date: Mon, 10 Sep 90 07:37:12 PDT
From: "k1io@FN42jk  10-Sep-1990 1027" <[e-mail]>
Subject: RSPF problems
To: [e-mail]

Look at the bright side:  You're making history just trying it.
Unlike TCP and IP, RSPF was designed for packet radio use, and nobody
has ever coded it before Anders, nor tried it before recently. So
we're really looking at the first lab testbed, and should expect
results accordingly..

That means we're simultaneously debugging the protocol and the
implementations.  I can only comment on protocol issues.  One
question that I think came up last year was about hard-coded routes.
When designing the auto-routing protocol, I wasn't thinking about
manual routing, but it obviously exists and will remain there, at
least until (and probably after) auto routing is dominant.

Should manual entries override or be overriden by RSPF?  I don't
think there's a good answer.  Today, with RSPF still "experimental",
it's probably prudent for the manually-set tables to override whatever
RSPF does.  That means you'll have an RSPF-generated route table
and a manual one, and the manual one wins if it's set. That allows
RSPF to run in "play" mode, without really changing traffic, for
existing routes.  Once RSPF stabilizes, though, you'd probably want
to switch RSPF to become dominant over manual routes; the manual
routes become sort of an initialization value that NOS uses before
RSPF has found better paths.

That probably calls for a parameter so you can choose whether manual
or RSPF dominates.  In any case, the manual table should not be
munged by RSPF.  That's probably bad network theory and it may want
to be changed in the future, but we still have to figure out whether any
given anomaly is code or protocol, so for the moment...
    fred k1io

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

Date: Mon, 10 Sep 90 18:09:33 +0200
From: [e-mail]
Subject: RSPF problems
To: [e-mail] (D. Crompton)

> Maybe someone could explain what we should see? Should we see routes
> added in the route list? Can hard coded routes still exist and not
> be bothered?

Yes you should see new routes appear in the routing table. If you have
any manually entered routes that refer to the same station as the
route generated by RSPF, they will be replaced with the RSPF generated
route. This is a difference between the 2.0 and 2.1 implementations.
Ok, so I introduced a bug here. It turns out that all permanent routes
are being deleted. I have sent Kelvin a patch that fixes this problem.
I have also updated my archive at sics.se.

When it comes to the problem with ARP, that really beats me. I have
just added one single line to arp.c, that is all.

There are some hacks done in the RSPF code to allow broadcasting on
several different interfaces. I hope to clean this upp by adding
multicast support to the IP layer, as specified in RFC-1112. This
would include IGMP (Internet Group Management Protocol.)

Anders

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

Date: Mon, 10 Sep 90 15:43:19 CDT
From: Jay Maynard <[e-mail]>
Subject: RSPF problems
To: [e-mail], [e-mail]

I saw the one-line difference in arp.c, too...Which version of NOS did you
start with when making changes? Perhaps there's a subtle incompatibility there.
I did find two typos in rspf.c - mbuf was spelled mubf in one place, and
router was spelled rotuer. Perhaps I need to snarf the current version of
your archive. One other note: I put the FORTH interpreter in at the same time,
and merged the config.c changes from the RSPF code into that one, since it
matched the original config.c more closely. Why the maxstk value of 200 for
the killer? I put it back to 512. That's all I did to the code... :-)

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

Date: Mon, 10 Sep 90 9:52:21 PDT
From: Brian Lloyd <[e-mail]>
Subject: SSID's
To: [e-mail]

Everyone has a different "standard", "official" SSID's are not part of
the protocol, and it seems unlikely that this group will ever bring
the rest of the world "in line", and . . .

                        does it really matter?

73 de Brian, WB6RQN

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

Date: Mon, 10 Sep 90 15:32:36 EST
From: bill gunshannon <[e-mail]>
Subject: SSID's
To: [e-mail]

>Everyone has a different "standard", "official" SSID's are not part of
>the protocol, and it seems unlikely that this group will ever bring
>the rest of the world "in line", and . . .
>
>                        does it really matter?
>
>73 de Brian, WB6RQN


I thought it was decided a couple years ago (after much heated debate)
that SSID's have no real meaning and attempting to apply meaning to them
was a bad idea.
Or is my memory really that bad??  :-)

bill    KB3YV

                                          bill gunshannon
                                       [e-mail]

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

Date: Mon, 10 Sep 90 7:31:18 CDT
From: Jay Maynard <[e-mail]>
Subject: SSIDs and NETROM IDs
To: [e-mail]

There's not much standard around here, except for TCP/IP users using -8 (and
up for multiple stations). We have no standard for NETROM IDs yet, but I've
proposed one which may gain some acceptance:
Take the low order 24 bits of the IP address. Use the top 4 bits to form one
hex digit, and then take the remaining 20 bits in groups of 5 to make 4
base-32 digits in the range 0-9a-v. Put a leading # to make the name private.
Example: My IP address is 44.76.0.92. This makes:
        44              76              0               92
0 0 0 1 1 1 0 0|0 1 0 0 1 1 0 0|0 0 0 0 0 0 0 0|0 1 0 1 1 1 0 0
(ignore this)  |   4   |    O    |    0    |    2    |    S

This is guaranteed to be unique for all AMPRNET hosts. The bit-twiddling
can be done by a simple C routine, and might even be built into the netrom
commands in NOS. I know there's been a similar scheme mentioned on
Compu$erve, but that one (using the hex representation of the low 16 bits)
would break down at the edges of the assignment areas.

Comments, anyone?


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

Date: Mon, 10 Sep 90 09:51:34 MDT
From: Bdale Garbee <[e-mail]>
Subject: SSIDs and NETROM IDs
To: [e-mail]

> This is guaranteed to be unique for all AMPRNET hosts. The bit-twiddling
> can be done by a simple C routine, and might even be built into the netrom
> commands in NOS. I know there's been a similar scheme mentioned on
> Compu$erve, but that one (using the hex representation of the low 16 bits)
> would break down at the edges of the assignment areas.

> Comments, anyone?
>

We use the hex representation of the low-order 24 bits, and don't use the
leading pound... no value is seen by making IP nodes "private" in the NET/ROM
sense around here.  With six allowable digits of callsign, and the relative
ease of dealing with pure hex, we think this is a win.

So, I'm 200001:N3EUA, aka [44.32.0.1] for the machine on the air.

Bdale

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

Date: Mon, 10 Sep 90 14:18:10 edt
From: [e-mail]
Subject: SSIDs and NETROM IDs
To: [e-mail]

CEO summary:
  There IS a value to having the Net/Scam IDs "hidden".  The
mainstream NET/Scam'ers have a tendency to try to connect to every
node they can find.  If one doesn't want this to happen, one hides it
with the #.  Also, the mainstreamers complain about the size of the
nodes lists.

Cheers.
---
Kurt Freiberger, WB5BBW / voice 713.877.8222 / FAX [phone]
amprnet 44.76.0.1 / PBBS: WB5BBW @ WB5BBW.#HOU.TX.USA.NA
Data General Corp.  Houston, TX / "Anyone for Iraq of Lamb"??
Get someone else's opinion.  I'm keeping mine.

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

Date: Mon, 10 Sep 90 15:35:16 CDT
From: Jay Maynard <[e-mail]>
Subject: SSIDs and NETROM IDs
To: [e-mail] (Bdale Garbee)

> We use the hex representation of the low-order 24 bits, and don't use the
> leading pound... no value is seen by making IP nodes "private" in the NET/ROM
> sense around here.  With six allowable digits of callsign, and the relative
> ease of dealing with pure hex, we think this is a win.

Hm. We use private names to encourage people to use the real TheNet nodes
(we've completely gotten rid of NetScam in the Houston area) instead of going
through the KA9Q leaf nodes. Is this realistic?

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

Date: Mon, 10 Sep 90 14:32:09 MDT
From: Bdale Garbee <[e-mail]>
Subject: SSIDs and NETROM IDs
To: [e-mail]

> CEO summary:
>   There IS a value to having the Net/Scam IDs "hidden".  The
> mainstream NET/Scam'ers have a tendency to try to connect to every
> node they can find.  If one doesn't want this to happen, one hides it
> with the #.  Also, the mainstreamers complain about the size of the
> nodes lists.

Ok, what you're really saying is that you've responded to pressure from the
"locals".  That's fair.  Here, the majority of use of the NET/ROM "network"
(note carefully placed quotation marks!) is for TCP/IP and PBBS forwarding...
and our node population and configuration is such that it's a pain to get
anything useful in the nodetable... size has never been an issue.

I hate running IP over NET/Wrong, but we've got a lot of work left to do before
I can kiss it off forever...

Bdale

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

Date: Mon, 10 Sep 1990 17:30:37 EDT
From: [e-mail]   (Luca Bertagnolio, IK2OVV)
Subject: SSIDs in Italy
To: [e-mail]

Folks,
here is the "standard" for SSIDs in Italy (in quotes because this is most
used, but there are also others in use):
-0 standard terminal AX.25 (eg. cmd:)
-1 PBBS (eg. PacCom PMS, Kantronics) built-in on the TNCs
-2 dumb AX.25 gateways (UHF-VHF)
-3 KAnodes
-8 PBBS (RLI, MBL, etc.)
Also, Net/ROM and TheNet use -2 for the 2-meter band, -7 for 70 cm and
-12 for 1.2 GHz.
As you can see the SSID for TCP/IP is not fixed, partly because of the
lack of someone coordinating the effort; IMHO, 1200 bps is too slow a speed
for TCP/IP, you will always have a stupid guys setting the parameters in
his fashion, and collapsing the net.
Anyway, Brian, you are right! ;-)
73, Luca
Milan, Italy

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

Date: Mon, 10 Sep 1990 17:24:04 EDT
From: [e-mail]   (Luca Bertagnolio, IK2OVV)
Subject: TAPR 1.1.7 KISS broken
To: [e-mail], [e-mail]

Mike et al,
Stefano IK2OYD here in Milan has just finished to make some tests on
the code; it *definitely* is broken, because when you run half-duplex
the delay introduced by the persist is waited, the the TNC goes in TX.
With full-duplex on you always get an instant TX, no matter of the persist
(and that's OK).
So, who's the guy willing to fix this? Also, is the source for this code
available somewhere?
73, Luca

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

End of TCP-Group Digest
******************************

--
+------------------------------------------------------------------------------+
|  Peter Franks  |          [e-mail]  OR  [e-mail]          |
|      NI9D      |                   Use whichever one works                   |
+------------------------------------------------------------------------------+