hi folks, i'm having problem providing an IP address to a device connected via a bridge (apple airport). it appears that ipfilter is the culprit, since it is blocking part of the DHCP broadcast:
# ipmon -t 03/01/2009 12:31:17.325558 rge2 @60:9 b 0.0.0.0,68 -> 255.255.255.255,67 PR udp len 20 328 IN broadcast the thing is, i've tried several permutations of rules to allow this, here's the latest (network addresses redacted): @7 block in quick on rge2 all head 60 @1 pass in quick on rge2 proto tcp from 203.16.x.y/27 to any keep state keep frags group 60 @2 pass in quick on rge2 proto udp from 203.16.x.y/27 to any keep state group 60 @3 pass in quick on rge2 proto gre from 203.16.x.y/27 to any keep state group 60 @4 pass in quick on rge2 proto esp from 203.16.x.y/27 to any keep state group 60 @5 pass in quick on rge2 proto icmp from 203.16.x.y/27 to any keep state group 60 @6 pass in quick on rge2 proto udp from any to any port = bootps keep state group 60 @7 pass in quick on rge2 proto udp from any to any port = bootpc keep state group 60 @8 pass in quick on rge2 proto udp from 0.0.0.0/32 port = bootpc to 255.255.255.255/32 port = bootps keep state group 60 @9 block in log first quick all group 60 ...now i would have thought that 60 at 6 would have allowed the traffic shown blocked by ipmon to pass, or if not that then at least 60 at 8 which is an exact match for what's blocked (isn't it?) turning OFF ipfilter allows the DHCP session to complete & the device to acquire an address as expected, further implicating ipfilter. fwiw the problem only affects the device accessing via the bridge. devices directly connected to that network segment can get their IP address without problems, although i haven't checked to see if they get some packets blocked during the session & can cope since they're physically connected. dhcp/ipfilter server is snv103 x86 32 bit. any suggestions very welcome! -- This message posted from opensolaris.org
