Re: PROBLEM: rtlwifi drops most IPv6 packets

[Larry Finger <Larry.Finger@lwfinger.net>]

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

On 02/17/2015 02:29 AM, Alan Fisher wrote:
> Larry,
>
>> I am guessing that you have an RTL8188CE, which uses rtl8192ce.
>
> Yep, my wireless card is an RTL8188CE
>
>> The purpose of rtl_is_special_data() is to ensure that management packets have
>> the highest probability of being successfully transmitted by sending them at a
>> low rate.
> ...
>> It also occurs to me that mac80211 probably handles this function, and that it
>> may be possible to remove this routine, which is essentially what your
>> workaround does.
> I couldn't find any information on mac80211 treating certain packets (ARP, DHCP,
> etc...) as special. It does seem to handle automatic rate selection, though. I
> would think that would be enough to handle packet loss reasonably well. I
> believe the protocols tested for here all have mechanisms for handling lost
> packets. I also can't find any other 802.11 drivers which try to handle DHCP
> packets in a special way. I think it would be safe to remove this routine. I
> have a patch to do that, if you're okay with that change.

The story is a bit more complicated. These drivers use firmware rate selection, 
not the ones in mac80211. At this point, I would not be comfortable with 
removing the entire routine.
>
> Regarding the patch, this change:
>
> -    } else if (0x86DD == ether_type) {
> -        return true;
>       }
>
> successfully prevents IPv6 packets from being treated as special (and thus
> dropped).
>
> However, this:
> +    if (ETH_P_IP == ether_type || ETH_P_IPV6 == ether_type) {
>           ip = (struct iphdr *)((u8 *)skb->data + offset +
>
> seems to be reading an IPv4 header (struct iphdr) from an IPv6 packet. I believe
> a struct ipv6hdr should be used here.

You are correct. My patch was prepared too hastily.

> If we are to continue handling certain types of packets differently, IPv6
> neighbor solicitation messages (like ARP in IPv4) and IPv6 router discovery
> messages (stateless IPv6 autoconfig, similar to DHCP in IPv4 networks) should
> probably be added to the list to maintain consistency with what is being handled
> for IPv4. These are both variants of ICMPv6 packets, although generally
> transmitting all ICMPv6 packets at the lowest rate is probably a bad idea, as
> ICMP echo is commonly used to measure network performance and should be treated
> the same as normal traffic.

For the moment, I think we need to return false, not true, for all IPv6 packets 
until a more complete solution is found. Does the attached patch fix the problem 
you are seeing? I do not have an IPv6 compliant ISP, thus I cannot do much testing.

Larry



[-- Attachment #2: modify_is_special_data --]
[-- Type: text/plain, Size: 572 bytes --]

Index: wireless-drivers-next/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-drivers-next.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-drivers-next/drivers/net/wireless/rtlwifi/base.c
@@ -1386,8 +1386,11 @@ u8 rtl_is_special_data(struct ieee80211_
 		}
 
 		return true;
-	} else if (0x86DD == ether_type) {
-		return true;
+	} else if (ETH_P_IPV6 == ether_type) {
+		/* TODO: Handle any IPv6 cases that need special handling.
+		 * For now, always return false
+		 */
+		goto end;
 	}
 
 end: