Date: Sun, 21 Feb 93 04:30:10 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 #49
To: tcp-group-digest
TCP-Group Digest Sun, 21 Feb 93 Volume 93 : Issue 49
Today's Topics:
56k modems, P.I. cards, and authentication
Anyone got a vanilla copy of grinos 2.0J source?
Death of AX.25
FEC in amateur radio
new firmware?
NOSintro - TCP/IP over Packet Radio
redoing amateur packet
stat() in Borland C++
Uncle! UNCLE! (Problem with FTP on NET)
WG7J breaks PPP?
WG7J v1.07 breaks PPP?
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, 20 Feb 93 12:48:25 PST
From: jmorriso@ee.ubc.ca (John Paul Morrison)
Subject: 56k modems, P.I. cards, and authentication
To: tcp-group@ucsd.edu
(I just unsubscribed to tcp-group, but I'm still on tcp-group-digest,
hopefully this won't bounce)
I was looking at KA9Q's talk about FEC and the 56k modems. I'd like to
add another suggestion: an encryption scheme for the packets that will
allow at least host and user authentication (this sort of encryption
is legal, ie control info. encryption of content is not legal in the
amateur bands).
the authentication will have to go into every packet, and it must encrypt
the time and/or packet order, to prevent faking of users or hosts merely
by replaying saved packets. the encryption should be quick, yet robust.
it should be some kind of public key system, so people can identify you,
but they can't impersonate you. I haven't looked at these methods before,
but I imagine Kerberos, the host authentication and security stuff for
NFS might have some info.
the authentication is important if an internet 'wormhole' is established.
(since Internet won't like having riff-raff invading the networks)
On another topic: can anyone recommend a test procedure for the Ottowa
Packet Interface (PI) cards? These are the HDLC controllers that let an
IBM PC talk to the 56k modem. We have been having a bitch of a time with
them.
VE7JPM
__________________________________________________________________________
John Paul Morrison |
University of British Columbia, Canada |
Electrical Engineering | .sig file without a cause
jmorriso@ee.ubc.ca VE7JPM |
________________________________________|_________________________________
------------------------------
Date: Sat, 20 Feb 93 21:54:42 +0100
From: jt@fuw.edu.pl
Subject: Anyone got a vanilla copy of grinos 2.0J source?
To: root@thed.uk22.bull.com, tcp-group@ucsd.edu
I have it on zfja-gate.fuw.edu.pl (148.81.6.100). FTP, login as "nos"
with any password, and "cd /user/jt/pa0gri". Unfortunately, our link
to internet is 72kbaud only and it is >800kB file - will take some time.
73's, JT
------------------------------
Date: Sat, 20 Feb 93 19:41:40 CST
From: jimh%kd4ldo.tcman.ampr.org@skeggi.vware.mn.org
Subject: Death of AX.25
To: tcp-group@ucsd.edu
Heh...I guess that if they want to make people learn Morse code to use
unattended packet, maybe they should require people who use CW to learn
something about computer programming! That would make just as much sense.
Maybe we need to either a) all join the ARRL and overturn this nonsense, or
b) form our own group. The second option could prove conterproductive, but
IMHO, we can't let people who don't use/understand packet to set rules and
regulations for its use. That would be like allowing me to make rules about
height restrictions for military aircraft...
----
Jim Henderson, KD4LDO/W0 jimh@kd4ldo.ampr.org [44.94.249.38] on 144.99 MHz
Crystal, MN Internet: jimh%kd4ldo@skeggi.vware.mn.org
CIS: 71321,1461 Alt. Internet: hendersj@alpha.db.erau.edu
"Don't ask me how it works or I'll start to whimper!" - Arthur Dent
------------------------------
Date: Sat, 20 Feb 93 13:11:24 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: FEC in amateur radio
To: glenne@srlr12.sr.hp.com
Glenn, I used to think as you did about FEC -- that it was something you did
as a last resort to patch up a bad radio channel, when you couldn't fix the
actual problem (e.g., by running more power.) But if I've learned anything
from the CDMA cellular project here at Qualcomm, it's that FEC is essential
in wringing maximum performance out of a radio system, even when you have
the option of increasing transmitter power or using a better antenna.
One good reason is spectral efficiency. Efficient spectrum use means a high
degree of geographic channel reuse (i.e., a cellular scheme), which implies
that the system is ultimately interference (not noise) limited. To pack
co-channel users as closely as possible, you want a modulation method with
the greatest possible resistance to interference. Even if this makes the
signal much wider, you're still better off in the end.
Spread spectrum is of course the way to do this, but FEC also plays
an important part. By reducing the average required transmitter power 5 dB
or so, FEC reduces the interference caused to other users by the same
amount,
and this turns directly into a 5dB system capacity increase.
So far this assumes gaussian "noise", which is a good model for the
interference one sees in spread spectrum. But FEC can *really* shine when
you're fighting
non-gaussian interference, especially radar. Here in Southern California we have
a serious, chronic problem with military radar on the 70cm band, and I am
now convinced that FEC is the only practical way to deal with it (without
simply abandoning large parts of the band to the radars).
Consider a typical military radar with a 400 Hz rep rate, a 8 Mhz bandwidth,
a 10 second antenna sweep rate, and a 20 microsecond pulse width (this
latter figure is the most uncertain, I estimated it with an HP spectrum
analyzer set in "zero span" mode with the fastest possible sweep, 50 us/div).
If the pulses were really short, i.e., on the order of 1/bandwidth, then
even at 56kb/s a simple pulse blanker would be very effective at dealing
with it. Unfortunately the radar pulses are much longer than they have to be
for the bandwidth they use, probably because of either pulse compression and/or
simple pulse broadening to increase target sensitivity. Because the pulse
durations are comparable to an entire bit time at 56 kilobits, a pulse blanker
would remove entire data bits along with the radar pulses.
Let's say that your link is otherwise reasonably well engineered, so most
of your channel bit errors are due to radar pulse hits. Let's also assume
that the radar pulses, when they occur, are much stronger than the data
bits themselves -- say by 40 dB or so. To overcome the radar QRM by brute
force, you'd have to make up that 40 dB by either turning up the wick by
that amount (probably not practical, as well as not legal, especially in
one of the 50W limit zones), or by using antennas with that much additional
gain and/or sidelobe suppression (difficult if not impossible when you
consider scattering.
Or you can use FEC. If the pulse rep rate is 400 Hz and your data rate is
56kb/s, then the radar will hit, at most, one or two data bits out of every
56000/400 = 140. That's a channel bit error rate of 1%, in round numbers,
which is much too high for good performance without FEC. And cranking up
the wick won't do anything to lower this error rate until you swamp the
radar's power, which we already know is impractical.
But it's *easy* to build FEC systems that handle channel bit error rates of 1%.
I've built a software sequential decoder using the Fano algorithm that decodes a
rate 1/2, constraint length 32 convolutional code. The exact decoding
throughput is a random number that depends on the channel error rate, but
at relatively low error rates like 1% it has no problem keeping up with a
56kb/s modem with time to spare on a 33 Mhz 486. The chances of an
uncorrected error at this rate
are nil for all practical purposes, so the effective coding gain in this case
is equal to the amount of power you'd have to run to get the same effect by
simply cranking up the wick -- 40 dB in this example. That's a pretty impressive
figure!
So this strongly suggests using a Fano decoder on packet channels that get
hit by radar QRM. A rate 1/2 code does decrease the user data rate by half,
so
you probably want an adaptive scheme that adds the FEC overhead only when
it is actually needed. So consider a hybrid ARQ/FEC scheme that works like this.
You choose a "systematic" convolutional code where the original data appears
in the coded output (every other channel bit is a user data bit, the others
are generated by the coder). When you first send a packet, you send just the
original data bits plus a CRC. If that checks out, you go on to the next
packet and not bother sending the FEC overhead. But if the CRC check fails,
you return a NAK (negative acknowledgement).
Now instead of simply retransmitting the original packet, the sender now
sends the second set of symbols from the convolutional encoder (the ones that
aren't just the original data bits). The receiver now combines *both* frames,
and runs them through the sequential decoder. If this works, it goes onto the
next packet. If not, you start the process over.
What's really neat about this is that both frames (the original one plus
the encoded one) can be riddled with errors, but as long as the rate isn't
higher than about 6 or 7%, the decoder will quickly recover good data from the
combination. This makes it *much* more efficient than simply resending the
unencoded frame over and over in the hope that it will get through without
any errors -- which is pretty unlikely if the average error rate is that high.
Phil (again sending over a CDMA connection from a mobile van, now back at the
hotel parking lot where we started...)
------------------------------
Date: Sat, 20 Feb 1993 22:11:39 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: new firmware?
To: tcp-group@ucsd.edu
Speaking of Reed-Solomon coding, you say you've got a chip for it?
Tell us more!
I'm sure there's fairly common silicon for a pair of common R-S
codes; namely, (28,24) and (32,28) octets. I'm sitting here tonight
listening to Toad The Wet Sprocket on my new CD-ROM driver (what a
strange use of SCSI but hey) and of course, that's dual-R-S coded.
Perhaps those are in the ballpark for radio use too. Especially on
HF, where error rates are outrageous. But CD-ROMs use byte-oriented,
not bit-oriented, R-S; is that optimal for radio?
Heck, ANYTHING is better than the absurdity now contaminating 145.01.
fred k1io
------------------------------
Date: Sat, 20 Feb 93 19:20:11 EST
From: John Ackermann AG9V <John.Ackermann@DaytonOH.NCR.COM>
Subject: NOSintro - TCP/IP over Packet Radio
To: k1io FN42jk <goldstein@carafe.tay2.dec.com>
You (k1io, FN42jk) write:
>
> Sounds like a good book. Question: Is the book mainly written for
> end users, as in "here's how to use NOS", or does it provide a
> technical discussion of the code itself, as in "these are the modules,
> here's how it works, etc."?
> fred k1io
>
It's end-user oriented, based primarily on the PA0GRI 2.0m. It does
talk about some of the high-level internals (ie, how mail is processed
through alias, rewrite, mbox, etc.) but there's no code-level stuff.
John
------------------------------
Date: Sat, 20 Feb 93 12:03:06 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: redoing amateur packet
To: glenne@srlr12.sr.hp.com, tcp-group@ucsd.edu
Speaking of improved links, this message is coming to you over a 900
Mhz spread spectrum, power controlled, forward error corrected digital
cellular channel. It's our (Qualcomm's) CDMA system; I'm riding around
in a van in San Diego (currently at Linda Vista and Napa, for anyone
who knows this area). I'm running NOS over a special radio link protocol
designed for the CDMA radio modem. So far I've had this call up for 36
minutes, have received 9152 packets and none of them were lost or had
CRC errors.
Oh, and the average transmitter power from the mobile is something like
1 milliwatt.
So I say it *is* possible to do digital radio right, even from a small
omni antenna on a moving vehicle.
KB5MU is right next to me, typing on a Powerbook that's routing
through the NOS box I'm using.
Phil
------------------------------
Date: Sat, 20 Feb 93 20:44:54 EST
From: n4yyh@ipswich.wa2hee.ampr.org
Subject: stat() in Borland C++
To: crompton@nadc.navy.mil
The stat() function in Borland C++ uses the realloc() function, although
I have no idea for what. NOS supplies its own memory alloction system,
but does not supply a replacement for realloc(). I don't know for
certain what the effects of running Borland's realloc() against a block
allocated by NOS's malloc() would be, but I suspect it wouldn't be pretty.
With NOS compiled against my particular CONFIG.H, there are no other
references to realloc() in the EXE file, and there aren't any direct
references in any of the NOS source.
73,
Ross N4YYH
------------------------------
Date: Sat, 20 Feb 93 12:18:54 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Uncle! UNCLE! (Problem with FTP on NET)
To: TCP-Group@UCSD.Edu, prg@mgweed.att.com
Phil -- normally when this kind of problem appears (you can ping a
site, but you can't FTP to it) I suspect one of those $#@!! firewall
routers that filter packets for "security" reasons, but I doubt
there's one in the path to ucsd.edu you were testing. So I would next
suspect your IP TTL value might be too low. Have you tried increasing
it?
Phil
------------------------------
Date: Sat, 20 Feb 1993 23:18:27 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: WG7J breaks PPP?
To: tcp-group@ucsd.edu
Slippery fingers ... the first message should have read "from 1.05 to
1.07b."
------------------------------
Date: Sat, 20 Feb 1993 23:16:45 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: WG7J v1.07 breaks PPP?
To: tcp-group@ucsd.edu
After upgrading from 1.07 to 1.07b my PPP connection to the Netblazer
broke big time! NOS dials and logs in properly and appears to get
through the LCP and IPCP negotiation phase okay, however all the
data packets show up in trace with "unknown protocol = 0x0021" and
get tossed.
Has anyone else seen this? Is there a workaround (besides SLIP)?
--lyndon
------------------------------
End of TCP-Group Digest V93 #49
******************************
******************************