[RFT] p54: implement multicast + arp req PS filter

[RFT] p54: implement multicast + arp req PS filter

[Christian Lamparter]

"For best CPU usage and power consumption, having as few
frames as possible percolate through the stack is
desirable. Hence, the hardware should filter as much
as possible."

Note: The available stlc45xx softmac specification does not
specify whenever these features are implemented in the
common [pci/usb] branches, or not . At least from the data
I could gather, it doesn't look like this is the case.
Therefore, I'm looking for test results from p54spi users.
---
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 2fab7d2..e8c7d02 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -727,3 +727,67 @@ int p54_fetch_statistics(struct p54_common *priv)
 	p54_tx(priv, skb);
 	return 0;
 }
+
+int p54_set_arpfilter(struct p54_common *priv)
+{
+	struct p54_arp_table *arp;
+	struct sk_buff *skb;
+	struct ieee80211_bss_conf *bss_conf = NULL;
+	bool on = false;
+
+	skb = p54_alloc_skb(priv, P54_HDR_FLAG_CONTROL_OPSET, sizeof(*arp),
+			    P54_CONTROL_TYPE_ARPTABLE, GFP_KERNEL);
+	if (!skb)
+		return -ENOMEM;
+
+	arp = (struct p54_arp_table *)skb_put(skb, sizeof(*arp));
+	if (priv->vif) {
+		bss_conf = &priv->vif->bss_conf;
+
+		on = bss_conf->arp_filter_enabled &&
+		     bss_conf->arp_addr_cnt == 1;
+	}
+
+	if (on) {
+		arp->filter_enable = cpu_to_le16(1);
+		memcpy(arp->ipv4_addr, &bss_conf->arp_addr_list[0],
+		       sizeof(arp->ipv4_addr));
+	} else {
+		arp->filter_enable = cpu_to_le16(0);
+		memset(arp->ipv4_addr, 0, sizeof(arp->ipv4_addr));
+	}
+
+	p54_tx(priv, skb);
+	return 0;
+}
+
+int p54_set_groupfilter(struct p54_common *priv)
+{
+	struct p54_group_address_table *grp;
+	struct sk_buff *skb;
+	bool on = false;
+
+	skb = p54_alloc_skb(priv, P54_HDR_FLAG_CONTROL_OPSET, sizeof(*grp),
+			    P54_CONTROL_TYPE_GROUP_ADDRESS_TABLE, GFP_KERNEL);
+	if (!skb)
+		return -ENOMEM;
+
+	grp = (struct p54_group_address_table *)skb_put(skb, sizeof(*grp));
+
+	on = !(priv->filter_flags & FIF_ALLMULTI) &&
+	     (priv->mc_maclist_num > 0 &&
+	      priv->mc_maclist_num < MC_FILTER_ADDRESS_NUM);
+
+	if (on) {
+		grp->filter_enable = cpu_to_le16(1);
+		grp->num_address = cpu_to_le16(priv->mc_maclist_num);
+		memcpy(grp->mac_list, priv->mc_maclist, sizeof(grp->mac_list));
+	} else {
+		grp->filter_enable = cpu_to_le16(0);
+		grp->num_address = cpu_to_le16(0);
+		memset(grp->mac_list, 0, sizeof(grp->mac_list));
+	}
+
+	p54_tx(priv, skb);
+	return 0;
+}
diff --git a/drivers/net/wireless/p54/lmac.h b/drivers/net/wireless/p54/lmac.h
index f666482..2990715 100644
--- a/drivers/net/wireless/p54/lmac.h
+++ b/drivers/net/wireless/p54/lmac.h
@@ -540,6 +540,8 @@ int p54_update_beacon_tim(struct p54_common *priv, u16 aid, bool set);
 int p54_setup_mac(struct p54_common *priv);
 int p54_set_ps(struct p54_common *priv);
 int p54_fetch_statistics(struct p54_common *priv);
