Hi,

Does anyone have any experience with X.25 on Linux?

I'm doing a lot of reading about X.25 on Linux, particularly X.25 via LAPB over Ethernet and X.25 over asynchronous serial.

This is involving a lot of archeology and really old archives of things form the late '90s / early '00s.

I wondering if / hoping I can establish an XOT connection with ?strid's Telebahn and then switch (term?) to multiple things local to my LAN.



--
Grant. . . .
unix || die

Hi Grant,

On Sat, Jun 25, 2022 at 12:18:57AM -0600, Grant Taylor via groups.io wrote:

Does anyone have any experience with X.25 on Linux?

unortunately not. However, I know that a number of HAM radio operators are
still using the AX.25 in Linux. It has not received a lot of maintenance
in the last 15+ years or so, but there's some new grant to get that fixed:



The net/x25 directory still exists. It looks like the application-side
interface uses a sockets based API.

If you grep for ARPHRD_X25, you can find the only drivers that work with that code:

* drivers/net/wan/hdlc_x25.c

This is a backend for the generic HLDC / synchronous WAN device code.

I'm using this HDLC code (with frame relay on top, not X.25) even in
production setups together with DAHDI on Digium and other cards. So at
least up to that HDLC layer we know it works.

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.


* drivers/net/wan/lapbether.c

This is the LAPB-over-Ethernet driver you already hinted. I've never
used it, but looking at the code it seems that it automatically creates
a "lapb*" interface for each ethernet interface in your system.

I wondering if / hoping I can establish an XOT connection with ?strid's
Telebahn and then switch (term?) to multiple things local to my LAN.

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.

--
- Harald Welte <laforge@...>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

On 6/25/22 8:13 AM, Harald Welte wrote:

Hi Grant,

Hi Harald,

unortunately not. However, I know that a number of HAM radio operators are still using the AX.25 in Linux. It has not received a lot of maintenance in the last 15+ years or so, but there's some new grant to get that fixed:

*nod*nod*

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.

The net/x25 directory still exists. It looks like the application-side interface uses a sockets based API.

I saw on the linux-x25 mailing list that there were updates to the Linux kerenel earlier this year. So there's active development work.

I'm using this HDLC code (with frame relay on top, not X.25) even in production setups together with DAHDI on Digium and other cards. So at least up to that HDLC layer we know it works.

ACK

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. :-)

* drivers/net/wan/lapbether.c
This is the LAPB-over-Ethernet driver you already hinted. I've never used it, but looking at the code it seems that it automatically creates a "lapb*" interface for each ethernet interface in your system.

I was thinking that a lapb0, et al., device was created per interface as you suggested.

I'm working to find the user space commands and utilities to bring the interface(s) up and how to use it (them).

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.



--
Grant. . . .
unix || die

Pre Script: Thanks Murphy. It's obvious that I would find the docs that I read last night /after/ I hit send on the message.

On 6/25/22 10:22 AM, Grant Taylor via groups.io wrote:

I'm working to find the user space commands and utilities to bring the interface(s) up and how to use it (them).

It seems as if the README file in the x25-utils-2.1.20 package has the most directly useful information.

--8<--
To start up X.25 under Linux
----------------------------

First start up your LAPB interface. At present the only such interface is the LAPB over ethernet device. Firstly get your ethernet card up and running as normal using ifconfig.

Next bring up the lapb0 device with:

ifconfig lapb0 up

Next set up your X.25 routes. I would guess at this stage you just want all X.25 packets to go out via via lapb0, so just do:

x25route add 1/0 lpab0

To make sure its all OK do:

cat /proc/net/x25*

You will see alsorts of useless information !

To set up an X.25 TELNET link, start up telnetd on the remote machine with the command:

./telnetd <address>

Where <address> is the X.121 address that you want telnetd to listen on.

On the local machine use the command:

./telnet <locaddr> <remaddr>

Where <locaddr> is the local X.121 address to be used for the outgoing connection, and <remaddr> is the X.121 address of the remote copy of telnetd.

If you are running Linux/X.25 to another machine running Linux/X.25 without an intermediate machine operating as a DCE, it will not work. What you need to do is build *one* of your machines with the LAPB layer operating as a DCE. To do this edit the linux/include/net/lapb.h and change the line:

#define LAPB_DEFAULT_MODE (LAPB_STANDARD | LAPB_SLP | LAPB_DTE)

to:

#define LAPB_DEFAULT_MODE (LAPB_STANDARD | LAPB_SLP | LAPB_DCE)

and rebuild your kernel. I hope that this will be a run-time option eventually, but at the moment this is the only way to do it.
-->8--



--
Grant. . . .
unix || die

On 6/25/22 10:30 AM, Grant Taylor via groups.io wrote:

If you are running Linux/X.25 to another machine running Linux/X.25 without an intermediate machine operating as a DCE, it will not work. What you need to do is build *one* of your machines with the LAPB layer operating as a DCE.? To do this edit the linux/include/net/lapb.h and change the line:
#define??? LAPB_DEFAULT_MODE??? (LAPB_STANDARD | LAPB_SLP | LAPB_DTE)
to:
#define??? LAPB_DEFAULT_MODE??? (LAPB_STANDARD | LAPB_SLP | LAPB_DCE)
and rebuild your kernel. I hope that this will be a run-time option eventually, but at the moment this is the only way to do it.

