[HECnet] DECnet for Linux

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