+int p54_set_arpfilter(struct p54_common *priv);
+int p54_set_groupfilter(struct p54_common *priv);
 
 /* e/v DCF setup */
 int p54_set_edcf(struct p54_common *priv);
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index e6205e4..ef612f5 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -308,6 +308,27 @@ out:
 	return ret;
 }
 
+static u64 p54_prepare_multicast(struct ieee80211_hw *dev,
+				 struct netdev_hw_addr_list *mc_list)
+{
+	struct p54_common *priv = dev->priv;
+	struct netdev_hw_addr *ha;
+	int i = 0;
+
+	BUILD_BUG_ON(ARRAY_SIZE(priv->mc_maclist) !=
+		ARRAY_SIZE(((struct p54_group_address_table *)NULL)->mac_list));
+
+	priv->mc_maclist_num = netdev_hw_addr_list_count(mc_list);
+	netdev_hw_addr_list_for_each(ha, mc_list) {
+		memcpy(&priv->mc_maclist[i], ha->addr, ETH_ALEN);
+		i++;
+		if (i >= ARRAY_SIZE(priv->mc_maclist))
+			break;
+	}
+
+	return 1; /* update */
+}
+
 static void p54_configure_filter(struct ieee80211_hw *dev,
 				 unsigned int changed_flags,
 				 unsigned int *total_flags,
@@ -316,12 +337,16 @@ static void p54_configure_filter(struct ieee80211_hw *dev,
 	struct p54_common *priv = dev->priv;
 
 	*total_flags &= FIF_PROMISC_IN_BSS |
+			FIF_ALLMULTI |
 			FIF_OTHER_BSS;
 
 	priv->filter_flags = *total_flags;
 
 	if (changed_flags & (FIF_PROMISC_IN_BSS | FIF_OTHER_BSS))
 		p54_setup_mac(priv);
+
+	if (changed_flags & FIF_ALLMULTI || multicast)
+		p54_set_groupfilter(priv);
 }
 
 static int p54_conf_tx(struct ieee80211_hw *dev, u16 queue,
@@ -412,6 +437,9 @@ static void p54_bss_info_changed(struct ieee80211_hw *dev,
 		}
 	}
 
+	if (changed & BSS_CHANGED_ARP_FILTER)
+		WARN_ON(p54_set_arpfilter(priv));
+
 	mutex_unlock(&priv->conf_mutex);
 }
 
