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?
--
Paul
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
On Wed, 2012-12-12 at 14:09 -0800, Paul Stewart wrote:
> > 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).
That seems like it's just an (unrelated) broadcast frame from somebody
else, I'd imagine if it was yours the AP wouldn't first retransmit it
and then deauth you.
johannes
On Wed, Dec 12, 2012 at 1:15 PM, Johannes Berg
<[email protected]> 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
>