[HECnet] DECnet for Linux

[Dave McGuire]

  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