FUWO (For Unix Wizards Only)...


robert a woodburn (woody@MACOM3)
Wed, 10 Jun 87 09:50:50 EDT


We're working on an experimental protocol and in the course
of prototype development, decided we needed to add a few
protocol numbers to the kernel configurations to do our work.

The strange part is that we had already successfully added one
protocol previously. Trying to add just one more seems to break
our kernel. The kernel works, but is flaky with the following symptoms:

>[>[woody@macom3|/usr/macserver/woody]<*> uptime
> 9:28am up 6369 days, 12:14, 1 user, load average: 0.00, 7168355.43, 7156480.00
>[>[woody@macom3|/usr/macserver/woody]<*> ps
> PID TT STAT TIME COMMAND
>ps: error reading proc table from /dev/kmem
>[>[woody@macom3|/usr/macserver/woody]<*> ps -uax
>ps: error reading text table from /dev/kmem
>[>[woody@macom3|/usr/macserver/woody]<*>

So as you can see the process table seems corrupt, or at least
applications trying to access kernel memory are confused for
some reason. The following lines were added to "/usr/sys/netinet/in.h"

#define IPPROTO_DGP 9 /* dgp */
#define IPPROTO_DGP1 8 /* dgp */

(Yes, I know, 8 is the number for EGP, but we're not running EGP,
 so its ok)

and these lines were added to "/usr/sys/netinet/in_proto.c" to the
inetsw structure:

{ SOCK_RAW, PF_INET, IPPROTO_DGP, PR_ATOMIC|PR_ADDR,
  rip_input, rip_output, 0, 0,
  raw_usrreq,
  0, 0, 0, 0,
},
{ SOCK_RAW, PF_INET, IPPROTO_DGP1, PR_ATOMIC|PR_ADDR,
  rip_input, rip_output, 0, 0,
  raw_usrreq,
  0, 0, 0, 0,
},

Now, just adding one record is fine, but adding two causes the minor
brain damage described above. We only have a total of ten protocols
in use total. After making these changes, all that I do is run
/etc/config, and then make the kernel, and thats it, and it doesn't work.
If anyone out there has had this problem and found a solution, or even
if you haven't found a solutions, please send me mail.

                                THANKS!!!!
                                                wood y



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:19 GMT