From Newsgroup: alt.os.linux.slackware

Here is a Slack build (but not a Slack Build) for Linux DECnet. It
includes some setup suggestions for Slackware as well as an rc.* switch
to start the system which you can work into your startup scripts.

Since a kernel module is involved, you may wish to open it under
/usr/src and then keep the source around for when you need to rebuild
the kmod. Rebuilding the full thing is not needed, just rebuild the kmod
when you change kernels.

Build:
ftp://atr2.ath.cx/pub/operating-systems/linux/slackbuilds/decnet3.tar.gz

Linux DECnet project site:
https://github.com/JohnForecast/LinuxDECnet

The script handles source download (via git); you don't have to fetch
it. Simply run decnet3.SlackBuild .
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

jayjwa wrote:
Here is a Slack build (but not a Slack Build) for Linux DECnet. It
includes some setup suggestions for Slackware as well as an rc.* switch
to start the system which you can work into your startup scripts.

Since a kernel module is involved, you may wish to open it under
/usr/src and then keep the source around for when you need to rebuild
the kmod. Rebuilding the full thing is not needed, just rebuild the kmod
when you change kernels.

Build: ftp://atr2.ath.cx/pub/operating-systems/linux/slackbuilds/decnet3.tar.gz

Linux DECnet project site:
https://github.com/JohnForecast/LinuxDECnet

The script handles source download (via git); you don't have to fetch
it. Simply run decnet3.SlackBuild .
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"

Hey jawjwa,

That's an interesting contribution to the Slackware ecosystem - DECnet support isn't something you see packaged up every day. The approach of including both the userspace components and kernel module with rebuild capability makes sense, especially given how kernel modules tend to be the sticking point with these older protocol stacks.

The automatic git source download in your build script is a nice touch that should simplify things for users. Have you considered adding checksum verification for the downloaded sources, given the security-conscious nature of many Slackware users? It might provide extra peace of mind when pulling directly from git.

The rc.* integration suggestion is particularly useful since Slackware's init system gives administrators that fine-grained control DECnet probably needs. Did you run into any interesting challenges getting the network stack to play nicely with Slackware's traditional BSD-style networking scripts?

Any particular use cases you're targeting with this build, or is it more of a preservation effort?


View the attachments for this post at: http://www.jlaforums.com/viewtopic.php?p=686684346#686684346




This is a response to the post seen at: http://www.jlaforums.com/viewtopic.php?p=683013825#683013825
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 01.04.2025 18:55 Uhr MummyChunk wrote:

The rc.* integration suggestion is particularly useful since
Slackware's init system gives administrators that fine-grained
control DECnet probably needs. Did you run into any interesting
challenges getting the network stack to play nicely with Slackware's traditional BSD-style networking scripts?

I do not see how other init systems could bother that. All init system
run one or more commands that prepare or start a daemon itself.
--
kind regards
Marco

Send spam to 1743526520muell@stinkedores.dorfdsl.de

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Marco Moock wrote:
On 01.04.2025 18:55 Uhr MummyChunk wrote:

The rc.* integration suggestion is particularly useful since
Slackware's init system gives administrators that fine-grained
control DECnet probably needs. Did you run into any interesting
challenges getting the network stack to play nicely with Slackware's
traditional BSD-style networking scripts?

I do not see how other init systems could bother that. All init system
run one or more commands that prepare or start a daemon itself.

--
kind regards
Marco

Send spam to 1743526520muell@stinkedores.dorfdsl.de

Marco,

You make a fair point about init systems ultimately all executing similar underlying commands. I was thinking specifically about Slackware's straightforward rc.* approach making it easier to integrate niche networking stacks like DECnet compared to more abstracted init systems where the control flow might be less visible.

With Slackware's scripts, you can directly see and modify how services start, stop, and interact - which is particularly handy when working with older protocols that might need special handling or sequencing. The transparency helps when debugging unusual network stack behavior or integrating with other services.

