[HECnet] DECnet for Linux

Wed Jan 24 22:20:17 PST 2018

I'll speak up. I'd use it if it was stable (again).

-Mark

On Wed, Jan 24, 2018 at 9:54 PM, Dave McGuire <mcguire at neurotica.com> wrote:

>
>   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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20180124/8b47cca5/attachment-0001.html>