@@ -591,6 +619,7 @@ static const struct ieee80211_ops p54_ops = {
 	.config			= p54_config,
 	.flush			= p54_flush,
 	.bss_info_changed	= p54_bss_info_changed,
+	.prepare_multicast	= p54_prepare_multicast,
 	.configure_filter	= p54_configure_filter,
 	.conf_tx		= p54_conf_tx,
 	.get_stats		= p54_get_stats,
diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
index 50730fc..799d05e 100644
--- a/drivers/net/wireless/p54/p54.h
+++ b/drivers/net/wireless/p54/p54.h
@@ -211,8 +211,10 @@ struct p54_common {
 	/* BBP/MAC state */
 	u8 mac_addr[ETH_ALEN];
 	u8 bssid[ETH_ALEN];
+	u8 mc_maclist[4][ETH_ALEN];
 	u16 wakeup_timer;
 	unsigned int filter_flags;
+	int mc_maclist_num;
 	int mode;
 	u32 tsf_low32, tsf_high32;
 	u32 basic_rate_mask;

Re: [RFT] p54: implement multicast + arp req PS filter

[Max Filippov]

Hi, Christian.

> "For best CPU usage and power consumption, having as few
> frames as possible percolate through the stack is
> desirable. Hence, the hardware should filter as much
> as possible."
> 
> Note: The available stlc45xx softmac specification does not
> specify whenever these features are implemented in the
> common [pci/usb] branches, or not . At least from the data
> I could gather, it doesn't look like this is the case.
> Therefore, I'm looking for test results from p54spi users.

I used for tests the following cell:

wlan1     Scan completed :
          Cell 01 - Address: 00:22:15:1C:09:D1
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=67/70  Signal level=-43 dBm  
                    Encryption key:on
                    ESSID:"test"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s
                    Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=0000000ebd708a53
                    Extra: Last beacon: 1016ms ago
                    IE: Unknown: 000474657374
                    IE: Unknown: 010882848B960C121824
                    IE: Unknown: 03010B
                    IE: Unknown: 2A0100
                    IE: Unknown: 32043048606C
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK
                    IE: Unknown: DD180050F2020101000003A4000027A4000042435E0062322F00

Is it suitable? I guess that to do e.g. ARP filtering firmware must be able to decipher incoming packets.
How can I make sure that it does?

So, I associated with that AP and obtained an IP address.
Here's dmesg output to that moment:

[    4.192993] ieee80211 phy0: device now idle
[    4.197265] omap_device: omap2_mcspi.2: new worst case deactivate latency 0: 335693
[    4.217712] p54_set_groupfilter 1
[   30.147735] ieee80211 phy0: device no longer idle - scanning
[   30.152770] p54_set_groupfilter 1
[   31.028350] p54_set_groupfilter 1
[   31.028503] ieee80211 phy0: device now idle
[   36.037445] ieee80211 phy0: device no longer idle - scanning
[   36.037628] p54_set_groupfilter 1
[   36.919036] p54_set_groupfilter 1
[   36.919189] ieee80211 phy0: device now idle
[   36.931854] ieee80211 phy0: device no longer idle - working
[   36.932067] wlan0: authenticate with 00:22:15:1c:09:d1 (try 1)
[   36.948089] wlan0: authenticated
[   36.952606] ieee80211 phy0: device now idle
[   36.969268] ieee80211 phy0: device no longer idle - working
[   36.969512] wlan0: associate with 00:22:15:1c:09:d1 (try 1)
[   36.988677] wlan0: RX AssocResp from 00:22:15:1c:09:d1 (capab=0x411 status=0 aid=2)
[   36.988830] wlan0: associated
[   36.988922] ieee80211 phy0: Allocated STA 00:22:15:1c:09:d1
[   36.992919] ieee80211 phy0: Inserted STA 00:22:15:1c:09:d1
[   36.993103] ieee80211 phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0 uapsd=0
[   36.993255] ieee80211 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
[   36.993377] ieee80211 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
[   36.993530] ieee80211 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
[   36.993743] p54_set_arpfilter 0
[   37.006134] omap_device: omap2_mcspi.2: new worst case deactivate latency 0: 1220703
[   37.028442] omap_device: omap2_mcspi.2: new worst case activate latency 0: 122070
[   51.168762] p54_set_arpfilter 1
[   51.170257] p54_set_groupfilter 1
[   51.171569] p54_set_groupfilter 1

Regarding ARP filtering I tried the following test:
- ping station from the outside to see if ARPs for its IP pass through;
- ping non-existing IP in the same network from the outside to see if other ARPs pass through.

To test multicast filtering I tried to ping several multicast addresses from the outside.

> +	if (on) {
> +		arp->filter_enable = cpu_to_le16(1);
> +		memcpy(arp->ipv4_addr, &bss_conf->arp_addr_list[0],
> +		       sizeof(arp->ipv4_addr));
> +	} else {
> +		arp->filter_enable = cpu_to_le16(0);
> +		memset(arp->ipv4_addr, 0, sizeof(arp->ipv4_addr));
> +	}

I see that although ARP filter was set (I added printfs to both branches above), all ARP requests pass through:

(none):~# ./tcpdump -i wlan0 -nn -s0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:01:33.715332 arp who-has 192.168.4.33 tell 192.168.4.138
00:01:33.716644 arp reply 192.168.4.33 is-at 00:1d:6e:9b:ee:0d
00:01:38.765838 arp who-has 192.168.4.138 tell 192.168.4.33
00:01:38.777496 arp reply 192.168.4.138 is-at 00:21:00:38:5e:d9
00:01:45.486572 arp who-has 192.168.4.34 tell 192.168.4.138
00:01:46.458496 arp who-has 192.168.4.34 tell 192.168.4.138

> +	if (on) {
> +		grp->filter_enable = cpu_to_le16(1);
> +		grp->num_address = cpu_to_le16(priv->mc_maclist_num);
> +		memcpy(grp->mac_list, priv->mc_maclist, sizeof(grp->mac_list));
> +	} else {
> +		grp->filter_enable = cpu_to_le16(0);
> +		grp->num_address = cpu_to_le16(0);
> +		memset(grp->mac_list, 0, sizeof(grp->mac_list));
> +	}

And the same (no filtering, although multicast filter was set) result for multicast messages:

(none):~# ./tcpdump -i wlan0 -nn -s0 -e icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:22:23.855499 00:21:00:38:5e:d9 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.0.1: ICMP echo request, id 11114, seq 1, length 64
00:22:24.856842 00:21:00:38:5e:d9 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.0.1: ICMP echo request, id 11114, seq 2, length 64
00:22:26.632324 00:21:00:38:5e:d9 > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.0.2: ICMP echo request, id 11370, seq 1, length 64
00:22:31.850555 00:21:00:38:5e:d9 > 01:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.1.1: ICMP echo request, id 13162, seq 1, length 64
00:22:32.846283 00:21:00:38:5e:d9 > 01:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.1.1: ICMP echo request, id 13162, seq 2, length 64
00:22:35.624542 00:21:00:38:5e:d9 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.1.1.1: ICMP echo request, id 13418, seq 1, length 64
00:22:36.624847 00:21:00:38:5e:d9 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.1.1.1: ICMP echo request, id 13418, seq 2, length 64
00:22:43.052642 00:21:00:38:5e:d9 > 01:00:5e:01:02:03, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 230.1.2.3: ICMP echo request, id 13674, seq 1, length 64
00:22:44.052764 00:21:00:38:5e:d9 > 01:00:5e:01:02:03, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 230.1.2.3: ICMP echo request, id 13674, seq 2, length 64

Do you have any other tests in mind that I could run?
By the way, I see that ARP filter does not apply to the station in IBSS or mesh mode. Is that intended?

Thanks.
-- Max

Re: [RFT] p54: implement multicast + arp req PS filter

[Christian Lamparter]

Hello,

On Friday 08 April 2011 01:28:52 Max Filippov wrote:
> I used for tests the following cell:
> 
> wlan1     Scan completed :
>           Cell 01 - Address: 00:22:15:1C:09:D1
>                     Channel:11
>                     Frequency:2.462 GHz (Channel 11)
>                     Quality=67/70  Signal level=-43 dBm  
>                     Encryption key:on
>                     ESSID:"test"
>	[...]
> Is it suitable?
certainly, in fact any configuration should do.

> I guess that to do e.g. ARP filtering firmware must
> be able to decipher incoming packets.
> How can I make sure that it does?
As long as the module parameter nohwcrypt is left untouched, 
the firmware should be able to decipher incoming frame on
its own. [we setup the rxkeys in p54_set_key]

> So, I associated with that AP and obtained an IP address.
Just a question, that popped into my head: "Have you enabled PS?
either with "iw dev wlanX set power_save on" or
?iwconfig wlanX power on?, because the filters may be restricted
to PSM.

> Regarding ARP filtering I tried the following test:
> - ping station from the outside to see if ARPs for its IP pass through;
> - ping non-existing IP in the same network from the outside to see
>   if other ARPs pass through.
> 
> To test multicast filtering I tried to ping several multicast addresses
> from the outside.
sounds about right. 

> I see that although ARP filter was set (I added printfs to both
> branches above), all ARP requests pass through:
 
> (none):~# ./tcpdump -i wlan0 -nn -s0 arp
hmm, what about "-p"? I think that the interface should not be in
promisc mode since it might change the result.
 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 00:01:33.715332 arp who-has 192.168.4.33 tell 192.168.4.138
> 00:01:33.716644 arp reply 192.168.4.33 is-at 00:1d:6e:9b:ee:0d
>
> (none):~# ./tcpdump -i wlan0 -nn -s0 -e icmp
on a second thought, maybe we should take tcpdump out of
the equation all together and dump the raw data coming
from the device when PSM is enabled.

(for my usb device, I've used usbmon. But I don't know
if there's something similar for spi/sdio?)
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 00:22:23.855499 00:21:00:38:5e:d9 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.0.1: ICMP echo request, id 11114, seq 1, length 64
> 00:22:24.856842 00:21:00:38:5e:d9 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.4.138 > 224.0.0.1: ICMP echo request, id 11114, seq 2, length 64

> Do you have any other tests in mind that I could run?
> By the way, I see that ARP filter does not apply to the station
> in IBSS or mesh mode. Is that intended?
Really? No that's not intended, is this a shortcoming of the driver or
of the stack?

Regards,
	Christian

Re: [RFT] p54: implement multicast + arp req PS filter

[Max Filippov]

Hello.

> > So, I associated with that AP and obtained an IP address.
> Just a question, that popped into my head: "Have you enabled PS?
> either with "iw dev wlanX set power_save on" or
> ?iwconfig wlanX power on?, because the filters may be restricted
> to PSM.

I hadn't. LMAC API doc doesn't say that they're related.
This time I ran tests both with "iwconfig wlan0 power on" and without it.
Looks like PSM only makes kernel print "wlan0: detected beacon loss from AP - sending probe request".
I see no other effect.

> > I see that although ARP filter was set (I added printfs to both
> > branches above), all ARP requests pass through:
>  
> > (none):~# ./tcpdump -i wlan0 -nn -s0 arp
> hmm, what about "-p"? I think that the interface should not be in
> promisc mode since it might change the result.

My bad ):
So, I re-tested both cases with tcpdump -p.

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.

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.

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.

> on a second thought, maybe we should take tcpdump out of
> the equation all together and dump the raw data coming
> from the device when PSM is enabled.

Ok, I'm probably going to printk those raw packets to see what's going on with ARPs with and without traffic, if it makes sense. 

> > By the way, I see that ARP filter does not apply to the station
> > in IBSS or mesh mode. Is that intended?
> Really? No that's not intended, is this a shortcoming of the driver or
> of the stack?

I've found a comment in ieee80211_ifa_changed saying that ARP filtering is only supported in managed mode.

Thanks.
-- Max

Re: [RFT] p54: implement multicast + arp req PS filter

[Christian Lamparter]

On Saturday 09 April 2011 22:23:51 Max Filippov wrote:
>>> So, I associated with that AP and obtained an IP address.
>> Just a question, that popped into my head: "Have you enabled PS?
>> either with "iw dev wlanX set power_save on" or
>> ?iwconfig wlanX power on?, because the filters may be restricted
>> to PSM.
> 
> I hadn't. LMAC API doc doesn't say that they're related.
> This time I ran tests both with "iwconfig wlan0 power on"
> and without it. Looks like PSM only makes kernel print
> "wlan0: detected beacon loss from AP - sending probe request".
> I see no other effect.
Well, that settles that.

>>[..]
> 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?

or apply:

http://www.spinics.net/lists/linux-wireless/msg65488.html
(this patch makes the psm less aggressive by only sleeping
for one beacon interval at most [instead of listen_interval = 5]).

> 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.

> 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?
 
Thanks,
	Christian

Re: [RFT] p54: implement multicast + arp req PS filter

[Max Filippov]

> > 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

Re: [RFT] p54: implement multicast + arp req PS filter

[Christian Lamparter]

On Sunday 10 April 2011 01:34:21 Max Filippov wrote:
> > > 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.
ok. but still there's something positive about the result:
	ps no longer breaks everything ;)
	[Michael]

> 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 for ff:ff:ff:ff:ff:ff.
> 
> But currently that cancels ARP filtering completely.

Ok, so we can't have both [atm] and we can't really choose between them either.
Or do you think it's worth salvaging the multicast filter for a [PATCH]?
> > > 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" ?
yeah, it was a while ago... 
"p54spi (STLC4560) with Marvel XScale CPU (kernel 2.6.25.4)"
http://www.spinics.net/lists/linux-wireless/msg55967.html

AFAIK they have another p54spi firmware
"phy0: FW rev 2.19.0.0.A.14 Private - Softmac protocol 5.6"

Regards,
	Chr

Re: [RFT] p54: implement multicast + arp req PS filter

[Max Filippov]

> > > > 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 for ff:ff:ff:ff:ff:ff.
> > 
> > But currently that cancels ARP filtering completely.
> 
> Ok, so we can't have both [atm] and we can't really choose between them either.
> Or do you think it's worth salvaging the multicast filter for a [PATCH]?

Well, multicast filtering appears to work good with that additional broadcast entry. So, why not.

> > > 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" ?
> yeah, it was a while ago... 
> "p54spi (STLC4560) with Marvel XScale CPU (kernel 2.6.25.4)"
> http://www.spinics.net/lists/linux-wireless/msg55967.html
> 
> AFAIK they have another p54spi firmware
> "phy0: FW rev 2.19.0.0.A.14 Private - Softmac protocol 5.6"

Ok, I'll try to test it with firmware images other than nokia's native.

Thanks.
-- Max

Re: [RFT] p54: implement multicast + arp req PS filter

[Max Filippov]

Hello, Christian.

> > > "sagred stuff" ?
> > yeah, it was a while ago... 
> > "p54spi (STLC4560) with Marvel XScale CPU (kernel 2.6.25.4)"
> > http://www.spinics.net/lists/linux-wireless/msg55967.html
> > 
> > AFAIK they have another p54spi firmware
> > "phy0: FW rev 2.19.0.0.A.14 Private - Softmac protocol 5.6"
> 
> Ok, I'll try to test it with firmware images other than nokia's native.

The results are the following:

2.19.0.0.A.14 -- ARP and multicast filters are completely ignored in both normal mode and PSM.
2.13.12.0.a.5.2 -- ARP and multicast filters are completely ignored in both normal mode and PSM.
2.13.0.0.a.23 -- ARP and multicast filters are completely ignored in both normal mode and PSM.
2.13.0.0.a.22.0 -- same as with nokia's native
2.13.0.0.a.13.14 -- ARP and multicast filters are completely ignored in both normal mode and PSM.

Thanks.
-- Max

Re: [RFT] p54: implement multicast + arp req PS filter

[Christian Lamparter]

On Wednesday 13 April 2011 23:48:54 Max Filippov wrote:
> Hello, Christian.
> 
> > > > "sagred stuff" ?
> > > yeah, it was a while ago... 
> > > "p54spi (STLC4560) with Marvel XScale CPU (kernel 2.6.25.4)"
> > > http://www.spinics.net/lists/linux-wireless/msg55967.html
> > > 
> > > AFAIK they have another p54spi firmware
> > > "phy0: FW rev 2.19.0.0.A.14 Private - Softmac protocol 5.6"
> > 
> > Ok, I'll try to test it with firmware images other than nokia's native.
> 
> The results are the following:
> 
> 2.19.0.0.A.14 -- ARP and multicast filters are completely ignored in both normal mode and PSM.
> 2.13.12.0.a.5.2 -- ARP and multicast filters are completely ignored in both normal mode and PSM.
> 2.13.0.0.a.23 -- ARP and multicast filters are completely ignored in both normal mode and PSM.
> 2.13.0.0.a.22.0 -- same as with nokia's native
> 2.13.0.0.a.13.14 -- ARP and multicast filters are completely ignored in both normal mode and PSM.

thanks,

so the sagrad firmwares do work on the n8xx? Maybe it would be a good idea
to send them over to maxi@daemonizer.de. Do you still have the binaries?

Regards,
	Chr

Re: [RFT] p54: implement multicast + arp req PS filter

[Max Filippov]

> so the sagrad firmwares do work on the n8xx? Maybe it would be a good idea
> to send them over to maxi@daemonizer.de. Do you still have the binaries?

I didn't run any performance/stability tests, just basic sanity. To that extent they all work.
And I got the same idea regarding nokia's native and sagrad firmware blobs.

Thanks.
-- Max