On Wed, 2012-12-12 at 13:08 -0800, Paul Stewart wrote:
> The "unauthorized port" test in ieee80211_subif_start_xmit reads as follows:
>
> /*
> * Drop unicast frames to unauthorised stations unless they are
> * EAPOL frames from the local station.
> */
> if (unlikely(!ieee80211_vif_is_mesh(&sdata->vif) &&
> !is_multicast_ether_addr(hdr.addr1) && !authorized &&
> (cpu_to_be16(ethertype) != sdata->control_port_protocol ||
> !ether_addr_equal(sdata->vif.addr, skb->data + ETH_ALEN)))
> ) {
> #ifdef CONFIG_MAC80211_VERBOSE_DEBUG
> net_info_ratelimited("%s: dropped frame to %pM (unauthorized por
> t)\n",
> dev->name, hdr.addr1);
> #endif
>
> [...]
>
> Was it explicitly meant to allow multicast/broadcast frames while not
> authorized? I'm starting to see isolated cases in packet traces where
> APs deauth clients due to errant broadcasts being sent during/before
> the 4-way handshake, after association. Are there situations where
> these broadcasts / multicasts should be allowed, or would it be
> acceptable to drop the multicast check? The change which introduced
> it is
> 7d185b8bb17eac9e9d673eb483ded0fbf0b28b97, but I don't quite understand
> it since if we're not authenticated to the AP, should we still be
> allowed to send (non-authentication) traffic to it?
That commit was meant for AP mode, and in managed mode hdr.addr1 should
never be a multicast address. Any idea how that happens?
johannes
--
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
