diff mbox series

[v5] wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port

Message ID 20221104163339.227432-1-marex@denx.de
State New
Headers show
Series [v5] wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port | expand

Commit Message

Marek Vasut Nov. 4, 2022, 4:33 p.m. UTC
When using wpa_supplicant v2.10, this driver is no longer able to
associate with any AP and fails in the EAPOL 4-way handshake while
sending the 2/4 message to the AP. The problem is not present in
wpa_supplicant v2.9 or older. The problem stems from HostAP commit
144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available")
which changes the way EAPOL frames are sent, from them being send
at L2 frames to them being sent via nl80211 control port.

An EAPOL frame sent as L2 frame is passed to the WiFi driver with
skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control
port has skb->protocol set to ETH_P_802_3 . The later happens in
ieee80211_tx_control_port(), where the EAPOL frame is encapsulated
into 802.3 frame.

The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority
frames and sends them via highest-priority transmit queue, while
the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way
handshake frames must be sent as highest-priority, otherwise the
4-way handshake times out.

Therefore, to fix this problem, inspect the skb control flags and
if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is
an EAPOL frame and transmit the frame via high-priority queue just
like other ETH_P_PAE frames.

Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements")
Signed-off-by: Marek Vasut <marex@denx.de>
---
NOTE: I am really unsure about the method of finding out the exact
      place of ethernet header in the encapsulated packet and then
      extracting the ethertype from it. Is there maybe some sort of
      helper function for that purpose ?
---
V2: - Turn the duplicated code into common function
V3: - Simplify the TX EAPOL detection (Johannes)
V4: - Drop the double !!() from test
    - Update commit message
V5: - Inline the rsi_is_tx_eapol() again, undoes V2 change completely
---
Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
Cc: Angus Ainslie <angus@akkea.ca>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: Martin Fuzzey <martin.fuzzey@flowbird.group>
Cc: Martin Kepplinger <martink@posteo.de>
Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Cc: Siva Rebbagondla <siva8118@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 drivers/net/wireless/rsi/rsi_91x_core.c | 4 +++-
 drivers/net/wireless/rsi/rsi_91x_hal.c  | 6 +++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

Comments

Kalle Valo Nov. 7, 2022, 12:37 p.m. UTC | #1
Marek Vasut <marex@denx.de> writes:

> When using wpa_supplicant v2.10, this driver is no longer able to
> associate with any AP and fails in the EAPOL 4-way handshake while
> sending the 2/4 message to the AP. The problem is not present in
> wpa_supplicant v2.9 or older. The problem stems from HostAP commit
> 144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available")
> which changes the way EAPOL frames are sent, from them being send
> at L2 frames to them being sent via nl80211 control port.
>
> An EAPOL frame sent as L2 frame is passed to the WiFi driver with
> skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control
> port has skb->protocol set to ETH_P_802_3 . The later happens in
> ieee80211_tx_control_port(), where the EAPOL frame is encapsulated
> into 802.3 frame.
>
> The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority
> frames and sends them via highest-priority transmit queue, while
> the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way
> handshake frames must be sent as highest-priority, otherwise the
> 4-way handshake times out.
>
> Therefore, to fix this problem, inspect the skb control flags and
> if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is
> an EAPOL frame and transmit the frame via high-priority queue just
> like other ETH_P_PAE frames.
>
> Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements")
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> NOTE: I am really unsure about the method of finding out the exact
>       place of ethernet header in the encapsulated packet and then
>       extracting the ethertype from it. Is there maybe some sort of
>       helper function for that purpose ?
> ---
> V2: - Turn the duplicated code into common function
> V3: - Simplify the TX EAPOL detection (Johannes)
> V4: - Drop the double !!() from test
>     - Update commit message
> V5: - Inline the rsi_is_tx_eapol() again, undoes V2 change completely

