On Wed, Dec 12, 2012 at 1:15 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> 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?
Good point. I mistook that for the Ethernet addr1. Moreover, looking
at the packet capture, this is a "from DS to STA" frame, which implies
I compeltely mistook where this frame originated from (either that or
something much stranger is happening). Needless to say, I should look
a lot more closely at this before presuming that the problem lies
here.
--
Paul
>
> 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
