| |
PA2AGA > TCPDIG 30.08.96 04:56l 179 Lines 7095 Bytes #-10903 (0) @ EU
BID : TCP_96_174B
Read: GUEST
Subj: TCP-Group Digest 96/174B
Path: DB0AAB<DB0PV<DB0MAK<DB0SON<DB0SIF<DB0EAM<DB0SGL<DB0HAG<DB0ACH<DB0NDK<
DB0RWI<PI8JOP<PI8ZAA<PI8GCB<PI8WFL<PI8VNW
Sent: 960829/2011Z @:PI8VNW.#ZH2.NLD.EU #:57826 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA16421 ; Thu, 29 Aug 96 19:40:30 UTC
Received: from pa2aga-1 by pa2aga (NET/Mac 2.3.61/7.1) with SMTP
id AA00003648 ; Thu, 29 Aug 96 20:55:12 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.61/7.5.4) with SMTP
id AA00007985 ; Thu, 29 Aug 96 20:40:02 MET
Date: Thu, 29 Aug 96 20:29:48 MET
Message-Id: <tcp_96_174B>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/174B
X-BBS-Msg-Type: B
SRS> gasping for air.
Windows 95 is probably misdetecting the chip and trying to use the advanced
features available on the Pentium or newer 486 chips, particularly VME.
-- Mike
------------------------------
Date: Tue, 27 Aug 1996 10:53:25 -0700 (PDT)
From: "Dana H. Myers" <myers@bigboy.West.Sun.COM>
Subject: AX.25 - that darn PID
So, I've prototyped a DLPI AX.25 driver (under SunOS 5.x) and it works as well
as I expected. I'm currently only using datagram mode for IP frames, and
don't support AX.25 connections at all.
In the DLPI model, a complete address is the combination of the physical
address and 'service access point' (SAP) - where a SAP is usually mapped to
a protocol ID for a given media type (i.e., SAPs are mapped to Ether
types on Ethernet). AX.25 has essentially the same thing as an
Ether type in the PID octet. The problem with this is that the PID
octet is only present in I frames; when a connection is established, there's
no way to know what SAP the connection is going to end up using.
Of course, in the AX.25 model, connections aren't really bound to
SAPs, they're really just an extension of the MAC layer to provide for the
reliable, sequenced, delivery of I frames. The I frames contain the PID
and are routed appropriately.
We've seen this same problem show up in the net/rom vs BBS connection
tweaks in JNOS - jumpstart and all. The target of a connect can't
figure out which server to kick into action until an I-frame shows
up.
The reason I care about all this is I'd like to complete the project
I envisioned - a STREAMS implementation of the AX.25 protocols (LAPB,
net/rom, etc.) using standard interfaces (DLPI).
I'm concluding I've got no choice but to implement 'lazy connects'
the way they're done in JNOS, and build ioctls into the AX.25 driver
to allow for the jumpstart feature. By 'lazy connect', I mean that
AX.25 connections will be managed autonomously by the AX.25 driver, and
the AX.25 driver will generate virtual connection requests based on
the PID of incoming I frames.
The missing bit of information is that the DLPI model allows a
network driver to manage both connectionless and connection-oriented
data links, and I really want to implement all the connection semantics
as part of the standard DLPI approach.
Any thoughts? Anyone else interested in STREAMS? They're cool, you
know.
Dana KK6JQ
Dana@Source.Net
------------------------------
Date: Wed, 28 Aug 1996 15:27:06 +1000 (EST)
From: Carl Makin <cmakin@nla.gov.au>
Subject: AX.25 - that darn PID
On Tue, 27 Aug 1996, Dana H. Myers wrote:
> So, I've prototyped a DLPI AX.25 driver (under SunOS 5.x) and it works as
well
> as I expected. I'm currently only using datagram mode for IP frames, and
> don't support AX.25 connections at all.
Hmmm.. I run FreeBSD. I wonder how portable your implementation is?
> We've seen this same problem show up in the net/rom vs BBS connection
> tweaks in JNOS - jumpstart and all. The target of a connect can't
> figure out which server to kick into action until an I-frame shows
> up.
> I'm concluding I've got no choice but to implement 'lazy connects'
> the way they're done in JNOS, and build ioctls into the AX.25 driver
> to allow for the jumpstart feature. By 'lazy connect', I mean that
> AX.25 connections will be managed autonomously by the AX.25 driver, and
> the AX.25 driver will generate virtual connection requests based on
> the PID of incoming I frames.
There is another possibility. AX.25 allows for the use of up to 16 SSIDs.
It's become the convention around here that IP frames use xxxxx-2, netrom
node connects use xxxxx-1 and BBS/users use xxxxxx-0. You could do a
similar thing. Instead of using just the PID, add the SSID as a hint to
build the SAP. If the SSIDs used are configurable you can even have
multiple boxes on air with the same callsign. It's how the "jumpstart"
problem was solved in jnos.
Carl.
--
Carl Makin (VK1KCM) <http://email.nla.gov.au/~cmakin/>
C.Makin@nla.gov.au 'Work +61 6 262 1576' "Speaking for myself only!"
'If you want to make your spouse pay attention to what you say...
Talk in your sleep!'
------------------------------
Date: Tue, 27 Aug 1996 02:08:25 -0700
From: brian@nothing.UCSD.EDU (Brian Kantor)
Subject: Linux router boot floppy
You can buy Eprom floppy and/or hard drive emulators off the shelf.
Look in the ads in the back of Midnight Engineering or Circuit Cellar Ink
magazine.
Neither is a very complex interface and might make a nice little
hardware project, true, but no need to reinvent what's already
available.
I have a vague recollection of a floppy emulator being one of the
app-notes in someone's GAL catalog a while back too, but I didn't
turn it up in a quick grep of my bookshelf here at home. This is
something you could throw a PIC uP at quite easily. Up, SRAM, and a
lithium battery ought to do it quite nicely.
BTW, the little IDE drives used in laptops are available on the surplus
market quite cheaply - I think I paid $65 each for some 120 MB
ruggedized drives that had been pulled out of laptops because they were
too small. Those have IDE powerdown/idle functions so they only draw a
few mA when you aren't accessing them, and they spin up in just a
second or two when you do need them. I'm using one in a remote base
control system. It hasn't been in service long enough to know if it's
going to be super reliable, but so far so good. Engineering a sealed
dust-tight box with adequate cooling was the big problem.
- Brian
------------------------------
Date: Tue, 27 Aug 96 14:26:00 -0000
From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
Subject: Linux router boot floppy
Brian Kantor wrote in a message to Mike Bilow:
BK> You can buy Eprom floppy and/or hard drive emulators off the
BK> shelf. Look in the ads in the back of Midnight Engineering or
BK> Circuit Cellar Ink magazine.
Most of these depend upon a real-mode TSR. None that I know of are hardware
emulators, nor would that be a reasonable design approach. It would probably
be easy to write the necessary driver for non-DOS operating systems if the
hardware interface was documented, but otherwise would require reverse
engineering the ROM code.
BK> Neither is a very complex interface and might make a nice
BK> little hardware project, true, but no need to reinvent what's
BK> already available.
BK> I have a vague recollection of a floppy emulator being one of
BK> the app-notes in someone's GAL catalog a while back too, but I
To be continued in digest: tcp_96_174C
Read previous mail | Read next mail
| |
