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>
In-Reply-To: <3ceecfc1-ab04-7d54-51bd-457a4708c0ac@gmail.com>
From:   Artem Makhutov <artem.makhutov@gmail.com>
Date:   Thu, 20 Apr 2023 18:12:16 +0200
Message-ID: <CALbLcfCpb8xbN+w2VvCZ6Gdr+L_ECH0UQsWZrpO1Hcpoef66UQ@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,

Am Do., 20. Apr. 2023 um 17:33 Uhr schrieb Bitterblue Smith
<rtl8821cerfe2@gmail.com>:
>
> On 20/04/2023 14:40, Artem Makhutov wrote:
> > Hi,
> >
> > I think that I have found the problem: It happens when rx_desc->rxht
> > == 1 - then the urb is 4 bytes shorter...
> >
>
> That's very interesting. So it has a problem with MCS rates
>
> According to Johannes Berg, the 8 bytes at the end of the working ping
> are the MIC, which mac80211 will strip. Of course mac80211 doesn't know
> that rtl8xxxu sometimes receives 4 bytes fewer.

The strange thing is that this issue does not appear with another
Logilink WL0151 connected to my home network... Here the MCS rates
work fine and I am always getting the full 8 bytes.

> What kind of encryption does the network have? Is it possible to try
> without any encryption?

It uses WPA1 + WPA2 right now. Before that we had WPA2 only and it was
exactly the same.
I also did a test without encryption before. As far as I remember I
was able to send larger packets, but the issue was still there.
I will redo the test without encryption to double check it.

> Another thing to try is software crypto, using this tested patch and
> the module parameter debug=0x8000:

Just tried it out. There was no change at all.

Any ideas?