bwp@utcs.UUCP (Bruce Pinn) (11/16/84)
Our site is currently running Wollongong's IP/TCP under Eunice. Recently I have been attempting to port the route daemon to our machine and have run into a number of problems. They are 1. How does one read the routing tables directly from the kernel code? /dev/kmem does not exist under Eunice and hence is not available for reading. 2. I believe that the nlist function works off of the inet.stb file. Is this correct, or am I simply on a winding trail to nowhere? Does anyone (please) know the answer to these questions, or can provide insite into the way Wollongong reads the incore tables (they must be reading the `inet memory' for commands like netstat, route, etc). Thanks in advance! Bruce Pinn (University of Toronto) ...allegra!utzoo!utcs!utgumby!bwp ...ihnp4!utcs!utgumby!bwp p.s. With a few minor exceptions Wollongong's IP/TCP code is really quite good!
kvc@scgvaxd.UUCP (Kevin Carosso) (11/20/84)
In article <> bwp@utcs.UUCP (Bruce Pinn) writes: > > 1. How does one read the routing tables directly from the kernel > code? /dev/kmem does not exist under Eunice and hence is not > available for reading. One thing to remember -- under VMS, the "kernel" is part of your address space (it is the S0 (lower half of the upper half, actually) part). You can read the routing tables by simply looking at the right address in system space. I dunno what the address is, but maybe Wollongong provided a link map of their driver code, which would have the symbols and offsets of their data structures (dream on...). /Kevin Carosso allegra!scgvaxd!kvc Hughes Aicraft Co.
kashtan@sri-iu.UUCP (David L. Kashtan) (11/21/84)
Under EUNICE, nlist() will indeed read the ETC:INET.STB symbol table. Since the network data structures in the kernel may contain sensitive information, they are specifically kept KERNEL-MODE access only. The following routines implement klseek()/klread() which act like lseek/read on /dev/kmem. David /* * /dev/kmem seek/read */ static char *current_addr = 0; /* Our current Seek address */ klseek(dummy,addr,whence) char *addr; { current_addr = addr; /* Just stash the desired address */ } static char *klread_buffer; /* User buffer to read into */ static int klread_size; /* User buffer size */ klread(dummy,buffer,size) char *buffer; { extern klread_krnl(); /* * Fill in arguments to the kernel mode code */ klread_buffer = buffer; klread_size = size; /* * Fetch the kernel data in kernel mode */ sys$cmkrnl(klread_krnl,0); /* * Return the given size (just to be consistent with read) */ return(size); } /* * This is executed in kernel mode * (since network data structures are protected from casual user access) */ static klread_krnl() { register char *cp,*cp1; register int i; cp1 = klread_buffer; cp = current_addr; i = klread_size; while(i > 0) { if (kl_prober(cp)) *cp1++ = *cp++; current_addr++; i--; } return; } static kl_prober(cp) { /* * Change our previous mode to KERNEL so that the probe * will check for kernel read access -- construct a new * PSL/PC on the stack and REI to it */ asm(" clrl -(sp)"); asm(" movab 1f,-(sp)"); asm(" rei"); /* * Now check for read access */ asm("1: prober $0,$4,*4(ap)"); asm(" bneq 2f"); asm(" clrl r0"); asm(" ret"); asm("2: movl $1,r0"); asm(" ret"); } -- David Kashtan, Artificial Intelligence Center, SRI International ARPA: Kashtan@SRI-IU or Kashtan@SRI-AI UUCP: {lbl-csam, sri-unix, cmcl2} !sri-iu!kashtan