Christopher SEKIYA wrote:
> Don't know, but the patch as committed by darrenr and pulled up to 2.0 broke
> ipf on i386.  With sources refreshed this afternoon, ipf -E bombs out with
> "SIOCFRENB: Bad address".
> 
> It looks like it's dying at the COPYIN() at ip_fil_netbsd.c:451.  The
> surrounding code looks like:
> 
>         case SIOCFRENB :
>                 if (!(mode & FWRITE))
>                         error = EPERM;
>                 else {
>                         error = COPYIN(data, &tmp, sizeof(tmp));
>                         if (error)
>                                 break;

Yeah, that code is obviously wrong - 'data' is memory malloced by kernel
code in kernel address space, so this could never work. Does
any OS IPF runs on leave 'data' for ioctl as the user-space pointer?
If so, there should be some new macro, otherwise it should
be changed to memcpy/bcopy or direct assignment.

BTW, I can also confirm the new IPF (before the COPYIN() macro
change) works fine for me on i386 with IPv4. Using IPv6 with IPF
enabled results in panic - I can submit repeatable steps to do that
even on local machine without external IPv6 connectivity.

Jaromir

>  
> Reverting that patch results in a functioning instance of ipf.  I'm open to
> the possibility that the problem actually lies elsewhere, but this really
> looks like the cause for my failure at least.
> 
> -- Chris
> 	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)
> 

-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the Buddhist -=-
-=- masters say, ``You may notice during meditation that you        -=-
-=- sometimes levitate or glow.   Do not let this distract you.''   -=-