[HECnet] DECnet for Linux
Erik Olofsen
e.olofsen at xs4all.nl
Fri Jan 26 13:57:02 PST 2018
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
More information about the Hecnet-list
mailing list