* [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
@ 2013-10-28 23:28 Larry Finger
2013-10-29 0:07 ` Ben Hutchings
0 siblings, 1 reply; 4+ messages in thread
From: Larry Finger @ 2013-10-28 23:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Mark Cave-Ayland, netdev, Larry Finger, Stable
From: Mark Cave-Ayland <mark.cave-ayland@ilande•co.uk>
All of the rtlwifi drivers have an error in the routine that tests if
the received data is "special". The 16-bit quantity is big-endian, but
was being extracted in native CPU mode. One of the effects of this bug
is to inhibit association under some conditions.
A statement that would have made the code correct had been changed to
a comment. Rather than just reinstating that code, the fix here passes
sparse tests.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger•net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande•co.uk>
Cc: Stable <stable@vger•kernel.org> [2.6.38+]
---
drivers/net/wireless/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 9a78e3d..1efde7f 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
SNAP_SIZE + PROTOC_TYPE_SIZE);
- ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
- /* ether_type = ntohs(ether_type); */
+ ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
+ SNAP_SIZE));
if (ETH_P_IP == ether_type) {
if (IPPROTO_UDP == ip->protocol) {
--
1.8.4
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
2013-10-28 23:28 [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type Larry Finger
@ 2013-10-29 0:07 ` Ben Hutchings
2013-10-29 14:27 ` Bjørn Mork
0 siblings, 1 reply; 4+ messages in thread
From: Ben Hutchings @ 2013-10-29 0:07 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, Mark Cave-Ayland, netdev, Stable
On Mon, 2013-10-28 at 18:28 -0500, Larry Finger wrote:
> From: Mark Cave-Ayland <mark.cave-ayland@ilande•co.uk>
>
> All of the rtlwifi drivers have an error in the routine that tests if
> the received data is "special". The 16-bit quantity is big-endian, but
> was being extracted in native CPU mode. One of the effects of this bug
> is to inhibit association under some conditions.
>
> A statement that would have made the code correct had been changed to
> a comment. Rather than just reinstating that code, the fix here passes
> sparse tests.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger•net>
> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande•co.uk>
> Cc: Stable <stable@vger•kernel.org> [2.6.38+]
> ---
> drivers/net/wireless/rtlwifi/base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
> index 9a78e3d..1efde7f 100644
> --- a/drivers/net/wireless/rtlwifi/base.c
> +++ b/drivers/net/wireless/rtlwifi/base.c
> @@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
>
> ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
> SNAP_SIZE + PROTOC_TYPE_SIZE);
> - ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
> - /* ether_type = ntohs(ether_type); */
> + ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
> + SNAP_SIZE));
>
> if (ETH_P_IP == ether_type) {
> if (IPPROTO_UDP == ip->protocol) {
This crazy function also says that *all* IPv6 frames are special, which
apparently means that on TX they should get sent at the lowest possible
bit rate. So I think this is going to cause a regression for IPv6
throughput unless you remove that case.
The DHCP case is also not validating IP and UDP header lengths against
the packet length, though this may be harmless in practice.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
2013-10-29 0:07 ` Ben Hutchings
@ 2013-10-29 14:27 ` Bjørn Mork
2013-10-29 20:16 ` Larry Finger
0 siblings, 1 reply; 4+ messages in thread
From: Bjørn Mork @ 2013-10-29 14:27 UTC (permalink / raw)
To: Ben Hutchings
Cc: Larry Finger, linville, linux-wireless, Mark Cave-Ayland, netdev,
Stable
Ben Hutchings <bhutchings@solarflare•com> writes:
>> @@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
>>
>> ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
>> SNAP_SIZE + PROTOC_TYPE_SIZE);
>> - ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
>> - /* ether_type = ntohs(ether_type); */
>> + ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
>> + SNAP_SIZE));
>>
>> if (ETH_P_IP == ether_type) {
>> if (IPPROTO_UDP == ip->protocol) {
>
> This crazy function also says that *all* IPv6 frames are special, which
> apparently means that on TX they should get sent at the lowest possible
> bit rate. So I think this is going to cause a regression for IPv6
> throughput unless you remove that case.
>
> The DHCP case is also not validating IP and UDP header lengths against
> the packet length, though this may be harmless in practice.
It's not validating the upper 8 bits of the port numbers either, so it
will hit random UDP traffic in addition to DHCP.
But it was good to see this function now. I was wondering how to support
some buggy 3G modem firmware without ugly hacks. Seems there will always
be worse hacks in drivers/net, no matter what I do :-)
Bjørn
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
2013-10-29 14:27 ` Bjørn Mork
@ 2013-10-29 20:16 ` Larry Finger
0 siblings, 0 replies; 4+ messages in thread
From: Larry Finger @ 2013-10-29 20:16 UTC (permalink / raw)
To: Bjørn Mork, Ben Hutchings
Cc: linville, linux-wireless, Mark Cave-Ayland, netdev, Stable
On 10/29/2013 09:27 AM, Bjørn Mork wrote:
>
> It's not validating the upper 8 bits of the port numbers either, so it
> will hit random UDP traffic in addition to DHCP.
>
> But it was good to see this function now. I was wondering how to support
> some buggy 3G modem firmware without ugly hacks. Seems there will always
> be worse hacks in drivers/net, no matter what I do :-)
I'm happy that Realtek and I could make your day. The next version is checking
the full 16-bit port numbers.
Thanks,
Larry
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-29 20:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-28 23:28 [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type Larry Finger
2013-10-29 0:07 ` Ben Hutchings
2013-10-29 14:27 ` Bjørn Mork
2013-10-29 20:16 ` Larry Finger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox