[HECnet] DECnet for Linux
Johnny Billquist
bqt at softjar.se
Fri Jan 26 13:52:27 PST 2018
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
More information about the Hecnet-list
mailing list