Skip to contentSkip to conversation

Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

DISCUSSION Felix Fietkau 4 participants 5 messages May 1, 2013 – May 2, 2013 5 messages not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Felix Fietkau

author
#0 lore raw

Hi,

commit 576eb62598f10c8c7fd75703fe89010cdcfff596

Author: stephen hemminger <[email protected]>
Date:   Fri Dec 28 18:15:22 2012 +0000

bridge: respect RFC2863 operational state

This commit breaks putting a mac80211 4-address client mode interface in a bridge and using it with WPA encryption.

wpa_supplicant has to receive EAP frames for authentication from the bridge interface, since the rx handler hook steals them from the wireless interface. However, it also keeps the interface operstate to IF_OPER_DORMANT for as long as the WPA handshake is incomplete, which causes the bridge code to drop EAP packets.

In the long run, I'd like to sort out this mess by passing EAP frames to userspace via nl80211 - but since that will require userspace changes, what do we do about this issue in the mean time?

- Felix

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 4 lines · Felix Fietkau

In the long run, I'd like to sort out this mess by passing EAP frames to userspace via nl80211 - but since that will require userspace changes, what do we do about this issue in the mean time?

One quick solution i can think of is:

Temporarily we can make the interface UP as soon as we are associated and then drop the data packets except for EAPOL-KEY (ETH_H_PAE) frames in the mac80211.

ieee80211_frame_allowed has a rule to drops the unencrypted data frames we just need to add a rule to drop encrypted data frames.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): CAOaVG179Rx_JfV99mbjWhwQTALb5gh+2_WVFWDSbngA0qkzoGw@mail.gmail.com

A message that is not in the archive (sent off-list or not yet received): CAOaVG179Rx_JfV99mbjWhwQTALb5gh+2_WVFWDSbngA0qkzoGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#5 lore raw
Quoted 2 lines · Stephen Hemminger

What about using AF_PACKET bound to underlying wireless device and the packet type. You can even use BPF to filter.

As far as I know, AF_PACKET only works when not binding it to the packet type (otherwise it get stolen by the rx handler).
Not binding it to the packet type and using BPF to filter is expensive on small embedded devices with small caches. Still, this requires userspace changes, so we need a different solution.

Quoted 2 lines

Another alternative would be to have bridge accept control frames on dormant device but not send.

Sounds good, will you send a patch for that?

- Felix

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw
Quoted 5 lines · On Wed, 01 May 2013 23:06:16 +0200 Felix Fietkau…
Quoted 2 lines · Stephen Hemminger

What about using AF_PACKET bound to underlying wireless device and the packet type. You can even use BPF to filter.

As far as I know, AF_PACKET only works when not binding it to the packet type (otherwise it get stolen by the rx handler).

You can do AF_PACKET and it gets handle before rx_handler.

Quoted 10 lines

Not binding it to the packet type and using BPF to filter is expensive on small embedded devices with small caches. Still, this requires userspace changes, so we need a different solution.

Quoted 2 lines

Another alternative would be to have bridge accept control frames on dormant device but not send.

Sounds good, will you send a patch for that?

- Felix

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20130501154904.0ea31991-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org

#9 lore raw
Quoted 10 lines · Stephen Hemminger
Quoted 5 lines · On Wed, 01 May 2013 23:06:16 +0200 Felix Fietkau…
Quoted 2 lines · Stephen Hemminger

What about using AF_PACKET bound to underlying wireless device and the packet type. You can even use BPF to filter.

As far as I know, AF_PACKET only works when not binding it to the packet type (otherwise it get stolen by the rx handler).

You can do AF_PACKET and it gets handle before rx_handler.

If I don't bind it to a protocol, it ends up in ptype_all, if I do, it ends up in &ptype_base. ptype_all is processed before the rx_handler, ptype_base is processed after the rx handler.
Hooking into ptype_all wastes tons of CPU cycles, hooking into ptype_base does not solve the problem.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html