[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: Problems with ipmon core dumping under SunOS 4.1.4
From:       schorr () ead ! dsa ! com (Andrew J !  Schorr)
Date:       1997-03-21 19:25:56
[Download RAW message or body]

Tim,

You wrote:
> 
> 
> Now that the modload charmajor problem is solved, I began using ipfilter
> 3.1.9 in earnest.  Again, SunOS 4.1.4, compiled with gcc 2.7.2 as a LKM.
> 
> What is happening now is that ipmon runs for a while and then dumps core.
> It appears to do this after logging any message.  Has anyone else had this
> type of problem with ipmon?
> 

I think the following copy of some e-mail I sent to Darren on March 11
will help you with your problem.  I probably should have posted it to
the list, but I hadn't joined the list yet at the time (the material
about SunOS 4.1.4 LKM's is now outdated, and should be ignored):

First, let me thank you for providing a wonderful package that is indispensable
to our site's security.

Second, allow me to complain about some problems I had with ip_fil3.1.9
on SunOS 4.1.4 :-)

I have only one bug to report, and the rest of my issues pertain to installation
problems.

Bug: in ipmon, the last line of the printpacket function tries to fflush
	the log FILE without checking whether it syslog is actually being
	used instead of a FILE.  So, if you use ipmon -s, you get a core
	file every time printpacket is called.  Here is a patch:

*** ipmon.c.0	Tue Feb  4 09:49:19 1997
--- ipmon.c	Tue Mar 11 10:50:06 1997
***************
*** 484,490 ****
  		dumphex(log, buf, sizeof(struct ipl_ci));
  	if (opts & OPT_HEXBODY)
  		dumphex(log, ip, lp->plen + lp->hlen);
! 	fflush(log);
  }
  
  int main(argc, argv)
--- 484,491 ----
  		dumphex(log, buf, sizeof(struct ipl_ci));
  	if (opts & OPT_HEXBODY)
  		dumphex(log, ip, lp->plen + lp->hlen);
! 	if (!(opts & OPT_SYSLOG))
! 		fflush(log);
  }
  
  int main(argc, argv)

	
And now for my installation problems:

1. I first tried to install ip_fil as a loadable kernel module for
	SunOS 4.1.4.  I run the SunOS4/minstall script, and everything
	seemed fine until I rebooted the system.  After running
	modload if_ipl.o, modstat gave the following output:

Id  Type  Loadaddr      Size   B-major  C-major  Sysnum   Mod Name
 1  Pdrv  ff07f000      d000               1.             IP Filter v3.1.9 - 8/3/97

	Meanwhile, the device /dev/ipl had been created as follows:
ls -l /dev/ipl
crw-------  1 root      59,   0 Mar 10 18:24 /dev/ipl

	I do not know very much about how loadable drivers are implemented
	in SunOS 4.1.4, but everything appeared to be screwed up because
	the modstat was showing C-major 1 instead of C-major 59, but the
	device file was created with a major number of 59.  When I tried
	to run ipf or ipfstat, they gave errors like:

	    open device: No such device
	    ioctl(SIOCADDFR): Bad file number
	    ioctl(SIOCADDFR): Bad file number

	When I previously had installed ip_fil2.8 on SunOS 4.1.3, I did not
	have this problem; modstat showed C-major 59., and the device
	was created properly with device 59.

	I frankly have no clue why modload is loading the device
	with C-major 1.  Any light you can shed on this problem would be
	appreciated.

2. So I gave up on using a loadable kernel module and decided to install
	the packet filter package directly into the kernel.  I followed
	the instructions and ran SunOS4/kinstall.

	However, when I compiled the kernel, the C compiler gave the following
	error message:

"../../netinet/in_proto.c", line 55: warning: illegal pointer combination

	I took a look at in_proto.c, and the compiler appears to be correct.
	You are defining ip_init to be iplinit, but this poses a problem since
	ip_init returns an int, whereas iplinit() is declared as void iplinit().

	To correct this problem, I applied the following patch:

*** SunOS4/in_proto.c.diffs.0	Thu Jan  9 10:14:49 1997
--- SunOS4/in_proto.c.diffs	Mon Mar 10 20:19:55 1997
***************
*** 7,13 ****
    #endif
    
  + #ifdef IPFILTER
! + extern	void	iplinit();
  + #define	ip_init	iplinit
  + #endif
  + 
--- 7,13 ----
    #endif
    
  + #ifdef IPFILTER
! + extern	int	iplinit();
  + #define	ip_init	iplinit
  + #endif
  + 
*** ip_fil.c.0	Wed Feb 19 07:45:02 1997
--- ip_fil.c	Mon Mar 10 20:21:06 1997
***************
*** 701,710 ****
  
  
  #ifndef	IPFILTER_LKM
! void iplinit()
  {
  	(void) iplattach();
! 	ip_init();
  }
  #endif
  
--- 701,710 ----
  
  
  #ifndef	IPFILTER_LKM
! int iplinit()
  {
  	(void) iplattach();
! 	return ip_init();
  }
  #endif
  
	After making this patch, I built the kernel and rebooted the machine.
	But when I rebooted the system, my network connectivity was totally
	hosed.  After much gnashing of teeth, I realized that the filters
	were using a default policy of blocking all the packets.  This wreaked
	havoc with the system boot/initialization procedures.

	After a little bit of thought, I realized that there are a few
	symbols defined in the Makefile that comes with the ip_fil package
	that are not being defined when SunOS builds the kernel.  In particular,	I concluded \
that these two defines need to be in effect when the  kernel is built:

		#define IPFILTER_LOG
		#define IPF_DEFAULT_PASS FR_PASS

	The first problem was easily solved by adding IPFILTER_LOG as a
	kernel configuration option.  I did this using the following
	patch to the SunOS4/kinstall script:

*** SunOS4/kinstall.0	Thu Jan  9 10:14:49 1997
--- SunOS4/kinstall	Tue Mar 11 12:28:43 1997
***************
*** 34,40 ****
  	mv /sys/$karch/$newconfig /sys/$karch/$newconfig.bak
  endif
  mv $confdir/$newconfig $confdir/$newconfig.bak
! awk '{print $0;if($2=="INET"){print"options IPFILTER"}}' \
  	$confdir/$newconfig.bak > $confdir/$newconfig
  echo "Running config $newconfig"
  cd $confdir
--- 34,40 ----
  	mv /sys/$karch/$newconfig /sys/$karch/$newconfig.bak
  endif
  mv $confdir/$newconfig $confdir/$newconfig.bak
! awk '{print $0;if($2=="INET"){print"options IPFILTER\noptions IPFILTER_LOG"}}' \
  	$confdir/$newconfig.bak > $confdir/$newconfig
  echo "Running config $newconfig"
  cd $confdir

	I still did not see an easy way to get IPF_DEFAULT_PASS defined
	properly.  In the end, I just made the following patch to fil.c
	to make pass the default policy when it is not explicitly defined:

*** fil.c.0	Tue Feb 18 05:53:47 1997
--- fil.c	Tue Mar 11 12:33:09 1997
***************
*** 103,109 ****
  #ifdef	IPF_DEFAULT_PASS
  #define	IPF_NOMATCH	(IPF_DEFAULT_PASS|FR_NOMATCH)
  #else
! #define	IPF_NOMATCH	(FR_NOMATCH)
  #endif
  
  struct	filterstats frstats[2] = {{0,0,0,0,0},{0,0,0,0,0}};
--- 103,109 ----
  #ifdef	IPF_DEFAULT_PASS
  #define	IPF_NOMATCH	(IPF_DEFAULT_PASS|FR_NOMATCH)
  #else
! #define	IPF_NOMATCH	(FR_PASS|FR_NOMATCH)
  #endif
  
  struct	filterstats frstats[2] = {{0,0,0,0,0},{0,0,0,0,0}};

	I am not sure whether this patch is advisable in general, but it
	fixed my problems.  Do people really want a default policy of
	blocking the packets?

Anyway, sorry to go on for so long, but I was hoping that these changes could
be incorporated so that I won't need to hack up future versions.

Once again, thanks for a great package,
Andy

P.S. Please let me know if anything in this message is confusing, unclear,
	or wrong.

=============================
Andrew Schorr, SVP
Daiwa Securities America Inc.
Financial Square
32 Old Slip, 12th Floor
New York, NY 10005-3538

e-mail: schorr@ead.dsa.com
phone:  212-612-6574
fax:    212-612-7115


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic