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
<mailto: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/
<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
<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 <mailto: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 <mailto:bqt at softjar.se>? ? ? ? ? ? ?||
Reading murder books
> pdp is alive!? ? ? ? ? ? ? ? ? ? ?||?
tryin' to stay hip" - B. Idol
--
Dave McGuire, AK4HZ
New Kensington, PA