Hi Grant,
On Sat, Jun 25, 2022 at 10:22:13AM -0600, Grant Taylor via groups.io wrote:
Unfortunately, despite being related, I think that X.25 and AX.25 are about
as compatible as IPv4 and IPv6. If even that. At least IPv6 can have IPv4
addresses mapped into it and converted.
:) ok. I haven't ever looked at AX.25 in detail.
You could follow
with the only difference that you have to use 'sethdlc hdlc0 x25' to
tell the HDLC WAN code to put X.25 on top.
Interesting.
Though I suspect that's going to require specific hardware. Conversely X.25
over TCP or X.25 over Ethernet or X.25 over Async uses more generic
hardware. :-)
Sure. I was just assuming that people who playing with legacy tech would also
likely want to interface legacy hardware. There's also for example the FarSite
WAN boards that expose X.21. Those should also show up as hldcX netdev and
hence be used with the X.25 code. But of course there are always many different
use cases.
I've not seen any XOT code in Linux, so there doesn't seem to be a
straight-forward way to hook those two up.
I have found xotd.c 0.04 from 1999-01-08 by Stephane Fillod.
It naturally doesn't want to compile as is on contemporary systems. I've not
yet tried to compile on older commensurate systems.
good luck :)
My personal take is that with at least some of those incomplete old
kernel implementations for ancient protocols it's often easier to simply
rewrite what's needed in userspace (I did so with frame relay about two
years ago). At the speed of modern computers, there's not really any
advantage of running it in the kernel. And if the mainline code has
some constraints or bugs you need to work around, you have to rebuild
the kernel etc. - a lot of effort.
The kernel FR for example imposes some arbitrary MTU limits (1500?)
while the FR specs permit for larger message sizes, and non-IP users
actually use those in the real world (3GPP Gb interface over FR).
Regards,
Harald
--
- Harald Welte <laforge@...>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
