[net.eunice] Reading the IP/TCP routing tables from memory

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