Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CALbLcfAXrHp4vsVGqU0nBdB_gFmKTKx0GcdrFJA7R_kodAy0Ew@mail.gmail.com>
 <bfe732f4-60dd-4d78-1259-5f9f6c11adbc@gmail.com> <CALbLcfB7cMctHC-Fv93z1WVCZkQ76uW2F_=P6rCW7ZSPXvmapw@mail.gmail.com>
 <2857f998-1b1a-e3c2-20fe-d03dadcf8f23@gmail.com> <CALbLcfCsyGzhvrqjSz37+7cLvc3rc4Y_kgspZV=kiPNs4TBE4w@mail.gmail.com>
 <CALbLcfBnF6njFMSfQk2TuOiZ3C3kHwqs4-c-MQGb72azzQ5sJA@mail.gmail.com>
 <38172c8e-d107-d96e-7292-09d0e3b061dd@gmail.com> <CALbLcfCHLU+zoFdTnTrJs22UUYwr2rETp5hqbv=NL352Qz-XgA@mail.gmail.com>
 <CALbLcfDZJmOyn-Gf24+9X-eHh3-3PY4_nP5soG3gHf_Vn85=EA@mail.gmail.com>
 <CALbLcfAiVgGi9iocEG4OfgET2XLDRq0dthbxDMP0vP3R6BBp_A@mail.gmail.com>
 <3ceecfc1-ab04-7d54-51bd-457a4708c0ac@gmail.com> <CALbLcfCpb8xbN+w2VvCZ6Gdr+L_ECH0UQsWZrpO1Hcpoef66UQ@mail.gmail.com>
 <8eaeb64e-3f7f-6752-4476-c0f0c88a008b@gmail.com> <CALbLcfD7AmMG72-Qxafc9533OQVBCL=RLDycjUCV2MJ0DRN6nw@mail.gmail.com>
 <2a679614-c964-dc3f-c987-6c7ee03923a0@gmail.com>
In-Reply-To: <2a679614-c964-dc3f-c987-6c7ee03923a0@gmail.com>
From:   Artem Makhutov <artem.makhutov@gmail.com>
Date:   Tue, 25 Apr 2023 11:04:20 +0200
Message-ID: <CALbLcfBGg8FTBZx-_8v6u5iLsAssr+=QgQYc+Q2bUbmEwJPRYQ@mail.gmail.com>
Subject: Re: RTL8188EU (LogiLink WL0151A) - Malformed packets
To:     Bitterblue Smith <rtl8821cerfe2@gmail.com>
Cc:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

> > As a workaround: What about checking the IP length field. If the
> > received packet is smaller by 4 bytes than what it should be then just
> > add extra 4 bytes at the end? Or does the MIC at the end have any
> > influence on anything?
>
> That should work, but it's ugly.

I did it and it is working, and yes, it is ugly :)

> If the router lets you change the MTU, does it help to make it smaller?

No, this is a bad idea. It will bring a lot of other issues.

> Do you have the problem with the v5.13.3 driver? If it works (other
> than completely dying after a while) we should see what it does
> differently compared to the v5.2.2.4 driver.

The v5.13.3 does not have this problem.

I have tested 3 different approaches and also made some quick speed tests:

1: I changed the skb length according the IP header so the packet is complete
2: Disabled ht by sband->ht_cap.ht_supported = false;
3: Tested v5.13.3 driver

Speedtests with iperf:
IP header hack:
24.5 Mbits/sec

HT hack:
18.7 Mbits/sec

v5.13.3 driver:
54.6 Mbits/sec

The v5.13.3 driver has the highest speed and does not have the missing
bytes bug. So it does something different...