broadcast problems with dhcpd on bridge interfaces?

[Chris Adams]

I'm seeing a fairly odd problem with a wisp-dist (2.4.20 / install on a 
Soekris 4521 with a NetGate NL-2511 Prism2.5 card. I have dhcpd running 
on a bridge interface using eth1 and netcs1. I have two OS X machines 
which obtain leases normally and a WET11 connected to a W2k desktop, 
neither of which can obtain a lease.

The entire config is pretty vanilla - public eth0 NATed for br0 
clients, no firewall rules, wireless card is a prism2.5 in HostAP mode, 
WEP isn't involved, etc. The only change from the default wisp-dist was 
the replacement of pump with dhclient to avoid pump's client ip 
brain-damage.

dhcpd is clearly seeing the requests:
> May 10 22:29:52 192.168.1.1 dhcpd: DHCPDISCOVER from 00:06:25:02:a4:54 
> via br0
> May 10 22:29:53 192.168.1.1 dhcpd: DHCPOFFER on 192.168.1.4 to 
> 00:06:25:02:a4:54 via br0

That offer is never received by the client. tcpdump on br0 (or netcs1) 
shows no sign of any reply being sent by dhcpd but that's apparently a 
bug as it never shows a reply for the working hosts, either. tcpdump 
behind the WET11 shows requests being sent without reply from the 
server.

The one interesting thing in syslog is this message:
> AP: packet to non-associated STA <ethernet MAC of machine behind WET11>

Everything works with static IP assignments; I can even send a 
broadcast ping from an autoconfigured (169.254) address and get replies 
from the other clients.

My current theory is that some interaction between the bridging code 
and broadcast is causing the hostap driver to discard broadcast 
packets, which would explain why unicast traffic is unaffected. What I 
don't understand is why this bug would only affect the WET11 - not 
forwarding packets to a machine which isn't known to be on the wireless 
network fits; refusing to send broadcast packets to another wireless 
client does not. There's also something odd about OS X being unaffected 
but I haven't compared the raw frames between the working and 
non-working systems yet - since the same machine which works over 
802.11b will also fail over ethernet behind the WET11 it doesn't look 
like a difference between the DHCP clients.

I've spent a fair amount of quality time with Google and haven't turned 
up any solutions, although I've found a few people asking about what 
sounds like the same problem. Has anyone found a fix?

"prism2_param netcs1 wds_type" looked interesting based on the 
description ("use broadcast RA (WDS frame destination) for broadcast 
and multicast frames") and the default having this disabled but it 
returns an error ("Interface doesn't accept private ioctl...") for any 
of the values listed. Based on the STA firmware version in dmesg 
(v1.4.9) it sounds like I need new firmware to have this work using the 
standard mode (4) - unfortunately, NetGate only has 1.4.9 up on their 
website.

Does it reasonable to expect a newer revision to fix this problem or am 
I chasing the wrong option?

Thanks,
Chris