Subject: kern/25647: IPF no longer does 0/32 correctly in some cases
To: None <gnats-bugs@gnats.NetBSD.org>
From: None <perry@piermont.com>
List: netbsd-bugs
Date: 05/19/2004 22:06:12
>Number:         25647
>Category:       kern
>Synopsis:       IPF no longer does 0/32 correctly in some cases
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 20 02:07:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Perry E. Metzger
>Release:        NetBSD 2.0E
>Organization:
Perry E. Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
>Environment:
	
	
System: NetBSD hackworth 2.0E NetBSD 2.0E (HACKWORTH) #0: Sat May 8 22:31:25 EDT 2004 perry@hackworth:/usr/src/sys/arch/i386/compile/HACKWORTH i386
Architecture: i386
Machine: i386
>Description:
	I have a machine with many NICs, some of which have several
>How-To-Repeat:
	See above.
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:
 	
 	
 >addresses. Prior to the IPF upgrade, the 0/32 syntax in lines like
 
 map pppoe0 166.84.151.64/28 -> 0/32 portmap tcp/udp 40000:60000 mssclamp 1400
 
 worked perfectly.
 
 Now IPF picks for 0/32 not the address pppoe0 but instead the second
 address on a different NIC entirely. This is VERY BAD.