Yeah, I'll second that. I have a copy of DECnet installed on Ubuntu
Trusty. I remember that I had a few problems with it and eventually gave up
on getting it running, but it's been too long and I don't remember all the
issues.
I'll probably upgrade that server to 16.04 or maybe 18.04 pretty soon, and
it'd be great if I could re-install DECnet and have it working.
Bob
-----Original Message-----
From: Hecnet-list [
]
On Behalf Of Dave McGuire
Sent: Wednesday, January 24, 2018 9:55 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet for Linux
Let me just say that I, for one, am very glad that you are working on
this. DECnet under (modern) Linux is something that is very important to
me. I know there are others who feel the same way; inexplicably they don't
speak up in support of your efforts.
Thank you for working on this. Please continue, if you are willing/able.
-Dave
On 01/24/2018 04:06 PM, Erik Olofsen wrote:
Hi Johnny,
You're right, and I will also get tired of it...!
However, being in the current routine of trying various kernels, I've
now arrived at the latest one 4.14.15, something I never expected to
be possible.
Different things go wrong with different kernels. With the latest one,
I get a lot of kernel messages about things the decnet module is doing
wrong, rather than mysterious failures, so there lies some hope. Note:
I get these messages while DECnet is working!
So I will continue just a little bit, and I'll be testing this latest
kernel. I hope you won't be getting too many strange packets from RULLFL.
Can I ask you after some days/weeks if you did?
With the changes in the Linux API, the decnet code has been updated,
even while it was orphaned, so that it compiles; but it hasn't been
tested (of course). I read somewhere that they're going to omit the
decnet source from the tree.
When I get tired of it, I'll document a bit how to get things working.
Erik
On Tue, Jan 23, 2018 at 11:34:35PM +0100, Johnny Billquist wrote:
> Erik, thanks for all the analyzing.
> This both (to me) shows the issues with a constantly changing
> internal API of the Linux kernel, and that maintaining DECnet for
> Linux is a constant effort and annoyance. If someone is willing to do
> it, great, but I suspect most people will tire after some time.
> Also, we still have the issues with DECnet under Linux in general,
> where it seems it don't work right at all in some situations.
>
> Johnny
>
> On 2018-01-23 13:34, Erik Olofsen wrote:
>> One more note:
>>
>> In the last longterm 3.x.y kernel, 3.18.92, sock_alloc_send_skb()
>> sets the errcode to ENOBUFS even when the sk_buff is allocated
>> successfully. This causes sendmsg() to stop with "No buffer space
>> available". That is easy to fix in dn_alloc_send_pskb().
>>
>>
>> On Mon, Jan 15, 2018 at 09:43:53PM +0100, Erik Olofsen wrote:
>>> Some more notes on this:
>>>
>>> The problem of accessing a Linux machine seems to be related to the
>>> standard mtu of 1500 of a network interface.
>>>
>>> Reducing the maximum packet size to 576 helps;
>>>
>>>
https://sourceforge.net/p/linux-decnet/mailman/message/2395733/
>>>
>>> This can be done using ifconfig or using 576 instead of dst_mtu()
>>> in dn_current_mss() af_decnet.c of the kernel module source.
>>>
>>> tcpdump shows that a large data packet is one byte too long.
>>> Perhaps this occurs because the pad byte in the header is not
>>> counted in dn_mss_from_pmtu() in af_decnet.c; with an additional
>>> mtu-- this seems to be fixed.
>>>
>>> Kernel warnings related to dst.h;
>>>
>>>
https://www.spinics.net/lists/netdev/msg225996.html
>>>
>>> indeed disappear by using dst_metric_raw at two places.
>>>
>>> The above was tested with kernel 3.10.17, and can be tested with
>>>
http://mim.update.uu.se/hecnet and nodename RULLFL.
>>>
>>> dntype mim::nodenames.dat works very well on a real machine; why it
>>> doesn't work very well with the virtual machine is not really
>>> solved yet...
>>>
>>>
>>> On Wed, Jan 03, 2018 at 04:44:54PM +0100, Johnny Billquist wrote:
>>>> On 2018-01-03 16:02, Erik Olofsen wrote:
>>>>> On a virtual machine with lubuntu 12.04, kernel 3.2.0, I have
>>>>> DECnet for Linux V.2.5.68s working, with dnprogs version 2.65.
>>>>> It is node RULLFL.
>>>>>
>>>>> The daemons and utilities use decnet.conf with node information,
>>>>> so something useful would be to create it from mim::nodenames.dat.
>>>>>
>>>>> On a VAX, TYPEing it works well, but on the Linux machine, dntype
>>>>> hangs after giving parts of the file; dndir mim:: works well.
>>>>>
>>>>> Does anyone have dntype mim::nodenames.dat working properly (with
>>>>> perhaps different versions of the above)?
>>>>
>>>> I can't help, but I can report that trying to read a file from a
>>>> Linux machine on MIM also hangs after a while.
>>>> A big problem with the DECnet/Linux implementation is that the
>>>> developers only ever tested against VMS, and nothing else.
>>>>
>>>> I've known for ages that it does not play well with RSX. But I do
>>>> not want to dig into the Linux implementation.
>>>>
>>>> (The Linux DAP claims to be a VMS system, by the way, which is
>>>> probably also not a good idea. Better if it had claimed to be some
>>>> Unix derivative.)
>>>>
>>>> Johnny
>>>>
>>>> --
>>>> Johnny Billquist || "I'm on a bus
>>>> || on a psychedelic trip
>>>> email: bqt at softjar.se || Reading murder books
>>>> pdp is alive! || tryin' to stay hip" - B.
Idol
>
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
Hecnet-list mailing list
Hecnet-list at