This part makes me wonder about two things:

1) Copying and renaming the lapbether driver to be lapbether-dte / lapbether-dce so that I can load the kernel module that I want.

2) Configuring an X.25/LAPB/Ether switch system as the DCE for the LAN.

I wonder how much, if any, of this I could get to work in a UML as opposed to a full / fat VM.



--
Grant. . . .
unix || die

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)

On Sat, Jun 25, 2022 at 10:30:20AM -0600, Grant Taylor via groups.io wrote:

If you are running Linux/X.25 to another machine running Linux/X.25 without
an intermediate machine operating as a DCE, it will not work. What you need
to do is build *one* of your machines with the LAPB layer operating as a
DCE. To do this edit the linux/include/net/lapb.h and change the line:

That paragraph alone shows you how mature that implementation is. Rebuilding
the kernel for switching DTE/DCE role ;)

--
- Harald Welte <laforge@...>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

On 6/27/22 12:27 PM, Harald Welte wrote:

Hi Grant,

Hi Harald,

Sure. I was just assuming that people who playing with legacy tech would also likely want to interface legacy hardware.

Fair enough. But "legacy hardware" can be a lot of things. As you say, it can be something with an X.21 interface. It can also be something with an RS-232 serial interface. The latter RS-232 serial interface can be had with contemporary equipment fairly easily; e.g. Raspberry Pi (et al.) with a TTL/RS-232 voltage level shifter and / or USB/RS-232 interface.

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 suspect this would be in the realm of people that explicitly want an X.21 interface, probably because they have another piece of equipment that has a matching X.21 interface which they want to connect to.

good luck :)

Thank you.

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).

I largely agree. Though I question how well a user space process can interface with specific hardware /without/ some sort of kernel involvement / blessing, even if it's only a stub driver to provide something minimal for the user space program to glom onto.

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.

Fair enough.

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).

1500 -- I presume -- bytes sounds like an Ethernet limitation applied to Frame Relay under the assumption that the FR is transporting Ethernet frames.



--
Grant. . . .
unix || die

On 6/27/22 12:28 PM, Harald Welte wrote:

That paragraph alone shows you how mature that implementation is. Rebuilding the kernel for switching DTE/DCE role ;)

I agree with the logic. However I think that it's extremely important to keep in mind when the documentation was written. A lot may have changed since then.

There is also the fact that documentation tends to get out of sync with the kernel / application capability as the latter slowly moves forward.



--
Grant. . . .
unix || die

开云体育

I have made a bunch of progress which might be helpful:

On 6/27/22 6:20 PM, Dave Brown wrote:

I have made a bunch of progress which might be helpful:

I have some drive by comments / questions. There is a chance that they are answered in things I've not read yet.

1.Created a standalone X.25 module for Raspbian based off Kernel??5.15.32-v7+ (this was on a Raspberry Pi 2)
a.The recipe for this is pretty easy, and really just a case of downloading the kernel source, and doing:
cd /usr/src/linux/net/x25
CONFIG_X25=m make -C /lib/modules/$(uname -r)/build/ M=$(pwd)

Aside: This is a new and novel way to compile a module that I wasn't familiar with.

2.Compiled jh-xotd ()
a.There is something wrong with the getopt in line 232. ?However if you change -1 to 255 it works
b.You need a script file as:
#!/bin/sh -e
echo "Setting up $1" > /dev/console
ip link set $1 up
route --x25 add 0/0 $1

Am I correct in assuming that tun0 is the most common option to this script?

What instantiates the tun0 interface? Is it the jh-xotd daemon?

c.And a config as:
tun0?10.0.0.2 /home/dave/jh-xotd/xotd-setup 256

Where is this config added? jh-xotd?

This is somewhat difficult as it needs you to specify the remote destination, so that needs some work, as honestly we want this “Dynamic”. ?However it will work for testing. ?Here 10.0.0.2 is my Cisco.

ACK

The tun0 is important for the moment, for Pad_srv. However it kinda makes sense when you think that probably most links where Point to Point. Worst case I think you can use the Cisco as a border XOT router to this.

How /important/ is it that it be the tunnel zero interface? Is it only a matter of matching the name that jh-xotd's open_x25.c is using?

I'm wondering about other things conflicting with the "tun0" interface name.

3.Compiled pad_svr ()
a. Modify Makefile to put -lrt at the end pad_svr gcc line not at the start. ?Else you will get complaints about timer_X (e.g. timer_create)
b. Modify "open_x25.c” look for a line as 'strcpy(subscription.device, “X”)’. ?Change the X to be the device you configured in the jh-xotd config
c. Create a pad_svr config as:
#This is config file for pad_svr program.
#
local_x121_address 1111
log_level 5
log_path /var/log/pad_svr.log
Watchdog_timeout 10
Winsize_in 2
Pacsize_in 128
Forward_idle_timeout 1
x29_profile 1:0,2:0,3:0,4:1,13:4,15:0 Buffer_size 32000
Change the x121 address to be the address of this instance (i.e. whatever your put in the x29 route on the Cisco)
4.From a Cisco configure XOT route to point at IP of Linux box, with the address
pad X <- Address from pad_svr
If it all works you should be prompted to login.

