> > In the ARP case, when there's no other traffic on p54spi, all ARP requests > > are dropped. But if there's some egress traffic from p54spi, filter seems > > to work correctly: only ARP requests that match filter pass through. > "no other traffic" sounds like a the psm filter at work, have you disabled > it before starting the experiment? I ran tests first without "iwconfig wlan0 power on", rebooted and re-ran them with PSM. Didn't notice any difference. And having ingress traffic only doesn't help ARPs to get through. They need egress to get in. In other words: I saw ingress packets in tcpdump, but no ARPs matching filter among them. But once packets start to go out of p54spi, ARPs matching filter get in. Looks very strange. > > In the multicast case filter seems to work correctly, but it treats broadcast > > as subject to that filtering too. By default only 01:00:5e:00:00:01 gets into > > priv->mc_maclist, so we miss all broadcasts. > ok, so we have to reserve a spot of ff:ff:ff:ff:ff:ff. But currently that cancels ARP filtering completely. > > These two filters seem to interfere: > > - if we set ARP filter and multicast filter without broadcast, we miss all > > ARPs if there's no egress traffic; > > - if we set ARP filter and multicast filter with broadcast, or don't set > > multicast filter at all we get all ARPs. > > > > This effect does not depend on filter setup order. > interesting, well a unnamed [but trustworthy] source told us that ST identified > a problem with the arp/multicast filter some time ago, unfortunately I haven't > seen any updated p54spi firmwares lately. Maybe this sagred stuff works? "sagred stuff" ? Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
