[HECnet] DECnet for Linux

[Erik Olofsen]

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