Does jh-xotd manage the getty? Or is my understanding backwards?

Ok you now having comms...
If you tcpdump of tun0 you will be able to see the raw X.25 frames. ?Now that I can do all that I think it might be possible to make this work with RSX11M, if I can make a DEC synchronous interface join “tunX”.

:-)



--
Grant. . . .
unix || die

On Jun 29, 2022, at 4:10 PM, Grant Taylor via groups.io <gtaylor@...> wrote:

On 6/27/22 6:20 PM, Dave Brown wrote:

I have made a bunch of progress which might be helpful:

I have some drive by comments / questions. There is a chance that they are answered in things I've not read yet.

1.Created a standalone X.25 module for Raspbian based off Kernel 5.15.32-v7+ (this was on a Raspberry Pi 2)
a.The recipe for this is pretty easy, and really just a case of downloading the kernel source, and doing:
cd /usr/src/linux/net/x25
CONFIG_X25=m make -C /lib/modules/$(uname -r)/build/ M=$(pwd)

Aside: This is a new and novel way to compile a module that I wasn't familiar with.

2.Compiled jh-xotd ()
a.There is something wrong with the getopt in line 232. However if you change -1 to 255 it works
b.You need a script file as:
#!/bin/sh -e
echo "Setting up $1" > /dev/console
ip link set $1 up
route --x25 add 0/0 $1

Am I correct in assuming that tun0 is the most common option to this script?

What instantiates the tun0 interface? Is it the jh-xotd daemon?

Yes jh-xotd creates it, based on the either it being the first available (=) or hard coded in the config file.

c.And a config as:
tun0 10.0.0.2 /home/dave/jh-xotd/xotd-setup 256

Where is this config added? jh-xotd?

In the jh-xotd config file.

This is somewhat difficult as it needs you to specify the remote destination, so that needs some work, as honestly we want this “Dynamic”. However it will work for testing. Here 10.0.0.2 is my Cisco.

ACK

There is another fork from the repo, that David Grizzly has been working on. That is Dynamic.

The tun0 is important for the moment, for Pad_srv. However it kinda makes sense when you think that probably most links where Point to Point. Worst case I think you can use the Cisco as a border XOT router to this.

How /important/ is it that it be the tunnel zero interface? Is it only a matter of matching the name that jh-xotd's open_x25.c is using?

Correct, it only needs to match what used in JH-XOTD config.

I have started going through the code to make it dynamic. However it's a horrible spaghetti mess, with possible buffer overrun everywhere. I have partially patched it, so you could set the interface in the config file, and then have JH-XOTD dynamically start pad_srv from its config file. However honestly this thing needs to be totally thrown away.

I'm wondering about other things conflicting with the "tun0" interface name.

3.Compiled pad_svr ()
a. Modify Makefile to put -lrt at the end pad_svr gcc line not at the start. Else you will get complaints about timer_X (e.g. timer_create)
b. Modify "open_x25.c” look for a line as 'strcpy(subscription.device, “X”)’. Change the X to be the device you configured in the jh-xotd config
c. Create a pad_svr config as:
#This is config file for pad_svr program.
#
local_x121_address 1111
log_level 5
log_path /var/log/pad_svr.log
Watchdog_timeout 10
Winsize_in 2
Pacsize_in 128
Forward_idle_timeout 1
x29_profile 1:0,2:0,3:0,4:1,13:4,15:0 Buffer_size 32000
Change the x121 address to be the address of this instance (i.e. whatever your put in the x29 route on the Cisco)
4.From a Cisco configure XOT route to point at IP of Linux box, with the address
pad X <- Address from pad_svr
If it all works you should be prompted to login.

Does jh-xotd manage the getty? Or is my understanding backwards?

pad_srv managed Getty. JH-XOTD purely takes in XOT packets, removes the X.25 payload and passes to the tun interface.

I have been looking at the SIMH code, and it appears that the PDP-11 simulator supports the hardware for the DU-11 Sync interface, so it may well be possible to have that use the tun device. If so then you would still use JH-XOTD, but replace pad_srv with services on some kind of PDP-11 OS.

Ok you now having comms...
If you tcpdump of tun0 you will be able to see the raw X.25 frames. Now that I can do all that I think it might be possible to make this work with RSX11M, if I can make a DEC synchronous interface join “tunX”.

:-)



--
Grant. . . .
unix || die

I am he that is working on the dynamic version of jh-xotd. I'm 99% sure I've missed something in making the changes to make it dynamic, and haven't had success testing it against my local cisco router. I also haven't yet figured out how to properly decode the X.25 packets from the tunnel interface to decide where to send them. All it does right now is bind to the XOT port and accept all incoming XOT traffic, shove it in the tunnel interface. Connections the opposite direction will fail when it can't find the outgoing connection for it.? I'll try to dig some more over the weekend as time allows.

My fork of jh-xotd:?

-DK