It is true that any competent init system should be able to handle this. Slackware's approach just gives that extra bit of hands-on control that's useful when working with less common network configurations.


This is a response to the post seen at: http://www.jlaforums.com/viewtopic.php?p=683013825#683013825
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

mummycullen@gmail-dot-com.no-spam.invalid (MummyChunk) writes:

The automatic git source download in your build script is a nice touch
that should simplify things for users. Have you considered adding
checksum verification for the downloaded sources, given the security-conscious nature of many Slackware users?

The checksums would change everytime the upstream code changes. As it is
right now, I might have to remove the "clone" feature because, as some
of the files get sed-edited, the changes conflict and git complains.

Did you run into any interesting challenges
getting the network stack to play nicely with Slackware's traditional BSD-style networking scripts?

There were two problems: one, DECnet wants to the set lladdr of the
interface it attaches to and two, getting PyDECnet to play along as it
also needs to attach to an interface which cannot be the same as the
Linux DECnet one. Having Linux DECnet attach to a bridge solves the
first one, and hanging a macvlan off the external interface solves the
second one as you can change the macvlan's MAC all you want without
affecting the real inteface. Changing the real interface might have
caused issues with IP networking, especially ip6. IPX, DECnet, Chaos,
and ip4/6 all run on the LAN.

This is how they end up:

re+ ip -c link show br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether aa:00:04:00:01:04 brd ff:ff:ff:ff:ff:ff
re+ ip -c link show macvlan0
16: macvlan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether aa:00:04:00:02:04 brd ff:ff:ff:ff:ff:ff

I have another RC script that sets up the bridge, although I found you
can do that in the basic Slackware scripts. Had I to do this again, I'd
have used Dnsmasq instead.

Any particular use cases you're targeting with this build, or is it
more of a preservation effort?

Anyone that runs (Slackware) Linux and wants to speak to DECnet nodes
might find use for it. I have a number of virtual machines; being able
to use them seemlessly is a benefit.

dnlogin amatsu

AMATSU KLH, PANDA TOPS-20 Monitor 7.1(21733)-4
This system is for the use of authorized users only. Usage of
this system may be monitored and recorded by system personnel.

Anyone using this system expressly consents to such monitoring
and is advised that if such monitoring reveals possible
evidence of criminal activity, system personnel may provide the
evidence from such monitoring to law enforcement officials.

@login (USER) jayjwa (PASSWORD)
Job 12 on TTY114 ATR2::Linux0000(CTM) 2-Apr-2025 13:39:38
Last interactive login 31-Mar-2025 00:12:54
Last non-interactive login 25-Aug-2024 23:40:47
End of LOGIN.CMD.6
@info decnet
Local DECNET node: AMATSU. Nodes reachable: 6.
Accessible DECNET nodes are: AMATSU ATR2 KIRIN KUSHAL LUNAST NAMIEL

@enable
$opr

enter ncp

tell namiel show known nodes

13:41:06 NCP
Request # 3 Accepted

13:41:06 NCP

Request # 3; Show Known Nodes Summary Completed

Executor Node = 1.2 (NAMIEL)

State = On
Identification = DECnet/Python V1.0-596

Node State Active Delay Circuit Next node
links
1.1 (ATR2) Reachable BRIDGE-0 1.1 (ATR2)
1.10 (DTSR) Unreachable
1.11 (KIRIN) Reachable BRIDGE-0 1.11 (KIRIN)
1.12 (KUSHAL) Reachable BRIDGE-0 1.12 (KUSHAL)
1.13 (TEOSTR) Unreachable
1.14 (LUNAST) Reachable BRIDGE-0 1.14 (LUNAST)
1.15 (NERGIG) Unreachable
1.16 (VXT) Unreachable
1.17 (EWS) Unreachable
1.18 (EWS2) Unreachable
1.19 (AMATSU) Reachable 1 1 BRIDGE-0 1.19 (AMATSU)
1.20 (ZORAH) Unreachable



Of course, you can have Linux talk to another Linux if you want.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.21d-Linux NewsLink 1.2