3 Jan
2018
3 Jan
'18
4:02 p.m.
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)?
Thanks!
3 Jan
3 Jan
4:44 p.m.
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
15 Jan
15 Jan
9:43 p.m.
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
23 Jan
23 Jan
1:34 p.m.
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
11:34 p.m.
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
24 Jan
24 Jan
10:06 p.m.
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 
25 Jan
25 Jan
6:54 a.m.
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
7:20 a.m.
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
7:51 a.m.
Hello!
"Works for me!" (Trademarked.)
I still have an open project regarding getting the software to connect
a Linux running system to a Terminal Server. And yes Dave it is a
relative to the batch that you brought that time.
And I am also glad that you're working on it.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Thu, Jan 25, 2018 at 1:20 AM, Mark Abene <phiber at phiber.com> wrote:
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
8:28 p.m.
I keep an Ubuntu 12.10 VM running at the museum to use as a hop-off
point and file transfer system. It sure would be nice to not have to do
that. :)
-Dave
On 01/25/2018 01:20 AM, Mark Abene wrote:
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:
--
Dave McGuire, AK4HZ
New Kensington, PA
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
8:45 p.m.
I've got sims of 4.10 and 9.10 currently running for testing. They are less
than reliable at best.
(MASTER:: and DOCTOR:: repectively). Let me know if you want to play on
them.
Tony.
On 25 January 2018 at 19:28, Dave McGuire <mcguire at neurotica.com> wrote:
I keep an Ubuntu 12.10 VM running at the museum to use as a hop-off
point and file transfer system. It sure would be nice to not have to do
that. :)
11:50 p.m.
On 2018-01-25 20:28, Dave McGuire wrote:
I keep an Ubuntu 12.10 VM running at the museum to use as a hop-off
point and file transfer system. It sure would be nice to not have to do
that. :)
Easy. Set up an RSX system instead. Then you can transport files between
DECnet and TCP/IP easily, as well as send/receive mail, and run
interactive terminal sessions, and more... :-)
Johnny
-Dave
On 01/25/2018 01:20 AM, Mark Abene wrote:
--
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
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
26 Jan
26 Jan
12:08 a.m.
On 01/25/2018 05:50 PM, Johnny Billquist wrote:
There are many RSX systems here. I think we're over a dozen now,
between the museum and the systems in my home/work building around the
corner. But we usually don't leave PDP-11s up and running all the time.
I am (slowly) moving toward getting your IP stack installed on a few
of the -PLUS systems, but there have been other priorities of late, like
keeping the power bills paid.
My "bridge between IP and DECnet" system had been a DS10L running VMS,
but it was a bit too modern for its own good, so its CPU fan seized up a
few weeks ago. I'm hoping to solve that problem soon, but with so many
other Linux systems here I'd prefer just to have direct
interoperability, as opposed to indirect.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
?? I keep an
Ubuntu 12.10 VM running at the museum to use as a hop-off
point and file transfer system.? It sure would be nice to not have to do
that. :)
Easy. Set up an RSX system instead. Then you can transport files between
DECnet and TCP/IP easily, as well as send/receive mail, and run
interactive terminal sessions, and more... :-) 
1:11 a.m.
On 1/25/2018 18:08, Dave McGuire wrote:
On 01/25/2018 05:50 PM, Johnny Billquist wrote:
There are many RSX systems here.
I think we're over a dozen now,
between the museum and the systems in my home/work building around the
corner. But we usually don't leave PDP-11s up and running all the time.
Here's Dave booting one up just shy of four hours away:
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
?? I
keep an Ubuntu 12.10 VM running at the museum to use as a hop-off
point and file transfer system.? It sure would be nice to not have to do
that. :)
Easy. Set up an RSX system instead. Then you can transport files between
DECnet and TCP/IP easily, as well as send/receive mail, and run
interactive terminal sessions, and more... :-)
1:16 a.m.
On 01/25/2018 07:11 PM, Supratim Sanyal wrote:
There are many RSX systems here.
I think we're over a dozen now,
between the museum and the systems in my home/work building around the
corner. But we usually don't leave PDP-11s up and running all the time.
Here's Dave booting one up just shy of four hours away:
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
Hey, I remember that interview! That was a fun day. Matt, the
journalist, has brought many friends to tour the museum since then.
Not exactly a flattering angle on me in that pic, but I'll take what I
can get. B-)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
?? I keep an
Ubuntu 12.10 VM running at the museum to use as a hop-off
point and file transfer system.? It sure would be nice to not have to do
that. :)
Easy. Set up an RSX system instead. Then you can transport files between
DECnet and TCP/IP easily, as well as send/receive mail, and run
interactive terminal sessions, and more... :-)
1:27 a.m.
New subject: [offline] a future visit to your museum
Hi Dave,
Obviously, living in Germantown, MD, I am rearing to drive up - but am
trying to get my ex-boss here too - he lives in Singapore but visits his
daughter in Princeton.
I worked for Digital in my home country of India and traveled around
South Asia fixing various industrial process control type installations
over 1994 - 1996. QCOCAL - my SIMH node on HECnet, was a real node on
Easynet in Calcutta. Used to be in the "SI" (systems integration) group.
My boss had been there much longer. I bailed just before Bob Palmer sold
it to Compaq and went to work in Tokyo.
Will pester you for an appointment some day. I am sure you have
fascinating stories to tell, going back to phone hacking.
Thanks for what you are doing!
Supratim
On 1/25/2018 19:16, Dave McGuire wrote:
On 01/25/2018 07:11 PM, Supratim Sanyal wrote:
Here's Dave booting one up just shy of four hours away:
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
Hey, I remember that interview! That was a fun day. Matt, the
journalist, has brought many friends to tour the museum since then.
Not exactly a flattering angle on me in that pic, but I'll take what I
can get. B-)
-Dave
> ?? I keep an Ubuntu 12.10 VM running at the
museum to use as a hop-off
> point and file transfer system.? It sure would be nice to not have to do
> that. :)
Easy. Set up an RSX system instead. Then you can transport files between
DECnet and TCP/IP easily, as well as send/receive mail, and run
interactive terminal sessions, and more... :-)
There are many RSX systems here.
I think we're over a dozen now,
between the museum and the systems in my home/work building around the
corner. But we usually don't leave PDP-11s up and running all the time.
7:33 a.m.
New subject: [offline] a future visit to your museum
On 01/25/2018 07:27 PM, Supratim Sanyal wrote:
Obviously, living in Germantown, MD, I am rearing to
drive up - but am
trying to get my ex-boss here too - he lives in Singapore but visits his
daughter in Princeton.
Very cool. Amusingly, I grew up near Princeton and used to work at
the university, a long time ago.
And I used to live in MD...I've lived in Greenbelt, then Silver
Spring, and then Laurel.
It seems we have some common paths. :)
I worked for Digital in my home country of India and
traveled around
South Asia fixing various industrial process control type installations
over 1994 - 1996. QCOCAL - my SIMH node on HECnet, was a real node on
Easynet in Calcutta. Used to be in the "SI" (systems integration) group.
My boss had been there much longer. I bailed just before Bob Palmer sold
it to Compaq and went to work in Tokyo.
Neat!!
Will pester you for an appointment some day. I am sure
you have
fascinating stories to tell, going back to phone hacking.
I'd love for you to visit! Let me know when you can make it. We will
have a lot of fun.
Thanks for what you are doing!
You are very welcome!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
7:33 a.m.
New subject: [offline] a future visit to your museum
Oops, I guess neither of those messages were "offline" after all. ;)
-Dave
On 01/26/2018 01:33 AM, Dave McGuire wrote:
On 01/25/2018 07:27 PM, Supratim Sanyal wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
Obviously, living in Germantown, MD, I am rearing
to drive up - but am
trying to get my ex-boss here too - he lives in Singapore but visits his
daughter in Princeton.
Very cool. Amusingly, I grew up near Princeton and used to work at
the university, a long time ago.
And I used to live in MD...I've lived in Greenbelt, then Silver
Spring, and then Laurel.
It seems we have some common paths. :)
I worked for Digital in my home country of India
and traveled around
South Asia fixing various industrial process control type installations
over 1994 - 1996. QCOCAL - my SIMH node on HECnet, was a real node on
Easynet in Calcutta. Used to be in the "SI" (systems integration) group.
My boss had been there much longer. I bailed just before Bob Palmer sold
it to Compaq and went to work in Tokyo.
Neat!!
Will pester you for an appointment some day. I am
sure you have
fascinating stories to tell, going back to phone hacking.
I'd love for you to visit! Let me know when you can make it. We will
have a lot of fun.
Thanks for what you are doing!
You are very welcome!
-Dave
4:31 a.m.
Hello!
Yikes! I believe that's the system that made a rude noise at me the
day we met, and VCF that year. No not the crowd I hung around with,
and of course yourself, but wow. I'll be there someday.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Thu, Jan 25, 2018 at 7:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 01/25/2018 07:11 PM, Supratim Sanyal wrote:
Here's Dave booting one up just shy of four hours away:
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
Hey, I remember that interview! That was a fun day. Matt, the
journalist, has brought many friends to tour the museum since then.
Not exactly a flattering angle on me in that pic, but I'll take what I
can get. B-)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
> I keep an Ubuntu 12.10 VM running at the museum
to use as a hop-off
> point and file transfer system. It sure would be nice to not have to do
> that. :)
Easy. Set up an RSX system instead. Then you can transport files between
DECnet and TCP/IP easily, as well as send/receive mail, and run
interactive terminal sessions, and more... :-)
There are many RSX systems here.
I think we're over a dozen now,
between the museum and the systems in my home/work building around the
corner. But we usually don't leave PDP-11s up and running all the time.
7:22 a.m.
The 11/70? Yes, that's the one that I had at VCF-E.
Amusingly, I remember meeting you, you had introduced yourself as
Gregg, but I had not made the connection that you were THE Gregg until a
few hours later, when I couldn't find you! ;)
I do hope you can come out to visit someday.
-Dave
On 01/25/2018 10:31 PM, Gregg Levine wrote:
Hello!
Yikes! I believe that's the system that made a rude noise at me the
day we met, and VCF that year. No not the crowd I hung around with,
and of course yourself, but wow. I'll be there someday.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Thu, Jan 25, 2018 at 7:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
> On 01/25/2018 07:11 PM, Supratim Sanyal wrote:
>>>>> I keep an Ubuntu 12.10 VM running at the museum to use as a
hop-off
>>>>> point and file transfer system. It sure would be nice to not have to
do
>>>>> that. :)
>>>> Easy. Set up an RSX system instead. Then you can transport files between
>>>> DECnet and TCP/IP easily, as well as send/receive mail, and run
>>>> interactive terminal sessions, and more... :-)
>>> There are many RSX systems here. I think we're over a dozen now,
>>> between the museum and the systems in my home/work building around the
>>> corner. But we usually don't leave PDP-11s up and running all the time.
>>
>> Here's Dave booting one up just shy of four hours away:
>>
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
>
> Hey, I remember that interview! That was a fun day. Matt, the
> journalist, has brought many friends to tour the museum since then.
>
> Not exactly a flattering angle on me in that pic, but I'll take what I
> can get. B-)
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
--
Dave McGuire, AK4HZ
New Kensington, PA
10:30 p.m.
Hello!
Indeed. I got there in time for your "How to wrap a computer for
mailing" session.. And naturally by the time you were looking for me,
I had managed to reach the point where I'd implode if I didn't return
here.
Then when you returned, they'd moved those events to the Friday, and I
was able to properly explore things. Where you are? RSN. As for Erik
building via Slackware, I am pleased. I also arranged that.
Now that I think about it, that sound it made was the teletypewriter
responding.......
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Fri, Jan 26, 2018 at 1:22 AM, Dave McGuire <mcguire at neurotica.com> wrote:
The 11/70? Yes, that's the one that I had at VCF-E.
Amusingly, I remember meeting you, you had introduced yourself as
Gregg, but I had not made the connection that you were THE Gregg until a
few hours later, when I couldn't find you! ;)
I do hope you can come out to visit someday.
-Dave
On 01/25/2018 10:31 PM, Gregg Levine wrote:
Hello!
Yikes! I believe that's the system that made a rude noise at me the
day we met, and VCF that year. No not the crowd I hung around with,
and of course yourself, but wow. I'll be there someday.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Thu, Jan 25, 2018 at 7:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
> On 01/25/2018 07:11 PM, Supratim Sanyal wrote:
>>>>> I keep an Ubuntu 12.10 VM running at the museum to use as a
hop-off
>>>>> point and file transfer system. It sure would be nice to not have to
do
>>>>> that. :)
>>>> Easy. Set up an RSX system instead. Then you can transport files between
>>>> DECnet and TCP/IP easily, as well as send/receive mail, and run
>>>> interactive terminal sessions, and more... :-)
>>> There are many RSX systems here. I think we're over a dozen now,
>>> between the museum and the systems in my home/work building around the
>>> corner. But we usually don't leave PDP-11s up and running all the time.
>>
>> Here's Dave booting one up just shy of four hours away:
>>
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
>
> Hey, I remember that interview! That was a fun day. Matt, the
> journalist, has brought many friends to tour the museum since then.
>
> Not exactly a flattering angle on me in that pic, but I'll take what I
> can get. B-)
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
--
Dave McGuire, AK4HZ
New Kensington, PA
10:38 p.m.
Thanks Gregg, I'm very glad that you (or your typewriter?) arranged it!
On Fri, Jan 26, 2018 at 04:30:29PM -0500, Gregg Levine wrote:
Hello!
Indeed. I got there in time for your "How to wrap a computer for
mailing" session.. And naturally by the time you were looking for me,
I had managed to reach the point where I'd implode if I didn't return
here.
Then when you returned, they'd moved those events to the Friday, and I
was able to properly explore things. Where you are? RSN. As for Erik
building via Slackware, I am pleased. I also arranged that.
Now that I think about it, that sound it made was the teletypewriter
responding.......
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Fri, Jan 26, 2018 at 1:22 AM, Dave McGuire <mcguire at neurotica.com> wrote:
>
> The 11/70? Yes, that's the one that I had at VCF-E.
>
> Amusingly, I remember meeting you, you had introduced yourself as
> Gregg, but I had not made the connection that you were THE Gregg until a
> few hours later, when I couldn't find you! ;)
>
> I do hope you can come out to visit someday.
>
> -Dave
>
> On 01/25/2018 10:31 PM, Gregg Levine wrote:
>> Hello!
>> Yikes! I believe that's the system that made a rude noise at me the
>> day we met, and VCF that year. No not the crowd I hung around with,
>> and of course yourself, but wow. I'll be there someday.
>> -----
>> Gregg C Levine gregg.drwho8 at gmail.com
>> "This signature fought the Time Wars, time and again."
>>
>>
>> On Thu, Jan 25, 2018 at 7:16 PM, Dave McGuire <mcguire at neurotica.com>
wrote:
>>> On 01/25/2018 07:11 PM, Supratim Sanyal wrote:
>>>>>>> I keep an Ubuntu 12.10 VM running at the museum to use as
a hop-off
>>>>>>> point and file transfer system. It sure would be nice to
not have to do
>>>>>>> that. :)
>>>>>> Easy. Set up an RSX system instead. Then you can transport files
between
>>>>>> DECnet and TCP/IP easily, as well as send/receive mail, and run
>>>>>> interactive terminal sessions, and more... :-)
>>>>> There are many RSX systems here. I think we're over a dozen
now,
>>>>> between the museum and the systems in my home/work building around
the
>>>>> corner. But we usually don't leave PDP-11s up and running all
the time.
>>>>
>>>> Here's Dave booting one up just shy of four hours away:
>>>>
http://triblive.com/local/valleynewsdispatch/12104848-74/new-kensington-mus…
>>>
>>> Hey, I remember that interview! That was a fun day. Matt, the
>>> journalist, has brought many friends to tour the museum since then.
>>>
>>> Not exactly a flattering angle on me in that pic, but I'll take what
I
>>> can get. B-)
>>>
>>> -Dave
>>>
>>> --
>>> Dave McGuire, AK4HZ
>>> New Kensington, PA
>
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
9:52 p.m.
Thank you all for your support!
So here are some more detailed notes to get DECnet for Linux working with a
recent longterm kernel, 4.9.77. How stable it remains to be seen...
Changes to sources of other kernels are likely to be similar. But because of
many API changes, there are many differences between decnet module sources
with different kernel versions, so patch files are not too useful. However,
just a few small edits are needed.
The patches below were tested with Slackware 14.1 (which doesn't use systemd),
where it is relatively easy to build a custom kernel. Also, decnet startup
was done by hand rather than using a script:
# ifconfig eth0 mtu 576 # see below
# modprobe decnet
# echo -n area.node > /proc/sys/net/decnet/node_address
# dnetd
# phoned
[Kernel 4.14.15 gives BUG: unable to handle kernel NULL pointer dereference
which seems to be related to xfrm_lookup(). A kernel warning about dst.h:256
can be avoided by using dst_use_noref() instead of dst_use() at two places.]
--- MTU ---
It seems the decnet module can generate packets which are one byte larger than
intended. This can be fixed (?) in af_decnet.c:dn_mss_from_pmtu() by adding
one line:
*/
mtu -= (21 + DN_MAX_NSP_DATA_HEADER + 16);
}
+ mtu--; /* probably due to padding */
if (mtu > mss)
mss = mtu;
return mss;
The dneigh utility gives
Node HWtype HWaddress Flags MTU Iface
rullfl loop AA:00:04:00:04:70 --- 65533 lo
rullfs ether AA:00:04:00:29:70 -2- 1498 eth0
gorvax ether AA:00:04:00:90:21 -2- 1498 eth0
pdxvax ether AA:00:04:00:98:F2 -2- 1498 eth0
dimma ether AA:00:04:00:0B:EC -2- 576 eth0
jocke ether AA:00:04:00:15:04 -2- 576 eth0
mim ether AA:00:04:00:0D:04 -2- 1500 eth0
hub ether AA:00:04:00:FE:AB -2- 576 eth0
bitxoz ether AA:00:04:00:51:1C 1-- 1492 eth0
skhngw ether AA:00:04:00:04:38 -2- 576 eth0
a44rtr ether AA:00:04:00:FF:B3 -2- 1498 eth0
where it is interesting to see values of 576, but also a value of 1500 for MIM
(but communication with MIM works well).
MTUs or blksizes are computed in dn_neigh.c, accompanied by the remark:
/*
* Make an estimate of the remote block size by assuming that its
* two less then the device mtu, which it true for ethernet (and
* other things which support long format headers) since there is
* an extra length field (of 16 bits) which isn't part of the
* ethernet headers and which the DECnet specs won't admit is part
* of the DECnet routing headers either.
*
* If we over estimate here its no big deal, the NSP negotiations
* will prevent us from sending packets which are too large for the
* remote node to handle. In any case this figure is normally updated
* by a hello message in most cases.
*/
dn->blksize = dev->mtu - 2;
The above mtu--; seems sufficient, and subtracting an additional two not necessary.
For HECnet, it seems best to set the MTU to 576, to be able to reach nodes in
different areas. This can be done with ifconfig.
Optionally in sysctl_net_decnet.c a /proc/sys/net/decnet/mtu entry could be added with:
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "mtu",
+ .data = &decnet_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
},
{ }
};
where decnet_mtu needs to be declared in this source file, and in linux/net/include/dn.h
as:
extern int decnet_mtu;
which could be used at various places instead of dst_mtu(). [But perhaps the
blksize can be requested from the remote host.]
--- "No buffer space available" message by a dnprogs utility ---
At some point in time, sock_alloc_send_skb() changed, causing a problem in
af_decnet.c:dn_alloc_send_pskb(), which can be fixed by adding the second "+"
line (the first one seems common practice, but may be unnecessary):
if (skb) {
skb->protocol = htons(ETH_P_DNA_RT);
skb->pkt_type = PACKET_OUTGOING;
+ skb->sk = sk;
+ *errcode = 0;
}
return skb;
}
--- "Destroying alive neighbour" kernel message ---
This issue could be related by dneigh entries that are neither local nor routers.
The following two changes seem to help (based on comparing various sources):
The check of __refcnt in dn_route.c:dn_dst_check_expire():
spin_lock(&dn_rt_hash_table[i].lock);
while ((rt = rcu_dereference_protected(*rtp,
lockdep_is_held(&dn_rt_hash_table[i].lock))) != NULL) {
- if (atomic_read(&rt->dst.__refcnt) ||
+ if (atomic_read(&rt->dst.__refcnt) > 1 ||
(now - rt->dst.lastuse) < expire) {
rtp = &rt->dst.dn_next;
continue;
And the setting of initial_ref in dn_route.c:dn_route_output_slow():
if (dev_out->flags & IFF_LOOPBACK)
flags |= RTCF_LOCAL;
- rt = dst_alloc(&dn_dst_ops, dev_out, 0, DST_OBSOLETE_NONE, DST_HOST);
+ rt = dst_alloc(&dn_dst_ops, dev_out, 1, DST_OBSOLETE_NONE, DST_HOST);
if (rt == NULL)
goto e_nobufs;
--- "WARNING: CPU: 0 PID: nnn at include/net/dst.h:188" kernel message ---
This seems to be benign, and can be avoided by the following two changes
in dn_route.c, in void dn_dst_update_pmtu() and dn_rt_set_next_hop():
- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
+ if (dst_metric_raw(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
- if (dst_metric(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
+ if (dst_metric_raw(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
--- Kernel segfault with ctermd (login from remote node) ---
dnprogs 2.65 were used for testing. The segfault happens with
ctermd.c:cterm_reset(), where variable line is used, even though
it is not assigned when DNETUSE_DEVPTS is defined. So this #ifndef
around the code using line helps:
#ifndef DNETUSE_DEVPTS
p=line+sizeof("/dev/")-1;
setutent();
memcpy(entry.ut_line,p,strlen(p));
entry.ut_line[strlen(p)]='\0';
lentry=getutline(&entry);
lentry->ut_type=DEAD_PROCESS;
memset(lentry->ut_line,0,UT_LINESIZE);
memset(lentry->ut_user,0,UT_NAMESIZE);
lentry->ut_time=0;
pututline(lentry);
(void)chmod(line,0666);
(void)chown(line,0,0);
*p='p';
(void)chmod(line,0666);
(void)chown(line,0,0);
#endif
--- Using local node with dnprogs crashes the machine ---
This has not been solved.
10:40 p.m.
The packet size announced by MIM is because I configured it that way.
.ncp sho sys cha
System characteristics as of 26-JAN-18 22:38:01
Maximum control buffers = 50, Maximum small buffers = 15
Maximum large buffers = 40, Large buffer size = 1500
Minimum receive buffers = 25
576 is otherwise the default packet size that DECnet uses in most
places, but you can change as you wish.
And, with that said, MIM will still send you 576 byte packets, because
that is actually controlled by a different parameter.
From NCP SHO EXEC CHA
.
.
Segment buffer size = 576
Johnny
On 2018-01-26 21:52, Erik Olofsen wrote:
Thank you all for your support!
So here are some more detailed notes to get DECnet for Linux working with a
recent longterm kernel, 4.9.77. How stable it remains to be seen...
Changes to sources of other kernels are likely to be similar. But because of
many API changes, there are many differences between decnet module sources
with different kernel versions, so patch files are not too useful. However,
just a few small edits are needed.
The patches below were tested with Slackware 14.1 (which doesn't use systemd),
where it is relatively easy to build a custom kernel. Also, decnet startup
was done by hand rather than using a script:
# ifconfig eth0 mtu 576 # see below
# modprobe decnet
# echo -n area.node > /proc/sys/net/decnet/node_address
# dnetd
# phoned
[Kernel 4.14.15 gives BUG: unable to handle kernel NULL pointer dereference
which seems to be related to xfrm_lookup(). A kernel warning about dst.h:256
can be avoided by using dst_use_noref() instead of dst_use() at two places.]
--- MTU ---
It seems the decnet module can generate packets which are one byte larger than
intended. This can be fixed (?) in af_decnet.c:dn_mss_from_pmtu() by adding
one line:
*/
mtu -= (21 + DN_MAX_NSP_DATA_HEADER + 16);
}
+ mtu--; /* probably due to padding */
if (mtu > mss)
mss = mtu;
return mss;
The dneigh utility gives
Node HWtype HWaddress Flags MTU Iface
rullfl loop AA:00:04:00:04:70 --- 65533 lo
rullfs ether AA:00:04:00:29:70 -2- 1498 eth0
gorvax ether AA:00:04:00:90:21 -2- 1498 eth0
pdxvax ether AA:00:04:00:98:F2 -2- 1498 eth0
dimma ether AA:00:04:00:0B:EC -2- 576 eth0
jocke ether AA:00:04:00:15:04 -2- 576 eth0
mim ether AA:00:04:00:0D:04 -2- 1500 eth0
hub ether AA:00:04:00:FE:AB -2- 576 eth0
bitxoz ether AA:00:04:00:51:1C 1-- 1492 eth0
skhngw ether AA:00:04:00:04:38 -2- 576 eth0
a44rtr ether AA:00:04:00:FF:B3 -2- 1498 eth0
where it is interesting to see values of 576, but also a value of 1500 for MIM
(but communication with MIM works well).
MTUs or blksizes are computed in dn_neigh.c, accompanied by the remark:
/*
* Make an estimate of the remote block size by assuming that its
* two less then the device mtu, which it true for ethernet (and
* other things which support long format headers) since there is
* an extra length field (of 16 bits) which isn't part of the
* ethernet headers and which the DECnet specs won't admit is part
* of the DECnet routing headers either.
*
* If we over estimate here its no big deal, the NSP negotiations
* will prevent us from sending packets which are too large for the
* remote node to handle. In any case this figure is normally updated
* by a hello message in most cases.
*/
dn->blksize = dev->mtu - 2;
The above mtu--; seems sufficient, and subtracting an additional two not necessary.
For HECnet, it seems best to set the MTU to 576, to be able to reach nodes in
different areas. This can be done with ifconfig.
Optionally in sysctl_net_decnet.c a /proc/sys/net/decnet/mtu entry could be added with:
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "mtu",
+ .data = &decnet_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
},
{ }
};
where decnet_mtu needs to be declared in this source file, and in linux/net/include/dn.h
as:
extern int decnet_mtu;
which could be used at various places instead of dst_mtu(). [But perhaps the
blksize can be requested from the remote host.]
--- "No buffer space available" message by a dnprogs utility ---
At some point in time, sock_alloc_send_skb() changed, causing a problem in
af_decnet.c:dn_alloc_send_pskb(), which can be fixed by adding the second "+"
line (the first one seems common practice, but may be unnecessary):
if (skb) {
skb->protocol = htons(ETH_P_DNA_RT);
skb->pkt_type = PACKET_OUTGOING;
+ skb->sk = sk;
+ *errcode = 0;
}
return skb;
}
--- "Destroying alive neighbour" kernel message ---
This issue could be related by dneigh entries that are neither local nor routers.
The following two changes seem to help (based on comparing various sources):
The check of __refcnt in dn_route.c:dn_dst_check_expire():
spin_lock(&dn_rt_hash_table[i].lock);
while ((rt = rcu_dereference_protected(*rtp,
lockdep_is_held(&dn_rt_hash_table[i].lock))) != NULL) {
- if (atomic_read(&rt->dst.__refcnt) ||
+ if (atomic_read(&rt->dst.__refcnt) > 1 ||
(now - rt->dst.lastuse) < expire) {
rtp = &rt->dst.dn_next;
continue;
And the setting of initial_ref in dn_route.c:dn_route_output_slow():
if (dev_out->flags & IFF_LOOPBACK)
flags |= RTCF_LOCAL;
- rt = dst_alloc(&dn_dst_ops, dev_out, 0, DST_OBSOLETE_NONE, DST_HOST);
+ rt = dst_alloc(&dn_dst_ops, dev_out, 1, DST_OBSOLETE_NONE, DST_HOST);
if (rt == NULL)
goto e_nobufs;
--- "WARNING: CPU: 0 PID: nnn at include/net/dst.h:188" kernel message ---
This seems to be benign, and can be avoided by the following two changes
in dn_route.c, in void dn_dst_update_pmtu() and dn_rt_set_next_hop():
- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
+ if (dst_metric_raw(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
- if (dst_metric(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
+ if (dst_metric_raw(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
--- Kernel segfault with ctermd (login from remote node) ---
dnprogs 2.65 were used for testing. The segfault happens with
ctermd.c:cterm_reset(), where variable line is used, even though
it is not assigned when DNETUSE_DEVPTS is defined. So this #ifndef
around the code using line helps:
#ifndef DNETUSE_DEVPTS
p=line+sizeof("/dev/")-1;
setutent();
memcpy(entry.ut_line,p,strlen(p));
entry.ut_line[strlen(p)]='\0';
lentry=getutline(&entry);
lentry->ut_type=DEAD_PROCESS;
memset(lentry->ut_line,0,UT_LINESIZE);
memset(lentry->ut_user,0,UT_NAMESIZE);
lentry->ut_time=0;
pututline(lentry);
(void)chmod(line,0666);
(void)chown(line,0,0);
*p='p';
(void)chmod(line,0666);
(void)chown(line,0,0);
#endif
--- Using local node with dnprogs crashes the machine ---
This has not been solved.
--
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
10:45 p.m.
Ok; I wondered why it seems to have received 1502 from dev->mtu...
Do you know about the extra length field which may or may not be present,
in packets or the DECnet specs?
On Fri, Jan 26, 2018 at 10:40:20PM +0100, Johnny Billquist wrote:
The packet size announced by MIM is because I
configured it that way.
.ncp sho sys cha
System characteristics as of 26-JAN-18 22:38:01
Maximum control buffers = 50, Maximum small buffers = 15
Maximum large buffers = 40, Large buffer size = 1500
Minimum receive buffers = 25
576 is otherwise the default packet size that DECnet uses in most places,
but you can change as you wish.
And, with that said, MIM will still send you 576 byte packets, because that
is actually controlled by a different parameter.
From NCP SHO EXEC CHA
.
.
Segment buffer size = 576
Johnny
On 2018-01-26 21:52, Erik Olofsen wrote:
Thank you all for your support!
So here are some more detailed notes to get DECnet for Linux working with a
recent longterm kernel, 4.9.77. How stable it remains to be seen...
Changes to sources of other kernels are likely to be similar. But because of
many API changes, there are many differences between decnet module sources
with different kernel versions, so patch files are not too useful. However,
just a few small edits are needed.
The patches below were tested with Slackware 14.1 (which doesn't use systemd),
where it is relatively easy to build a custom kernel. Also, decnet startup
was done by hand rather than using a script:
# ifconfig eth0 mtu 576 # see below
# modprobe decnet
# echo -n area.node > /proc/sys/net/decnet/node_address
# dnetd
# phoned
[Kernel 4.14.15 gives BUG: unable to handle kernel NULL pointer dereference
which seems to be related to xfrm_lookup(). A kernel warning about dst.h:256
can be avoided by using dst_use_noref() instead of dst_use() at two places.]
--- MTU ---
It seems the decnet module can generate packets which are one byte larger than
intended. This can be fixed (?) in af_decnet.c:dn_mss_from_pmtu() by adding
one line:
*/
mtu -= (21 + DN_MAX_NSP_DATA_HEADER + 16);
}
+ mtu--; /* probably due to padding */
if (mtu > mss)
mss = mtu;
return mss;
The dneigh utility gives
Node HWtype HWaddress Flags MTU Iface
rullfl loop AA:00:04:00:04:70 --- 65533 lo
rullfs ether AA:00:04:00:29:70 -2- 1498 eth0
gorvax ether AA:00:04:00:90:21 -2- 1498 eth0
pdxvax ether AA:00:04:00:98:F2 -2- 1498 eth0
dimma ether AA:00:04:00:0B:EC -2- 576 eth0
jocke ether AA:00:04:00:15:04 -2- 576 eth0
mim ether AA:00:04:00:0D:04 -2- 1500 eth0
hub ether AA:00:04:00:FE:AB -2- 576 eth0
bitxoz ether AA:00:04:00:51:1C 1-- 1492 eth0
skhngw ether AA:00:04:00:04:38 -2- 576 eth0
a44rtr ether AA:00:04:00:FF:B3 -2- 1498 eth0
where it is interesting to see values of 576, but also a value of 1500 for MIM
(but communication with MIM works well).
MTUs or blksizes are computed in dn_neigh.c, accompanied by the remark:
/*
* Make an estimate of the remote block size by assuming that its
* two less then the device mtu, which it true for ethernet (and
* other things which support long format headers) since there is
* an extra length field (of 16 bits) which isn't part of the
* ethernet headers and which the DECnet specs won't admit is part
* of the DECnet routing headers either.
*
* If we over estimate here its no big deal, the NSP negotiations
* will prevent us from sending packets which are too large for the
* remote node to handle. In any case this figure is normally updated
* by a hello message in most cases.
*/
dn->blksize = dev->mtu - 2;
The above mtu--; seems sufficient, and subtracting an additional two not necessary.
For HECnet, it seems best to set the MTU to 576, to be able to reach nodes in
different areas. This can be done with ifconfig.
Optionally in sysctl_net_decnet.c a /proc/sys/net/decnet/mtu entry could be added with:
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "mtu",
+ .data = &decnet_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
},
{ }
};
where decnet_mtu needs to be declared in this source file, and in linux/net/include/dn.h
as:
extern int decnet_mtu;
which could be used at various places instead of dst_mtu(). [But perhaps the
blksize can be requested from the remote host.]
--- "No buffer space available" message by a dnprogs utility ---
At some point in time, sock_alloc_send_skb() changed, causing a problem in
af_decnet.c:dn_alloc_send_pskb(), which can be fixed by adding the second "+"
line (the first one seems common practice, but may be unnecessary):
if (skb) {
skb->protocol = htons(ETH_P_DNA_RT);
skb->pkt_type = PACKET_OUTGOING;
+ skb->sk = sk;
+ *errcode = 0;
}
return skb;
}
--- "Destroying alive neighbour" kernel message ---
This issue could be related by dneigh entries that are neither local nor routers.
The following two changes seem to help (based on comparing various sources):
The check of __refcnt in dn_route.c:dn_dst_check_expire():
spin_lock(&dn_rt_hash_table[i].lock);
while ((rt = rcu_dereference_protected(*rtp,
lockdep_is_held(&dn_rt_hash_table[i].lock))) != NULL) {
- if (atomic_read(&rt->dst.__refcnt) ||
+ if (atomic_read(&rt->dst.__refcnt) > 1 ||
(now - rt->dst.lastuse) < expire) {
rtp = &rt->dst.dn_next;
continue;
And the setting of initial_ref in dn_route.c:dn_route_output_slow():
if (dev_out->flags & IFF_LOOPBACK)
flags |= RTCF_LOCAL;
- rt = dst_alloc(&dn_dst_ops, dev_out, 0, DST_OBSOLETE_NONE, DST_HOST);
+ rt = dst_alloc(&dn_dst_ops, dev_out, 1, DST_OBSOLETE_NONE, DST_HOST);
if (rt == NULL)
goto e_nobufs;
--- "WARNING: CPU: 0 PID: nnn at include/net/dst.h:188" kernel message ---
This seems to be benign, and can be avoided by the following two changes
in dn_route.c, in void dn_dst_update_pmtu() and dn_rt_set_next_hop():
- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
+ if (dst_metric_raw(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
- if (dst_metric(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
+ if (dst_metric_raw(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
--- Kernel segfault with ctermd (login from remote node) ---
dnprogs 2.65 were used for testing. The segfault happens with
ctermd.c:cterm_reset(), where variable line is used, even though
it is not assigned when DNETUSE_DEVPTS is defined. So this #ifndef
around the code using line helps:
#ifndef DNETUSE_DEVPTS
p=line+sizeof("/dev/")-1;
setutent();
memcpy(entry.ut_line,p,strlen(p));
entry.ut_line[strlen(p)]='\0';
lentry=getutline(&entry);
lentry->ut_type=DEAD_PROCESS;
memset(lentry->ut_line,0,UT_LINESIZE);
memset(lentry->ut_user,0,UT_NAMESIZE);
lentry->ut_time=0;
pututline(lentry);
(void)chmod(line,0666);
(void)chown(line,0,0);
*p='p';
(void)chmod(line,0666);
(void)chown(line,0,0);
#endif
--- Using local node with dnprogs crashes the machine ---
This has not been solved.
--
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
10:52 p.m.
No idea where a 1502 might come from. Some weird Linux internal stuff.
There got to be some place in the Linux or (maybe more probably) the
DECnet/Linux code where an additional two bytes are thrown in there,
totally without reason.
Setting the interface MTU to 576 will hurt your TCP/IP performance, by
the way. So it's nothing I would really recommend.
Johnny
On 2018-01-26 22:45, Erik Olofsen wrote:
Ok; I wondered why it seems to have received 1502 from
dev->mtu...
Do you know about the extra length field which may or may not be present,
in packets or the DECnet specs?
On Fri, Jan 26, 2018 at 10:40:20PM +0100, Johnny Billquist wrote:
> The packet size announced by MIM is because I configured it that way.
>
> .ncp sho sys cha
>
> System characteristics as of 26-JAN-18 22:38:01
>
> Maximum control buffers = 50, Maximum small buffers = 15
> Maximum large buffers = 40, Large buffer size = 1500
> Minimum receive buffers = 25
>
> 576 is otherwise the default packet size that DECnet uses in most places,
> but you can change as you wish.
>
> And, with that said, MIM will still send you 576 byte packets, because that
> is actually controlled by a different parameter.
>
> From NCP SHO EXEC CHA
> .
> .
> Segment buffer size = 576
>
> Johnny
>
> On 2018-01-26 21:52, Erik Olofsen wrote:
>> Thank you all for your support!
>>
>> So here are some more detailed notes to get DECnet for Linux working with a
>> recent longterm kernel, 4.9.77. How stable it remains to be seen...
>>
>> Changes to sources of other kernels are likely to be similar. But because of
>> many API changes, there are many differences between decnet module sources
>> with different kernel versions, so patch files are not too useful. However,
>> just a few small edits are needed.
>>
>> The patches below were tested with Slackware 14.1 (which doesn't use
systemd),
>> where it is relatively easy to build a custom kernel. Also, decnet startup
>> was done by hand rather than using a script:
>>
>> # ifconfig eth0 mtu 576 # see below
>> # modprobe decnet
>> # echo -n area.node > /proc/sys/net/decnet/node_address
>> # dnetd
>> # phoned
>>
>> [Kernel 4.14.15 gives BUG: unable to handle kernel NULL pointer dereference
>> which seems to be related to xfrm_lookup(). A kernel warning about dst.h:256
>> can be avoided by using dst_use_noref() instead of dst_use() at two places.]
>>
>>
>> --- MTU ---
>>
>> It seems the decnet module can generate packets which are one byte larger than
>> intended. This can be fixed (?) in af_decnet.c:dn_mss_from_pmtu() by adding
>> one line:
>>
>> */
>> mtu -= (21 + DN_MAX_NSP_DATA_HEADER + 16);
>> }
>> + mtu--; /* probably due to padding */
>> if (mtu > mss)
>> mss = mtu;
>> return mss;
>>
>>
>> The dneigh utility gives
>>
>> Node HWtype HWaddress Flags MTU Iface
>> rullfl loop AA:00:04:00:04:70 --- 65533 lo
>> rullfs ether AA:00:04:00:29:70 -2- 1498 eth0
>> gorvax ether AA:00:04:00:90:21 -2- 1498 eth0
>> pdxvax ether AA:00:04:00:98:F2 -2- 1498 eth0
>> dimma ether AA:00:04:00:0B:EC -2- 576 eth0
>> jocke ether AA:00:04:00:15:04 -2- 576 eth0
>> mim ether AA:00:04:00:0D:04 -2- 1500 eth0
>> hub ether AA:00:04:00:FE:AB -2- 576 eth0
>> bitxoz ether AA:00:04:00:51:1C 1-- 1492 eth0
>> skhngw ether AA:00:04:00:04:38 -2- 576 eth0
>> a44rtr ether AA:00:04:00:FF:B3 -2- 1498 eth0
>>
>> where it is interesting to see values of 576, but also a value of 1500 for MIM
>> (but communication with MIM works well).
>>
>> MTUs or blksizes are computed in dn_neigh.c, accompanied by the remark:
>>
>> /*
>> * Make an estimate of the remote block size by assuming that its
>> * two less then the device mtu, which it true for ethernet (and
>> * other things which support long format headers) since there is
>> * an extra length field (of 16 bits) which isn't part of the
>> * ethernet headers and which the DECnet specs won't admit is part
>> * of the DECnet routing headers either.
>> *
>> * If we over estimate here its no big deal, the NSP negotiations
>> * will prevent us from sending packets which are too large for the
>> * remote node to handle. In any case this figure is normally updated
>> * by a hello message in most cases.
>> */
>> dn->blksize = dev->mtu - 2;
>>
>> The above mtu--; seems sufficient, and subtracting an additional two not
necessary.
>>
>> For HECnet, it seems best to set the MTU to 576, to be able to reach nodes in
>> different areas. This can be done with ifconfig.
>>
>> Optionally in sysctl_net_decnet.c a /proc/sys/net/decnet/mtu entry could be added
with:
>>
>> .maxlen = sizeof(int),
>> .mode = 0644,
>> .proc_handler = proc_dointvec,
>> + },
>> + {
>> + .procname = "mtu",
>> + .data = &decnet_mtu,
>> + .maxlen = sizeof(int),
>> + .mode = 0644,
>> + .proc_handler = proc_dointvec,
>> },
>> { }
>> };
>>
>> where decnet_mtu needs to be declared in this source file, and in
linux/net/include/dn.h
>> as:
>>
>> extern int decnet_mtu;
>>
>> which could be used at various places instead of dst_mtu(). [But perhaps the
>> blksize can be requested from the remote host.]
>>
>>
>> --- "No buffer space available" message by a dnprogs utility ---
>>
>> At some point in time, sock_alloc_send_skb() changed, causing a problem in
>> af_decnet.c:dn_alloc_send_pskb(), which can be fixed by adding the second
"+"
>> line (the first one seems common practice, but may be unnecessary):
>>
>> if (skb) {
>> skb->protocol = htons(ETH_P_DNA_RT);
>> skb->pkt_type = PACKET_OUTGOING;
>> + skb->sk = sk;
>> + *errcode = 0;
>> }
>> return skb;
>> }
>>
>>
>> --- "Destroying alive neighbour" kernel message ---
>>
>> This issue could be related by dneigh entries that are neither local nor
routers.
>>
>> The following two changes seem to help (based on comparing various sources):
>>
>> The check of __refcnt in dn_route.c:dn_dst_check_expire():
>>
>> spin_lock(&dn_rt_hash_table[i].lock);
>> while ((rt = rcu_dereference_protected(*rtp,
>>
lockdep_is_held(&dn_rt_hash_table[i].lock))) != NULL) {
>> - if (atomic_read(&rt->dst.__refcnt) ||
>> + if (atomic_read(&rt->dst.__refcnt) > 1 ||
>> (now - rt->dst.lastuse) < expire)
{
>> rtp = &rt->dst.dn_next;
>> continue;
>>
>> And the setting of initial_ref in dn_route.c:dn_route_output_slow():
>>
>> if (dev_out->flags & IFF_LOOPBACK)
>> flags |= RTCF_LOCAL;
>> - rt = dst_alloc(&dn_dst_ops, dev_out, 0, DST_OBSOLETE_NONE,
DST_HOST);
>> + rt = dst_alloc(&dn_dst_ops, dev_out, 1, DST_OBSOLETE_NONE,
DST_HOST);
>> if (rt == NULL)
>> goto e_nobufs;
>>
>>
>> --- "WARNING: CPU: 0 PID: nnn at include/net/dst.h:188" kernel message
---
>>
>> This seems to be benign, and can be avoided by the following two changes
>> in dn_route.c, in void dn_dst_update_pmtu() and dn_rt_set_next_hop():
>>
>> - if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
>> + if (dst_metric_raw(dst, RTAX_MTU) > mtu && mtu >= min_mtu)
{
>>
>> - if (dst_metric(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
>> + if (dst_metric_raw(&rt->dst, RTAX_MTU) >
rt->dst.dev->mtu)
>>
>>
>> --- Kernel segfault with ctermd (login from remote node) ---
>>
>> dnprogs 2.65 were used for testing. The segfault happens with
>> ctermd.c:cterm_reset(), where variable line is used, even though
>> it is not assigned when DNETUSE_DEVPTS is defined. So this #ifndef
>> around the code using line helps:
>>
>> #ifndef DNETUSE_DEVPTS
>> p=line+sizeof("/dev/")-1;
>>
>> setutent();
>> memcpy(entry.ut_line,p,strlen(p));
>> entry.ut_line[strlen(p)]='\0';
>> lentry=getutline(&entry);
>> lentry->ut_type=DEAD_PROCESS;
>>
>> memset(lentry->ut_line,0,UT_LINESIZE);
>> memset(lentry->ut_user,0,UT_NAMESIZE);
>> lentry->ut_time=0;
>> pututline(lentry);
>>
>> (void)chmod(line,0666);
>> (void)chown(line,0,0);
>> *p='p';
>> (void)chmod(line,0666);
>> (void)chown(line,0,0);
>> #endif
>>
>>
>> --- Using local node with dnprogs crashes the machine ---
>>
>> This has not been solved.
>>
>
>
> --
> 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
10:57 p.m.
Yes indeed, that's why I was considering setting it via a sysctl.
I'll be thinking about a better way...
On Fri, Jan 26, 2018 at 10:52:27PM +0100, Johnny Billquist wrote:
No idea where a 1502 might come from. Some weird Linux
internal stuff.
There got to be some place in the Linux or (maybe more probably) the
DECnet/Linux code where an additional two bytes are thrown in there, totally
without reason.
Setting the interface MTU to 576 will hurt your TCP/IP performance, by the
way. So it's nothing I would really recommend.
Johnny
On 2018-01-26 22:45, Erik Olofsen wrote:
Ok; I wondered why it seems to have received 1502
from dev->mtu...
Do you know about the extra length field which may or may not be present,
in packets or the DECnet specs?
On Fri, Jan 26, 2018 at 10:40:20PM +0100, Johnny Billquist wrote:
>The packet size announced by MIM is because I configured it that way.
>
>.ncp sho sys cha
>
>System characteristics as of 26-JAN-18 22:38:01
>
> Maximum control buffers = 50, Maximum small buffers = 15
> Maximum large buffers = 40, Large buffer size = 1500
> Minimum receive buffers = 25
>
>576 is otherwise the default packet size that DECnet uses in most places,
>but you can change as you wish.
>
>And, with that said, MIM will still send you 576 byte packets, because that
>is actually controlled by a different parameter.
>
> From NCP SHO EXEC CHA
> .
> .
> Segment buffer size = 576
>
> Johnny
>
>On 2018-01-26 21:52, Erik Olofsen wrote:
>>Thank you all for your support!
>>
>>So here are some more detailed notes to get DECnet for Linux working with a
>>recent longterm kernel, 4.9.77. How stable it remains to be seen...
>>
>>Changes to sources of other kernels are likely to be similar. But because of
>>many API changes, there are many differences between decnet module sources
>>with different kernel versions, so patch files are not too useful. However,
>>just a few small edits are needed.
>>
>>The patches below were tested with Slackware 14.1 (which doesn't use
systemd),
>>where it is relatively easy to build a custom kernel. Also, decnet startup
>>was done by hand rather than using a script:
>>
>># ifconfig eth0 mtu 576 # see below
>># modprobe decnet
>># echo -n area.node > /proc/sys/net/decnet/node_address
>># dnetd
>># phoned
>>
>>[Kernel 4.14.15 gives BUG: unable to handle kernel NULL pointer dereference
>>which seems to be related to xfrm_lookup(). A kernel warning about dst.h:256
>>can be avoided by using dst_use_noref() instead of dst_use() at two places.]
>>
>>
>>--- MTU ---
>>
>>It seems the decnet module can generate packets which are one byte larger than
>>intended. This can be fixed (?) in af_decnet.c:dn_mss_from_pmtu() by adding
>>one line:
>>
>> */
>> mtu -= (21 + DN_MAX_NSP_DATA_HEADER + 16);
>> }
>>+ mtu--; /* probably due to padding */
>> if (mtu > mss)
>> mss = mtu;
>> return mss;
>>
>>
>>The dneigh utility gives
>>
>>Node HWtype HWaddress Flags MTU Iface
>>rullfl loop AA:00:04:00:04:70 --- 65533 lo
>>rullfs ether AA:00:04:00:29:70 -2- 1498 eth0
>>gorvax ether AA:00:04:00:90:21 -2- 1498 eth0
>>pdxvax ether AA:00:04:00:98:F2 -2- 1498 eth0
>>dimma ether AA:00:04:00:0B:EC -2- 576 eth0
>>jocke ether AA:00:04:00:15:04 -2- 576 eth0
>>mim ether AA:00:04:00:0D:04 -2- 1500 eth0
>>hub ether AA:00:04:00:FE:AB -2- 576 eth0
>>bitxoz ether AA:00:04:00:51:1C 1-- 1492 eth0
>>skhngw ether AA:00:04:00:04:38 -2- 576 eth0
>>a44rtr ether AA:00:04:00:FF:B3 -2- 1498 eth0
>>
>>where it is interesting to see values of 576, but also a value of 1500 for MIM
>>(but communication with MIM works well).
>>
>>MTUs or blksizes are computed in dn_neigh.c, accompanied by the remark:
>>
>> /*
>> * Make an estimate of the remote block size by assuming that its
>> * two less then the device mtu, which it true for ethernet (and
>> * other things which support long format headers) since there is
>> * an extra length field (of 16 bits) which isn't part of the
>> * ethernet headers and which the DECnet specs won't admit is part
>> * of the DECnet routing headers either.
>> *
>> * If we over estimate here its no big deal, the NSP negotiations
>> * will prevent us from sending packets which are too large for the
>> * remote node to handle. In any case this figure is normally updated
>> * by a hello message in most cases.
>> */
>> dn->blksize = dev->mtu - 2;
>>
>>The above mtu--; seems sufficient, and subtracting an additional two not
necessary.
>>
>>For HECnet, it seems best to set the MTU to 576, to be able to reach nodes in
>>different areas. This can be done with ifconfig.
>>
>>Optionally in sysctl_net_decnet.c a /proc/sys/net/decnet/mtu entry could be added
with:
>>
>> .maxlen = sizeof(int),
>> .mode = 0644,
>> .proc_handler = proc_dointvec,
>>+ },
>>+ {
>>+ .procname = "mtu",
>>+ .data = &decnet_mtu,
>>+ .maxlen = sizeof(int),
>>+ .mode = 0644,
>>+ .proc_handler = proc_dointvec,
>> },
>> { }
>> };
>>
>>where decnet_mtu needs to be declared in this source file, and in
linux/net/include/dn.h
>>as:
>>
>>extern int decnet_mtu;
>>
>>which could be used at various places instead of dst_mtu(). [But perhaps the
>>blksize can be requested from the remote host.]
>>
>>
>>--- "No buffer space available" message by a dnprogs utility ---
>>
>>At some point in time, sock_alloc_send_skb() changed, causing a problem in
>>af_decnet.c:dn_alloc_send_pskb(), which can be fixed by adding the second
"+"
>>line (the first one seems common practice, but may be unnecessary):
>>
>> if (skb) {
>> skb->protocol = htons(ETH_P_DNA_RT);
>> skb->pkt_type = PACKET_OUTGOING;
>>+ skb->sk = sk;
>>+ *errcode = 0;
>> }
>> return skb;
>> }
>>
>>
>>--- "Destroying alive neighbour" kernel message ---
>>
>>This issue could be related by dneigh entries that are neither local nor routers.
>>
>>The following two changes seem to help (based on comparing various sources):
>>
>>The check of __refcnt in dn_route.c:dn_dst_check_expire():
>>
>> spin_lock(&dn_rt_hash_table[i].lock);
>> while ((rt = rcu_dereference_protected(*rtp,
>>
lockdep_is_held(&dn_rt_hash_table[i].lock))) != NULL) {
>>- if (atomic_read(&rt->dst.__refcnt) ||
>>+ if (atomic_read(&rt->dst.__refcnt) > 1 ||
>> (now - rt->dst.lastuse) < expire)
{
>> rtp = &rt->dst.dn_next;
>> continue;
>>
>>And the setting of initial_ref in dn_route.c:dn_route_output_slow():
>>
>> if (dev_out->flags & IFF_LOOPBACK)
>> flags |= RTCF_LOCAL;
>>- rt = dst_alloc(&dn_dst_ops, dev_out, 0, DST_OBSOLETE_NONE, DST_HOST);
>>+ rt = dst_alloc(&dn_dst_ops, dev_out, 1, DST_OBSOLETE_NONE, DST_HOST);
>> if (rt == NULL)
>> goto e_nobufs;
>>
>>
>>--- "WARNING: CPU: 0 PID: nnn at include/net/dst.h:188" kernel message
---
>>
>>This seems to be benign, and can be avoided by the following two changes
>>in dn_route.c, in void dn_dst_update_pmtu() and dn_rt_set_next_hop():
>>
>>- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
>>+ if (dst_metric_raw(dst, RTAX_MTU) > mtu && mtu >= min_mtu)
{
>>
>>- if (dst_metric(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
>>+ if (dst_metric_raw(&rt->dst, RTAX_MTU) >
rt->dst.dev->mtu)
>>
>>
>>--- Kernel segfault with ctermd (login from remote node) ---
>>
>>dnprogs 2.65 were used for testing. The segfault happens with
>>ctermd.c:cterm_reset(), where variable line is used, even though
>>it is not assigned when DNETUSE_DEVPTS is defined. So this #ifndef
>>around the code using line helps:
>>
>>#ifndef DNETUSE_DEVPTS
>> p=line+sizeof("/dev/")-1;
>>
>> setutent();
>> memcpy(entry.ut_line,p,strlen(p));
>> entry.ut_line[strlen(p)]='\0';
>> lentry=getutline(&entry);
>> lentry->ut_type=DEAD_PROCESS;
>>
>> memset(lentry->ut_line,0,UT_LINESIZE);
>> memset(lentry->ut_user,0,UT_NAMESIZE);
>> lentry->ut_time=0;
>> pututline(lentry);
>>
>> (void)chmod(line,0666);
>> (void)chown(line,0,0);
>> *p='p';
>> (void)chmod(line,0666);
>> (void)chown(line,0,0);
>>#endif
>>
>>
>>--- Using local node with dnprogs crashes the machine ---
>>
>>This has not been solved.
>>
>
>
>--
>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 
28 Jan
28 Jan
7:18 p.m.
Yay! Thanks for arranging it at latest Linux kernels! I will apply them to
my codes.
A few weeks ago, I downloaded a copy of CVS repo from Sourceforge and
successfully converted to Git repo. I plan to upload it to my github
account soon.
Then I will apply that patches to repo.
I have Ubuntu 17.10 and kept getting complaints every few minutes about NULL
pointer in decent module.
I am working on my Tinker SBC (Pi clone with faster CPU processor) for 7/24
operation.
Tim
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Erik Olofsen
Sent: Friday, January 26, 2018 3:52 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet for Linux
Thank you all for your support!
So here are some more detailed notes to get DECnet for Linux working with a
recent longterm kernel, 4.9.77. How stable it remains to be seen...
Changes to sources of other kernels are likely to be similar. But because of
many API changes, there are many differences between decnet module sources
with different kernel versions, so patch files are not too useful. However,
just a few small edits are needed.
The patches below were tested with Slackware 14.1 (which doesn't use
systemd), where it is relatively easy to build a custom kernel. Also, decnet
startup was done by hand rather than using a script:
# ifconfig eth0 mtu 576 # see below
# modprobe decnet
# echo -n area.node > /proc/sys/net/decnet/node_address # dnetd # phoned
[Kernel 4.14.15 gives BUG: unable to handle kernel NULL pointer dereference
which seems to be related to xfrm_lookup(). A kernel warning about dst.h:256
can be avoided by using dst_use_noref() instead of dst_use() at two places.]
--- MTU ---
It seems the decnet module can generate packets which are one byte larger
than intended. This can be fixed (?) in af_decnet.c:dn_mss_from_pmtu() by
adding one line:
*/
mtu -= (21 + DN_MAX_NSP_DATA_HEADER + 16);
}
+ mtu--; /* probably due to padding */
if (mtu > mss)
mss = mtu;
return mss;
The dneigh utility gives
Node HWtype HWaddress Flags MTU
Iface
rullfl loop AA:00:04:00:04:70 --- 65533
lo
rullfs ether AA:00:04:00:29:70 -2- 1498
eth0
gorvax ether AA:00:04:00:90:21 -2- 1498
eth0
pdxvax ether AA:00:04:00:98:F2 -2- 1498
eth0
dimma ether AA:00:04:00:0B:EC -2- 576
eth0
jocke ether AA:00:04:00:15:04 -2- 576
eth0
mim ether AA:00:04:00:0D:04 -2- 1500
eth0
hub ether AA:00:04:00:FE:AB -2- 576
eth0
bitxoz ether AA:00:04:00:51:1C 1-- 1492
eth0
skhngw ether AA:00:04:00:04:38 -2- 576
eth0
a44rtr ether AA:00:04:00:FF:B3 -2- 1498
eth0
where it is interesting to see values of 576, but also a value of 1500 for
MIM (but communication with MIM works well).
MTUs or blksizes are computed in dn_neigh.c, accompanied by the remark:
/*
* Make an estimate of the remote block size by assuming that its
* two less then the device mtu, which it true for ethernet (and
* other things which support long format headers) since there is
* an extra length field (of 16 bits) which isn't part of the
* ethernet headers and which the DECnet specs won't admit is part
* of the DECnet routing headers either.
*
* If we over estimate here its no big deal, the NSP negotiations
* will prevent us from sending packets which are too large for the
* remote node to handle. In any case this figure is normally
updated
* by a hello message in most cases.
*/
dn->blksize = dev->mtu - 2;
The above mtu--; seems sufficient, and subtracting an additional two not
necessary.
For HECnet, it seems best to set the MTU to 576, to be able to reach nodes
in different areas. This can be done with ifconfig.
Optionally in sysctl_net_decnet.c a /proc/sys/net/decnet/mtu entry could be
added with:
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "mtu",
+ .data = &decnet_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
},
{ }
};
where decnet_mtu needs to be declared in this source file, and in
linux/net/include/dn.h
as:
extern int decnet_mtu;
which could be used at various places instead of dst_mtu(). [But perhaps the
blksize can be requested from the remote host.]
--- "No buffer space available" message by a dnprogs utility ---
At some point in time, sock_alloc_send_skb() changed, causing a problem in
af_decnet.c:dn_alloc_send_pskb(), which can be fixed by adding the second
"+"
line (the first one seems common practice, but may be unnecessary):
if (skb) {
skb->protocol = htons(ETH_P_DNA_RT);
skb->pkt_type = PACKET_OUTGOING;
+ skb->sk = sk;
+ *errcode = 0;
}
return skb;
}
--- "Destroying alive neighbour" kernel message ---
This issue could be related by dneigh entries that are neither local nor
routers.
The following two changes seem to help (based on comparing various sources):
The check of __refcnt in dn_route.c:dn_dst_check_expire():
spin_lock(&dn_rt_hash_table[i].lock);
while ((rt = rcu_dereference_protected(*rtp,
lockdep_is_held(&dn_rt_hash_table[i].lock))) != NULL) {
- if (atomic_read(&rt->dst.__refcnt) ||
+ if (atomic_read(&rt->dst.__refcnt) > 1 ||
(now - rt->dst.lastuse) < expire) {
rtp = &rt->dst.dn_next;
continue;
And the setting of initial_ref in dn_route.c:dn_route_output_slow():
if (dev_out->flags & IFF_LOOPBACK)
flags |= RTCF_LOCAL;
- rt = dst_alloc(&dn_dst_ops, dev_out, 0, DST_OBSOLETE_NONE,
DST_HOST);
+ rt = dst_alloc(&dn_dst_ops, dev_out, 1, DST_OBSOLETE_NONE,
+ DST_HOST);
if (rt == NULL)
goto e_nobufs;
--- "WARNING: CPU: 0 PID: nnn at include/net/dst.h:188" kernel message ---
This seems to be benign, and can be avoided by the following two changes in
dn_route.c, in void dn_dst_update_pmtu() and dn_rt_set_next_hop():
- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
+ if (dst_metric_raw(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
- if (dst_metric(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
+ if (dst_metric_raw(&rt->dst, RTAX_MTU) > rt->dst.dev->mtu)
--- Kernel segfault with ctermd (login from remote node) ---
dnprogs 2.65 were used for testing. The segfault happens with
ctermd.c:cterm_reset(), where variable line is used, even though it is not
assigned when DNETUSE_DEVPTS is defined. So this #ifndef around the code
using line helps:
#ifndef DNETUSE_DEVPTS
p=line+sizeof("/dev/")-1;
setutent();
memcpy(entry.ut_line,p,strlen(p));
entry.ut_line[strlen(p)]='\0';
lentry=getutline(&entry);
lentry->ut_type=DEAD_PROCESS;
memset(lentry->ut_line,0,UT_LINESIZE);
memset(lentry->ut_user,0,UT_NAMESIZE);
lentry->ut_time=0;
pututline(lentry);
(void)chmod(line,0666);
(void)chown(line,0,0);
*p='p';
(void)chmod(line,0666);
(void)chown(line,0,0);
#endif
--- Using local node with dnprogs crashes the machine ---
This has not been solved.
5 Feb
5 Feb
8:24 p.m.
My last note was:
--- Using local node with dnprogs crashes the machine
---
This has not been solved.
But fortunately, the following + line to dn_nsp_out.c:dn_nsp_clone_and_send()
cb->xmit_count++;
cb->stamp = jiffies;
skb2->sk = skb->sk;
+ skb2->destructor = skb->destructor;
dn_nsp_send(skb2);
}
appears to fix the BUG_ON kernel panic (when connecting via the loopback device).
25 Jan
25 Jan
11:27 p.m.
Well, if it ever worked right with RSX, then I could make some use of
it. :-)
Johnny
On 2018-01-25 07:20, Mark Abene wrote:
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:
--
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
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
3:03 p.m.
Yeah, I'll second that. I have a copy of DECnet installed on Ubuntu
Trusty. I remember that I had a few problems with it and eventually gave up
on getting it running, but it's been too long and I don't remember all the
issues.
I'll probably upgrade that server to 16.04 or maybe 18.04 pretty soon, and
it'd be great if I could re-install DECnet and have it working.
Bob
-----Original Message-----
From: Hecnet-list [mailto:hecnet-list-bounces+bob=jfcl.com at lists.sonic.net]
On Behalf Of Dave McGuire
Sent: Wednesday, January 24, 2018 9:55 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet for Linux
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
_______________________________________________
Hecnet-list mailing list
Hecnet-list at lists.sonic.net
https://lists.sonic.net/mailman/listinfo/hecnet-list
27 Jan
27 Jan
7:50 p.m.
Please forgive me for letting this thread age in my inbox for a while, but I'll speak
up, too. I appreciate this work!
I had previously set up a VM with an old enough Debian distribution to support DECnet in
order to get some filesystem images off of my VAX-11/730, with partial success. I was able
to copy off images of a few RL-02 packs, but wasn't able to copy a block-level image
of its R80 drive. The copy aborted when it hit the first bad block, and I didn't (and
still don't) know enough VMS to work around that.
I have since changed my approach to setting up a SIMH emulation of a VAX running recent
enough OpenVMS to speak both DECnet and TCP/IP fluently in order to serve as a bridge
between my modern systems and the older DECnet-speaking hardware. But being able to have a
recent Linux kernel speaking DECnet would also be very helpful!
I'd like to run the SIMH emulation on a small embedded computer that I can leave on
all the time without burning lots of power, such as a BeagleBoard or Raspberry Pi. It
would be very nice if that emulation host could also natively speak DECnet. I tried
building the DECnet drivers that are still present in the Linux distro, and using the
userland stuff that's (surprisingly?) still present in the debian distro that the
BeagleBoards use, and it didn't work. I hope I'll be able to find time soon to try
out the patches, and I hope that they will make it into the mainline Linux distributions.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
8:01 p.m.
I run SIMH on a couple of Raspberry Pis without issue, one running VMS 5.4
the other VMS 7.3. They each run as cluster members so I have a cluster for
5.4 and 7.3 running at all times. It is very straightforward. I have even
set it up to automatically boot SIMH when the machine is powered on using a
tool called "screen", so I can run it completely headless. I have found that
the Raspberry Pi networking starts to get a bit unreliable after running
these machines 24 hours a day for a few years.
Regards
Rob
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Mark J. Blair
Sent: 27 January 2018 18:50
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet for Linux
Please forgive me for letting this thread age in my inbox for a while, but
I'll speak up, too. I appreciate this work!
I had previously set up a VM with an old enough Debian distribution to
support DECnet in order to get some filesystem images off of my VAX-11/730,
with partial success. I was able to copy off images of a few RL-02 packs,
but wasn't able to copy a block-level image of its R80 drive. The copy
aborted when it hit the first bad block, and I didn't (and still don't) know
enough VMS to work around that.
I have since changed my approach to setting up a SIMH emulation of a VAX
running recent enough OpenVMS to speak both DECnet and TCP/IP fluently in
order to serve as a bridge between my modern systems and the older
DECnet-speaking hardware. But being able to have a recent Linux kernel
speaking DECnet would also be very helpful!
I'd like to run the SIMH emulation on a small embedded computer that I can
leave on all the time without burning lots of power, such as a BeagleBoard
or Raspberry Pi. It would be very nice if that emulation host could also
natively speak DECnet. I tried building the DECnet drivers that are still
present in the Linux distro, and using the userland stuff that's
(surprisingly?) still present in the debian distro that the BeagleBoards
use, and it didn't work. I hope I'll be able to find time soon to try out
the patches, and I hope that they will make it into the mainline Linux
distributions.
--
Mark J. Blair, NF6X <nf6x at nf6x.net <mailto:nf6x at nf6x.net> >
http://www.nf6x.net/
8:14 p.m.
On Jan 27, 2018, at 11:01, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
I run SIMH on a couple of Raspberry Pis without issue, one running VMS 5.4 the other VMS
7.3. They each run as cluster members so I have a cluster for 5.4 and 7.3 running at all
times. It is very straightforward. I have even set it up to automatically boot SIMH when
the machine is powered on using a tool called ?screen?, so I can run it completely
headless. I have found that the Raspberry Pi networking starts to get a bit unreliable
after running these machines 24 hours a day for a few years.
I have SIMH running on a BeagleBone Green, though I don't have a lot of time or use on
it yet. It's just the native DECnet support under Linux which doesn't work out of
the box using the source in the kernel distribution and the userland stuff available via
apt-get.
One thing I'd like to look into for a full-time server is whether I might be able to
have host system shutdown trigger a VMS shutdown on the emulated system, or alternately,
just halt and checkpoint the emulation. That could be nice in conjunction with a
supercap-based backup supply for the host computer, so it can have time to shut down when
the power unexpectedly drops. I have an MFM hard drive emulator designed by David Gesswein
which is built around a BeagleBone, and it has supercap-based backup to let it be embedded
inside an old computer and simply powered on and off without worrying about performing a
shutdown on it first. When the power gets yanked, the supercaps keep it running long
enough to shut down and dismount its filesystems cleanly.
Is the network unreliability that you mention just a matter of high uptime? Does an
occasional reboot fix it, e.g. by resetting memory leaks?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
9:19 p.m.
I have the same MFM emulator, it is great, I use it to image old disks and then run the
machines from the images. I occasionally get power outages because something in kitchen
trips an RCD, the SIMH instances on the Pi have always survived this without a problem,
although a clean shutdown mechanism would be nice. However, unless you get extended power
outages, then perhaps something like this would work:
https://www.pi-supply.com/product/pi-ups-uninterrupted-power-supply-raspber…. I can?t
say I have tried it myself, but it is a nice idea.
I think the network problem with Pi is hardware, it seems to become unreliable after a
while, despite a reboot. But it does take quite some time before it becomes a problem, so
at the price, I think it is fine to get a Pi.
Regards
Rob
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark
J. Blair
Sent: 27 January 2018 19:14
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet for Linux
On Jan 27, 2018, at 11:01, Rob Jarratt <robert.jarratt at ntlworld.com
<mailto:robert.jarratt at ntlworld.com> > wrote:
I run SIMH on a couple of Raspberry Pis without issue, one running VMS 5.4 the other VMS
7.3. They each run as cluster members so I have a cluster for 5.4 and 7.3 running at all
times. It is very straightforward. I have even set it up to automatically boot SIMH when
the machine is powered on using a tool called ?screen?, so I can run it completely
headless. I have found that the Raspberry Pi networking starts to get a bit unreliable
after running these machines 24 hours a day for a few years.
I have SIMH running on a BeagleBone Green, though I don't have a lot of time or use on
it yet. It's just the native DECnet support under Linux which doesn't work out of
the box using the source in the kernel distribution and the userland stuff available via
apt-get.
One thing I'd like to look into for a full-time server is whether I might be able to
have host system shutdown trigger a VMS shutdown on the emulated system, or alternately,
just halt and checkpoint the emulation. That could be nice in conjunction with a
supercap-based backup supply for the host computer, so it can have time to shut down when
the power unexpectedly drops. I have an MFM hard drive emulator designed by David Gesswein
which is built around a BeagleBone, and it has supercap-based backup to let it be embedded
inside an old computer and simply powered on and off without worrying about performing a
shutdown on it first. When the power gets yanked, the supercaps keep it running long
enough to shut down and dismount its filesystems cleanly.
Is the network unreliability that you mention just a matter of high uptime? Does an
occasional reboot fix it, e.g. by resetting memory leaks?
--
Mark J. Blair, NF6X <nf6x at nf6x.net <mailto:nf6x at nf6x.net> >
http://www.nf6x.net/
5 Jan
5 Jan
5:43 a.m.
Erik,
Works fine for me from FEDACH and FOMFOR (ubuntu 14):
$ uname -a
Linux fedach 3.13.0-137-generic #186-Ubuntu SMP Mon Dec 4 19:12:26 UTC
2017 i686 i686 i686 GNU/Linux
$ dntype? 'mim::nodenames.dat'
?? NODE????? NODE
? ADDRESS??? NAME
1.1???????? MAGICA
1.2???????? ERNIE
1.3???????? FNATTE
1.4???????? GOBLIN
1.5???????? ZEKE
1.6???????? GNOME
1.7???????? BJARNE
1.8???????? KRILLE
1.9???????? TEMPO
1.10??????? SIGGE
1.11??????? ROCKY
1.12??????? PONY
1.13??????? MIM
1.14??????? TINA
1.15??????? PONDUS
1.16??????? GNAT
1.17??????? JOSSE
1.18??????? PAMINA
1.19??????? BEA
1.20??????? WXP
1.21??????? JOCKE
1.22??????? PUFF
1.23??????? WXP2
1.24??????? SPEEDY
1.100?????? FLETCH
1.150?????? HORSE
1.151?????? QEMUNT
1.200?????? PLINTH
1.201?????? CRISPS
1.202?????? NIPPER
1.250?????? TARDIS
1.251?????? MASTER
1.252?????? DOCTOR
1.253?????? SIDRAT
1.254?????? DAVROS
1.255?????? RUTAN
1.256?????? VAROS
1.257?????? THOROS
1.301?????? ORAV23
1.302?????? ORAV41
1.303?????? RSX134
1.304?????? RSX145
1.305?????? RSX170
1.306?????? RSX124
1.307?????? RSX184
1.350?????? ERSATZ
1.351?????? DBIT
1.400?????? VALAR
1.450?????? DE1RSX
1.451?????? KLIO
1.452?????? DE1RSY
1.500?????? HYUNA
1.510?????? PMAVS2
1.520?????? PISTON
1.540?????? REI
1.541?????? PAI
1.542?????? ROJIN
1.550?????? QCOCAL
1.551?????? CLOUDY
1.552?????? JUICHI
1.553?????? FEDACH
1.554?????? FOMFOR
1.555?????? OSTARA
1.556?????? WEXPEE
1.557?????? ENTEE4
1.558?????? RAPTOR
1.559?????? IMPVAX
1.560?????? PIDP11
1.601?????? TOPSY
1.602?????? HUGIN
1.603?????? MUNIN
1.604?????? TIPSY
1.605?????? ATLE
1.606?????? AURORA
1.607?????? LOKE
1.608?????? FREJ
1.609?????? YMER
1.610?????? NOMAD
1.616?????? ELIN
1.617?????? ELMER
1.620?????? ATHENA
1.621?????? PALLAS
1.720?????? NOXBIT
1.730?????? GAXP
1.731?????? GVAX
1.1023????? A1RTR
2.1???????? LEGATO
2.2???????? POCO
2.4???????? MEZZO
2.6???????? LARGO
2.7???????? CODA
2.9???????? DIVISI
2.10??????? ADAGIO
2.11??????? LENTO
2.12??????? JENSEN
2.14??????? MULTIA
2.15??????? PAVANE
2.16??????? ZITI
2.17??????? CHARON
2.20??????? VENTI
2.150?????? LOKI
2.201?????? SELENE
2.300?????? LEXX
2.301?????? DREAM
2.302?????? BEE
3.47??????? RVDSXL
3.171?????? NUK1C
3.222?????? MUSIPC
4.1???????? B7
4.2???????? HALO
4.10??????? DALLAS
4.11??????? RIPLEY
4.12??????? TSR2
4.13??????? VULCAN
4.14??????? VICTOR
4.244?????? CALPHA
4.245?????? ENGINE
4.246?????? MOTHER
4.247?????? MINERV
4.248?????? SIMVAX
4.249?????? SLAVE
4.250?????? ORAC
4.251?????? ZX6000
4.252?????? NODE3
4.253?????? NODE2
4.255?????? X60
4.256?????? BUBBLE
4.257?????? ELLEN
4.258?????? TIGER
4.259?????? ALEPH
5.2???????? VLC1
5.8???????? VAX780
5.10??????? MICRO1
5.11??????? MAINVX
5.12??????? MICRO2
5.14??????? VAX4
5.20??????? VAX6
5.21??????? VAX7
5.24??????? MICRO4
5.30??????? RTVAX
5.101?????? DAGO
5.102?????? FRANZ
5.103?????? DANIEL
5.104?????? DONALD
5.105?????? TRACK
5.106?????? TRICK
5.107?????? DAISY
5.108?????? GUNDEL
5.109?????? GITTA
5.110?????? PANZER
5.111?????? PRIMUS
5.112?????? GUSTAV
5.113?????? DORETT
5.114?????? HELFER
5.115?????? DICKY
5.116?????? KUNO
5.117?????? KLAAS
5.118?????? RITA
5.130?????? HOMER
5.132?????? MAGGIE
5.201?????? EARL
5.202?????? FRAN
5.203?????? ROBBIE
5.204?????? CHARLY
5.205?????? BRUCE
5.206?????? ETHYL
5.207?????? ROY
5.208?????? BASIL
5.209?????? SPIKE
5.210?????? MONICA
5.211?????? MARIO
5.301?????? JAKA
5.302?????? LILI
5.303?????? JULIUS
5.1023????? A5RTR
6.1???????? STAR69
6.2???????? QUIGON
6.3???????? BARTLD
6.4???????? TOOCHI
6.51??????? DARMOK
6.52??????? JALAD
6.110?????? ARTHUR
6.130?????? MARSHA
6.134?????? ROOSTA
7.6???????? MBSERV
7.60??????? BITXOV
7.61??????? BITXOO
7.64??????? BITXO1
7.65??????? BITXO2
7.66??????? BITXOS
7.67??????? BITXO4
7.68??????? BITXO5
7.70??????? BITXOT
7.71??????? BITXOR
7.72??????? BITXOM
7.74??????? BITXOW
7.76??????? BITXOX
7.78??????? BITXT2
7.79??????? BITXT0
7.80??????? BITXT1
7.81??????? BITXOZ
7.82??????? BITXOU
8.100?????? PPVX01
8.101?????? PPVX02
8.102?????? PPVX03
8.195?????? KETURA
8.199?????? MOSHIX
8.200?????? TACO
8.201?????? HIRAME
8.202?????? INARI
8.203?????? HAMACH
8.204?????? SUZUKI
8.205?????? EBISU
8.207?????? UNAGI
8.210?????? MAGURO
8.220?????? BEIRUT
8.221?????? LBNVAX
8.222?????? KIBBEH
8.223?????? WATAN
8.224?????? LABNEH
8.225?????? JBEIL
8.226?????? RMEIL
8.244?????? RESCUE
8.400?????? GORVAX
8.401?????? CHIMPY
8.402?????? CHIMP
8.403?????? RHESUS
8.404?????? SAMDEV
8.405?????? ARIVAX
8.408?????? VAXPLS
8.410?????? FIDOGW
8.414?????? SOLAR
8.415?????? LUNAR
8.430?????? LEMUR
8.444?????? B4GATE
8.500?????? PYFFLE
8.700?????? RAZZLE
8.800?????? BONZO
8.808?????? DELLVX
8.900?????? SMDEV0
8.901?????? SMDEV1
8.902?????? SMDEV2
8.903?????? SMDEV3
9.1???????? MOIRA
9.2???????? MINDY
9.3???????? MISSY
9.4???????? MANDY
9.5???????? GEWTST
9.7???????? GEWT1
9.10??????? MARLEY
9.12??????? MOYA
9.54??????? PYTHON
9.55??????? NI1D
9.1022????? A9RTR2
9.1023????? A9RTR1
10.1??????? SHARK
10.2??????? SNAKE
11.1??????? VAXSYS
11.2??????? MAISA
11.3??????? A11PI
11.4??????? SORKKA
11.5??????? VS3K1
11.6??????? VSVLC
11.7??????? HAWK
11.8??????? EAGLE
11.9??????? JYLKM5
11.10?????? VS2K1
11.11?????? VS4K5
11.12?????? VS2K3
11.13?????? VS2K4
11.14?????? UGLY
11.15?????? CUTE
11.16?????? MOPO
11.17?????? ROMU
11.18?????? VS3K2
11.20?????? PAKVXT
11.100????? DS20
11.101????? AXPSYS
11.102????? ALPHA
11.103????? GAMMA
11.104????? DELTA
11.105????? BETA
11.1023???? A11RTR
12.1??????? DOCMST
12.2??????? BENDER
12.3??????? TRON
12.4??????? POOKY
12.1023???? A12RTR
13.1??????? BLACK
13.2??????? BROWN
13.3??????? RED
13.4??????? ORANGE
13.5??????? YELLOW
13.6??????? GREEN
13.7??????? BLUE
13.8??????? VIOLET
13.9??????? GREY
13.10?????? WHITE
13.1023???? COLORS
14.1??????? SKNLIN
14.2??????? SKNRSX
14.3??????? SKNRSE
14.4??????? SKHNGW
14.5??????? SKNRX5
17.101????? BLISH
17.102????? GORDON
17.221????? VERNE
17.1023???? KNIGHT
18.100????? VEGAS
18.101????? RENO
18.102????? MINDEN
18.103????? NYE
18.104????? FALLON
18.105????? EYN
18.150????? ELKO
18.151????? ELY
18.414????? SULLY
18.777????? FLIND
18.1023???? GATE18
19.4??????? STRGTE
19.11?????? AGENA
19.12?????? ALTAIR
19.13?????? CRUCIS
19.14?????? TAURI
19.15?????? SCORPI
19.16?????? SPICA
19.17?????? POLLUX
19.18?????? PISCIS
19.19?????? DENUB
19.23?????? PLUTO
19.38?????? LUNA
19.40?????? SGC
19.41?????? SG1
19.42?????? SG2
19.43?????? SG3
19.44?????? SG4
19.45?????? SG5
19.46?????? SG6
19.47?????? SG7
19.48?????? SG8
19.49?????? SG9
19.55?????? VENUS
19.77?????? STARS
19.82?????? CERES
19.83?????? MARS
19.140????? DWARF
19.141????? DWARF1
19.142????? DWARF2
19.143????? DWARF3
19.144????? DWARF4
19.145????? DWARF5
19.146????? DWARF6
19.147????? DWARF7
19.150????? GALAXY
19.151????? HELIOS
19.152????? SIRIUS
19.153????? ORION
19.155????? SATURN
19.216????? RPIPDP
19.224????? RPIVAX
19.253????? DECVAX
19.254????? DECLAB
19.255????? URANUS
19.511????? ISIS
19.512????? KRONOS
19.513????? EOS
19.514????? ATLAS
19.515????? HYDRA
19.1023???? BLKHOL
20.1??????? WOPR
20.2??????? SIOP
20.3??????? TX0
20.4??????? JOSHUA
20.5??????? FALKEN
20.6??????? LYTMAN
20.100????? NORAD
20.513????? SNOW
22.10?????? SNIFFY
22.11?????? SNOTTY
22.12?????? SNORTR
22.13?????? KVASIR
22.14?????? OLAF
22.15?????? ODIN
22.16?????? THOR
22.17?????? SNOTRA
22.18?????? ULLR
22.19?????? LOFN
22.20?????? GRUMPY
22.21?????? DOPEY
22.22?????? SNEEZY
22.23?????? SLEEPY
22.24?????? HAPPY
22.25?????? BSHFUL
22.26?????? DOCK
22.27?????? HEIGH
22.28?????? HO
22.29?????? RAVEN
22.30?????? DWARFS
22.31?????? THANOS
22.32?????? BALDUR
22.33?????? TYR
22.34?????? SKAGI
22.35?????? BORR
22.36?????? DAGUR
22.37?????? NOTT
22.38?????? HEL
22.1023???? A22RTR
23.1??????? PIGLET
23.2??????? RABBIT
23.3??????? OWL
23.4??????? ROO
24.1??????? MEGARA
24.2??????? DEUS
24.3??????? MIRAGE
24.4??????? LINC
24.5??????? EVE
24.7??????? HEX
24.8??????? SARAH
24.20?????? MARA
24.21?????? DURNDL
24.22?????? LEELA
24.23?????? TYCHO
24.24?????? TRAXUS
24.25?????? THOTH
24.1023???? FROST
25.29?????? MEDDLE
25.30?????? AGAR30
25.31?????? SPRI31
26.114????? DOUDOU
26.115????? VIDOU
26.201????? MERKUR
26.411????? TGE411
27.1??????? AREA27
27.3??????? MVB
27.4??????? ALDUR
28.1??????? RULCRI
28.4??????? RULLFL
28.5??????? RULLF2
28.8??????? CUTLER
28.9??????? MSTG84
28.26?????? RULLF
28.41?????? RULLFS
30.1??????? FRODO
30.2??????? SNOOPY
30.3??????? BLINKN
30.4??????? YODA
30.6??????? R2D2
32.1??????? FDR
33.1??????? THRIFT
33.4??????? CHARY
33.14?????? FRUGAL
33.15?????? MISER
33.17?????? CHEAP
39.1??????? MASON
39.10?????? ROXY
39.11?????? BOSCO
42.1??????? CANADA
42.2??????? DAFFY
42.3??????? FUZZY
42.4??????? RIVEN
42.5??????? SPARKY
42.6??????? EARTH
42.7??????? MOON
42.8??????? FRICK
42.9??????? FRACK
42.42?????? BET
42.1022???? HUB
42.1023???? A42RTR
43.43?????? HVITA
43.44?????? HEKLA
44.1??????? HELIUM
44.2??????? XENON
44.3??????? ARGON
44.4??????? NEON
44.5??????? ZILVER
44.6??????? JODIUM
44.7??????? RADON
44.8??????? ASTAAT
44.9??????? OSMIUM
44.10?????? CHLOOR
44.11?????? ZWAWEL
44.12?????? INDIUM
44.13?????? ERBIUM
44.14?????? BROOM
44.15?????? FOSFOR
44.16?????? COBALT
44.17?????? KOPER
44.18?????? CERIUM
44.19?????? IJZER
44.20?????? CHROOM
44.21?????? NIKKEL
44.22?????? ZINK
44.23?????? LOOD
44.24?????? CURIUM
44.25?????? KWIK
44.26?????? GOUD
44.27?????? RADIUM
44.28?????? TIN
44.29?????? FLUOR
44.30?????? BOOR
44.31?????? SELEEN
44.32?????? ARSEEN
44.33?????? CARBON
44.34?????? OXYGEN
44.35?????? TITAAN
44.36?????? URAAN
44.37?????? BARIUM
44.38?????? CESIUM
44.39?????? KALIUM
44.41?????? AZOTE
44.42?????? VISMUT
44.43?????? OZON
44.1023???? A44RTR
47.11?????? GIFTVX
47.12?????? GFTVX2
47.47?????? RFSAXP
47.100????? HILANT
47.113????? SIIRI
47.333????? BEEFY
47.555????? LABVAX
47.556????? KUHAVX
47.559????? HPIVAX
47.661????? SOLAR5
47.700????? K4VX1
47.701????? K4VX2
47.727????? SHAMS
47.747????? QAMAR
47.800????? K90VX1
47.801????? K90VX2
47.900????? RNDVAX
47.1000???? BONZO2
47.1001???? SIIKA
47.1002???? SIIKAX
51.1??????? SLIMER
51.2??????? WALTER
51.3??????? DANA
51.4??????? GOZER
51.5??????? RAY
51.6??????? VIGO
51.7??????? LENNY
51.10?????? GHOST
52.1??????? SUN
52.2??????? RIFTER
52.3??????? VIGIL
52.4??????? DRAKE
52.11?????? VARGUR
52.12?????? GOLEM
52.600????? DEB390
52.1023???? A52RTR
54.27?????? CHEKOV
54.28?????? GEORDI
54.59?????? CEIRE
54.66?????? SPOCK
54.80?????? CEIDE
54.81?????? CEISI
54.82?????? CEIEE
54.92?????? SCOTTY
54.100????? A54RTR
54.188????? BTP
54.203????? NEWACA
54.334????? BOFIN
59.1??????? ODEN
59.7??????? NADJA
59.10?????? SOL
59.11?????? DIMMA
59.16?????? XERXES
59.18?????? KLEO
59.19?????? KLAS
59.20?????? KICKI
59.23?????? STORM
59.30?????? TOAD1
59.31?????? ULLA
59.32?????? FORNAX
59.33?????? REGN
59.40?????? VERA
59.41?????? MRC
59.53?????? ELVIRA
59.55?????? KRYLBO
59.56?????? R29GW
59.57?????? E825GW
59.58?????? STUPI
59.59?????? OPS1VA
59.60?????? R29GWA
60.648????? CAMECA
60.649????? ZEUS
60.650????? SAVAGE
60.651????? JOHNNY
60.652????? MONK
60.653????? HAM
60.654????? DOC
60.660????? RENNY
60.661????? LNGTOM
60.662????? DS201
60.663????? RSTSE
60.664????? PDXVAX
61.2??????? AXPEE
61.3??????? EBOLA
61.4??????? MECCA
61.5??????? FANG
61.6??????? BIGV7K
61.50?????? RA
61.150????? GLGMSH
61.151????? MARDUK
61.152????? ENKIDU
61.1023???? A61RTR
62.1??????? CTEPBA
62.2??????? XPEH
62.3??????? BIGSYS
62.4??????? COPOKA
62.5??????? BOPOHA
62.6??????? KOPOBA
62.7??????? TIS
62.8??????? ASDS20
62.9??????? ASGS80
62.10?????? NOKIA
62.11?????? KYPEBO
62.12?????? CTEPEO
62.13?????? MOHO
62.14?????? CM1420
62.15?????? CAXAP
62.16?????? BETEP
62.17?????? CCCP
62.637????? CTAKAH
On 1/3/2018 10: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)?
Thanks!
8 Feb
8 Feb
7:07 p.m.
To come back to the connection to MIM described below, it seems
to be related to an unnecessary congestion issue.
When connecting to a node, a configuration message contains
the remote buffer size. MIM/RSX returns 2086.
Accordingly, dnprogs' libdap/connection.cc:set_socket_buffer_size
sets
setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &blocksize, sizeof(blocksize))
and likewise for SO_SNDBUF, as per protocol. But this triggers "on/off"
flow control in the kernel module; the overhead to have a packet in the
decnet socket buffers is such that the above blocksize is too small,
even when it is doubled by default by the kernel - especially with
the low value of 2086. Increasing it with (in exchange_config())
set_blocksize(min(MAX_READ_SIZE, cm->get_bufsize()<<1));
(or perhaps just set_blocksize(MAX_READ_SIZE); ?)
helps a lot. Note that the kernel module and VMS announce "no flow control"
(apart from "on/off"), and RSX uses "Session Control Message" flow
control,
which the kernel module implements for outbound data, so having
the buffers perhaps too large may not be too problematic.
PS: For creating a decnet.conf the 'dncopynodes' utility may be used.
On Wed, Jan 03, 2018 at 04:02:19PM +0100, 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)?
Thanks!
11:24 p.m.
Hi.
On 2018-02-08 19:07, Erik Olofsen wrote:
To come back to the connection to MIM described below,
it seems
to be related to an unnecessary congestion issue.
When connecting to a node, a configuration message contains
the remote buffer size. MIM/RSX returns 2086.
Oh, we're talking about file transfers.
Accordingly, dnprogs'
libdap/connection.cc:set_socket_buffer_size
sets
setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &blocksize, sizeof(blocksize))
and likewise for SO_SNDBUF, as per protocol. But this triggers "on/off"
flow control in the kernel module; the overhead to have a packet in the
decnet socket buffers is such that the above blocksize is too small,
even when it is doubled by default by the kernel - especially with
the low value of 2086. Increasing it with (in exchange_config())
set_blocksize(min(MAX_READ_SIZE, cm->get_bufsize()<<1));
(or perhaps just set_blocksize(MAX_READ_SIZE); ?)
helps a lot. Note that the kernel module and VMS announce "no flow control"
(apart from "on/off"), and RSX uses "Session Control Message" flow
control,
which the kernel module implements for outbound data, so having
the buffers perhaps too large may not be too problematic.
PS: For creating a decnet.conf the 'dncopynodes' utility may be used.
I can't see how it could ever be problematic to use different buffers on
the Linux end compared to the remote node. I'm even maybe a bit
surprised that Linux tries to set it's buffers based on what RSX use.
RSX uses buffer sizes that makes sense for RSX, given the constraints of
the OS and hardware.
Johnny
On Wed, Jan 03, 2018 at 04:02:19PM +0100, 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)?
>
> Thanks!
>
--
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
2276
days inactive
2312
days old
37 comments
11 participants
participants (11)
-
bob＠jfcl.com -
bqt＠softjar.se -
e.olofsen＠xs4all.nl -
fsword007＠gmail.com -
gregg.drwho8＠gmail.com -
mcguire＠neurotica.com -
nf6x＠nf6x.net -
phiber＠phiber.com -
robert.jarratt＠ntlworld.com -
supratim＠riseup.net -
tonyblews＠gmail.com