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
