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.