BTW did you test this on a real device?
Marek Vasut Nov. 7, 2022, 1:23 p.m. UTC | #2
On 11/7/22 13:37, Kalle Valo wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> When using wpa_supplicant v2.10, this driver is no longer able to
>> associate with any AP and fails in the EAPOL 4-way handshake while
>> sending the 2/4 message to the AP. The problem is not present in
>> wpa_supplicant v2.9 or older. The problem stems from HostAP commit
>> 144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available")
>> which changes the way EAPOL frames are sent, from them being send
>> at L2 frames to them being sent via nl80211 control port.
>>
>> An EAPOL frame sent as L2 frame is passed to the WiFi driver with
>> skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control
>> port has skb->protocol set to ETH_P_802_3 . The later happens in
>> ieee80211_tx_control_port(), where the EAPOL frame is encapsulated
>> into 802.3 frame.
>>
>> The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority
>> frames and sends them via highest-priority transmit queue, while
>> the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way
>> handshake frames must be sent as highest-priority, otherwise the
>> 4-way handshake times out.
>>
>> Therefore, to fix this problem, inspect the skb control flags and
>> if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is
>> an EAPOL frame and transmit the frame via high-priority queue just
>> like other ETH_P_PAE frames.
>>
>> Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements")
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> ---
>> NOTE: I am really unsure about the method of finding out the exact
>>        place of ethernet header in the encapsulated packet and then
>>        extracting the ethertype from it. Is there maybe some sort of
>>        helper function for that purpose ?
>> ---
>> V2: - Turn the duplicated code into common function
>> V3: - Simplify the TX EAPOL detection (Johannes)
>> V4: - Drop the double !!() from test
>>      - Update commit message
>> V5: - Inline the rsi_is_tx_eapol() again, undoes V2 change completely
> 
> BTW did you test this on a real device?

Yes, SDIO RS9116 on next-20221104 and 5.10.153 .

What prompts this question ?
Kalle Valo Nov. 7, 2022, 1:54 p.m. UTC | #3
Marek Vasut <marex@denx.de> writes:

>> BTW did you test this on a real device?
>
> Yes, SDIO RS9116 on next-20221104 and 5.10.153 .

Very good, thanks.

> What prompts this question ?

I get too much "fixes" which have been nowhere near real hardware and
can break the driver instead of fixing anything, especially syzbot
patches have been notorious. So I have become cautious.
Marek Vasut Nov. 7, 2022, 2:44 p.m. UTC | #4
On 11/7/22 14:54, Kalle Valo wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>>> BTW did you test this on a real device?
>>
>> Yes, SDIO RS9116 on next-20221104 and 5.10.153 .
> 
> Very good, thanks.
> 
>> What prompts this question ?
> 
> I get too much "fixes" which have been nowhere near real hardware and
> can break the driver instead of fixing anything, especially syzbot
> patches have been notorious. So I have become cautious.

Ah, this is a real problem right here.

wpa-supplicant 2.9 from OE dunfell 3.1 works.
wpa-supplicant 2.10 from OE kirkstone 4.0 fails.

That's how I ran into this initially. My subsequent tests were with 
debian wpa-supplicant 2.9 and 2.10 packages, since that was easier, they 
(2.10 does, 2.9 does not) trigger the problem all the same.

I'm afraid this RSI driver is so poorly maintained and has so many bugs, 
that, there is little that can make it worse. The dealing I had with RSI 
has been ... long ... and very depressing. I tried to get documentation 
or anything which would help us fix the problems we have with this RSI 
driver ourselves, but RSI refused it all and suggested we instead use 
their downstream driver (I won't go into the quality of that). It seems 
RSI has little interest in maintaining the upstream driver, pity.

I've been tempted to flag this driver as BROKEN for a while, to prevent 
others from suffering with it. Until I send such a patch, you can expect 
real fixes coming from my end at least.
Martin Fuzzey Nov. 7, 2022, 4:50 p.m. UTC | #5
On Mon, 7 Nov 2022 at 15:44, Marek Vasut <marex@denx.de> wrote:
> I'm afraid this RSI driver is so poorly maintained and has so many bugs,
> that, there is little that can make it worse. The dealing I had with RSI
> has been ... long ... and very depressing. I tried to get documentation
> or anything which would help us fix the problems we have with this RSI
> driver ourselves, but RSI refused it all and suggested we instead use
> their downstream driver (I won't go into the quality of that). It seems
> RSI has little interest in maintaining the upstream driver, pity.
>

Yes I've had similar problems with RSI.

It seems things have gone downhill a lot since RSI was taken over by
Silabs and the people who wrote the driver initially left.
The last mainline patches from anyone at Redpine / Silabs seem to date
back to 2019.

But https://github.com/SiliconLabs/RS911X-nLink-OSD/blob/master/ReleaseNotes_OSD.pdf
 it still says in the latest (March 2022) version
"The contents of this driver will be submitted to kernel community
continuously" which does not seem to be the case.

> I've been tempted to flag this driver as BROKEN for a while, to prevent
> others from suffering with it. Until I send such a patch, you can expect
> real fixes coming from my end at least.

We still use it too but haven't run into the issue this patch
addresses as we are still on wpa supplicant 2.9
If we run into any more problems I'll try to fix and upstream but, due
to all the above, I have already recommended internally that we move
to other hardware for future devices.

Martin
Kalle Valo Nov. 8, 2022, 7:41 a.m. UTC | #6
Marek Vasut <marex@denx.de> wrote:

> When using wpa_supplicant v2.10, this driver is no longer able to
> associate with any AP and fails in the EAPOL 4-way handshake while
> sending the 2/4 message to the AP. The problem is not present in
> wpa_supplicant v2.9 or older. The problem stems from HostAP commit
> 144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available")
> which changes the way EAPOL frames are sent, from them being send
> at L2 frames to them being sent via nl80211 control port.
> 
> An EAPOL frame sent as L2 frame is passed to the WiFi driver with
> skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control
> port has skb->protocol set to ETH_P_802_3 . The later happens in
> ieee80211_tx_control_port(), where the EAPOL frame is encapsulated
> into 802.3 frame.
> 
> The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority
> frames and sends them via highest-priority transmit queue, while
> the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way
> handshake frames must be sent as highest-priority, otherwise the
> 4-way handshake times out.
> 
> Therefore, to fix this problem, inspect the skb control flags and
> if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is
> an EAPOL frame and transmit the frame via high-priority queue just
> like other ETH_P_PAE frames.
> 
> Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements")
> Signed-off-by: Marek Vasut <marex@denx.de>

Patch applied to wireless-next.git, thanks.

b8f6efccbb9d wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port
Kalle Valo Nov. 9, 2022, 4:20 p.m. UTC | #7
Marek Vasut <marex@denx.de> writes:

> On 11/7/22 14:54, Kalle Valo wrote:
>> Marek Vasut <marex@denx.de> writes:
>>
>>>> BTW did you test this on a real device?
>>>
>>> Yes, SDIO RS9116 on next-20221104 and 5.10.153 .
>>
>> Very good, thanks.
>>
>>> What prompts this question ?
>>
>> I get too much "fixes" which have been nowhere near real hardware and
>> can break the driver instead of fixing anything, especially syzbot
>> patches have been notorious. So I have become cautious.
>
> Ah, this is a real problem right here.
>
> wpa-supplicant 2.9 from OE dunfell 3.1 works.
> wpa-supplicant 2.10 from OE kirkstone 4.0 fails.
>
> That's how I ran into this initially. My subsequent tests were with
> debian wpa-supplicant 2.9 and 2.10 packages, since that was easier,
> they (2.10 does, 2.9 does not) trigger the problem all the same.
>
> I'm afraid this RSI driver is so poorly maintained and has so many
> bugs, that, there is little that can make it worse. The dealing I had
> with RSI has been ... long ... and very depressing. I tried to get
> documentation or anything which would help us fix the problems we have
> with this RSI driver ourselves, but RSI refused it all and suggested
> we instead use their downstream driver (I won't go into the quality of
> that). It seems RSI has little interest in maintaining the upstream
> driver, pity.
>
> I've been tempted to flag this driver as BROKEN for a while, to
> prevent others from suffering with it.

That's a pity indeed. Should we at least mark the driver as orphaned in
MAINTAINERS?

Or even better if you Marek would be willing to step up as the
maintainer? :)

> Until I send such a patch, you can expect real fixes coming from my
> end at least.

Great, thank you.
Marek Vasut Nov. 9, 2022, 6:17 p.m. UTC | #8
On 11/9/22 17:20, Kalle Valo wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> On 11/7/22 14:54, Kalle Valo wrote:
>>> Marek Vasut <marex@denx.de> writes:
>>>
>>>>> BTW did you test this on a real device?
>>>>
>>>> Yes, SDIO RS9116 on next-20221104 and 5.10.153 .
>>>
>>> Very good, thanks.
>>>
>>>> What prompts this question ?
>>>
>>> I get too much "fixes" which have been nowhere near real hardware and
>>> can break the driver instead of fixing anything, especially syzbot
>>> patches have been notorious. So I have become cautious.
>>
>> Ah, this is a real problem right here.
>>
>> wpa-supplicant 2.9 from OE dunfell 3.1 works.
>> wpa-supplicant 2.10 from OE kirkstone 4.0 fails.
>>
>> That's how I ran into this initially. My subsequent tests were with
>> debian wpa-supplicant 2.9 and 2.10 packages, since that was easier,
>> they (2.10 does, 2.9 does not) trigger the problem all the same.
>>
>> I'm afraid this RSI driver is so poorly maintained and has so many
>> bugs, that, there is little that can make it worse. The dealing I had
>> with RSI has been ... long ... and very depressing. I tried to get
>> documentation or anything which would help us fix the problems we have
>> with this RSI driver ourselves, but RSI refused it all and suggested
>> we instead use their downstream driver (I won't go into the quality of
>> that). It seems RSI has little interest in maintaining the upstream
>> driver, pity.
>>
>> I've been tempted to flag this driver as BROKEN for a while, to
>> prevent others from suffering with it.
> 
> That's a pity indeed. Should we at least mark the driver as orphaned in
> MAINTAINERS?
> 
> Or even better if you Marek would be willing to step up as the
> maintainer? :)

