Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
UUCP limitations and AX.25
72 views
Skip to first unread message
Stuart Longland VK4MSL
Mar 1, 2014, 12:19:48 AM3/1/14
to
Hi all,
Just a silly question. I'm starting to look into UUCP having had to set
it up for a customer at my workplace. Outside of work I do a bit of
emergency communications work using amateur radio and it struck me that
UUCP looks like a good means to pass data and messages over temporary
radio links.
The sort of services I'm considering are mail and news, perhaps voice
mail (compressed with Codec2 to save space) as well. UUCP has a long
history of doing the former two. The latter would be a new concept, but
I don't think it's impossible to implement: data is just data after-all.
What I don't know of though, are its limitations. In my scenario, there
won't be too many people with old VAXen and similarly ancient hardware
trying to connect. If anything, my challenge is to get the modern-day OS
to talk to it: Linux isn't a problem, Windows is. Thankfully, I think
Cygwin might have an answer there.
Some of the factors I wish to consider are things like byte escaping:
most TNCs ("modems") require certain bytes to be prefixed before sending
as they have special meanings (i.e. ^C brings you back to command mode,
to send ^C one must send ^V^C; likewise ^V has a special meaning).
Links between TNCs behave a bit like TCP/IP in that it's buffered then
sent, usually on line breaks (carriage return) or after 128 bytes (or 256
bytes, it's configurable but 128 seems to be default on most, 256 is the
maximum). Software TNCs like the `ax25-call` command in Linux behave
more like `cu`; with ~ needing special treatment.
As for node names, I thought it'd be good to just use the TNC's SSID as
the node name. All TNCs have a SSID which is the owner's callsign,
suffixed by a station ID: i.e. VK4MSL-10; if the -10 is omitted, it's
presumed to be -0. They can use from -0 to -15.
The callsigns on AX.25 itself can be up to 6 characters. Adding a hyphen
and two digits brings us to 9 characters. I'd also like to make it open
(via the Internet, perhaps using UUCP over SSH) to people with longer
callsigns (i.e. Australian Foundation licensees), but I'm not sure what
UUCP typically supports.
I hear older implementations assumed 6 character host names. I plan to
use Taylor UUCP for this project, but haven't spotted what it supports
officially, so I'm interested in what people have found here.
If anyone has any ideas, please let me know.
Just a silly question. I'm starting to look into UUCP having had to set
it up for a customer at my workplace. Outside of work I do a bit of
emergency communications work using amateur radio and it struck me that
UUCP looks like a good means to pass data and messages over temporary
radio links.
The sort of services I'm considering are mail and news, perhaps voice
mail (compressed with Codec2 to save space) as well. UUCP has a long
history of doing the former two. The latter would be a new concept, but
I don't think it's impossible to implement: data is just data after-all.
What I don't know of though, are its limitations. In my scenario, there
won't be too many people with old VAXen and similarly ancient hardware
trying to connect. If anything, my challenge is to get the modern-day OS
to talk to it: Linux isn't a problem, Windows is. Thankfully, I think
Cygwin might have an answer there.
Some of the factors I wish to consider are things like byte escaping:
most TNCs ("modems") require certain bytes to be prefixed before sending
as they have special meanings (i.e. ^C brings you back to command mode,
to send ^C one must send ^V^C; likewise ^V has a special meaning).
Links between TNCs behave a bit like TCP/IP in that it's buffered then
sent, usually on line breaks (carriage return) or after 128 bytes (or 256
bytes, it's configurable but 128 seems to be default on most, 256 is the
maximum). Software TNCs like the `ax25-call` command in Linux behave
more like `cu`; with ~ needing special treatment.
As for node names, I thought it'd be good to just use the TNC's SSID as
the node name. All TNCs have a SSID which is the owner's callsign,
suffixed by a station ID: i.e. VK4MSL-10; if the -10 is omitted, it's
presumed to be -0. They can use from -0 to -15.
The callsigns on AX.25 itself can be up to 6 characters. Adding a hyphen
and two digits brings us to 9 characters. I'd also like to make it open
(via the Internet, perhaps using UUCP over SSH) to people with longer
callsigns (i.e. Australian Foundation licensees), but I'm not sure what
UUCP typically supports.
I hear older implementations assumed 6 character host names. I plan to
use Taylor UUCP for this project, but haven't spotted what it supports
officially, so I'm interested in what people have found here.
If anyone has any ideas, please let me know.
Ed Ravin
Mar 1, 2014, 11:32:23 PM3/1/14
to
From somewhere in cyberspace, Stuart Longland VK4MSL <m...@vk4msl.yi.org> said:
....
things for Windows or Fidonet. You are not likely to run into any of
those systems.
> I plan to
>use Taylor UUCP for this project, but haven't spotted what it supports
>officially, so I'm interested in what people have found here.
I'm sure I used to know this stuff, but it's been a long time since I last
worked with UUCP, and my favorite O'Reilly book is not handy. A web search
turns up a description of at least one limitation on hostname length in the
spool filename:
http://www.math.utah.edu/docs/info/uucp_5.html
> The remote system name will be truncated to seven characters, to ensure
> that the command file name will fit in the 14 character file name limit of
> the traditional Unix file system. UUCP packages which have no other means
> of distinguishing which command files are intended for which systems thus
> require all systems they connect to to have names that are unique in the
> first seven characters. Some UUCP packages use a variant of this format
> which truncates the system name to six characters. HDB uses a different
> spool directory format, which allows up to fourteen characters to be used
> for each system name. The Taylor UUCP spool directory format is
> configurable. The new Taylor spool directory format permits system names to
> be as long as file names; the maximum length of a file name depends on the
> particular Unix file system being used.
This suggests to me that on a system with a short hostname limit, names
past the limit will still work, but if that system communicates with two
different hosts whose names are the same for all the characters within
the limit, then queue files could get mixed up between them.
I don't recall any issues like hostname length or other arbitrary
limitations with Taylor UUCP. You might run into some "modern"
porting issues, like large file support (files over 4 GB), but that
shouldn't be too hard to fix.
-- Ed
--
Ed Ravin | Warning - this email may contain rhetorical
| devices, metaphors, analogies, typographical
eravin@ | errors, or just plain snarkiness. A sense of
panix.com | humor may be required for proper interpretation.
....
>The callsigns on AX.25 itself can be up to 6 characters. Adding a hyphen
>and two digits brings us to 9 characters. I'd also like to make it open
>(via the Internet, perhaps using UUCP over SSH) to people with longer
>callsigns (i.e. Australian Foundation licensees), but I'm not sure what
>UUCP typically supports.
>
>I hear older implementations assumed 6 character host names.
That might have been the original AT&T System V, and maybe some homebrew
>and two digits brings us to 9 characters. I'd also like to make it open
>(via the Internet, perhaps using UUCP over SSH) to people with longer
>callsigns (i.e. Australian Foundation licensees), but I'm not sure what
>UUCP typically supports.
>
>I hear older implementations assumed 6 character host names.
things for Windows or Fidonet. You are not likely to run into any of
those systems.
> I plan to
>use Taylor UUCP for this project, but haven't spotted what it supports
>officially, so I'm interested in what people have found here.
worked with UUCP, and my favorite O'Reilly book is not handy. A web search
turns up a description of at least one limitation on hostname length in the
spool filename:
http://www.math.utah.edu/docs/info/uucp_5.html
> The remote system name will be truncated to seven characters, to ensure
> that the command file name will fit in the 14 character file name limit of
> the traditional Unix file system. UUCP packages which have no other means
> of distinguishing which command files are intended for which systems thus
> require all systems they connect to to have names that are unique in the
> first seven characters. Some UUCP packages use a variant of this format
> which truncates the system name to six characters. HDB uses a different
> spool directory format, which allows up to fourteen characters to be used
> for each system name. The Taylor UUCP spool directory format is
> configurable. The new Taylor spool directory format permits system names to
> be as long as file names; the maximum length of a file name depends on the
> particular Unix file system being used.
This suggests to me that on a system with a short hostname limit, names
past the limit will still work, but if that system communicates with two
different hosts whose names are the same for all the characters within
the limit, then queue files could get mixed up between them.
I don't recall any issues like hostname length or other arbitrary
limitations with Taylor UUCP. You might run into some "modern"
porting issues, like large file support (files over 4 GB), but that
shouldn't be too hard to fix.
-- Ed
--
Ed Ravin | Warning - this email may contain rhetorical
| devices, metaphors, analogies, typographical
eravin@ | errors, or just plain snarkiness. A sense of
panix.com | humor may be required for proper interpretation.
Stuart Longland VK4MSL
Mar 3, 2014, 5:38:11 AM3/3/14
to
Hi Ed,
bit, the answer was staring right at me.
Having a closer look, I can see it now. So, modern Unix, Taylor UUCP,
there shouldn't be a problem.
I did notice SCO seemed to truncate hostnames too to 7 characters (I was
working with this implementation of UUCP as recently as this afternoon),
just wasn't sure if that was typical of UUCP elsewhere or just SCO being,
well, SCO.
> I don't recall any issues like hostname length or other arbitrary
> limitations with Taylor UUCP. You might run into some "modern"
> porting issues, like large file support (files over 4 GB), but that
> shouldn't be too hard to fix.
4GB files would be a nice feature, but in this use case, I don't see too
many 4GB files being transferred over 1200bps VHF radio links or even
23cm D-Star (which goes 128kbps). I've got Taylor UUCP running fine on a
few Linux systems (i686 and AMD64).
Windows is the next challenge, although I wonder if for some things, I
might be better using Taylor UUCP as a test bed for interoperability and
doing an "embedded" UUCP implementation that can run as a library within
some application.
Time to mull things over a bit more me thinks.
Thanks for the heads up though.
Regards,
Stuart Longland
On Sun, 02 Mar 2014 04:32:23 +0000, Ed Ravin wrote:
> From somewhere in cyberspace, Stuart Longland VK4MSL <m...@vk4msl.yi.org>
said:
> From somewhere in cyberspace, Stuart Longland VK4MSL <m...@vk4msl.yi.org>
said:
>>I hear older implementations assumed 6 character host names.
>
> That might have been the original AT&T System V, and maybe some homebrew
> things for Windows or Fidonet. You are not likely to run into any of
> those systems.
>
>> I plan to
>>use Taylor UUCP for this project, but haven't spotted what it supports
>>officially, so I'm interested in what people have found here.
>
> I'm sure I used to know this stuff, but it's been a long time since I
> last worked with UUCP, and my favorite O'Reilly book is not handy. A
> web search turns up a description of at least one limitation on hostname
> length in the spool filename:
>
> http://www.math.utah.edu/docs/info/uucp_5.html
>
>> The remote system name will be truncated to seven characters, to ensure
>> that the command file name will fit in the 14 character file name
>> limit of the traditional Unix file system. [...]
>
> That might have been the original AT&T System V, and maybe some homebrew
> things for Windows or Fidonet. You are not likely to run into any of
> those systems.
>
>> I plan to
>>use Taylor UUCP for this project, but haven't spotted what it supports
>>officially, so I'm interested in what people have found here.
>
> I'm sure I used to know this stuff, but it's been a long time since I
> last worked with UUCP, and my favorite O'Reilly book is not handy. A
> web search turns up a description of at least one limitation on hostname
> length in the spool filename:
>
> http://www.math.utah.edu/docs/info/uucp_5.html
>
>> The remote system name will be truncated to seven characters, to ensure
>> that the command file name will fit in the 14 character file name
>> The new Taylor spool directory format permits system names to
>> be as long as file names; the maximum length of a file name depends
>> on the particular Unix file system being used.
>
> This suggests to me that on a system with a short hostname limit, names
> past the limit will still work, but if that system communicates with two
> different hosts whose names are the same for all the characters within
> the limit, then queue files could get mixed up between them.
Well, I looked that document over a few times, and must've missed that
>> be as long as file names; the maximum length of a file name depends
>> on the particular Unix file system being used.
>
> This suggests to me that on a system with a short hostname limit, names
> past the limit will still work, but if that system communicates with two
> different hosts whose names are the same for all the characters within
> the limit, then queue files could get mixed up between them.
bit, the answer was staring right at me.
Having a closer look, I can see it now. So, modern Unix, Taylor UUCP,
there shouldn't be a problem.
I did notice SCO seemed to truncate hostnames too to 7 characters (I was
working with this implementation of UUCP as recently as this afternoon),
just wasn't sure if that was typical of UUCP elsewhere or just SCO being,
well, SCO.
> I don't recall any issues like hostname length or other arbitrary
> limitations with Taylor UUCP. You might run into some "modern"
> porting issues, like large file support (files over 4 GB), but that
> shouldn't be too hard to fix.
many 4GB files being transferred over 1200bps VHF radio links or even
23cm D-Star (which goes 128kbps). I've got Taylor UUCP running fine on a
few Linux systems (i686 and AMD64).
Windows is the next challenge, although I wonder if for some things, I
might be better using Taylor UUCP as a test bed for interoperability and
doing an "embedded" UUCP implementation that can run as a library within
some application.
Time to mull things over a bit more me thinks.
Thanks for the heads up though.
Regards,
Stuart Longland
Ignatios Souvatzis
Mar 3, 2014, 2:13:16 PM3/3/14
to
Stuart Longland VK4MSL wrote:
> Windows is the next challenge, although I wonder if for some things, I
> might be better using Taylor UUCP as a test bed for interoperability and
> doing an "embedded" UUCP implementation that can run as a library within
> some application.
Hm. Isn't there something like "services for unix" around?, that would
> Windows is the next challenge, although I wonder if for some things, I
> might be better using Taylor UUCP as a test bed for interoperability and
> doing an "embedded" UUCP implementation that can run as a library within
> some application.
give you enough of a unix-ish environment to make Taylor run?
-is
Stuart Longland VK4MSL
Mar 6, 2014, 3:50:02 AM3/6/14
to
mature, works with most software and open-source…
Then there's Interix which Microsoft bought and released as "Services For
Unix" which is half-baked, barely works and proprietary.
If I have to get real UUCP going in a Unix-like environment, the decision
is a no-brainer. ;-)
UUCP emulation though, would allow for a more user-friendly experience
which is important as some of the people who will be using this will be
non-technical.
David K. Bryant
Mar 23, 2014, 3:13:29 PM3/23/14
to
> Just a silly question. I'm starting to look into UUCP having had to set
> it up for a customer at my workplace. Outside of work I do a bit of
> emergency communications work using amateur radio and it struck me that
> UUCP looks like a good means to pass data and messages over temporary
> radio links.
Good. I like it when people use existing
> it up for a customer at my workplace. Outside of work I do a bit of
> emergency communications work using amateur radio and it struck me that
> UUCP looks like a good means to pass data and messages over temporary
> radio links.
rock-solid solutions instead of the usual
way of dropping in a Windoz box as the
default, sub-optimal solution.
As they say, when your only tool is a
hammer everything looks like a nail.
> If anything, my challenge is to get the modern-day OS
> to talk to it: Linux isn't a problem, Windows is. Thankfully, I think
> Cygwin might have an answer there.
poor foundation.
Your solution may be found here:
UUPC
No, not uuCP, uuPC. It's written specifically
to run within the crippled PC environment.
www.kew.com/kendra/uupc
Some day I'll get around to using it on some
small 286 boards that I'll be embedding into
my sprinkler controller so I can push to it
a watering schedule. Some day. RSN.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Andy Valencia
Mar 23, 2014, 3:19:54 PM3/23/14
to
"David K. Bryant" <dbryan...@earthlink.net> writes:
> www.kew.com/kendra/uupc
> Some day I'll get around to using it on some
> small 286 boards that I'll be embedding into
> my sprinkler controller so I can push to it
> a watering schedule. Some day. RSN.
It's hard to justify all the power dissipated by old iron like
> www.kew.com/kendra/uupc
> Some day I'll get around to using it on some
> small 286 boards that I'll be embedding into
> my sprinkler controller so I can push to it
> a watering schedule. Some day. RSN.
a 286. Have a look at a Cubieboard or its ilk--full Debian
on a $50 board which runs on a couple watts. I've moved all
our 24/7 systems to such hardware, and only spin up an x86 when
real heavy lifting--like video transcoding--is needed.
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
David K. Bryant
Mar 23, 2014, 4:58:47 PM3/23/14
to
On 03/23/2014 12:19 PM, Andy Valencia wrote:
> It's hard to justify all the power dissipated by old iron like
> a 286.
Not a full 286 PC.
> It's hard to justify all the power dissipated by old iron like
> a 286.
Ampro LittleBoard/PC and LittleBoard/286
as well as PC/104 form-factor boards w. 486.
Less than half amp of +5vdc. All I'm doing
is control & data collection so I've pulled
all the computing power and processing back
to where it's appropriate and only send out
task assignments. (If I ever get around to it.)
Stuart Longland
Mar 24, 2014, 6:54:25 AM3/24/14
to
On Sun, 23 Mar 2014 12:13:29 -0700, David K. Bryant wrote:
> As they say, when your only tool is a
> hammer everything looks like a nail.
Ain't that the truth!
> As they say, when your only tool is a
> hammer everything looks like a nail.
The project that introduced me to UUCP was oddly enough, a weighbridge
project for a rail company. The original system was commissioned in
1997 and was built on SCO OpenServer 5.0.
Over the years they tried numerous Windows-based solutions, nothing thus
far has managed to displace it. Until now: a new build of Ubuntu-based
systems will be replacing the SCO boxes.
Until this project came along I thought of UUCP as the pre-Internet mail
and news. I didn't know about its general-purpose remote-execution and
file transfer properties, or twig to the fact that it did this over
temporary links.
>> If anything, my challenge is to get the modern-day OS
>> to talk to it: Linux isn't a problem, Windows is. Thankfully, I think
>> Cygwin might have an answer there.
>
> No need to add even one more layer onto a
> poor foundation.
>
> Your solution may be found here:
>
> UUPC
>
> No, not uuCP, uuPC. It's written specifically
> to run within the crippled PC environment.
>
> www.kew.com/kendra/uupc
There's one event in particular where my group uses packet: the
International Rally of Queensland. This is an off-road car rally which
occurs every year in the Imbil State Forest in the Sunshine Coast
Hinterland.
Presently we use a VisualBASIC 6-based application. It's served us well
over the years, but I'm concerned about how easily we can maintain it.
Its task is simple enough: collect scores handed to us by the race
officials and report these back to base. There's some short message
service, time-syncing and error-checking done but for the most part,
that's mostly what the field software does.
I'm not privvy to what happens back at base.
The base software acknowledges each score sent on receipt.
I've thought of an alternative package based around the 'uux' command.
A station in the field would first log-in by running `uux`, calling a
given script. This would log the AX.25 path on the master computer and
would trigger an update of the Systems file.
The master would then poll each station on a schedule. Scores would be
sent by calling the 'uux' command to run a script with the score passed
in (either command-line arguments or stdin, not sure what's better).
The ACK would be queued up via 'uux', and sent to the station next time
it was polled.
Obviously for this to work, the field station has to both make and
accept UUCP calls. i.e. be running a getty-like process.
How well does packages like UUPC handle this? Does it communicate to a
process via stdio or does it expect to talk to a serial port?
David K. Bryant
Apr 4, 2014, 12:48:52 AM4/4/14
to
> Ahh okay, I'll give that a look. How well does it handle dial-in cases?
> in the Sunshine Coast Hinterland.
Ah, Brisbane and Surfer's Paradise, 1968.
> Presently we use a VisualBASIC 6-based application.
> Obviously for this to work, the field station has to both make and
> accept UUCP calls. i.e. be running a getty-like process.
>
> How well does packages like UUPC handle this?
a directly connected serial line initiated
from the host end only.
Stuart Longland
May 11, 2014, 6:16:51 AM5/11/14
to
On Sat, 01 Mar 2014 15:19:48 +1000, Stuart Longland VK4MSL wrote:
> Links between TNCs behave a bit like TCP/IP in that it's buffered then
> sent, usually on line breaks (carriage return) or after 128 bytes (or
> 256 bytes, it's configurable but 128 seems to be default on most, 256 is
> the maximum). Software TNCs like the `ax25-call` command in Linux
> behave more like `cu`; with ~ needing special treatment.
The other day I gave UUCP over a hardware TNC a try. With the server end
> Links between TNCs behave a bit like TCP/IP in that it's buffered then
> sent, usually on line breaks (carriage return) or after 128 bytes (or
> 256 bytes, it's configurable but 128 seems to be default on most, 256 is
> the maximum). Software TNCs like the `ax25-call` command in Linux
> behave more like `cu`; with ~ needing special treatment.
running in so-called "KISS" mode (so the AX.25 stack was being done on
the Linux host) and my client running the TNC in the Kenwood TH-D72A
transceiver.
One characteristic I hadn't counted on: a *real* TNC echoes back
characters, and sends data on a newline (carriage return). This is
because they were originally plugged into dumb terminals, or maybe a
vintage PC with terminal software.
Taylor UUCP did not like hearing the transmitted data get echoed back,
and dropped the link straight away.
So it looks as if the simplest bet for this to work is to run in KISS
mode and use the AX.25 stack in Linux. For the non-Linux case, I'll have
to look elsewhere.
AX.25 in addition to having a connected-mode which behaves like TCP, also
has an unconnected (so-called "unproto") mode which is more like UDP.
I'm thinking maybe dissecting an existing UUCP protocol (e.g. g), since
that's in packets already, and encapsulating those might be the most
flexible solution.
It's just a matter then of whether I set up an application which Taylor
UUCP runs to spoof the UUCP handshake and protocol, or whether I just re-
implement UUCP wholesale, basically a DIY protocol with UUCP as the basis.
0 new messages