[HECnet] DECnet for Linux

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