I think best mark it orphaned, to make it clear what the state of the 
driver really is.

If RSI was willing to provide documentation, or at least releases which 
are not 30k+/20k- single-all-in-one-commit dumps of code, or at least 
any help, I would consider it. But not like this.
Kalle Valo Nov. 10, 2022, 5:39 a.m. UTC | #9
Marek Vasut <marex@denx.de> writes:

> On 11/9/22 17:20, Kalle Valo wrote:
>> Marek Vasut <marex@denx.de> writes:
>>
>>> On 11/7/22 14:54, Kalle Valo wrote:
>>>> Marek Vasut <marex@denx.de> writes:
>>>>
>>>>>> BTW did you test this on a real device?
>>>>>
>>>>> Yes, SDIO RS9116 on next-20221104 and 5.10.153 .
>>>>
>>>> Very good, thanks.
>>>>
>>>>> What prompts this question ?
>>>>
>>>> I get too much "fixes" which have been nowhere near real hardware and
>>>> can break the driver instead of fixing anything, especially syzbot
>>>> patches have been notorious. So I have become cautious.
>>>
>>> Ah, this is a real problem right here.
>>>
>>> wpa-supplicant 2.9 from OE dunfell 3.1 works.
>>> wpa-supplicant 2.10 from OE kirkstone 4.0 fails.
>>>
>>> That's how I ran into this initially. My subsequent tests were with
>>> debian wpa-supplicant 2.9 and 2.10 packages, since that was easier,
>>> they (2.10 does, 2.9 does not) trigger the problem all the same.
>>>
>>> I'm afraid this RSI driver is so poorly maintained and has so many
>>> bugs, that, there is little that can make it worse. The dealing I had
>>> with RSI has been ... long ... and very depressing. I tried to get
>>> documentation or anything which would help us fix the problems we have
>>> with this RSI driver ourselves, but RSI refused it all and suggested
>>> we instead use their downstream driver (I won't go into the quality of
>>> that). It seems RSI has little interest in maintaining the upstream
>>> driver, pity.
>>>
>>> I've been tempted to flag this driver as BROKEN for a while, to
>>> prevent others from suffering with it.
>>
>> That's a pity indeed. Should we at least mark the driver as orphaned in
>> MAINTAINERS?
>>
>> Or even better if you Marek would be willing to step up as the
>> maintainer? :)
>
> I think best mark it orphaned, to make it clear what the state of the
> driver really is.
>
> If RSI was willing to provide documentation, or at least releases
> which are not 30k+/20k- single-all-in-one-commit dumps of code, or at
> least any help, I would consider it. But not like this.

