Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!pacbell!qvax2!israel From: israel@qvax2.UUCP ( Renegade@ex2564) Newsgroups: comp.unix.wizards Subject: My rwhod don't - the Final Solution! Keywords: tcp udp bsd rwho ruptime Message-ID: <539@qvax2.UUCP> Date: 25 Apr 89 18:56:04 GMT Organization: Qantel Corp., Hayward, CA Lines: 79 Thanks to all the wonderful netlanders out there who mailed in their advice on the problem. As it turned out, there were serveral problems to be dealt with, which all needed fixing. I'll summerize them all. To recap, I've got two VAX 11/750's running BSD4.2 and one uVAX running BSD4.3, all connected up to an ethernet. The 750's are using Interlan NI1010A controllers, configured with the il driver, while the uVAX is using a DEQNA board with the qe driver. The problem was that the 750's were not generating any status files via the rwhod daemon for the rwho and ruptime commands, while the uVAX was generating status only for itself. This was all true despite the fact that all other ethernet operations, such as rlogin, rsh, rexec, rcp, and even telnet and ftp were working perfectly. The first problem, that the 750's failed to generate rwhod status files (even for themselves), was the result of a kernel bug in the network ioctl calls. In order to generate status files, rwhod checks the flag settings for each network device driver for the flag IFF_BROADCAST or IFF_POINTTOPOINT. If neither flag is on, no status is processed via that interface. The problem turned out to be that the il0 interface for the network controller had the IFF_BROADCAST flag turned off improperly. The bug was located in the file /usr/sys/net/if.c, in routine ifioctl. In order to function properly, the code for case SIOCSIFFLAGS should read as follows: case SIOCSIFFLAGS: if (!suser()) return(u.u_error); if (ifp->if_flags & IFF_UP && (ifr->ifr_flags &IFF_UP) == 0) { int s = splimp(); if_down(ifp); splx(s); } ifp->if_flags = (ifp->if_flags & IFF_CANTCHANGE) | (ifr->ifr_flags &~ IFF_CANTCHANGE); break; Also, the define for IFF_CANTCHANGE needs to be added to the file /usr/sys/net/if.h, after the other IFF defines: #define IFF_CANTCHANGE (IFF_BROADCAST | IFF_POINTTOPOINT | IFF_RUNNING) After remaking the system for the 11/750's, they were now able to generate rwhod status. However, they were only able to talk to each other, and not to the uVAX. The problem now was two-fold: 1) The default broadcast addresses were different between BSD4.2 and BSD4.3 - the 4.2 nodes were communicating over network address 128.2.0.0, while 4.3 wanted to talk to 128.2.255.255. 2) An error in the calculation of udp checksum values in the BSD4.2 udp packets (which are used for transmitting rwhod status files) resulted in 4.2 nodes talking to each other, but prevented 4.3 nodes from accepting 4.2-generated packets. Fixes to both problems were implemented on the uVAX side. The first problem was dealt with by reconfiguring the broadcast address for the qe0 driver using the ifconfig utility. The following command was included in the /etc/rc.local file on the uVAX: /etc/ifconfig qe0 inet `hostname` broadcast 128.2.0.0 As a result, the uVAX broadcast address is now reconfigured to the broadcast address of the 11/750's during each boot-up procedure. This now permits the uVAX to send udp packets to the 11/750's, but it is still not able to receive them. In order to accomplish that, it is necessary to disable udp checksum checking on the BSD4.3 side. This is done by setting the COMPAT_42 option in the system configuration file, and remaking the system. As a result, the file /usr/sys/netinet/udp_usrreq.c will compile the variable udpcksum with an initialized value of 0, disabling checksum checking. (Be sure to touch the file /usr/sys/netinet/udp_usrreq.c before the remake to insure that it will be recompiled.) With the checksum off, BSD4.3 can now transmit and receive udp packets from BSD4.2. -- Renegade of Berkeley, Qantel Business Systems, hplabs!qantel!qvax2!israel or Renegade Systems, hplabs!qantel!hamster!israel Disclaimer: "Who, me? I wasn't even there!"