Yeah, very understandable. So let's mark the driver orphaned then, can
someone send a patch?
Marek Vasut Nov. 13, 2022, 6:59 p.m. UTC | #10
On 11/10/22 06:39, Kalle Valo wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> On 11/9/22 17:20, Kalle Valo wrote:
>>> Marek Vasut <marex@denx.de> writes:
>>>
>>>> On 11/7/22 14:54, Kalle Valo wrote:
>>>>> Marek Vasut <marex@denx.de> writes:
>>>>>
>>>>>>> BTW did you test this on a real device?
>>>>>>
>>>>>> Yes, SDIO RS9116 on next-20221104 and 5.10.153 .
>>>>>
>>>>> Very good, thanks.
>>>>>
>>>>>> What prompts this question ?
>>>>>
>>>>> I get too much "fixes" which have been nowhere near real hardware and
>>>>> can break the driver instead of fixing anything, especially syzbot
>>>>> patches have been notorious. So I have become cautious.
>>>>
>>>> Ah, this is a real problem right here.
>>>>
>>>> wpa-supplicant 2.9 from OE dunfell 3.1 works.
>>>> wpa-supplicant 2.10 from OE kirkstone 4.0 fails.
>>>>
>>>> That's how I ran into this initially. My subsequent tests were with
>>>> debian wpa-supplicant 2.9 and 2.10 packages, since that was easier,
>>>> they (2.10 does, 2.9 does not) trigger the problem all the same.
>>>>
>>>> I'm afraid this RSI driver is so poorly maintained and has so many
>>>> bugs, that, there is little that can make it worse. The dealing I had
>>>> with RSI has been ... long ... and very depressing. I tried to get
>>>> documentation or anything which would help us fix the problems we have
>>>> with this RSI driver ourselves, but RSI refused it all and suggested
>>>> we instead use their downstream driver (I won't go into the quality of
>>>> that). It seems RSI has little interest in maintaining the upstream
>>>> driver, pity.
>>>>
>>>> I've been tempted to flag this driver as BROKEN for a while, to
>>>> prevent others from suffering with it.
>>>
>>> That's a pity indeed. Should we at least mark the driver as orphaned in
>>> MAINTAINERS?
>>>
>>> Or even better if you Marek would be willing to step up as the
>>> maintainer? :)
>>
>> I think best mark it orphaned, to make it clear what the state of the
>> driver really is.
>>
>> If RSI was willing to provide documentation, or at least releases
>> which are not 30k+/20k- single-all-in-one-commit dumps of code, or at
>> least any help, I would consider it. But not like this.
> 
> Yeah, very understandable. So let's mark the driver orphaned then, can
> someone send a patch?

Done
Kalle Valo Nov. 14, 2022, 12:57 p.m. UTC | #11
Marek Vasut <marex@denx.de> writes:

> On 11/10/22 06:39, Kalle Valo wrote:
>
>> Marek Vasut <marex@denx.de> writes:
>>
>>> On 11/9/22 17:20, Kalle Valo wrote:
>>>
>>>> That's a pity indeed. Should we at least mark the driver as orphaned in
>>>> MAINTAINERS?
>>>>
>>>> Or even better if you Marek would be willing to step up as the
>>>> maintainer? :)
>>>
>>> I think best mark it orphaned, to make it clear what the state of the
>>> driver really is.
>>>
>>> If RSI was willing to provide documentation, or at least releases
>>> which are not 30k+/20k- single-all-in-one-commit dumps of code, or at
>>> least any help, I would consider it. But not like this.
>>
>> Yeah, very understandable. So let's mark the driver orphaned then, can
>> someone send a patch?
>
> Done

Great, thank you very much.
diff mbox series

Patch

diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c b/drivers/net/wireless/rsi/rsi_91x_core.c
index 0f3a80f66b61c..ead4d4e043280 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -466,7 +466,9 @@  void rsi_core_xmit(struct rsi_common *common, struct sk_buff *skb)
 							      tid, 0);
 			}
 		}
-		if (skb->protocol == cpu_to_be16(ETH_P_PAE)) {
+
+		if (IEEE80211_SKB_CB(skb)->control.flags &
+		    IEEE80211_TX_CTRL_PORT_CTRL_PROTO) {
 			q_num = MGMT_SOFT_Q;
 			skb->priority = q_num;
 		}
diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c
index c61f83a7333b6..c7460fbba0142 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -162,12 +162,16 @@  int rsi_prepare_data_desc(struct rsi_common *common, struct sk_buff *skb)
 	u8 header_size;
 	u8 vap_id = 0;
 	u8 dword_align_bytes;
+	bool tx_eapol;
 	u16 seq_num;
 
 	info = IEEE80211_SKB_CB(skb);
 	vif = info->control.vif;
 	tx_params = (struct skb_info *)info->driver_data;
 
+	tx_eapol = IEEE80211_SKB_CB(skb)->control.flags &
+		   IEEE80211_TX_CTRL_PORT_CTRL_PROTO;
+
 	header_size = FRAME_DESC_SZ + sizeof(struct rsi_xtended_desc);
 	if (header_size > skb_headroom(skb)) {
 		rsi_dbg(ERR_ZONE, "%s: Unable to send pkt\n", __func__);
@@ -231,7 +235,7 @@  int rsi_prepare_data_desc(struct rsi_common *common, struct sk_buff *skb)
 		}
 	}
 
-	if (skb->protocol == cpu_to_be16(ETH_P_PAE)) {
+	if (tx_eapol) {
 		rsi_dbg(INFO_ZONE, "*** Tx EAPOL ***\n");
 
 		data_desc->frame_info = cpu_to_le16(RATE_INFO_ENABLE);